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
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
