yaVDR und [irmp]lircd Fernbedienungen – eine grundsätzliche Frage

  • Was ist denn an der Reihenfolge falsch?

    Also die Wertebelegung für die KEY_EV ist folgendermaßen:

    value 0: Key-Release

    value 1: Key-Down

    value 2: Key-Repeat


    Beim ersten Beispiel kommt der Key-Release vor den Key-Repeats, die dann von eventlircd ignoriert werden, weil es direkt davor kein Key-Down Event gab, sondern die Taste wieder losgelassen wurde.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • OK.

    Dann muss da noch ein zweiter Faktor mitspielen.

    Kann es sein, dass dein lircd2uinput das /dev/uinput so konfiguriert, dass keine Wiederholungen automatisch generiert werden bzw. die Intervalle vergrößert, während lircd-uinput das auf den viel zu schnellen Defaults lässt?


    Ich kann den Release hinter die Repeats stellen, aber dann funkt mir ja der automatische Repeat dazwischen. Deswegen muss der abgestellt oder zumindest geändert werden.


    Ich habe nur noch nicht heraus bekommen, an welcher Stelle lircd2uinput (bzw. die zugrunde liegende Lib) das macht. Wenn ich wüßte, wie das geht, könnte ich das übernehmen.

    Weißt du das?

  • python-uinput nutzt (über ctypes) die C-Bibliothek libsuinput: https://github.com/tuomasjjras…ut/tree/master/libsuinput

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Kann es erst in den nächsten Tagen testen, aber ich denke, mit release-timeout=125 und Repeat-Delay=500 für uinput (per ir-keytable Parameter oder ev. per lircd-uinput Parameter) sollte es gehen (jedenfalls RC-5).


    In den Sourcen von libsuinput hatte ich nichts gefunden, möglicherweise wird Repeat-Delay und Repeat-Period schon im Kernel je nach System anders eingestellt (ich meine die Repeat-defaults von uinput)?

  • Wenn ich das richtig verstehe, setzt lircd-uinput das EV_REP Flag (https://sourceforge.net/p/lirc…ons/lircd-uinput.cpp#l565), das laut https://www.kernel.org/doc/Doc…ion/input/event-codes.txt die automatische Tastenwiederholung anschaltet. libsuinput macht das nicht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Schau mal in Post #5: https://github.com/tuomasjjras…master/src/suinput.c#L186

    Soweit ich das verstehe, macht libsuinput das auch, oder sehe ich das falsch?

  • Es hapert jetzt noch daran, dass lircd-uinput immer nach seinem timeout einen release absetzt, statt das nur dann zu tun, wenn innerhalb der Zeit kein weiterer Knopf gedrückt wird.

    Das muss noch geändert werden. Dazu muss ich erst mal curl_poll verstehen ...


    Mit -R kann man Repeat-Delay und Repeat-Period einstellen:

    ./lircd-uinput -R 5000,1000 -a

  • Bei mir geht es jetzt :) .


    ./irmplircd -t ./irmp_stm32.map -r 300 -s 100

    irmplircd läuft mit 300 ms Repeat-Delay und 100 ms Repeat-Period, und da RC-5 alle 114 ms feuert, kommt dabei tatsächlich ein Delay von 342 ms und ein Repeat von 114 ms zustande.


    In der lirc_options.conf habe ich unter [lircd-uinput] release-timeout = 400 um die 342 ms zu überbrücken.

    Der Start und die ersten Meldungen von lircd-uinput:

    Das kernel repeat delay muss größer als der release-timeout sein.


    irw:

    Code
    1516102345.485184:
    070000001d00 0 KEY_UP IRMP
    1516102345.826071:
    070000001d00 1 KEY_UP IRMP
    1516102345.940125:
    070000001d00 2 KEY_UP IRMP
    1516102346.054072:
    070000001d00 3 KEY_UP IRMP


    evtest:

  • Test mit eventlircd:


    irw am irmplircd Sockel:

    1516111033.135733: 070000001300 0 KEY_RIGHT IRMP

    1516111033.476740: 070000001300 1 KEY_RIGHT IRMP

    1516111033.590703: 070000001300 2 KEY_RIGHT IRMP

    1516111033.704884: 070000001300 3 KEY_RIGHT IRMP

    1516111033.817814: 070000001300 4 KEY_RIGHT IRMP

    1516111033.931879: 070000001300 5 KEY_RIGHT IRMP

    1516111034.045748: 070000001300 6 KEY_RIGHT IRMP


    ./eventlircd -vvv -f -s /var/run/lirc/lircd2

    eventlircd[543]: input device /dev/input/event11: events of unsupported event type EV_REP will be discarded

    eventlircd[543]: input device /dev/input/event11: grabbed

    eventlircd[543]: input device /dev/input/event11: created output event device


    irw am eventlircd Sockel:

    1516111033.136306: 6a 0 KEY_RIGHT devinput

    1516111033.480819: 6a 1 KEY_RIGHT devinput

    1516111033.590948: 6a 2 KEY_RIGHT devinput

    1516111033.705035: 6a 3 KEY_RIGHT devinput

    1516111033.817966: 6a 4 KEY_RIGHT devinput

    1516111033.932029: 6a 5 KEY_RIGHT devinput

    1516111034.045983: 6a 6 KEY_RIGHT devinput

  • Mein lirc hatte ich mir aus dem git geholt:

    git clone git://git.code.sf.net/p/lirc/git lirc

    Das Binary hatte ich auf openSuse gebaut.

  • Auf LibreELEC hat der -R 5000,1000 anscheinend keine Wirkung, da muss man das mit ir-keytable -D 5000 -P 1000 -d /dev/input/event9 machen.

    Allerdings greift da noch eine andere Beschleunigung, der Cursor ist viel schneller als evtest anzeigt.

  • Mit eventlircd oder wenn der X-Server die Events weiterreicht?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, aber kommen die Events über eventlircd zu KODI oder wertet es die Events des X-Servers aus?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das sind meine ersten Schritte auf LibreELEC, und ich habe leider keine Ahnung ;) .

    Soweit ich mich erinnere, hatte ich mal ardelay und arinterval ausprobiert, aber dann die Lösung ohne eventlircd bevorzugt (da gab es meinen Patch noch nicht).

    Ich denke, ich frage mal im LibreELEC Forum an.


    Wie macht yaVDR das denn?

  • So wie im deinem ersten Post erwähnt - alles, was einen lirc-kompatiblen Sockel anbietet wird an lircd2uinput gehängt, das reicht die Tastendrücke an eventlircd weiter und VDR und KODI arbeiten am Sockel von eventlircd als Lirc-Clients.


    Damit das bei KODI funktioniert, braucht es eine Lircmap.xml, die Definitionen für ein Gerät mit dem Namen "devinput" enthält - die könnte z.B. so aussehen: https://github.com/yavdr/yavdr…s/userdata/Lircmap.xml#L4 und diese Tasten werden dann über die remote.xml auf KODI-interne Tastennamen gemapped.


    Ich habe heute noch mal die aktuelle Version von lircd2uinput mit einer bekannt prellenden Fernbedienung (die sendet 3 Frames für einen einzelnen Tastendruck) auf ein KODI 17 losgelassen, das hat die initialen Tastenwiederholungen genauso brav weggefiltert wie der VDR.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Jetzt geht es (ich hatte was übersehen).

    Es ist ein Feature von Kodi, dass nach ein paar Wiederholungen beschleunigt wird. Das ist für das Scrollen durch lange Listen gut. Die Tastendrücke kommen jetzt so an, wie sie sollen und werden anfangs auch im richtigen Tempo umgesetzt.


    Code
    Install irmplircd on LibreELEC via ssh:
    cd ~
    wget https://raw.githubusercontent.com/j1rie/IRMP_STM32/master/irmplircd/LibreELEC/irmplircd.tar.bz2
    tar -xjvf irmplircd.tar.bz2
    systemctl enable irmplircd lircd-uinput
    shutdown -r now


    Ein Problemchen habe ich noch.

    Meine irmplircd.service:

    Meine lircd-uinput.service:

    Meine 80-irmp.rules:

    Code
    KERNEL=="hidraw*", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4444", SYMLINK+="irmp_stm32", TAG+="systemd"

    Damit kann ich den Empfänger im laufendem Betrieb an- und abstecken, und es tut wie gewünscht.

    Ich lasse das über dev-irmp_stm32.device laufen, damit er den Symlink @irmp_stm32 anlegt, damit meine Konfigurationsprogramme den Empfänger automatisch finden.

    Wenn aber beim Hochfahren der Empfänger nicht dran hängt, zeigt er mir 90 Sekunden lang "A start job is waiting for dev-irmp_stm32.device". Das soll nicht so sein.

    Eigentlich dachte ich, er tut nur was, wenn das Device da ist. Aber wieso wartet er auf es, wenn es nicht da ist?

    Wie kann ich das verbessern?

  • Wie kann ich das verbessern?

    Ich habe das für irmplircd so gelöst - damit hängt es rein an der Erkennung der Hardware über udev, ob die Systemd-Unit gestartet wird oder nicht:

    Code: irmplircd.udev
    ACTION=="add", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="27d9", TAG+="systemd", ENV{SYSTEMD_WANTS}="irmplircd@%k.service"
    ACTION=="add", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4444", TAG+="systemd", ENV{SYSTEMD_WANTS}="irmplircd@%k.service"
    Code: irmplircd@.service
    [Unit]
    Description=irmplircd - a daemon for IRMP receivers
    
    [Service]
    Type=forking
    Environment="SOCKET=/var/run/lirc/irmplircd" "KEYMAP=/etc/irmplircd/irmplicd.map"
    EnvironmentFile=-/etc/default/irmplircd
    ExecStart=/usr/bin/irmplircd -t ${KEYMAP} -d ${SOCKET}-%I /dev/%I
    SuccessExitStatus=0 71

    Und das Paket yavdr-hardware-irmp ergänzt dann das Drop-In für lircd2uinput:

    Code: irmplircd@.service.d/lircd2uinput-hooks.conf
    [Service]
    ExecStartPost=/usr/bin/lircd2uinput-add ${SOCKET}-%I
    ExecStopPost=/usr/bin/lircd2uinput-remove ${SOCKET}-%I

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Mit Requisite statt BindsTo in irmplircd.service geht es.

    Alles funktioniert und das Thema ist voll zufriedenstellend erledigt :) .


    seahawk1986, vielen Dank für deine Unterstützung!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!