Hi Marko, On Mon, Jan 03, 2022 at 12:35:23PM +0200, Marko Mäkelä wrote: > 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. Ah yes. > > 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. There is a balance to be struck here. If the button gets repeated too quickly, it becomes impossible to go up/down one item, for example. The way to do this, is to set the autorepeat period/delay to settings to what suits your likes/dislikes; it should not depend on the lower-level IR message. > > 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). So the delay for the keyup is 125857us or about 125ms. > 18022.345513: lirc protocol(nec): scancode = 0x40 repeat > 18022.345524: event type EV_MSC(0x04): scancode = 0x40 > 18022.345524: event type EV_SYN(0x00). However here the repeat gets reported too late. It gets reported 211373us after the first scancode (about 211ms). > 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. I am not sure if the naked eye can observe a delay of 200ms rather than 100ms. > > 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? This is the timeout field on rcdev. I think it is set here: https://git.linuxtv.org/media_tree.git/tree/drivers/media/usb/dvb-usb-v2/rtl28xxu.c#n1810 I think the interval is to set to value which is much to high; I think the 211 ms comes from this 200 value here. So, I think if you lower this to 100 then your problems might go away. I had forgotten that that for the delay between key down and key up, this also adds the repeat period for the protocol, see https://git.linuxtv.org/media_tree.git/tree/drivers/media/rc/rc-main.c#n857 So actually that is 110ms + 9741us ≈ 119m, which is near enough the values seen above. I suspect the issue is the interval but please experiment. Sean
