Re: Inconsistent RC5 ir-keytable events

Marko Mäkelä
2022-01-03T10:35:29Z

Hi Sean,

Thank you for your prompt and helpful reply.

Mon, Jan 03, 2022 at 09:21:23AM +0000, Sean Young wrote:
>On Mon, Jan 03, 2022 at 08:52:46AM +0200, Marko Mäkelä wrote:
>> Hi,
>>
>> Years ago, I was using the Hauppauge Nova-T PCI 90002 card that bundles a
>> remote control unit that uses RC5 codes.
>
>Would you mind sending the lspci output for this device? Then we know
>exactly how the driver is handling this.

I am no longer using the PCI (not PCIe) card, but only the remote
control unit. I still have the hardware sitting unused, but I do not
think that it is relevant to the problem when attempting to use the
remote control unit with the Astrometa DVB-T2 USB adapter.

>That's not the way things should work. The speed at which the IR
>message gets repeated depends on the IR protocol. You don't want a key
>down/up event for each of those.

There is a use case where I actually want that. When I press and hold
the volume-up button, or a button to scroll a list in a menu, I would
the user interface to update as frequently as possible.

Sure, an initial delay that would discard the 2nd..nth IR message could
be useful, so that when I press the channel+ button for less than half a
second, the channel would only change once. But still, it might be
better to filter out "premature repeats" for specific keycodes in the
application (possibly depending on context) and configure the driver to
pass everything through.

>You've turned off autorepeat with those options, so that's not going to
>change anything. If you press a key, hold it for some time, and then
>release you should get one key down, one key up and a few autorepeats
>depending on the --delay/--period settings.

You are right. I tested the bundled RCU of the adapter, and I am indeed
seeing such output. Here is the dmesg from 5.15.5:

[17984.345840] usb 2-6: Manufacturer: astrometadvbt2
[17984.352731] usb 2-6: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
[17984.514105] dvbdev: DVB: registering new adapter (Astrometa DVB-T2)
[17984.545328] Registered IR keymap rc-astrometa-t2hybrid

And here is the ir-keymap -t output. It looks like what I would expect
(except maybe the key_up event should be sent after the sequence of
repeat events, not before them).

18022.134140: lirc protocol(nec): scancode = 0x40
18022.134157: event type EV_MSC(0x04): scancode = 0x40
18022.134157: event type EV_KEY(0x01) key_down: KEY_FULL_SCREEN(0x0174)
18022.134157: event type EV_SYN(0x00).
18022.260014: event type EV_KEY(0x01) key_up: KEY_FULL_SCREEN(0x0174)
18022.260014: event type EV_SYN(0x00).
18022.345513: lirc protocol(nec): scancode = 0x40 repeat
18022.345524: event type EV_MSC(0x04): scancode = 0x40
18022.345524: event type EV_SYN(0x00).
18022.561538: lirc protocol(nec): scancode = 0x40 repeat
18022.561549: event type EV_MSC(0x04): scancode = 0x40
18022.561549: event type EV_SYN(0x00).
...
18024.057680: lirc protocol(nec): scancode = 0x40 repeat
18024.057694: event type EV_MSC(0x04): scancode = 0x40
18024.057694: event type EV_SYN(0x00).
^C

>I think this is the issue you are having. Somehow there are gaps in
>reading the IR, which are long enough to cause key up/down events.

I watched the IR LED in the live viewfinder of a digital camera while
pressing a button, and you may be right: instead of seeing a constant
stream of pulses, I saw a few pulses followed by a pause, then again a
few pulses. After I replaced the batteries, I only saw a short pause
every couple of seconds, which probably was a sampling artifact of the
camera. But, this did not improve the situation on Linux yet.

>Each rc device has a timeout which determines how long after keydown
>event, a key up event is sent as long as the same IR is not received
>again. This is usually IR_DEFAULT_TIMEOUT (125ms). You can see the
>value with
>`ir-ctl -f -d /dev/lirc0`
>
>I think the problem is that the gaps in your IR is greater than this timeout.

Again, you seem to be right:

sudo apt install v4l-utils
ir-ctl -f -d /dev/lirc0
Receive features /dev/lirc0:
- Device can receive raw IR
- Can report decoded scancodes and protocol
- Receiving timeout 9741 microseconds
Send features /dev/lirc0:
- Device cannot send

How to increase the timeout from this less than 10ms to something closer
to 125ms?

Note: The bundled remote control unit uses the NEC protocol while the
one that I am attempting to use (hauppauge.toml) is RC-5.

Best regards,

Marko