yavdr ansible - zweite Fernbedienung (mceusb) wird nicht richtig eingebunden

  • Hallo,


    nach erfolgreichem Start mit yavdr-ansible hakt es jetzt mit der Einbindung der zweiten Fernbedienung.

    Neben einem im Gehäuse vorhandenen imon-Empfänger habe ich noch einen externen über USB angebundenen Empfänger.

    Diese Kombi läuft mit eigenen Keymaps in yavdr6 seit Jahren problemlos.

    Unter ansible wird nur der imon-Empfänger richtig erkannt und die eigene modifizerte Keymap geladen.

    Den externen MCE-Empfänger schnappt sich irgendwie lirc.


    ir-keytable -v liefert folgendes:


    Eine probeweise Installation mit Ubuntu 18.04 Desktop führt zu zwei funktionierenden Fernbedienungen.


    Der Unterschied scheint ein laden von lirc_dev zu sein.


    lsmod liefert:


    Da weiß ich jetzt aber nicht mehr weiter.

    Das übliche Vorgehen mit irw, evtest und mode2 habe ich schon probiert - immer nur Ausgaben bei rc0.


    Gruß


    joe_pow

  • Lirc sollte nicht nötig sein, solange du ein IR-Protokoll nutzt, für das es im Kernel Dekoder gibt (also eines aus unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp).


    Welches IR-Protokoll und welche Keytable willst du denn mit dem Empfänger nutzen? Wenn du mit ir-keytable die Einstellungen für einen anderen Empfänger als rc0 ändern willst, musst du das Device mit angeben, also z.B. sudo ir-keytable --sysdev rc1 -P rc-6, um das IR-Protokoll auf rc-6 zu setzen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich gehe eigentlich genauso vor wie in yavdr6.


    Zuerst habe ich das Template der rc_maps.cfg auf meine Bedürfnisse angepasst:

    Die entsprechenden Keymaps sind hinterlegt und funktionieren genauso in yavdr6.

    rc6-jg:

    und rc-imon-pad-jg:


    Komischerweise werden automatisch beide Keymaps richtig geladen, nur bei der mce Fernbedienung wird RC6 nicht aktiviert.

    Ein manuelles Ausführen von sudo ir-keytable -s rc1 -a /etc/rc_maps.cfg aktiviert dann auch rc6, Protokoll lirc bleibt aber auch aktiviert:

    Code
    1. /sys/class/rc/rc1/ gefunden (/dev/input/event7) mit:
    2. Name: Media Center Ed. eHome Infrared Remote Transceiver (147a:e042)
    3. Treiber: mceusb, Tabelle: rc-rc6-mce
    4. Lirc Gerät: /dev/lirc0
    5. unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
    6. Aktivierte Protokolle: lirc rc-6
    7. zusätzliche Fähigkeiten: <Zugriff verweigert>

    Auch jetzt keine Reaktion mit irw, evtest etc.

  • Lirc Gerät: /dev/lirc0

    Gibt es da eventuell einen Prozess, der auf /dev/lirc0 zugreift? Eventuell sieht man da mit fuser etwas.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ein sudo fuser -v /dev/lirc0 bringt eine leere Ausgabe.


    Was mir auffällt im Vergleich zu einem Live-Ubuntu-Desktop ist das zusätzliche Laden der Module "lirc_dev" und "ir_lirc_codec", die bei meiner Konstellation nicht nötig sein sollten.

    Wie kann ich herausfinden, wo dies geschieht?

  • Hast du mal versucht die beiden Module zu blacklisten?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von seahawk1986 ()

  • So, bin jetzt einen kleinen Schritt weiter.

    Da blacklisten nichts half und die Hardwareerkennung mit Ubuntu Desktop offensichtlich anders funktioniert, habe ich einfach mal eine Ubuntu Desktop (minimal) Installation vorgenommen.

    Anschließend mit der Holzhammermethode X11 entfernt sudo apt-get purge libx11.* libqt.*

    Danach lief das Playbook ohne Probleme durch und führte zu einer funktionierenden ansible-Installation.


    Ein ir-keytable liefert jetzt:


    Leider greift die rc_maps.cfg nur für den imon-Empfänger.


    Ein manueller Aufruf von sudo ir-keytable -s rc0 -a /etc/rc_maps.cfg setzt aber das Protokoll rc-6 richtig und beide Fernbedienungen laufen wie gewünscht.


    Jetzt bleibt nur die Frage, warum die Automatik nicht durchläuft.

  • Da blacklisten nichts half und die Hardwareerkennung mit Ubuntu Desktop offensichtlich anders funktioniert, habe ich einfach mal eine Ubuntu Desktop (minimal) Installation vorgenommen.

    Eigentlich sollte es da keinen Unterschied geben - der Empfänger wird über udev erkannt und dann reagieren Udev-Regeln und Dienste darauf. Wenn eventlircd läuft, öffnet es das Gerät exklusiv, d.h. wenn man mit ir-keytable Tastendrücke sehen will, muss man den Dienst (und die Socket-Activation) zuvor stoppen: systemctl mask --now --runtime stop eventlircd.service eventlircd.socket


    In MCE Remote mit 1804+Ansible verhält sich komsich gab es ein ähnliches Problem - ist das eventuell das selbe in grün?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Auch die probeweise Installation über die Mini.iso lieferte die Einbindung über lirc_dev. Da auch dabei ein blacklisten nichts half, habe ich einfach mal die Module "lirc_dev" und "ir-lirc-codec" umbenannt, so dass sie nicht mehr gefunden wurden.


    Und siehe da - alles funktioniert problemlos, auch über Reboot und An- und Abstecken hinweg.


    Mittlerweile habe ich auch in http://www.lirc.org/html/configuration-guide.html gesehen, dass die Standardkonfiguration von lirc nur mit einer Fernbedienung funktioniert. Ich verstehe aber die Zusammenhänge mit vdr nicht ganz und würde es gerne sauber konfigurieren, so dass ich nach einem Kernel-Update nicht jedesmal die Module umbenennen muss.

  • Lirc wird von yavdr-ansible eigentlich nicht gestartet, solange es keinen Atric IrWakeupUSB oder eine yaUsbIR findet - dessen Dienste sollten dann vom Playbook maskiert werden: https://github.com/yavdr/yavdr…remote/tasks/main.yml#L26.


    Die Eingaben von Kernel Input Devices mit einen entsprechenden udev-Tag werden von eventlircd gelesen auf dessen lircd-kompatiblen Sockel ausgegeben, von dem der VDR (und KODI) lesen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Tja, ist wohl offensichtlich kein yavdr-Problem.


    Nachdem "normales" Blacklisten nicht funktionert hat, bin ich testweise mal so vorgegangen (Module aber eingetragen in blacklist.conf):

    Manuelles entfernen der Module mit sudo rmmod ir_lirc_codec und sudo rmmod lirc_dev

    Anschließend sudo depmod -a und sudo update-initramfs -u

    Nach einem Reboot erscheinen zwar wieder die Module mit lsmod, es funktioniert aber alles.


    Ich kapier es zwar nicht, gebe jetzt aber auf und warte mal auf das nächsten Kernel-Update.