[erledigt] LIRC+VDR es kommen zu viele Tastendrücke an

Zitat von SigVDR

VDR2.0.5 liefert mir von lirc zu viele Tastendrücke.

Beim VDR kommen zuviele Tasten-Codes an, der VDR liefert diese nicht, sondern reagiert nur darauf.

Zitat von SigVDR

Das Kontrollprogramm ...

ist irw und absolut kein Geheimnis. Das zeigt Dir auch, das aus Lirc zuviele Tastencodes kommen.

Aber LIRC ist nur noch bedingt der richtige Weg, seit geraumer Zeit ist "rc-core" das Ding für Remote Control und die Services inputlirc oder eventlirc, nicht mehr lircd.

Erzähl mal was zu Deinem System, Basis-OS, Distro ...

Regards
fnu

Und Infos zu den Argumenten mit denen lircd gestartet wurde sind auch nicht verkehrt (nicht dass da -u bzw. --uinput oder sowas dabei ist):

ps aux | grep lirc

Zitat von SigVDR

Code

root   	897  0.0  0.1   3636   708 ?    	Ss   17:23   0:00 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput

Also ist --uinput aktiv und damit füttert er ein Virtuelles Kernel Input Device, das zusätzlich Tastendrücke generiert - mit evtest solltest du sehen können, was das so von sich gibt.
Bei yaVDR hatten wir das für die Vorabversionen der 0.4 auch genutzt, aber leider gibt es da ein merkwürdiges Prell-Verhalten bei den generierten Tastendrücken, daher habe ich für yaVDR lircd2uinput geschrieben, das die Tastendrücke brauchbar auf ein Kernel input device umsetzt.

BTW:
Wenn dein VDR sowohl vom tty als auch vom Lircd-Socket liest, wäre das auch noch eine mögliche Erklärung weshalb da mehrfache Tastendrücke ankommen.

Zitat von SigVDR

nur einen Tastendruck wo VDR gleich 3 daraus macht.

Ok, jetzt hab ich Dein Problem verstanden.

Zitat von SigVDR

Ist das aber nicht auf dem Weg von "Hardware" zu lirc? Der ist bei mir doch in Ordnung!

Nein, der Lirc-Daemon generiert dann nochmal extra Tastendrücke, siehe Manpage:

Zitat von man 8 lircd

On Linux systems the --uinput option will enable automatic generation of Linux input events. lircd will open /dev/input/uinput and inject key events to the Linux kernel. The key code depends on the name that was given a button in the lircd config file, e.g. if the button is named KEY_1, the '1' key code will be generated. You will find a complete list of possible button names in /usr/include/linux/input.h.

Zitat von SigVDR

Das kommt also möglicherweise über "Tastatur" nochmal in den VDR?

Genau.

Die Frage ist eigentlich, ob du lircd überhaupt mit --uinput starten willst - der VDR und XBMC können ja vom ganz normalen Lircd-Sockel lesen.

SigVDR

Ja, läuft weiterhin über diesen Socket, daran ändert sich nichts. Irgendwo wird definiert was durch diesen am VDR ankommt und dieser reagiert per remote.conf dann drauf.

Das vor dem Socket hat sich geändert, welche Kernelmodule, wie antworten und wo diese gemappt werden, alles Event-basiert. Man muß z.B. keine lircd.conf mehr anlernen und könnte theoretisch mit null Konfigurationsaufwand die FBs zum laufen bewegen. Praktisch liegt der Teufel wie immer im Detail ...

inputlirc haben vmtl. alle Linux-Distros an Board, eventlirc bietet eine paar AddOns dazu, ist aber nicht Standard.

Regards
fnu

Um welchen Empfänger geht es denn konkret? Es gibt ja immer noch reine Lirc-Empfänger (z-B- lirc_rpi, yaUsbIR, der kommende Atric IR-WakeupUSB) - es macht die Entwicklung halt ein bisschen einfacher wenn man bestehende Treiber und Decoder nutzen kann oder einen Userspace-Treiber für USB-Geräte baut als gleich ein neues Modul in den Kernel zu bringen...

Bei den aktuellen Lirc Debian-Paketen sollte es wie bei Ubuntu auch nur noch Userspace-Treiber geben (und der Kernel bringt noch für ein paar Empfänger Lirc-Treibermodule mit):

Zitat von debian/rules vom lircd-Paket

Code

configure_flags := \
		--prefix=/usr \
		--mandir=\$${prefix}/share/man \
		--infodir=\$${prefix}/share/info \
		--libdir=\$${prefix}/lib \
		--sysconfdir=/etc/lirc/ \
		--with-driver=userspace \
		--with-syslog=LOG_DAEMON \
		--enable-sandboxed \
		--build=$(DEB_BUILD_GNU_TYPE)