Help request: VDR CoreElec (chroot oder Zabrimus) und amremote/eventlird

Zabrimus · 2. Oktober 2023

Perfekt. Danke. Der Build funktioniert mit CE19 und CE20. Ich habe das committed.

Es scheint, als ob ich mich tatsächlich verrannt habe.

Was jetzt genau wie getestet werden kann, ist mir noch unklar. Zumindest baut es jetzt.

Dr. Seltsam · 2. Oktober 2023

Zitat von Zabrimus

Was jetzt genau wie getestet werden kann, ist mir noch unklar.

Gebt mir etwas Zeit. Ich bin noch dabei, eine Corona-Infektion auszukurieren. Sobald ich kann, schreibe ich eine genaue Anleitung zur Umstellung auf den alternativen meson-remote Treiber ("amremote").

Dr. Seltsam · 13. Oktober 2023

So, ich versuche mich mal an einer Anleitung.

Worum geht es? amlogic-basierte Boxen haben in der Regel einen integrierten IR-Empfänger. Für dessen Betrieb gibt es zwei Möglichkeiten:

einen hardwarebasierten Treiber von amlogic (meson-remote), der aber nur das NEC-Protokoll unterstützt. Diese Methode ist als 'amremote' bekannt und war lange Zeit Standard bei CoreElec. Der Vorteil dieses Treibers ist, dass die Fernbedienung damit in aller Regel deutlich performanter läuft. Der Nachteil ist halt, dass z.B. gewöhnliche RC5 oder RC6-Fernbedienungen nicht benutzt werden können. (Nicht irritieren lassen: Man kann zwar andere Protokolle im Bootloader setzen, aber das hat nur Einfluss auf den wakeup-Code).
einen softwarebasierten Mainline-Kerneltreiber (meson-ir), der mit allen üblichen Protokollen benutzt werden kann undd er seit einiger Zeit Standard bei CoreElec ist. Die Erfahrung vieler Nutzer ist, dass die Tasten 'prellen', d.h. jeder Tastendruck wird mehrmals ausgeführt. Man kann das mit z.B. ir-keytable -D 600 -P 200 zwar verbessern, aber die Fernbedienung wird dadurch träger.

Damit CE statt meson-ir den meson-remote-Treiber ("amremote") verwendet, muss lediglich eine Datei remote.conf in /storage/.config abgelegt werden. Eine fertige remote.conf gibt es für viele Fernbedienungen von amlogic-Androidboxen hier. Unter Kodi sollte die Fernbedienung damit sofort laufen. Mit vdr geht erstmal nichts, und das hat mehrere Gründe:

Die verwandten Tastendefinitionen sind für vdr teils unüblich. Es werden auch in /usr/lib/systemd/system/remote-config einige Tasten neu gemappt - warum auch immer. So wird aus event code 128 (KEY_STOP) z.B. 45 (KEY_X). Aus 139 (KEY_MENU) wird 46 (KEY_C) und aus 158 (KEY_BACK) wird 1 (KEY_ESC - sollte für vdr sowieso der Standard sein). Alle anderen Ersetzungen betreffen event codes, die für vdr eher unüblich sind.

Man müsste also in vdr's remote.conf z.B. ein Mapping Lirc.Menu KEY_C vornehmen. Nun kommt aber das nächste Problem: Die Tastendrucke kommen bei vdr aber gar nicht an, weil eventlircd nicht auf das amremote-device hört. Dafür gäbe es zwei Lösungen - entweder man sorgt mit einer udev-Regel dafür, dass eventlircd es berücksichtigt. Oder man nutzt das remote-Plugin, das man allerdings erstmal patchen müsste, damit es nicht exklusiven Zugriff bekommt (was den Wechsel von/zu Kodi behindern würde). Beides bringt aber nichts, denn der Treiber erzeugt bei gedrückter Taste keine repeats. Unter Kodi ist das kein Problem, da Kodi die repeats irgendwie selbst erzeugt. Unter vdr würden die fehlenden Wiederholungen die Bedienbarkeit massiv erschweren. Damit man keinen Krampf in den Fingern bekommt, gibt es zum Glück eine Lösung: seahawk1986 hatte für einen ähnlichen Fall mal ein Python-Script geschrieben, das die Tastenwiederholungen erzeugt. Wie implementiert man das ganze nun für vdr? Damit das python-Script laufen kann, wird python3-evdev benötigt. Zabrimus hat das in VDR*Elec kürzlich mit aufgenommen. Es ist aber noch nichts konfiguriert/eingerichtet, um das out-of-the-box nutzen zu können. Ich selbst verwende die Lösung in einer chroot-Umgebung und kann an dieser Stelle nur die grundsätzliche Vorgehensweise beschreiben und hoffe, dass Zabrimus den Rest integriert.

