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
