yaUSBir mit lirc 0.9.4

FireFly · Aug 15th 2017

Hallo zusammen,

ich habe den lirc-Patch für yaUSBir für lirc -0.9.4c angepasst (siehe Anhang) und grundsätzlich funktioniert die Fernbedienung auch gut damit (nur Empfang getestet, für das Sendemodul fehlen mir die Testmöglichkeiten).

Allerdings wird das yaUSBir Modul nach ca 15-20 min von usbcore abgehängt, da es angeblich nicht mehr reagiert

Code

/var/log/messages
Start:
2017-08-15T08:33:40.570765+02:00 hdvdr lircd-0.9.4c[1084]: Notice: accepted new client on /var/run/lirc/lircd
2017-08-15T08:33:40.571462+02:00 hdvdr lircd-0.9.4c[1084]: Info: yaUsbIr: Initializing yaUsbIr
2017-08-15T08:33:40.572400+02:00 hdvdr lircd[1084]: lircd-0.9.4c[1084]: Notice: accepted new client on /var/run/lirc/lircd
2017-08-15T08:33:40.573069+02:00 hdvdr lircd[1084]: lircd-0.9.4c[1084]: Info: yaUsbIr: Initializing yaUsbIr
2017-08-15T08:33:40.583461+02:00 hdvdr lircd[1084]: lircd-0.9.4c[1162]: Notice: yaUsbIr: device: vid=10C4, pic=876C, with 1 interface
2017-08-15T08:33:40.584121+02:00 hdvdr lircd-0.9.4c[1162]: Notice: yaUsbIr: device: vid=10C4, pic=876C, with 1 interface
2017-08-15T08:33:40.590199+02:00 hdvdr lircd-0.9.4c[1162]: Notice:          Manufacturer: UG Development Lab#012                Product: yaUsbIR V3:IR transceiver with power switch#012                hid interface (generic)
2017-08-15T08:33:40.590845+02:00 hdvdr lircd-0.9.4c[1162]: Notice: yaUsbIr: in use by driver "dummy"
2017-08-15T08:33:40.591242+02:00 hdvdr lircd[1084]: lircd-0.9.4c[1162]: Notice:          Manufacturer: UG Development Lab
2017-08-15T08:33:40.591592+02:00 hdvdr lircd[1084]:                 Product: yaUsbIR V3:IR transceiver with power switch
2017-08-15T08:33:40.591957+02:00 hdvdr lircd[1084]:                 hid interface (generic)
2017-08-15T08:33:40.592265+02:00 hdvdr lircd[1084]: lircd-0.9.4c[1162]: Notice: yaUsbIr: in use by driver "dummy"

Error:
2017-08-15T08:51:12.072769+02:00 hdvdr lircd-0.9.4c[1162]: Error: yaUsbIr: error reading, device went offline
2017-08-15T08:51:12.073805+02:00 hdvdr lircd[1084]: lircd-0.9.4c[1162]: Error: yaUsbIr: error reading, device went offline
2017-08-15T08:51:12.075939+02:00 hdvdr kernel: [ 1074.713971] ohci-pci 0000:00:13.0: frame counter not updating; disabled
2017-08-15T08:51:12.075983+02:00 hdvdr kernel: [ 1074.713989] ohci-pci 0000:00:13.0: HC died; cleaning up
2017-08-15T08:51:12.075989+02:00 hdvdr kernel: [ 1074.714125] usb 7-4: USB disconnect, device number 2

Display More

Ich habe z.B. etwas gefunden, dass in neueren Kernelversionen da etwas an den USB Watchdogs Timern angepasst werden muss ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634737

), aber da das unter Leap 42.3 läuft weiß ich nicht ob das schon drin ist.

Andererseits tritt die Meldung "frame counter not updating" wohl oft auf wenn ein USB device in suspend geht. Das habe ich versucht abzustellen aber der Device wurde trotzdem disabled.

Weiß jemand Rat?

FireFly

M-Reimer · Aug 15th 2017

Eventuell ja (zumindest zum Testen) in dem Zusammenhang interessant:

https://github.com/M-Reimer/yausbir_lirc

Mir war es generell zu doof am LIRC rumzupatchen. Deshalb der externe Daemon, der die UDP-Schnittstelle ansteuert.

Mittlerweile habe ich den yaUSBIr aber zugunsten eines STM32/IRMP basierten Empfänger abgelöst. Wäre mal ein Kandidat zum hier bei "Verkaufen" reinstellen...

FireFly · Aug 15th 2017