Zunächst einmal benötigen wir eine udev-Regel, die einen Symlink für das von meson-remote erzeugte input device anlegt. Auf diese Weise ist das device immer unter der gleichen Adresse /device/input/meson-remote erreichbar, auch wenn sich durch z.B. angeschlossene Tastaturen die Numerierung der inputs ändert.

Code

#/storage/.config/udev.rules.d/aml_keypad.rules

KERNEL=="event?", ATTRS{name}=="aml_keypad", \
SYMLINK="input/meson-remote" , ENV{eventlircd_enable}="false"

Das python-Script ps3remote.py soll auf dieses /device/input/meson-remote device lauschen und die Tastendrücke (inkl. Wiederholungen) unter einem vom Script neu angelegten input device bereitstellen. Damit auch dieses unter einer gleich bleibenden Symlink-Adresse erreichbar ist und von eventlircd berücksichtigt wird, muss eine weitere udev-Regel angelegt werden:

Code

#/storage/.config/udev.rules.d/ps3remote.rules

KERNEL=="event?", ATTRS{name}=="PS3 Remote", \
SYMLINK="input/ps3remote" , ENV{eventlircd_enable}="true"

Soweit ist die Vorgehensweise für VDR*Elec und chroot-Installationen identisch. Bezüglich des Startens des ps3remote.py-Scriptes ist die Vorgehensweise nun unterschiedlich. Auf einem Standard-CE mit vdr in einer Ubuntu-chroot-Umgebung steht python3-evedev nur innerhalb der chroot-Umgebung zur Verfügung. Dort habe ich das direkt im runvdr-Script vor der Ausführung von vdr umgesetzt:

Code

REMOTECMD="/usr/local/bin/ps3remote.py -s /dev/input/meson-remote -r 150 &"

#check if udev in CE has created the symlink for amremote (meson-remote):
while [ ! -e /dev/input/meson-remote ]; do sleep 1; done

#python-Script zum Anlegen eines virtuellen input-devices starten
if [ $(/usr/bin/pgrep -f "ps3remote.py") ]; then
    echo "ps3remote.py is already running"
else
    echo "start ps3remote.py script"
    eval "$REMOTECMD"
fi

#wait for virtual input device, created by udev in CE:
while [ ! -e /dev/input/ps3remote ]; do sleep 1; done

Alles anzeigen

Unter VDR*ELEC sollte zum Starten des ps3remote-Scriptes sinnvollerweise ein system.d Service verwandt werden, der vor dem Starten von vdr und eventlircd zur Ausführung kommt. Ich bin leider kein systemd-Experte und kann daher an dieser Stelle leider keine fertige Lösung dafür anbieten.

Noch einmal zusammengefasst:

-meson-remote ("amremote") legt ein input-device an

-per udev-Regel wird dies auf /dev/input/input/meson-remote gelinkt

-ps3remote.py muss gestartet werden, greift auf /dev/input/input/meson-remote zu und stellt ein neues input device zur Verfügung, das Dank udev-Regel unter /dev/input/ps3remote erreichbar ist

-eventlircd hört nicht auf /dev/input/input/meson-remote, sondern nur auf /dev/input/ps3remote und übersetzt die Tastendrücke (inkl. Wiederholungen) an die von vdr erwartete lirc-Schnittstelle /var/run/lirc/lircd

-vdr wird ganz normal mit der Option --lirc gestartet

Ende Teil 1

Dr. Seltsam · 13. Oktober 2023

Teil 2

Wer bis dahin aufmerksam aufgepasst hat, wird sich vielleicht fragen, wozu eigentlich eventlircd benötigt wird. Ja, man könnte die auf /dev/input/ps3remote ankommenden Tastendrücke auch mittels des (gepatchten) remote-Plugins dem vdr direkt bereitstellen. Das klappte bei meinen Tests mit einer Android-Original-FB auch gut. Bei den von meiner Universal-FB erzeugten NEC-Codes kam es auf diesem Wege aber zu einem starken "Prellen", das ich nur lösen konnte, indem ich die repeat-Rate von ps3remote.py von 150 auf 300 vderdoppelte. Dann wurde die FB aber sehr langsam. Deutlich besser lief es über eventlircd.

Mit den im vdr-Einstellungsmenü möglichen Einstellungen für RcRepeatDelay (Standardwert 300) und RcRepeatDelta (Standardwert 100) muss man je nach verwandter Fernbedienung ggf. etwas experimentieren.

