Fernbedienung - USB X10 mit Kerneltreibern

Aus VDR Wiki
(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
K
 
(51 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Die Nutzung dieser Fernbedienung unter Verwendung von lirc erwies sich als schwierig.<br>
+
Die Nutzung dieser Fernbedienung unter Verwendung von lirc erwies sich als schwierig.
Es kam öfters dazu, dass der VDR nicht mehr auf Eingabe durch die Fernbedienung reagierte.<br>
+
 
Es liess sich jedoch nicht eindeutig isolieren, ob es direkt am lirc lag, oder der VDR nicht<br>
+
[[Fernbedienung - USB X10|Konfiguration Medion USB X10 mit LIRC]]
gut genug mit lirc zusammenarbeiten konnte.<br>
+
 
<br>
+
Es kam öfters dazu, dass der VDR nicht mehr auf Eingabe durch die Fernbedienung reagierte.Leider ließ es sich jedoch nicht eindeutig isolieren, ob es direkt am lirc lag, oder der VDR nicht gut genug mit lirc zusammenarbeiten konnte.
Aus diesem Grunde suchte ich nach einer anderen Möglichkeit meine Fernbedienung nutzen zu können.<br>
+
 
Mein VDR Rechner läuft mit einem 2.6 Kernel. Dieser bietet bereits Support für diese Fernbedienung<br>
+
Aus diesem Grunde suchte ich nach einer anderen Möglichkeit meine Fernbedienung nutzen zu können. Mein VDR Rechner läuft mit einem 2.6 Kernel. Dieser bietet bereits Support für diese Fernbedienung mit dem Kernel Module ati_remote an. Leider sind jedoch nicht alle Tasten der Fernbedienung nutzbar, da im Sourcecode des Treibers nicht alle Tasten eingetragen sind.
mit dem Kernel Module ati_remote an. Leider sind jedoch nicht alle Tasten der Fernbedienung nutzbar,<br>
+
Dieses Problem lässt sich jedoch lösen.
da im Sourcecode des Treibers nicht alle Tasten eingetragen sind.<br>
+
 
Dieses Problem lässt sich jedoch lösen.<br>
+
== Variante 1 Kernelmodul patchen ==
<br>
+
 
<br>
+
Damit alle Tasten funktionieren muss man das Kernelmodul [[Patches#Anleitung|patchen]].
Im folgenden also eine kleine Anleitung, wie man den Kerneltreiber verwenden kann, und trotzdem alle Tasten der Fernbedienung nutzen kann.<br>
+
 
<br>
+
Download hier:
Ich setze voraus, dass ein aktueller 2.6 Kernel Source tree unter /usr/src/linux zu finden ist.<br>
+
 
<br>
+
[http://vdr.emanuel-eberle.de/ati_remote.c_all_keys_and_keychange.patch Download Patch]
Das Originalmodul befindet sich im Verzeichniss /usr/src/linux/drivers/input/misc<br>
+
 
Wir sichern dies zuerst durch:<br>
+
Den Patch einfach im Sourceverzeichnis des Kernels /usr/src/linux-2.6.XX/ mit dem Befehl
cp /usr/src/linux/drivers/input/misc/ati_remote.c /usr/src/linux/drivers/input/misc/ati_remote.c.org<br>
+
 
Als nächstes ersetzen wir die Originaldatei mit einer modifizierten ati_remote.c, die die fehlenden Tasten unterstützt.<br>
+
patch -p1 < ati_remote.c_all_keys_and_keychange.patch
<br>
+
einspielen.
[http://www.xtremeweb.de/external/vdr/ati_remote.c Download]
+
 
<br>
+
== Variante 2 Kernelmodul ersetzen ==
Als nächstes sollte man sich das Verzeichniss /usr/src/linux/drivers/input/misc genauer anschauen:<br>
+
 
ll -h /usr/src/linux/drivers/input/misc<br>
+
Nicht mein präferierter Weg aber der vorherige Autor hatte ursprünglich diesen Weg beschrieben
 +
 
 +
Das Originalmodul befindet sich im Verzeichnis
 +
/usr/src/linux-2.6.XX/drivers/input/misc
 +
Man sichert dies zuerst durch:
 +
cp /usr/src/linux-2.6.XX/drivers/input/misc/ati_remote.c /usr/src/linux-2.6.XX/drivers/input/misc/ati_remote.c.bak
 +
Als nächstes ersetzt man die Originaldatei mit der vorgepatchten ati_remote.c.
 +
 
 +
Download hier:
 +
 
 +
[http://vdr.emanuel-eberle.de/ati_remote.c Download Kernelmodul]
 +
 
 +
== Kernel ==
 +
 
 +
 
 +
Als nächstes sollte man sich das Verzeichnis /usr/src/linux-2.6.XX/drivers/input/misc genauer anschauen:<br>
 +
ls -lh /usr/src/linux-2.6.XX/drivers/input/misc
 
Sind hier schon die Dateien<br>
 
Sind hier schon die Dateien<br>
.ati_remote.ko.cmd<br>
+
.ati_remote.ko.cmd
.ati_remote.mod.o.cmd<br>
+
.ati_remote.mod.o.cmd
.ati_remote.o.cmd<br>
+
.ati_remote.o.cmd
 
vorhanden, so bedeutet dies, dass das Modul (mit dem "alten" Sourcecode) bereits übersetzt wurde.<br>
 
vorhanden, so bedeutet dies, dass das Modul (mit dem "alten" Sourcecode) bereits übersetzt wurde.<br>
 
Man kann dies auch an den Timestamps der Dateien erkennen.<br>
 
Man kann dies auch an den Timestamps der Dateien erkennen.<br>
Zeile 34: Zeile 50:
 
"neuen" Dateien weglöschen. Die Auswahl, welche Dateien zu löschen sind, trifft man anhand des<br>
 
"neuen" Dateien weglöschen. Die Auswahl, welche Dateien zu löschen sind, trifft man anhand des<br>
 
Timestamps und der Endung der Datei.<br>
 
Timestamps und der Endung der Datei.<br>
Gelöscht werden können die Dateien mit den Endungen:<br>
+
Gelöscht werden können die Dateienn:<br>
'''*.cmd *.ko *.o'''<br>
+
ati_remote.ko  
 +
ati_remote.o
 +
ati_remote.mod.o
 +
ati_remote.mod.c
 +
...
 +
Also alle dateien mit ati_remote '''ausser ati_remote.c'''
 +
 
 
Nun sollte das Verzeichniss präpariert sein.<br>
 
Nun sollte das Verzeichniss präpariert sein.<br>
<br>
+
 
Nun '''make menuconfig''' aufrufen.<br>
+
Nun wechselt man ins Verzeichniss des Kernels mittels<br>
Wir aktivieren hier den Support für die Fernbedienung, indem wir ein Modul bauen lassen.<br>
+
'''cd /usr/src/linux/''' und starten '''make menuconfig'''<br>
 +
Man aktiviert hier den Support für die Fernbedienung, indem man ein Modul bauen lässt.<br>
 
Zu finden unter:<br>
 
Zu finden unter:<br>
 
'''Device Drivers  --->  Input device support  ---> Miscellaneous devices  ---> <M>  ATI / X10 USB RF remote control'''<br>
 
'''Device Drivers  --->  Input device support  ---> Miscellaneous devices  ---> <M>  ATI / X10 USB RF remote control'''<br>
Zeile 47: Zeile 70:
 
Wenn dies erledigt ist, müssen die Module installiert werden mittels:<br>
 
Wenn dies erledigt ist, müssen die Module installiert werden mittels:<br>
 
'''make modules_install'''<br>
 
'''make modules_install'''<br>
 +
Jetzt sollte das Modul installiert sein.<br>
 +
Man testet dies durch '''modprobe ati_remote'''
 
<br>
 
<br>
  
== Ebene 2 Überschrift ==
+
== VDR anpassen ==
qweq
+
 
 +
Mich hat immer gestört, dass bei USB Geräten nicht sicher davon ausgegangen werden konnte, dass der VDR<br>
 +
das richtige Inputdevice anspricht, nachdem man ein anderes USB Gerät an oder abgesteckt hat.<br>
 +
Beim nächsten Neustart konnte man nicht sicher sein, dass die Fernbedienung immer noch z.B. /dev/input/event4 ist.<br>
 +
Eine leichte Modifikation des Skriptes runvdr hilft mir bei diesem Problem:<br>
 +
<br>
 +
Folgenden 3zeiler in die runvdr mit einfügen (am Besten eine Zeile vor '''while (true) do''')<br>
 +
ln -sf $(for x in `ls /dev/input/event*` ; do
 +
if [ -n "$(udevinfo -a -p `udevinfo -q path -n $x` | grep 'X10 Wireless Technology')" ] ; then
 +
echo $x; fi ; done) /dev/input/tmx10
 +
 
 +
alternativ bietet sich folgende udev regel an
 +
 
 +
/etc/udev/rules.d/40-x10.rules
 +
 
 +
KERNEL=="event?", ATTRS{name}=="X10 WTI RF receiver", SYMLINK="input/tmx10"
 +
 
 +
 
 +
Das [[Remote-plugin]] des VDR kann nun /dev/input/tmx10 nutzen.
 +
 
 +
In der Datei plugin.remote.conf fehlt nun noch folgende Zeile (Debianbasierte Systeme) :
 +
 
 +
-i /dev/input/tmx10
 +
 
 +
Alternativ kann man in der runvdr dem [[Remote-plugin]] mitteilen, welches Inputdevice zu verwenden ist:
 +
 
 +
-P 'remote -i /dev/input/tmx10'
 +
 
 +
Durch den 3zeiler wurde ein Symlink von /dev/input/tmx10 auf das korrekte Inputdevice gelegt.<br>
 +
 
 +
Wenn man die Fernbedienung neu anlernen möchte (man hat ja nun die Farbtasten), den VDR stoppen, die remote.conf löschen und danach den VDR neu starten.
 +
 
 +
== Problem: Tasten müssen immer zweimal gedrückt werden ==
 +
 
 +
Wenn man beim Anlernen der Tasten im VDR jede Taste immer zweimal drücken muss und in den /var/log/messages folgendes Erscheint:
 +
 
 +
...
 +
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352               
 +
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352               
 +
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352               
 +
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352               
 +
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352               
 +
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                   
 +
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                   
 +
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                   
 +
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                   
 +
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e
 +
...
 +
 
 +
hat man aller Wahrscheinlichkeit nach eine Fernbedienung mit Wechselcode. (Die Zeilen mit keycode erhält man wenn man das Modul mit debug=1 lädt)
 +
 
 +
Das ist der Treiberoutput beim doppelten drücken einer Taste. Man erkennt den Offset 0x63 + 0x80 = 0xe3, 0x1e + 0x80 = 0x9e
 +
 
 +
Wie gesagt für eine andere Taste sieht das natürlich anders aus aber man hat immer den Unterschied von 0x80.
 +
 
 +
Der Patch bietet eine Lösung für dieses Problem indem man das Modul mit der option '''keychange=1''' lädt. '''Diese Option ist neu und wird mit dem Patch eingespielt'''
 +
 
 +
also erstmal Modul entladen:
 +
rmmod ati-remote
 +
und mit Optienen neu laden:
 +
modprobe ati-remote keychange=1
 +
...testen...
 +
Funktioniert? Gut :)
 +
 
 +
und damit das beim Neustart des Systems nicht alles verloren geht einfach
 +
echo 'options ati_remote keychange=1' > /etc/modprobe.d/ati-remote
 +
 
 +
Fertig :)
 +
 
 +
{{Box Datei | Beispiel [[Struktur|$VDRCONFIG]]/[[remote.conf]] (remote-plugin, /dev/input/event7) |
 +
<pre>
 +
remote-event7.Up        0000000100010067
 +
remote-event7.Down      000000010001006C
 +
remote-event7.Menu      0000000100010020
 +
remote-event7.Ok        0000000100010160
 +
remote-event7.Back      0000000100010084
 +
remote-event7.Left      0000000100010069
 +
remote-event7.Right      000000010001006A
 +
remote-event7.Red        00000001000100C8
 +
remote-event7.Green      00000001000100C9
 +
remote-event7.Yellow    00000001000100CA
 +
remote-event7.Blue      00000001000100CB
 +
remote-event7.0          000000010001000B
 +
remote-event7.1          0000000100010002
 +
remote-event7.2          0000000100010003
 +
remote-event7.3          0000000100010004
 +
remote-event7.4          0000000100010005
 +
remote-event7.5          0000000100010007
 +
remote-event7.6          0000000100010008
 +
remote-event7.7          0000000100010031
 +
remote-event7.8          0000000100010009
 +
remote-event7.9          000000010001000A
 +
remote-event7.Info      000000010001006B
 +
remote-event7.Play      00000001000100CF
 +
remote-event7.Pause      0000000100010077
 +
remote-event7.Stop      0000000100010080
 +
remote-event7.Record    00000001000100A7
 +
remote-event7.FastFwd    000000010001009F
 +
remote-event7.FastRew    00000001000100A8
 +
remote-event7.Next      0000000100010021
 +
remote-event7.Prev      0000000100010012
 +
remote-event7.Power      0000000100010074
 +
remote-event7.Channel+  0000000100010192
 +
remote-event7.Channel-  0000000100010193
 +
remote-event7.Volume+    0000000100010072
 +
remote-event7.Volume-    0000000100010073
 +
remote-event7.Mute      000000010001001E
 +
remote-event7.Schedule  0000000100010098
 +
remote-event7.Channels  0000000100010096
 +
remote-event7.Timers    0000000100010185
 +
remote-event7.Recordings 0000000100010060
 +
remote-event7.Setup      000000010001009C
 +
remote-event7.Commands  0000000100010166
 +
</pre>
 +
}}
 +
 
 +
[[Kategorie:Fernbedienungen]]

Aktuelle Version vom 9. Juli 2013, 16:59 Uhr

Die Nutzung dieser Fernbedienung unter Verwendung von lirc erwies sich als schwierig.

Konfiguration Medion USB X10 mit LIRC

Es kam öfters dazu, dass der VDR nicht mehr auf Eingabe durch die Fernbedienung reagierte.Leider ließ es sich jedoch nicht eindeutig isolieren, ob es direkt am lirc lag, oder der VDR nicht gut genug mit lirc zusammenarbeiten konnte.

Aus diesem Grunde suchte ich nach einer anderen Möglichkeit meine Fernbedienung nutzen zu können. Mein VDR Rechner läuft mit einem 2.6 Kernel. Dieser bietet bereits Support für diese Fernbedienung mit dem Kernel Module ati_remote an. Leider sind jedoch nicht alle Tasten der Fernbedienung nutzbar, da im Sourcecode des Treibers nicht alle Tasten eingetragen sind. Dieses Problem lässt sich jedoch lösen.

Inhaltsverzeichnis

[Bearbeiten] Variante 1 Kernelmodul patchen

Damit alle Tasten funktionieren muss man das Kernelmodul patchen.

Download hier:

Download Patch

Den Patch einfach im Sourceverzeichnis des Kernels /usr/src/linux-2.6.XX/ mit dem Befehl

patch -p1 < ati_remote.c_all_keys_and_keychange.patch

einspielen.

[Bearbeiten] Variante 2 Kernelmodul ersetzen

Nicht mein präferierter Weg aber der vorherige Autor hatte ursprünglich diesen Weg beschrieben

Das Originalmodul befindet sich im Verzeichnis

/usr/src/linux-2.6.XX/drivers/input/misc

Man sichert dies zuerst durch:

cp /usr/src/linux-2.6.XX/drivers/input/misc/ati_remote.c /usr/src/linux-2.6.XX/drivers/input/misc/ati_remote.c.bak

Als nächstes ersetzt man die Originaldatei mit der vorgepatchten ati_remote.c.

Download hier:

Download Kernelmodul

[Bearbeiten] Kernel

Als nächstes sollte man sich das Verzeichnis /usr/src/linux-2.6.XX/drivers/input/misc genauer anschauen:

ls -lh /usr/src/linux-2.6.XX/drivers/input/misc

Sind hier schon die Dateien

.ati_remote.ko.cmd
.ati_remote.mod.o.cmd
.ati_remote.o.cmd

vorhanden, so bedeutet dies, dass das Modul (mit dem "alten" Sourcecode) bereits übersetzt wurde.
Man kann dies auch an den Timestamps der Dateien erkennen.

Um später beim Compilieren zu Erreichen, dass das Modul erneut übersetzt wird, sollte man die
"neuen" Dateien weglöschen. Die Auswahl, welche Dateien zu löschen sind, trifft man anhand des
Timestamps und der Endung der Datei.
Gelöscht werden können die Dateienn:

ati_remote.ko 
ati_remote.o
ati_remote.mod.o
ati_remote.mod.c
...

Also alle dateien mit ati_remote ausser ati_remote.c

Nun sollte das Verzeichniss präpariert sein.

Nun wechselt man ins Verzeichniss des Kernels mittels
cd /usr/src/linux/ und starten make menuconfig
Man aktiviert hier den Support für die Fernbedienung, indem man ein Modul bauen lässt.
Zu finden unter:
Device Drivers ---> Input device support ---> Miscellaneous devices ---> <M> ATI / X10 USB RF remote control

Nachdem man mittels Exit wieder in der Shell ist, nun das Compilieren anstossen mittels:
make
Wenn dies erledigt ist, müssen die Module installiert werden mittels:
make modules_install
Jetzt sollte das Modul installiert sein.
Man testet dies durch modprobe ati_remote

[Bearbeiten] VDR anpassen

Mich hat immer gestört, dass bei USB Geräten nicht sicher davon ausgegangen werden konnte, dass der VDR
das richtige Inputdevice anspricht, nachdem man ein anderes USB Gerät an oder abgesteckt hat.
Beim nächsten Neustart konnte man nicht sicher sein, dass die Fernbedienung immer noch z.B. /dev/input/event4 ist.
Eine leichte Modifikation des Skriptes runvdr hilft mir bei diesem Problem:

Folgenden 3zeiler in die runvdr mit einfügen (am Besten eine Zeile vor while (true) do)

ln -sf $(for x in `ls /dev/input/event*` ; do
if [ -n "$(udevinfo -a -p `udevinfo -q path -n $x` | grep 'X10 Wireless Technology')" ] ; then
echo $x; fi ; done) /dev/input/tmx10

alternativ bietet sich folgende udev regel an

/etc/udev/rules.d/40-x10.rules
KERNEL=="event?", ATTRS{name}=="X10 WTI RF receiver", SYMLINK="input/tmx10"


Das Remote-plugin des VDR kann nun /dev/input/tmx10 nutzen.

In der Datei plugin.remote.conf fehlt nun noch folgende Zeile (Debianbasierte Systeme) :

-i /dev/input/tmx10

Alternativ kann man in der runvdr dem Remote-plugin mitteilen, welches Inputdevice zu verwenden ist:

-P 'remote -i /dev/input/tmx10'

Durch den 3zeiler wurde ein Symlink von /dev/input/tmx10 auf das korrekte Inputdevice gelegt.

Wenn man die Fernbedienung neu anlernen möchte (man hat ja nun die Farbtasten), den VDR stoppen, die remote.conf löschen und danach den VDR neu starten.

[Bearbeiten] Problem: Tasten müssen immer zweimal gedrückt werden

Wenn man beim Anlernen der Tasten im VDR jede Taste immer zweimal drücken muss und in den /var/log/messages folgendes Erscheint:

...
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352                
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352                
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352                
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352                
ati_remote 3-4.4.3:1.0: channel 0x07; data 63,1e; index 44; keycode 352                
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                    
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                    
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                    
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e                    
ati_remote 3-4.4.3:1.0: Unknown input from channel 0x07: data e3,9e
...

hat man aller Wahrscheinlichkeit nach eine Fernbedienung mit Wechselcode. (Die Zeilen mit keycode erhält man wenn man das Modul mit debug=1 lädt)

Das ist der Treiberoutput beim doppelten drücken einer Taste. Man erkennt den Offset 0x63 + 0x80 = 0xe3, 0x1e + 0x80 = 0x9e

Wie gesagt für eine andere Taste sieht das natürlich anders aus aber man hat immer den Unterschied von 0x80.

Der Patch bietet eine Lösung für dieses Problem indem man das Modul mit der option keychange=1 lädt. Diese Option ist neu und wird mit dem Patch eingespielt

also erstmal Modul entladen:

rmmod ati-remote

und mit Optienen neu laden:

modprobe ati-remote keychange=1

...testen... Funktioniert? Gut :)

und damit das beim Neustart des Systems nicht alles verloren geht einfach

echo 'options ati_remote keychange=1' > /etc/modprobe.d/ati-remote

Fertig :)

Datei
Beispiel $VDRCONFIG/remote.conf (remote-plugin, /dev/input/event7)
remote-event7.Up         0000000100010067
remote-event7.Down       000000010001006C
remote-event7.Menu       0000000100010020
remote-event7.Ok         0000000100010160
remote-event7.Back       0000000100010084
remote-event7.Left       0000000100010069
remote-event7.Right      000000010001006A
remote-event7.Red        00000001000100C8
remote-event7.Green      00000001000100C9
remote-event7.Yellow     00000001000100CA
remote-event7.Blue       00000001000100CB
remote-event7.0          000000010001000B
remote-event7.1          0000000100010002
remote-event7.2          0000000100010003
remote-event7.3          0000000100010004
remote-event7.4          0000000100010005
remote-event7.5          0000000100010007
remote-event7.6          0000000100010008
remote-event7.7          0000000100010031
remote-event7.8          0000000100010009
remote-event7.9          000000010001000A
remote-event7.Info       000000010001006B
remote-event7.Play       00000001000100CF
remote-event7.Pause      0000000100010077
remote-event7.Stop       0000000100010080
remote-event7.Record     00000001000100A7
remote-event7.FastFwd    000000010001009F
remote-event7.FastRew    00000001000100A8
remote-event7.Next       0000000100010021
remote-event7.Prev       0000000100010012
remote-event7.Power      0000000100010074
remote-event7.Channel+   0000000100010192
remote-event7.Channel-   0000000100010193
remote-event7.Volume+    0000000100010072
remote-event7.Volume-    0000000100010073
remote-event7.Mute       000000010001001E
remote-event7.Schedule   0000000100010098
remote-event7.Channels   0000000100010096
remote-event7.Timers     0000000100010185
remote-event7.Recordings 0000000100010060
remote-event7.Setup      000000010001009C
remote-event7.Commands   0000000100010166