Wenn man den LIRC nicht patchen will, kann man jetzt auch ein Plugin schreiben (http://www.lirc.org/html/driver-api.html Userspace, dynamically linked) - so heißen die einzelnen Treiber jetzt und das war verm. auch ein Grund für die komplette Code-Reorganisation. Allerdings wird für das Sendemodul ein #define von LIRC verändert weshalb ich das doch wieder als Patch realisiert habe.

M-Reimer · Aug 15th 2017

Vergiss doch das mit dem Senden wenn du es selber nicht brauchst.

Allerdings ist jede Minute Zeit die man dafür verwendet zu viel. Dieser Empfänger wird, anders als die IRMP-Lösung, die hier im Forum entwickelt wird, nicht aktiv weiterentwickelt.

seahawk1986 · Aug 16th 2017

Danke für das Anpassen des Patches. Ich habe das Senden gerade mal mit RC-5 Codes einer Hauppauge Fernbedienung ausprobiert, das funktioniert auf den ersten Blick unauffällig.

seahawk1986 · Aug 16th 2017

Mit dem Kernel 4.10 (unter Ubuntu 16.04) konnte ich das beschriebene Problem mit usbcore bislang nicht beobachten.

FireFly · Aug 16th 2017

Danke für das Feedback! Das hört sich so an, als würde es nicht am Patch liegen.

Ich konnte mittlerweile herausfinden, dass der Timeout erst beginnt, wenn man eine Taste drückt, d.h. nach dem Booten kommt stundenlang keine Meldung sondern erst einige Zeit nachdem man eine Taste gedrückt hat.

Kann das dann überhaupt am USB autosuspend liegen oder kann man das damit ausschließen?

seahawk1986 · Aug 16th 2017

Ausgehend von dem letzten Kommentar in dem von dir verlinkten Bugreport würde ich nach Möglichkeit mal einen Kernel 4.10 oder höher probieren, bei den Unmengen von Änderungen am LTS-Kernel von Leap 42.3 ist es nicht ganz einfach nachzuvollziehen, was die da jetzt genau von neueren Kernel-Versionen übernommen haben (die in dem Kommentar verlinkte Änderung für den Kernel 4.9 hat es soweit ich das gesehen habe bislang nicht in den SuSE LTS 4.4 Kernel geschafft: https://kernel.opensuse.org/cg…e/timer.c?h=openSUSE-42.3 )

jrie · Aug 17th 2017

Ich benutze mit Leap 42.3 einen selbst gebauten Standard Kernel 4.9.x wegen dem LTS von 4.9.

Der Fix ist da drin.

FireFly · Aug 18th 2017

Danke für die Infos. Nachdem ich nicht unbedingt einen Kernel kompilieren will (und man ja soviel Auswahl an fertigen hat ) habe ich einen 4.8.44 probiert, der aber keine ksyms im RPM bietet (nicht mal vmalloc!) und damit mein DVB-Treiber nicht mehr lädt. Der nächste war ein 4.12.7, damit kompiliert aber der DVB Treiber nicht mehr

Jetzt warte ich mal auf den offiziellen 4.4.83 für Leap 42.3 , der hat etliche USB fixes drin.

FireFly · Sep 28th 2017

um das mal abzuschließen .....

Das Problem ist die USB_watchdog-Funktion, die in neueren Kernel eingeführt wurde und Devices rauswirft, wenn nach einer bestimmten Zeit kein USB-Frame mehr geliefert wurde. Da usb_interrupt_read() im Patch einen Timeout von 25ms hat, ist das relativ häufig aufgetreten. Mit einem Timeout von 50000ms, den auch andere Plugins nutzen, funktioniert yaUSBir fehlerfrei.

Um den LIRC bei Updates nicht jedes mal patchen zu müssen, habe ich den Patch zum LIRC-Plugin umgeschrieben (siehe Anhang). Die Sende-Funktion nutze ich nicht, dafür ist vermutlich doch der LIRC-Patch notwendig da im LIRC noch ein #define geändert wird.

Fux · Nov 26th 2017

Hallo FireFly,

habe Deine Version vom 28.09 mal kompiliert und getestet. Das LIRC-Plugin läuft, jedoch scheine ich auch von dem Timeout Problem betroffen zu sein: es funktioniert einmal und dann nicht mehr.

Mein Kernel: 4.4.0-101 (Ubuntu LTS 16.04). Wo setze ich denn manuell den Timeout hoch, fängt man sich mit diesen Workaround eventuell andere Probleme ein?

Folgendes habe ich probiert, war jedoch nicht von Erfolg gekrönt:

Code

r = 50000; // PROBLEM usb_interrupt_read(hid->usb, hid->ep_in, (char*)buf, len, timeout);

Grüße

Fux

FireFly · Nov 26th 2017

nicht den Rückgabewert des usb_interrupt_read ändern - das ist ja der Code für die gedrückte Taste IIRC. Sondern da, wo die Funktion

rawhidrecv() aufgerufen wird in Zeile 270:

Code

num = rawhidrecv(ya_usbir_dev, ya_usbir_rxbuf, sizeof(ya_usbir_rxbuf), 50000); // 50000 = timeout in ms

Ich nutze den Patch seit der Zeit und habe bisher keine Probleme feststellen können.

yaUSBir mit lirc 0.9.4

Participate now!

Share