Wem jetzt noch nicht der Kopf raucht, der wird sich nun die Frage stellen, wie er eine /storage/.config/remote.conf anlegt - insbesondere, wenn es kein fertiges Muster für eine vorhandene FB im CE-repository gibt. Das ist leider - Ihr ahnt es schon - recht "komplex".

Es gibt dazu mehrere Beschreibungen. Zum einen hahtte ich das hier im Forum schon einmal beschrieben. Eine weitere gute Anleitung mit einer etwas anderen Vorgehensweise gibt es im CE-Wiki. Ich versuche, das nochmal zusammenzufassen: Man fängt am besten an, solange amremote noch nicht läuft - also ohne eine /storage/.config/remote.conf und mit noch laufendem Treiber meson-ir. Dann stoppt man vdr und/oder Kodi (je nachdem was gerade läuft) und eventlircd. Wenn man dann auf einer Konsole ir-keytable -u eingibt, wird jeder Tastendruck protokolliert. Am besten fängt man mit der Powertaste an und notiert sich das protokollierte Ergebnis

Beispiel: Received IRMP code: remotewakeup='0xb24d4040', decode_type='0x0', remotewakeupmask='0xffffffff'

denn die Werte müssen in der config.ini eingetragen werden, damit IR-wakeup funktioniert.

Man drückt danach alle Tasten nacheinander durch und notiert sich die angezeigten Werte - relevant ist aus dem unter remotewakeup angezeigten Code jeweils nur die 5. und 6. Stelle von rechts. Aus 0xb24d4040 ist also "4d" der eigentliche Tastencode, dem wir ein 0x vorsetzen - ergibt also 0x4d.

Die Syntax der remote.conf ist u.a. auf der Wiki-Seite beschrieben und eigentlich ganz einfach. Wir benötigen zum einen den factory code der Fernbedienung. Dieser ergibt sich aus 0x, den letzten 4 Stellen des als remotewakeup angezeigten Codes sowie der Konstante 0001. Also in diesem Beispiel 0x40400001

Die Einträge

Code

work_mode       = 0
repeat_enable   = 1
repeat_delay    = 130
repeat_peroid   = 120
release_delay   = 20
debug_enable    = 1

habe ich von einer Muster-conf bei mir einfach übernommen. Ich habe nie einen Unterschied bemerkt, egal ob repeat_enable 0 oder 1 ist oder welche Werte verwandt werden. Wichtig ist dann der Abschnitt zwischen key_begin und key_end. Hier kommen die ausgelesenen Tastencodes sowie die Kernel-event-Nummer rein - und zwar mit genau einer Leerstelle Abstand. Keine Tabs benutzen!

Wenn Ihr für die Menü-Taste den Code 0x40 ermittelt habt, dann sollte der Eintrag wie folgt aussehen:

Code

0x40 46    #KEY_C (statt 139 KEY_MENU)

Warum KEY_C und nicht KEY_MENU? Weil CoreElec bei jedem Start aufgrund der Ersetzungen in /usr/lib/systemd/system/remote-config aus 139 die 46 macht. Also können wir die auch gleich eintragen - und müssen dann natürlich in vdr's eigener remote.conf das Mapping analog vornehmen:

Code

LIRC.Menu       KEY_C

Wie schon beschrieben, lauert die gleiche Falle bei KEY_STOP.
In dem Abschnitt zwischen repeat_key_begin und repeat_key_end sollen dann nochmal alle Zuordnungen wiederholt werden, für die eine Tastenwiederholung erfolgen soll. Eigentlich ist das in unserem Fall nicht notwendig. Die Tastenwiederholungen werden generell für alle Tasten über ps3remote.py erzeugt. Wenn man eventlircd nicht verwendet, sondern für den vdr das remote-Plugin verwendet, dann kann es sein, dass dieser repeat_key-Block für Kodi benötigt wird. (Wobei ich mir nicht sicher bin, ob Kodi dann das input-device von meson-remote oder von ps3remote berücksichtigt. Oder beide?)

Das klingt jetzt wahrscheinlich alles sehr kompliziert: Dazu noch die Einschränkung, dass es nur mit NEC-Codes funktioniert. Die Frage ist dehalb naheliegend, ob sich das denn wirklich lohnt. Ja, eindeutig. Die Performance ist deutlich besser. Die Fernbedienung ist schneller und man muss auch nicht mehr so genau auf den Empfänger zielen. Insbesondere auf der Tanix TX3 ist es ein Unterschied wie Tag und Nacht. Wer noch das originale Android booten kann (wo meson-remote verwandt wird), kann sich einen Eindruck davon verschaffen, wieviel besser die FB dort funktioniert als unter CE mit meson-ir.

