Re: Inconsistent RC5 ir-keytable events

["Marko Mäkelä" <marko.makela@iki.fi>]

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