Wenn eine Fernbedienung einen Nutzen haben soll, dann hilft es nicht wenn 5 von 100 Tasten belegt sind.
Man hat jedoch bereits eine Out-of-the-box Grundfunktionalität auf welche man schrittweise aufbauen kann.
Ich habe bei mir auch sämtliche Tasten belegt, regelmäßig benutzte ich davon jedoch nur sehr wenige und so wird es vielen gehen.
Das man sie nachbelegen kann ist schön und gut, aber wenig hilfreich.
Bei lirc muss du sie auch erstmal belegen, genau davon handelt der Artikel den du gerade kommentierst.
Gängige Tasten von FB sind in X11 nicht vorgesehen.
Was im Einzelfall vollkommen egal ist ob die Taste welche mit "Prev.CH" auf der Fernbedienung beschriftet ist in X11 nun XF86Launch7 heißt. Die Taste wird einmal zur Applikation durchbelegt und fertig.
Damit mag man keinen Designpreis gewinnen, doch mit dem Aufbau einer Parallelinfrastruktur unter Zuhilfenahme mehrerer Daemons gewinnt man ihn auch nicht.
Die Bindung des Gerätes an Applikationen hast du missverstanden. Du willst wahrscheinlich nicht, das Buchstaben oder Zahlen einer Tastatur das gleiche bewirken wie Zahlen auf einer FB - hier kann T9 Buchstabeneingabe erwartet sein
Diese Funktionalität muss so und so auf Applikationsebene implementiert sein, in beiden Fällen.
Auf der anderen Seite kann man auch wieder fragen weshalb die Multimedia-Tasten einer Tastatur oder einer Maus völlig anders behandelt werden sollen als die selben Tasten einer Fernbedienung. Denn genau das macht lirc.
oder andersrum einfach Zahlenausgabe an die Appl. im Forkus, während die FB die Sender wechselt.
Was mit lirc auch nur so lange funktioniert, so lange du nur eine Applikation gestartet hast welche die Taste nutzt.
Ich stimme mit dir insofern überein, dass beides nicht die Optimallösung darstellt und du für beides keinen Preis gewinnen wirst. Bei beiden kannst du Vor- und Nachteile in speziellen Anwendungsfällen finden was in beiden Fällen den Großteil der Nutzer nicht betreffen wird.
Ich wollte aufzeigen, dass lirc keinesfalls mehr automatisch erforderlich ist wenn es um die Nutzung einer Fernbedienung geht, so wie dies früher noch der Fall war. Es macht deshalb durchaus Sinn sich zu überlegen ob man lirc wirklich noch benötigt, bevor man blindlings einen so abenteuerlichen Konstrukt wie das Umbiegen eines Eingabegerätes zur veralteten lirc-Infrastruktur umsetzt.
Ich verstehe dich schon geht aber wie gesagt an der Praxis vorbei.
Das einzig sinnvolle ist: Die Applikation kann sagen KEY_PREV_CHANNEL -> Sender rauf -> geht nicht X11 kann nur 255 Tasten. Dementsprechend gibt es in vielen dieser Anwendungen Tasten-Funktions-Mappings. Die meisten dieser Anwendungen können auch LIRC. Die Anwendungen die es nicht können, kriegst du per irexec. HTPC baust du nicht mit KDE oder Gnome.
Was ist deine Lösung ? Das abenteuerliche Konstrukt ist in der Realität ziemlich einfach und funktioniert.
Es geht auch bereits andersrum. Man kann also lirc über --uinput Tastendrücke schicken lassen. Dann brauch man kein LIRC bei den Anwendungen. Aber gewinnt man dadurch etwas ?
Soll heißen - es ist in der Realität sinnvoller als dir scheint. Und im Artikel ist ja auch beschrieben, wie man die Tasten umbelegen kann (ir-keytable) - so denn die FB Teil des RC Frameworks ist.
Der Artikel beschreibt das Tastenmapping vom Kernel zu lirc, das Tastenmapping von lirc zur Applikation und das dafür nötige starten mehrere Daemons. Hier wird wohl die Frage erlaubt sein müssen, warum man sich das antun sollte, wenn es in vielen Fällen auch einfacher geht und die Grundfunktionalität sogar bereits Out-of-the-box zur Verfügung steht.
Außerdem wird auch der Hinweis erlaubt sein müssen, dass lirc keinesfalls mehr notwendig ist um Fernbedienungen nutzen zu können, so wie dies früher mal der Fall war.
Ich empfehle deshalb weiterhin jedem Anwender als erstes zu prüfen, ob lirc für den gewünschten Anwendungszweck überhaupt benötigt wird.
Man hat jedoch bereits eine Out-of-the-box Grundfunktionalität auf welche man schrittweise aufbauen kann.
Ich habe bei mir auch sämtliche Tasten belegt, regelmäßig benutzte ich davon jedoch nur sehr wenige und so wird es vielen gehen.
Bei lirc muss du sie auch erstmal belegen, genau davon handelt der Artikel den du gerade kommentierst.
Was im Einzelfall vollkommen egal ist ob die Taste welche mit "Prev.CH" auf der Fernbedienung beschriftet ist in X11 nun XF86Launch7 heißt. Die Taste wird einmal zur Applikation durchbelegt und fertig.
Damit mag man keinen Designpreis gewinnen, doch mit dem Aufbau einer Parallelinfrastruktur unter Zuhilfenahme mehrerer Daemons gewinnt man ihn auch nicht.
Diese Funktionalität muss so und so auf Applikationsebene implementiert sein, in beiden Fällen.
Auf der anderen Seite kann man auch wieder fragen weshalb die Multimedia-Tasten einer Tastatur oder einer Maus völlig anders behandelt werden sollen als die selben Tasten einer Fernbedienung. Denn genau das macht lirc.
Was mit lirc auch nur so lange funktioniert, so lange du nur eine Applikation gestartet hast welche die Taste nutzt.
Ich stimme mit dir insofern überein, dass beides nicht die Optimallösung darstellt und du für beides keinen Preis gewinnen wirst. Bei beiden kannst du Vor- und Nachteile in speziellen Anwendungsfällen finden was in beiden Fällen den Großteil der Nutzer nicht betreffen wird.
Ich wollte aufzeigen, dass lirc keinesfalls mehr automatisch erforderlich ist wenn es um die Nutzung einer Fernbedienung geht, so wie dies früher noch der Fall war. Es macht deshalb durchaus Sinn sich zu überlegen ob man lirc wirklich noch benötigt, bevor man blindlings einen so abenteuerlichen Konstrukt wie das Umbiegen eines Eingabegerätes zur veralteten lirc-Infrastruktur umsetzt.
Ich verstehe dich schon geht aber wie gesagt an der Praxis vorbei.
Das einzig sinnvolle ist:
Die Applikation kann sagen KEY_PREV_CHANNEL -> Sender rauf -> geht nicht X11 kann nur 255 Tasten.
Dementsprechend gibt es in vielen dieser Anwendungen Tasten-Funktions-Mappings.
Die meisten dieser Anwendungen können auch LIRC.
Die Anwendungen die es nicht können, kriegst du per irexec.
HTPC baust du nicht mit KDE oder Gnome.
Was ist deine Lösung ? Das abenteuerliche Konstrukt ist in der Realität ziemlich einfach und funktioniert.
Es geht auch bereits andersrum. Man kann also lirc über --uinput Tastendrücke schicken lassen. Dann brauch man kein LIRC bei den Anwendungen. Aber gewinnt man dadurch etwas ?
Soll heißen - es ist in der Realität sinnvoller als dir scheint. Und im Artikel ist ja auch beschrieben, wie man die Tasten umbelegen kann (ir-keytable) - so denn die FB Teil des RC Frameworks ist.
Der Artikel beschreibt das Tastenmapping vom Kernel zu lirc, das Tastenmapping von lirc zur Applikation und das dafür nötige starten mehrere Daemons. Hier wird wohl die Frage erlaubt sein müssen, warum man sich das antun sollte, wenn es in vielen Fällen auch einfacher geht und die Grundfunktionalität sogar bereits Out-of-the-box zur Verfügung steht.
Außerdem wird auch der Hinweis erlaubt sein müssen, dass lirc keinesfalls mehr notwendig ist um Fernbedienungen nutzen zu können, so wie dies früher mal der Fall war.
Ich empfehle deshalb weiterhin jedem Anwender als erstes zu prüfen, ob lirc für den gewünschten Anwendungszweck überhaupt benötigt wird.