Abschließend noch ein Hinweis zu ps3remote.py: In meiner Ubuntu 20.04. chroot-Umgebung läuft python 3.8 Ein paar Warnungen bei der Ausführung lassen sich mit dem beiliegenden Patch vermeiden. Die Änderungen stammen von seahwak1986 und ich habe ihn bereits gefragt, ob er das in seinem git einchecken kann.

vdr_rossi · 13. Oktober 2023

Hey super, werde ich am Wochenende direkt umsetzen.

Benötige jetzt noch ein Tipp für meine lernbare FB (URC1635), welches Gerät kann ich z.B. für NEC Codes nehmen?

Oder einfacher gefragt: Welcher Fernseher, DVD Player usw. verwendet NEC Codes?

jrie · 13. Oktober 2023

Laut URC1635 Codeliste: NEC 3257, 1797, 1825, 1606, 0876

Dr. Seltsam · 13. Oktober 2023

Zitat

Welcher Fernseher, DVD Player usw. verwendet NEC Codes?

Das ist leider nicht so einfach zu beantworten, da viele Hersteller auch baugleiche Modelle anderer Hersteller im Sortiment haben/hatten. Mit der beschriebenen Methode (ir-keytable -u) sollte für eine FB mit NEC-Code decode_type='0x0' geloggt werden. Der decode_type sollte dem entsprechen, was in der config.ini als Kommentar hinterlegt ist:

Code

#   decode_type can be one of the following:
#   NEC='0x0', DUOKAN='0x1', TOSHIBA='0x2', RCA='0x3', RC5='0x4', RC6A='0x5', NEC_TOSHIBA_2IN1='0x6',
#   NEC_RCA_2IN1='0x7', RCMM='0x8', NEC_RC5_2IN1='0x9', NEC_RC5_2IN1='0xa', RC6='0xb'

Wenn also etwas anderes als decode_type='0x0' geloggt wird, ist es kein NEC-Code.

Ein anderer Test ist die Verwendung einer remote.conf ohne factory-Code und ohne Tastenzuordnungen. Nach einem reboot kann man sich dann mit dmesg -c bzw. unter CE mit journalctl -fk anzeigen lassen, wie die Tasten erkannt werden. Es sollte für jeden Tastendruck so etwas wie wrong custom code oder invalid code gefolgt von zB. 0xae517f80 geloggt werden. Wenn die Codes dabei für die gleiche Taste bei wiederholtem Druck unterschiedlich sind, ist es kein NEC Code.

Ansonsten sei zu dieser Methode darauf verwiesen, dass die Ermittlung des in der remote.conf einzutragenden Tastencodes gemäß dieser Anleitung analog zur Ausgabe von ir-keytable -u mit meson-ir ist.

Spoiler anzeigen

Dr. Seltsam · 13. Oktober 2023

Zitat von jrie

Laut URC1635 Codeliste: NEC 3257, 1797, 1825, 1606, 0876

Die Codelisten enthalten in der Regel Hersteller und sagen nichts darüber aus, welches Protokoll verwandt wird. Ich hatte NEC Videorekorder probiert und war überrascht, wieviele NEC-Rekorder keine NEC-Codes verwenden (vermutlich, weil baugleich von JVC übernommen).

Einen Hinweis habe ich in meiner Anleitung vergessen: Wenn Ihr für eine Taste als Tastencode 0x00 ermittelt, habt Ihr vermutlich die A...karte. Bei meinen Tests hat die so definierte Taste immer genau 1x funktioniert und danach nie wieder. Ich habe dann einen anderen Code auf der Taste angelernt.

jrie · 13. Oktober 2023

Zitat von Dr. Seltsam

Ich hatte NEC Videorekorder probiert

Mein Post war für TV, und da sind die Chancen recht gut.

Zabrimus · 14. Oktober 2023

Ich habe versucht das Tutorial von Dr. Seltsam für VDR*ELEC zu nutzen. Dafür gibt es den Branch 'amremote'. Wobei der Versuch ps3remote zu starten nur unternommen wird, wenn es die Datei /storage/.config/remote.conf überhaupt gibt. Ansonsten sollte das Verhalten der FB unverändert sein. Für meinen Test habe ich nur eine leere Datei angelegt.

Den Start von ps3remote mache ich fast genauso, wie Dr. Seltsam oben beschrieben hat. Später kann man schauen, was davon tatsächlich notwendig ist.

Soweit so gut:

Code

