Hi all,
TL;DR: How could I connect VDR to the kernel-provided /dev/lirc0 device? Is there a dummy lircd implementation that would simply open /dev/lirc0 in LIRC_MODE_SCANCODE and relay its contents over a socket?
As far as I understand, LIRC was first implemented as a user-space daemon that would decode a bitstream (via various bit-banging interfaces) into scancodes that would then be relayed over a socket to the final application.
At some point (before I started to use VDR in 2005 or 2006), support for remote control units was expanded in the Linux kernel, and also a translation into input events was implemented. In VDR, the input event interface can be used via the "remote" plugin (vdr -Premote). I think that this is what I always used with VDR, first using the cx88 driver (Hauppauge Nova-T PCI 90002) and now trying to use a USB stick (rtl82xxu, Astrometa DVB-T2) on a Raspberry Pi.
The input event interface is mapping the stream of IR messages to "key-down", "key-up" and "key-repeat" events, which adds some inaccuracy. For the rtl82xxu, the repeat logic is broken: key-repeat or key-down events for long key presses are only being sent intermittently. The fix in https://patchwork.linuxtv.org/project/linux-media/list/?series=7322 improves it a lot. The USB interface for delivering IR events in a 128-byte buffer is prone to race conditions, and that cannot be fixed without changing the device firmware.
There is also a kernel-based interface (such as /dev/lirc0) that can provide scan codes to end applications. Both the input event interface and this one would be polled by "ir-keytable -t".
I would like to use the /dev/lirc0 interface with VDR, so that VDR has a chance to react to each and every IR message that is sent by the remote control unit. I think that this would minimize the disturbance caused by the broken USB protocol of the rtl82xxu. It is OK if one LIRC scancode of a long keypress (say, browsing a list of recordings) would be lost; another one would be sent in 113ms by the RC5 protocol. With the input event driver, a lost IR message would result in a bogus key-up event, a bogus key-down event, and a long delay before key-repeat events are generated again.
My initial attempt at using /dev/lirc0 did not work:
vdr -v /var/lib/vdr/video --no-kbd --lirc=/dev/lirc0 -Prpihddevice
That is, pressing any buttons on the remote control unit did not have any effect, and VDR did not start in the "learning mode" either, even after I renamed the remote.conf that it is opening at startup. It appeared that a read() on "/dev/lirc0" would block indefinitely, but I did not check that.
I noticed that VDR's lirc.c is explicitly opening a Unix domain socket to the LIRC device, while "ir-keytable -t" would invoke open(2) followed by ioctl(lircfd, LIRC_SET_REC_MODE, &mode): https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/keytable.c
My goal would be to use the Hauppauge remote control with the Astrometa DVB-T2 stick and for it to be as responsive as it was back in 2006 with my patched cx88 driver. My implementation back then directly mapped IR messages to input events:
(1) produced a key-down event for the first IR message (2) discard the first repeated IR message (to have an initial delay) (3) produced key-repeat events for subsequent IR messages (every 113ms) (4) if any key-up events were produced, that would be after a timeout that would be reset in (1),(2),(3).
I think that it should be possible to implement this behaviour in a dummy lircd that translates /dev/lirc0 into a socket. Before I implement that from the scratch, I would like to know if something similar already exists.
Related to this, I submitted a fix to the kernel to set the "repeat" flag in the LIRC scan codes when appropriate: https://patchwork.linuxtv.org/project/linux-media/list/?series=8338 Without this fix, it should still be possible to detect repeat key events (long key presses) by comparing successive scancodes. For protocols that do not include a toggle flag (like RC5 does), it might be possible to compare timestamps to distinguish long button presses from multiple short presses.
Best regards,
Marko