26.11.2014, 22:18
Wie erfolgt die IR-Signalverarbeitung im Kernel-Modul?
Nachfolgend findet sich mein Wissensstand/Verständnis mit bitte um Korrektur 8)
Ich habe einen EasyVDR 2.0 ohne Lirc.
Die Lirc-Freiheit habe ich geprüft mit
und erhalte keine Ausgabe.
Zusätzliche Prüfung:
Schlußfolgerung: Nur das Kernelmodul bearbeitet IR-Signale.
Die Signalverarbeitung erfolgt nach meinem Verständnis Hardware seitig so:
IR-Sender -> IR-Empfänger -> USB/PCI -> OS
Ein halbwegs moderner IR-Empfänger empfängt beliebige IR-Protokolle vom IR-Sender wie
"Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC other"
Auf dieser ersten Kommunikationsebene (IR-Sender/IR-Empfänger) sollten beliebige Fernbedienungskombinationen zusammen passen, es sei denn die vom IR-Empfänger angenommenen Signale werden per Konfiguration im OS abgeschaltet (d.h. nach dem physikalischen Empfang geblockt). Sind jedoch alle IR-Protokolle freigeschaltet nimmt der IR-Empfänger beliebige IR-Signale an und gibt diese per USB oder PCI an das OS.
Ein Programm wie "evtest" oder "ir-keytable -t -c" sollte nach meinem Verständnis bei Auswahl des korrekten events alle empfangenen IR-Tastencodes ausgeben. Eine Zuordnung von IR-Tastencodes zu OS-KEY-Codes erfolgt in einer anzugebenden scancode/keycode Table nachgeordnet. Ist eine solche Table (d.h. Übersetzungstabelle) nicht vorhanden, wird einfach der Scancode ausgegeben aber nicht an das OS zur weiteren Verarbeitung weitergeleitet.
Beispiel:
sudo ir-keytable --device /dev/input/event7 -c -w /etc/rc_keymaps/hauppauge_pvr350_key_irkeytab.rc5
Hier lauscht das Programm ir-keytable auf Event7 löscht die bestehende Keytable und kädt eine neue aus der Datei /etc/rc_keymaps/hauppauge_pvr350_key_irkeytab.rc5, wobei das Dateiextension "*.rc5" möglicherweise darauf hindeutet, daß der FB-Sender scheinbar nur das rc5-Protokoll benutzt.
Stimmt dieses Verständnis soweit?
Danke an jeden Helfer.
RC
Nachfolgend findet sich mein Wissensstand/Verständnis mit bitte um Korrektur 8)
Ich habe einen EasyVDR 2.0 ohne Lirc.
Die Lirc-Freiheit habe ich geprüft mit
Code:
ps -ef | grep -i lircZusätzliche Prüfung:
Code:
sudo stop easyvdr-inputlirc
stop: Unknown instance:Die Signalverarbeitung erfolgt nach meinem Verständnis Hardware seitig so:
IR-Sender -> IR-Empfänger -> USB/PCI -> OS
Ein halbwegs moderner IR-Empfänger empfängt beliebige IR-Protokolle vom IR-Sender wie
"Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC other"
Auf dieser ersten Kommunikationsebene (IR-Sender/IR-Empfänger) sollten beliebige Fernbedienungskombinationen zusammen passen, es sei denn die vom IR-Empfänger angenommenen Signale werden per Konfiguration im OS abgeschaltet (d.h. nach dem physikalischen Empfang geblockt). Sind jedoch alle IR-Protokolle freigeschaltet nimmt der IR-Empfänger beliebige IR-Signale an und gibt diese per USB oder PCI an das OS.
Ein Programm wie "evtest" oder "ir-keytable -t -c" sollte nach meinem Verständnis bei Auswahl des korrekten events alle empfangenen IR-Tastencodes ausgeben. Eine Zuordnung von IR-Tastencodes zu OS-KEY-Codes erfolgt in einer anzugebenden scancode/keycode Table nachgeordnet. Ist eine solche Table (d.h. Übersetzungstabelle) nicht vorhanden, wird einfach der Scancode ausgegeben aber nicht an das OS zur weiteren Verarbeitung weitergeleitet.
Beispiel:
sudo ir-keytable --device /dev/input/event7 -c -w /etc/rc_keymaps/hauppauge_pvr350_key_irkeytab.rc5
Hier lauscht das Programm ir-keytable auf Event7 löscht die bestehende Keytable und kädt eine neue aus der Datei /etc/rc_keymaps/hauppauge_pvr350_key_irkeytab.rc5, wobei das Dateiextension "*.rc5" möglicherweise darauf hindeutet, daß der FB-Sender scheinbar nur das rc5-Protokoll benutzt.
Stimmt dieses Verständnis soweit?
Danke an jeden Helfer.
RC