odroid2:~ # ls -la /dev/input/
total 0
drwxr-xr-x    3 root     root           160 Oct 14 11:59 .
drwxr-xr-x   15 root     root          4420 Oct 14 11:59 ..
drwxr-xr-x    2 root     root            60 Oct 14 11:59 by-path
crw-rw----    1 root     input      13,  64 Oct 14 11:59 event0
crw-rw----    1 root     input      13,  65 Oct 14 11:59 event1
lrwxrwxrwx    1 root     root             6 Oct 14 11:59 meson-remote -> event1
crw-rw----    1 root     input      13,  63 Oct 14 11:59 mice
crw-rw----    1 root     input      13,  32 Oct 14 11:59 mouse0

Es gibt noch ein Problem mit der systemd unit:

Code

○ amremote.service - Start amremote multi-user.target: Found ordering cycle on amremote.service/start
     Loaded: loaded (/usr/lib/systemd/system/amremote.service; disabled; preset: disabled)
     Active: inactive (dead)

Okt 14 11:59:50 odroid2 systemd[1]: multi-user.target: Found ordering cycle on amremote.service/start
Okt 14 11:59:50 odroid2 systemd[1]: multi-user.target: Found dependency on graphical.target/start
Okt 14 11:59:50 odroid2 systemd[1]: multi-user.target: Found dependency on remote-config.service/start
Okt 14 11:59:50 odroid2 systemd[1]: multi-user.target: Found dependency on multi-user.target/start
Okt 14 11:59:50 odroid2 systemd[1]: multi-user.target: Job amremote.service/start deleted to break ordering cycle starting with multi-user.target/start

Da müssen wohl die Abhängigkeiten noch korrigiert bzw. verbessert werden. Aber das ist nicht das eigentliche Problem.

Der manuelle Start von /usr/local/bin/ps3remote.py liefert nur

Python

odroid2:~ # /usr/local/bin/ps3remote.py 
Traceback (most recent call last):
  File "/usr/local/bin/ps3remote.py", line 27, in <module>
    from evdev import UInput, InputDevice, ecodes, categorize
ModuleNotFoundError: No module named 'evdev'

Stimmt der Name des Verzeichnisses nicht, oder muss noch etwas eingestellt/konfiguriert werden?

Code

odroid2:~ # ls -la /usr/lib/python/evdev
total 142
drwxr-xr-x    2 root     root           273 Oct 14 11:19 .
drwxr-xr-x    4 root     root            63 Oct 14 11:19 ..
-rw-r--r--    1 root     root         17760 Oct 14 11:19 device.pyc
-rw-r--r--    1 root     root          2656 Oct 14 11:19 ecodes.pyc
-rwxr-xr-x    1 root     root         34152 Oct 14 11:19 _ecodes.so
-rw-r--r--    1 root     root          6348 Oct 14 11:19 eventio_async.pyc
-rw-r--r--    1 root     root          5854 Oct 14 11:19 eventio.pyc
-rw-r--r--    1 root     root          8564 Oct 14 11:19 events.pyc
-rw-r--r--    1 root     root         11403 Oct 14 11:19 evtest.pyc
-rw-r--r--    1 root     root          7001 Oct 14 11:19 ff.pyc
-rw-r--r--    1 root     root          2819 Oct 14 11:19 genecodes.pyc
-rw-r--r--    1 root     root           811 Oct 14 11:19 __init__.pyc
-rwxr-xr-x    1 root     root         14172 Oct 14 11:19 _input.so
-rw-r--r--    1 root     root         13841 Oct 14 11:19 uinput.pyc
-rwxr-xr-x    1 root     root          9956 Oct 14 11:19 _uinput.so
-rw-r--r--    1 root     root          5634 Oct 14 11:19 util.pyc

Alles anzeigen

Ich hoffe, jemand kann den entscheidenden Tip geben

Dr. Seltsam · 14. Oktober 2023

In meiner Ubuntu-chroot liegt das in /usr/lib/python3/dist-packages/evdev/

Code

CoreELEC:~/UBUNTU/usr/lib/python3/dist-packages/evdev # ls -l
total 123
-rw-r--r--    1 root     root           547 Jan 12  2020 __init__.py
drwxr-xr-x    2 root     root          1024 Apr  9  2023 __pycache__
-rw-r--r--    1 root     root         34696 Feb 18  2020 _ecodes.cpython-38-aarch64-linux-gnu.so
-rw-r--r--    1 root     root         14880 Feb 18  2020 _input.cpython-38-aarch64-linux-gnu.so
-rw-r--r--    1 root     root         14656 Feb 18  2020 _uinput.cpython-38-aarch64-linux-gnu.so
-rw-r--r--    1 root     root         12732 Jan 12  2020 device.py
-rw-r--r--    1 root     root          2639 Jan 12  2020 ecodes.py
-rw-r--r--    1 root     root          3961 Jan 12  2020 eventio.py
-rw-r--r--    1 root     root          2823 Jan 12  2020 eventio_async.py
-rw-r--r--    1 root     root          5794 Jan 12  2020 events.py
-rw-r--r--    1 root     root          5538 Jan 12  2020 evtest.py
-rw-r--r--    1 root     root          4982 Jan 12  2020 ff.py
-rw-r--r--    1 root     root          2447 Jan 12  2020 genecodes.py
-rw-r--r--    1 root     root          9391 Jan 12  2020 uinput.py
-rw-r--r--    1 root     root          3190 Jan 12  2020 util.py

