Hi Sean,
Tue, Feb 08, 2022 at 04:46:31PM +0000, Sean Young wrote:
Hi Marko,
On Sat, Jan 29, 2022 at 07:15:57PM +0200, Marko Mäkelä wrote:
Hi Sean,
Did you have a chance to repeat my findings with a remote control unit that
uses the RC5 protocol?
Yes, I've reproduced the problem now. It's very weird.
After pressing button 1, waiting for a second or two, and then pressing button
3, the device reports some old IR from button 1 before reporting the IR from
button 3.
The IR is not a copy of old data, it so presumably its IR that was not
reported before. Now I don't know why this IR gets reported so late.
When I repeated the problem, the delay between subsequent button presses
could have been even less than a second.
How did you determine that it is not a copy of old data? I assume that
you can do that fairly easily for any kernel-side buffers, but what
about the buffer on the USB device itself?
[snip]
I have not seen this happen. You can enable debugging for this using:
echo 'file rtl28xxu.c +p' > /sys/kernel/debug/dynamic_debug/control
dmesg -w
Thank you. It might take me some time to return to this.
I do not know exactly how the buffer works, only some experimentation
will help here. Unless there is a vendor driver/documentation for this
device.
I am just guessing here, since I do not have any experience with USB
programming, and hardly any experience with the Linux kernel. Could it
be that the IR samples are being stored in a ring buffer, and the device
does not implicitly discard IR events as it is sending them to the USB
host? A simple test could be to read the buffer twice in a row. Will it
return the same contents, instead of returning nothing on the second
read?
If my ring buffer hypothesis holds, perhaps the kernel driver should
keep track on where the data ended on the previous read, re-read the
device's entire ring buffer, and resume parsing from the previous end of
the ring buffer? In that way, we should not see phantom old events.
Best regards,
Marko
