[0.4]XBMC- Einfacher Tastendruck -> Doppelte eingabe

  • das mit dem --unput habe ich auch noch nicht ganz verstanden. Das Konzept vom yaVDR ist doch, dass alles - auch der lircd - die Events in den eventlircd pumpt. Soll ich da was dran ändern?


    Also mit --uinput erzeugt lircd ein Eingabegerät unter /dev/input/event<X>, das von eventlircd mittels udev-Regel eingebunden wird (weil es lircd heißt). Das Problem dabei ist IMHO, dass zu viele Tastendrücke von der FB pro Tastendruck auf diesem Gerät ankommen. Mein Ansatz ersetzt nun das, was --uinput machen würde, erlaubt dabei abgestimmt auf die eigene Fernbedienung die Wunsch-Tastenwiederholrate usw. anzupassen und erstellt letztendlich auch ein Eingabegerät unter /dev/input/event<X>, das dann von eventlircd ausgewertet wird - nur ohne nervige Tastenpreller und mit auf Wunsch mehr an die eigenen Bedürfnisse angepasster Tastenwiederholrate.


    In deinem Fall brauchst du nur das Paket python-uinput aus dem yaVDR-PPA nachzuinstallieren, das Skript holen

    Code
    sudo apt-get update
    sudo apt-get install python-uinput
    sudo wget  -O /usr/bin/lircd2uinput.py https://raw.github.com/yavdr/yavdr-utils/master/lircd2uinput/lircd2uinput.py
    sudo chmod +x /usr/bin/lircd2uinput.py


    und den lircd_helper wie hier beschrieben anzupassen: [0.4]XBMC- Einfacher Tastendruck -> Doppelte eingabe
    lircd2uinput.py kannst du noch übergeben, wie es auf gedrückt gehaltene Tasten reagieren soll:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hmm,


    irgendwie hört sich das für mich nach "von hinten durch die Brust ins Auge" an. Aber es bringt schon mal ein bisschen Klarheit.


    Das was ich jetzt verstanden habe ist folgendes:


    So ist es:



    Code
    /var/run/lirc/lircd-usb~hiddev0 --- (Einfache Events siehe Post)
                           /
    usb receiver  --- lircd 
                           \
                            /dev/input/event<X>  --- (doppelte Events) --- eventlircd --- vdr


    Dein Vorschlag:


    Code
    /var/run/lirc/lircd-usb~hiddev0 --- (Einfache Events siehe Post)
                           /
    usb receiver  --- lircd 
                           \
                            (doppelte Events)  lircd2uinput.py  (einfache Events) --- /dev/input/event<X>  --- eventlircd --- vdr


    Ist es dann nicht einfach und zuverlässiger (weil kein patch) einfach den VDR direkt an den lircd zudocken, wie man das früher auch gemacht hat? Der VDR wird ja schon mit einer (wenn auch falschen) lirc-Config gestartet.


    Oder ein noch besserer Ansatz, aber dafür musste ich mehr vom eventlircd verstehen:
    Man macht den eventlircd heile, dass er mit den Events klar kommt.


    Gruß
    Thomas

    Asus S1-AT5NM10E, SSD, Mystique SaTiX-S2 Sky USB, Unicable/SCR, Terratec USB IR Receiver, video.00 per NFS auf QNAP 410
    VDR-User seit 2002

  • Mein Vorschlag:

    Code
    /var/run/lirc/lircd-usb~hiddev0 --- (Einfache Events siehe Post)
                           /
    usb receiver  --- lircd 
                           \
                            (absolut egal, ob einfache oder mehrfache Events, da es filtern kann):  lircd2uinput.py  (einfache Events) --- /dev/input/event<X>  --- eventlircd --- vdr


    Ist es dann nicht einfach und zuverlässiger (weil kein patch) einfach den VDR direkt an den lircd zudocken, wie man das früher auch gemacht hat? Der VDR wird ja schon mit einer (wenn auch falschen) lirc-Config gestartet.


    Wieso falsche lircd-config?
    Wenn du nur lircd nutzen willst, dann muss der VDR aber auf den Start von lircd warten. Meine Lösung ist für die nächste Version von yaVDR schon größtenteils in den Quellen und funktioniert bei mir und den anderen im yaVDR-Team, die noch lircd-Empfänger verwenden soweit ich gehört habe gut...

    Man macht den eventlircd heile, dass er mit den Events klar kommt.


    Warum sollte man eventlircd fixen, wenn es nicht kaputt ist (aber wenn du da was basteln willst hält dich keiner davon ab :unsch )?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wieso falsche lircd-config?

    Weil die VDR konfiguriert ist, dass es lirc benutzen soll. Ich weiss nicht, ob das ein Überbleibsel ist, weil ich mal lirc über das WFE konfiguriert habe:


    Aus dem Syslog:
    Jan 3 17:23:50 poempel vdr: [2414] ERROR: lircd connection broken, trying to reconnect every 3.0 seconds


    der VDR Prozess
    vdr 1160 1 9 17:24 ? 00:00:19 /usr/bin/vdr --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction [...]


    Wenn es ein Überbleibsel ist. Wie werde ich es wieder los? Habe schon die Templates durchgesehen, bin aber nicht fündig geworden.


    Wenn du nur lircd nutzen willst, dann muss der VDR aber auf den Start von lircd warten.

    Ahh O.K. das habe ich mittlerweile auch verstanden. Aber ich schätze ich habe da gerade eh ein Problem, dass VDR auf den Lircd wartet. s.o.


    Meine Lösung ist für die nächste Version von yaVDR schon größtenteils in den Quellen und funktioniert bei mir und den anderen im yaVDR-Team, die noch lircd-Empfänger verwenden soweit ich gehört habe gut...

    O.K. das hört sich doch auch gut an! Ein paar Verständnisfragen habe ich trotzdem noch s.u.

    Zitat von »poggenpower«




    Man macht den eventlircd heile, dass er mit den Events klar kommt.

    Warum sollte man eventlircd fixen, wenn es nicht kaputt ist (aber wenn du da was basteln willst hält dich keiner davon ab :unsch )?

    Nee, will ja eben nicht basteln. Nach ein wenig nachdenken, liegt das unterschiedliche Verhalten ja im LIRCD.
    Was ich noch nicht verstehe sind zwei Dinge:


    1. Unterschiedliche Events
    Warum schickt der lircd unterschiedliche (Anzahl) an Events an die unterschiedlichen sockets

    • /var/run/lirc/lircd-usb~hiddev0: alles im grünen Bereich
    • /dev/input/event<X> : Events in drei unterschiedliche Varianten und die in unkontrollierter Dopplung.

    Könnte da eventlirc nicht einfach direkt von /dev/usb/hiddev0 Daten einsammeln.
    Oder kann man dem lircd bei der Option -uinput beibringen die Events so zu schicken wie auf dem Standardsocket.
    Ich will nicht die Arbeit an dem phython-wrapper schlecht machen, es geht mir drum, dass was an einer stelle schon richtig ist nicht an einer anderen Stelle noch mal zu korrigieren.


    2. Drei Varianten
    Laut den Traces, die ich gepostet, habe funktioniert der Eventlirc IMHO richtig, es gibt keine Dopplung der einzelnen Events mehr gibt. Nur scheint es drei Typen (Nummeriert 1,2,3) zu geben, die der Lircd ins Userland schickt. Hat jemand einen Tipp, warum es die drei unterschiedlichen Events gibt?
    Würde der python-warpper das auch kompensieren oder auf welchen der drei Typene reagiert er?
    Gibt es eine Beschreibung wie python-uinput funktioniert? und wo es sich die Events herholt und ausgibt.


    Gruß
    Thomas

    Asus S1-AT5NM10E, SSD, Mystique SaTiX-S2 Sky USB, Unicable/SCR, Terratec USB IR Receiver, video.00 per NFS auf QNAP 410
    VDR-User seit 2002

  • Was das Thema lircd und uinput angeht : lircd schickt die uinput Tastendrücke irgendwo mitten in der Verarbeitungskette - ob man das jetzt einen Bug nennt oder gewünscht - ich nenne es mal Fehlverhalten, seahawkslsg setzt sich auf den lircd-Sockel von lircd und wandelt die dort ankommenden Tastendrücke nach uinput um damit es über eventlircd zusammengefasst werden kann. Und ja genau für diesen Fall ist seine Lösung gedacht.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • der VDR Prozess
    vdr 1160 1 9 17:24 ? 00:00:19 /usr/bin/vdr --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction [...]
    Wenn es ein Überbleibsel ist. Wie werde ich es wieder los?


    Das ist kein Überbleibsel. Wenn du dir die Templates, die Upstart-Skripte (unter /etc/init/) und die udev-Regeln (/lib/udev/rules.d) durchsiehst merkst du, dass /var/run/lirc/lircd der Socket ist, auf dem Eventlircd dem VDR die gesammelten Eingabeevents übergibt. Lircd hat - wenn es über das WFE aktivert ist für Serielle Empfänger einen Socket, der als /var/run/lirc/lircd.<pid von lircd> angelegt wird, für USB-Lirc-Empfänger wird (in der /lib/udev/rules.d/98-lircd.rules) per udev-Regel der Start des /lib/udev/lircd_helper ausgelöst - ein Socket von so einem Lircd-Prozess, der von diesem Skript gestartet wurde heißt dann z.B. /var/run/lirc/lircd-usb~hiddev0


    Könnte da eventlirc nicht einfach direkt von /dev/usb/hiddev0 Daten einsammeln.


    Eventlircd sammelt wie der Name schon sagt Tastendrücke von Eventgeräten (/dev/input/event<X>) ein und gibt sie über einen Lircd-Socket wieder aus. Meine Bridge macht also nichts anderes als eventlircd ein sinnvoll verwertbares Eventgerät ohne Tastenpreller zur Verfügung zu stellen. Von gda gab es bereits einen Patch zu eventlircd, der dessen Repeat-Filter einstellbar gemacht hat - das Problem mit einem Nachlaufen der Fernbedienung bei länger gedrückt gehaltener Taste wurde dadurch aber eher noch verstärkt, daher mein Ansatz.


    Oder kann man dem lircd bei der Option -uinput beibringen die Events so zu schicken wie auf dem Standardsocket.


    Kann man sicherlich, nur muss man es auch können - wie gesagt wenn sich jemand da um sinnvolle Änderungen verdient machen will nur zu...


    Nur scheint es drei Typen (Nummeriert 1,2,3) zu geben, die der Lircd ins Userland schickt.


    Jein, bei Eventgeräten gibt es 0 = Taste losgelassen 1 = Taste gedrücht und 2 = wiederholter Tastendruck (siehst du bei evtest in deiner Ausgabe, dass es da prellt/eine Taste fälschlicherweise als gedrückt gehalten erkannt wird).

    Zitat

    Das wirft evtest heraus, bei einem klick auf "OK"

    -


    Ich weiß nicht was du beobachtet hast aber das ist der Socket von Eventlircd und da zählt irw einfach nur hoch, was ja (falls das Einzeltastendrücke sein sollen) zeigt, dass es prellt:

    Zitat
    Code
    root@poempel:~# irw 
    67 0 KEY_UP devinput
    67 1 KEY_UP devinput
    67 2 KEY_UP devinput
    160 0 KEY_OK devinput
    160 1 KEY_OK devinput
    160 2 KEY_OK devinput
    [...]


    Könnte da eventlirc nicht einfach direkt von /dev/usb/hiddev0 Daten einsammeln.


    Ganz ohne lircd dazwischen? Dann müsstest du einen auf deine FB/Empfängerkombination angepassten Treiber schreiben, damit eventlircd valide Tastenevents bekommt...


    Gibt es eine Beschreibung wie python-uinput funktioniert? und wo es sich die Events herholt und ausgibt.


    python-uinput ist nur eine Python-Bibliothek, die es erlaubt ein Eventgerät zu erzeugen und darauf Tastendrücke auszugeben. Schau dir doch einfach mal den Code an (ist bei Python ja nicht schwer da ranzukommen ;). Mein Skript (das von einem Lircd-Sockel liest und dann mittels python-uinput die Events weitergibt) findest du bei GitHub: https://github.com/yavdr/yavdr…/tree/master/lircd2uinput

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo!


    Vielen Dank für die vielen und sehr ausführlichen Antworten! Das gibt insbesondere seahawk!
    Jetzt verstehe ich schon viel mehr und die lircd2uinput Lösung gefällt mir immer besser.


    Zu mal ja auf dem lircd-Socket schon entprellte Events ankommen, sollte da ja nicht mehr viel schief gehen.


    Danke
    Thomas


    P.S: ich werde von meinem Erfolg berichten

    Asus S1-AT5NM10E, SSD, Mystique SaTiX-S2 Sky USB, Unicable/SCR, Terratec USB IR Receiver, video.00 per NFS auf QNAP 410
    VDR-User seit 2002

  • Jupp funktioniert alles wie es soll.
    Leider wiederholt die FB bei einer gedrückten Taste über den Lirc-Socket die Events nicht, so dass gar kein automatisches Scrollen möglich ist.
    Aber das ist jetzt wirklich eine Eigenart des samsung-Treibers.


    Danke noch mal!


    Gruß
    Thomas

    Asus S1-AT5NM10E, SSD, Mystique SaTiX-S2 Sky USB, Unicable/SCR, Terratec USB IR Receiver, video.00 per NFS auf QNAP 410
    VDR-User seit 2002

  • Hallo Mitstreiter,
    hab mir für heute vorgenommen die Alternativlösung von seahawk1986 zu testen und hab brav apt-get upgrade und dist-upgrade gemacht und schau „irw“ und kein prellen – der Repeat-Filter sollte ja auf 2 stehen und mindestens 3 Einträge bringen - nix.


    Ist die Lösung schon im Paket dabei ?

  • Nicht dass ich wüsste.. An den relevanten Paketen wurde noch nichts geändert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • So, ich habe ein paar Probleme in lircd2uinput.py behoben - wer das nutzt, sollte sich die aktuelle Version von Github holen: lircd2uinput.py und nach /usr/bin/lircd2uinput.py kopieren.


    Neu hinzugekommen: die Lautstärketasten reagieren schneller und die Bedienung ist durch das Beheben von zwei kleinen Bugs noch einmal deutlich flüssiger geworden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi Seahawk,
    loggt:

    Code
    Jan 24 19:31:47 ante lircd2uinput.py: Started lircd2uinput.py with these options:
    Jan 24 19:31:47 ante lircd2uinput.py: wait_repeats = 2
    Jan 24 19:31:47 ante lircd2uinput.py: max_gap = 350000
    Jan 24 19:31:47 ante lircd2uinput.py: min_gap = 150000
    Jan 24 19:31:47 ante lircd2uinput.py: acceleration = 0.25


    rennt prima soweit der kurztest zeigt, kann es sein das der erste druck auf vol ignoriert wird?
    macht nix man muss ja eh mehrfach drücken


    Danke
    Ulf

    Samsung UE43RU7479U, Antec Fusion Black, Prime A320m-k, Ryzen3 3200G, 2* DVB-T2,
    Yavdr-ansible auf Ubuntu Server 22.04

  • kann es sein das der erste druck auf vol ignoriert wird?


    Ja, danke für den Hinweis (meine Fernbedienung feuert so schnell, das es mir nicht direkt aufgefallen ist). Ich muss mal schauen, wie ich das am besten löse, ohne die Tastenwiederholung für die Lautstärketasten aufzugeben.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi alle,


    ich hatte das selbe Problem, wie hier von vielen beschrieben.
    Fernbedienung ist ne Harmony One, Empfaenger ist ein Samsung USB.


    Der Weg von Seahawk1986 funktioniert soweit prima! Es gab keinerlei Probleme. Scheint alles zu klappen!! Vielen Dank dafuer!!


    Wg dem Zusammenspiel von lircd, eventlircd gab es hier ein gutes Diagramm..


    Nochmal vielen Dank..
    Gruss, blogga

  • 'Nabend,


    ich habe das gerade mit einem Atric-Empfänger und einer Hauppauge FB ausprobiert. Aber egal was ich in der "/etc/init/lircd2uinput.conf" für Optionen mit übergebe, es ist recht lahm. eventlircd habe ich natürlich neu gestartet und im syslog sieht man auch, dass das Skript mit den Parametern gestartet wurde.
    Die Ausgaben von "irw" und "irw /var/run/lirc/lircd.$(pidof lircd) " sind deutlich schneller.


    Gruß

    ASUS M4A78LT-M GL | AMD Athlon II X2 250 | 2GB RAM | Asus ENGT430 | Digital Devices OctopusNet mit 2 x Digital Devices DuoFlex S2 | PS3Remote | yaVDR 0.6.1

  • Hast du auch den repeat-Filter von eventlircd ausgeschaltet?
    In der /etc/init/eventlircd.conf "--repeat-filter" aus den Startargumenten entfernen und den Dienst oder Rechner neu starten.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das hatte ich natürlich vergessen. :wand


    ABER, auch wenn ich es entferne wird es ehrlich gesagt nicht besser. Vielleicht verstehe ich die Optionen auch verkehrt!? Mit welchen Optionen sollte es denn auf jeden Fall schneller werden?

    ASUS M4A78LT-M GL | AMD Athlon II X2 250 | 2GB RAM | Asus ENGT430 | Digital Devices OctopusNet mit 2 x Digital Devices DuoFlex S2 | PS3Remote | yaVDR 0.6.1

  • Womit startest du es denn aktuell?
    Es gibt den "--max-gap", der legt die Zeitspanne zwischen den ersten Tastendrücken fest (Standard 300000 µs) - wenn man den herunterdreht, hat man vom Start weg eine höhere Tastenwiederholrate. Nach Ablauf der "--min-repeats" (Standard 2 Stück) beschleunigt die Fernbedienung in per "--acceleration" (Standard 0.25 - also vier Schritte) festgelegten Stufen, bis sie den "--min-gap" (Standard 150000 µs) erreicht hat.


    Da der VDR und XBMC unterschiedliche eigene Repeat-Filter besitzen, muss man da einen Kompromiss finden, damit die Tasten in XBMC nicht prellen. Falls man direkt ein konstant schnelles Ansprechen haben will, sollte man --max-gap und --min-gap gleich setzen.Bei mir funktionieren sowohl im VDR als auch in XBMC folgende Einstellungen IMHO sehr brauchbar (mit Ausnutzung der Beschleunigungsfunktion):

    Code
    --max-gap=250000 --min-gap=100000


    Falls es noch flotter gehen soll, kannst du mal die entsprechenden Tasten in die Variable "self.specialkeys" (Zeile 98 des Skripts) aufnehmen also z.B. :

    Code
    self.specialkeys = [(1, 114),(1, 115), uinput.KEY_UP, uinput.KEY_DOWN, uinput.KEY_RIGHT, uinput.KEY_LEFT]

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Mit deinen Optionen läuft das bei mir sehr träge. Um 10 Zeilen im OSD zu durchlaufen benötigt es ca. 5 Sekunden. Also viel zu lang. Auch Werte, die um den Faktor 10 kleiner sind, helfen nicht wirklich.


    Mit der Änderung in "/usr/bin/lircd2uinput.py" geht's jetzt deutlich schneller. Jetzt muss ich noch passende Werte für "--max-gap" und "--min-gap" finden.

    ASUS M4A78LT-M GL | AMD Athlon II X2 250 | 2GB RAM | Asus ENGT430 | Digital Devices OctopusNet mit 2 x Digital Devices DuoFlex S2 | PS3Remote | yaVDR 0.6.1

Jetzt mitmachen!

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