Alles anzeigen

Ich kenne mich mit python leider überhaupt nicht aus und war heilfroh, dass das Ubuntu-Paketmanagement sich um alles gekümmert hat. Die cpython-Dateien waren mit in dem Debian-Installationspaket von python-evdev enthalten

Zabrimus · 14. Oktober 2023

So. Das script /usr/local/bin/start_ps3remote.sh startet jetzt erfolgreich. Mit dem systemd script gibt es aber noch Probleme.

Ich habe in ps3remote.py den Modulpfad hinzugefügt:

Code

sys.path.append(r'/usr/lib/python')

Weiter bin ich aber noch nicht. Jetzt muss ich mal schauen, wie das mit der remote.conf funktioniert. Aber dazu kann ich keine allgemeine Konfiguration bereitstellen, da es einfach zuviele FB gibt und zudem auch noch individuell konfiguriert sein können.

Zumindest startet das ps3remote.py jetzt erfolgreich.

Zabrimus · 15. Oktober 2023

ps3remote wird jetzt endlich automatisch gestartet, wenn eine /storage/.config/remote.conf existiert. Die Links in /dev/input werden angelegt und augenscheinlich könnte man das testen.

Wenn ich das richtig verstanden habe, dann werden nur NEC Codes ausgewertet und da habe ich leider einen kleinen Mangel. Das Problem ist aber angegangen worden, weil ich auch mal sehen will, ob und wie es einen Unterschied gibt.

Ein neues Build wird vorbereitet, dauert aber ein paar Stunden. Also wird das erst heute Abend oder morgen früh verfügbar sein.

vdr_rossi · 15. Oktober 2023

...konnte es rudimentär zum laufen bringen. Mir fehlen noch ein paar vdr Tasten in /storage/.config/remote.conf bzw. ich muss mit dem eventcode mapping klar kommen.

Die beschriebene Möglichkeit (journalctl -fk) Tastencodes auszulesen, wenn amremote bereits läuft, listet bei mir (CE) keine Tastencodes.

Müsste dafür jetzt auf meson-ir zurück... Tastencode notieren, mapping verstehen u. prüfen...

Naja, warte nun auf das Build. Auch wegen Wakeup System.d Script -> setup_bl301.service

Dann schaue ich nochmal weiter.

Die "Arbeit" hat sich gelohnt. Die (paar) funktionierenden Tasten sind deutlich fluffiger bei mir.

Danke an alle Beteiligten!

p.s. URC1635 Code 4918 (NVidia) sendet NEC Codes.

Dr. Seltsam · 15. Oktober 2023

Zitat von vdr_rossi

Die beschriebene Möglichkeit (journalctl -fk) Tastencodes auszulesen, wenn amremote bereits läuft, listet bei mir (CE) keine Tastencodes.

eventlircd war gestoppt? Ich glaube, es muss erst der factory_code in der remote.config eingetragen sein. Danach die so ergänzte Konfiguration (noch ohne Tastenzuordnungen!) mit remotecfg /storage/.config/remote.conf einlesen.

Zitat

Müsste dafür jetzt auf meson-ir zurück... Tastencode notieren, mapping verstehen u. prüfen...

Weil man meson-ir ohnehin braucht, um die Einträge für den IR-wakeup-Code zu ermitteln, ist die von mir beschriebene Methode mit ir-keytable -u m.E. der einfachere Weg. Es ist in jedem Fall eine Puzzlearbeit, die Codes für die einzelnen Tasten zu ermitteln und richtig einzutragen.

vdr_rossi · 15. Oktober 2023

Zitat von Dr. Seltsam

eventlircd war gestoppt? ...

Ja, auch mit systemctl stop eventlircd vorweg kommen keine Codes im Journal... ok, /storage/.config/remote.conf hat neben factory_code bereits Tasten Einträge.

Hatte ja mit meson-ir angefangen... nun geht´s mir mehr um mapping oder einfach gegenchecken welche Taste(n) kommt an.

Morgen puzzle ich weiter.

Dr. Seltsam · 15. Oktober 2023

bei mir ging die Anzeige in journalctl -fk nach einem Reboot wieder. Bei einem zweiten Test reichte es

Code

rmmod meson-remote
modprobe meson-remote

zu machen.

Wie kann man jetzt testen, welcher Linux input event (KEY_ ...) beim Drücken der Taste erkannt wird? Das geht auch bei amremote mit evtest

Man muss dazu in der Abfrage die Nummer des aml_keypad eingeben. Die dann angezeigte ellenlange Liste der supported events kann man ignorieren. Am Ende steht Testing ... (interrupt to exit). Drückt man jetzt z.B. die 1 auf der FB, kommt bei richtiger Zuordnung in der remote.conf

Code

Event: time 1697378634.471512, type 1 (EV_KEY), code 2 (KEY_1), value 1

Das geht nur mit physikalischen input devices, nicht mit dem ps3remote device, das vom python-Script bereitgestellt wird. Da zwischen beiden das Mapping aber nicht verändert wird, ist das kein Problem. Man sieht halt nur bei evtest keine repeats (EV_REP).

Auf dem Wege zu vdr und Kodi könnte ein re-mapping allenfalls noch durch eventlircd stattfinden. Aber da dürfte in /etc/eventlircd.d nichts passieren.

Das einzige Re-Mapping, das bei jedem Booten durchgeführt wird, findet in /usr/lib/systemd/system/remote-config statt. Es wird dann nämlich nicht die eigentliche remote.conf konfiguriert, sondern eine 're-gemappte':

Code

   for f in $REMOTE_CONF_DIR/remote*.conf; do
    echo "configuring remote with $f"
    cp "$f" /tmp/remote.conf
    remap_keys /tmp/remote.conf
    remotecfg /tmp/remote.conf
    rm -f /tmp/remote.conf
  done

nachdem zuvor die Zuordnungen geändert wurden (hier mal aus dem Script 'entschlüsselt')

Code

keycode alt    Name alt            keycode neu   Name neu
63             KEY_F5              90            KEY_KATAKANA
97             KEY_RIGHTCTRL       28            KEY_ENTER
102            KEY_HOME            172           KEY_HOMEPAGE
125            KEY_LEFTMETA        46            KEY_C
128            KEY_STOP            45            KEY_X
139            KEY_MENU            46            KEY_C
142            KEY_SLEEP           116           KEY_POWER
143            KEY_WAKEUP          116           KEY_POWER
158            KEY_BACK            1             KEY_ESC
183            KEY_F13             59            KEY_F1
184            KEY_F14             399           KEY_GREEN
185            KEY_F15             400           KEY_YELLOW
186            KEY_F16             60            KEY_F2
232            KEY_REPLY           28            KEY_ENTER
240            KEY_UNKNOWN         164           KEY_PLAYPAUSE
241            KEY_VIDEO_NEXT      163           KEY_NEXTSONG
242            KEY_VIDEO_PREV      165           KEY_PREVIOUSSONG
244            KEY_BRIGHTNESS_AUTO 208           KEY_FASTFORWARD
245            KEY_DISPLAY_OFF     168           KEY_REWIND
264            BTN_8               63            KEY_F5
704            BTN_TRIGGER_HAPPY   116           KEY_POWER

Alles anzeigen

Nochmal zu Kodi: Das hat ja seine ganz eigenen Mechanismen, wie Tasten gemappt werden. In weiten Teilen ist mir das noch ein Buch mit 7 Siegeln. Es gibt aber ein addon "Key map Editor", mit dem man das per GUI konfigurieren kann.

Was ich bisher noch nicht herausgefunden habe: Wie kann man Kodi sagen, dass es nicht auf das von eventlircd bereitgestellte lirc-device hören soll, sondern nur direkt auf die input events von amremote? Kodi braucht nämlich weder Repeats (weil es die 'irgendwie' selbst erzeugt) noch benötigt es die lirc-Schnittstelle. Deshalb hört eventlircd auch gar nicht auf das aml_keypad (amremote) input device. Ob Kodi nun ohne den Umweg amremote -> python-Script ->ps3remote device > eventlircd besser laufen würde? Ich bin mir da noch nicht ganz sicher. Die FB läuft flüssig, aber gelegentlich scheint die KEY_ESC-Taste zu prellen. Das kann aber an meiner FB liegen.

Zabrimus · 15. Oktober 2023

Der Build ist endlich durch.

bl301 wird nicht automatisch aktiviert, sondern das muss einmal geschehen, wenn es erwünscht ist (ist auch im README beschrieben):

Code

cp /usr/local/system.d/setup_bl301.service /storage/.config/system.d
systemctl daemon-reload
systemctl enable setup_bl301.service
systemctl start setup_bl301.service

vdr_rossi · 15. Oktober 2023

Zitat von Dr. Seltsam
Wie kann man jetzt testen, welcher Linux input event (KEY_ ...) beim Drücken der Taste erkannt wird? Das geht auch bei amremote mit evtest
Man muss dazu in der Abfrage die Nummer des aml_keypad eingeben. Die dann angezeigte ellenlange Liste der supported events kann man ignorieren. Am Ende steht Testing ... (interrupt to exit). Drückt man jetzt z.B. die 1 auf der FB, kommt bei richtiger Zuordnung in der remote.conf
Code
Event: time 1697378634.471512, type 1 (EV_KEY), code 2 (KEY_1), value 1
...

Ok, auch bei gestopptem eventlircd (systemctl stop eventlircd) gibt evtest eine Meldung: This device ist grabbed by another process.

Code

    ...
    Event code 701 (?)
    Event code 702 (?)
    Event code 703 (?)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
    Event code 8 (REL_WHEEL)
Properties:
Testing ... (interrupt to exit)
***********************************************
  This device is grabbed by another process.
  No events are available to evtest while the
  other grab is active.
  In most cases, this is caused by an X driver,
  try VT-switching and re-run evtest again.
  Run the following command to see processes with
  an open fd on this device
 "fuser -v /dev/input/event3"
***********************************************

Alles anzeigen

Wenn ich den Prozess beende -> fuser -k /dev/input/event3

...werden Tastencodes ausgegeben, evtest Beispiel:

Code

Event: time 1697394995.291246, -------------- SYN_REPORT ------------
Event: time 1697394995.457225, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1697394995.457225, -------------- SYN_REPORT ------------
Event: time 1697394995.919018, type 1 (EV_KEY), code 46 (KEY_C), value 1

Das mapping bei KEY_ENTER darf in der vdr remote.conf (/storage/.config/vdropt/remote.conf) nicht umgebogen werden, wie in #44 beschrieben.

Sonst funktioniert die Taste bei laufendem eventlircd nicht im vdr.

Die Farbtasten (F1-F4) werden auch irgendwo umgebogen? Ausgabe evtest

Code

Testing ... (interrupt to exit)
Event: time 1697396031.473637, type 1 (EV_KEY), code 59 (KEY_F1), value 1
...

angepasste vdr remote.conf (/storage/.config/vdropt/remote.conf)

Code

...
LIRC.Red        KEY_F1
LIRC.Green      KEY_F2
LIRC.Yellow     KEY_F3
LIRC.Blue       KEY_F4
...

vorher war es z.B. KEY_RED usw.

Aber mit gestartetem eventlircd funktionieren Farbtasten nicht unter vdr.

Mir raucht für heute der Kopf.

Dr. Seltsam · 15. Oktober 2023

Den Test mit evtest hatte ich in chroot gemacht, da kam keine Fehlermeldung.

Die Mapping-Probleme kann ich nicht nachvollziehen. Ich habe auch nie gesagt, dass die Ok-Taste in /storage/.config/remote.conf als KEY_ENTER definiert werden soll. Wenn man sie als KEY_OK anlegt, bleibt das auch so. In vdr‘s remote.conf muss man dann natürlich auch Lirc.Ok KEY_OK zuweisen, aber das ist eigentlich der übliche Normalfall. Das ist bei all meinen vdr-Installationen schon immer Standard gewesen. Die einzige Abweichung beim Mapping ist die Menü-Taste, die man anders als sonst für vdr üblich als KEY_C anlegen muss.

Gibt es bei VDR*Elec denn eine vorbelegte remote.conf für vdr? Ich habe bislang keine gefunden.

Ich verstehe nicht, wieso eine Taste, die man in /storage/.config/remote.conf als KEY_RED anlegt, durch eventlircd zu KEY_F1 werden soll. Es gibt keine Mapping-Datei in /etc/eventlircd.d die sowas machen könnte. Ich muss dann wohl mal selbst VDR*Elec installieren und mir das anschauen. Im Moment habe ich aber keine freie SD-Karte.

Wenn man die Tasten so definiert, dass vdr richtig damit läuft, heisst das noch nicht, dass Kodi damit auch zurecht kommt! Entweder macht man die beiden remote.conf zueinander kongruent und justiert die Zuordnung dann in Kodi, z.B. über das erwähnte Addon. Oder man definiert die Tasten so, wie Kodi sie haben will (und ja, es ist möglich dass Kodi nicht KEY_OK sondern KEY_ENTER braucht). Dann muss man das mapping halt in vdr‘s remote.conf anpassen.

Linux wie wir es kennen und lieben. Jeder kocht sein eigenes Süppchen, und eine theoretisch simple Fernbedienungskonfiguration wird zur Raketenwissenschaft

Jetzt mitmachen!

Teilen