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.
> I tried to understand the code changes. A few observations:
>
> In rtl2831u_get_rc_config(), rc->interval is set to 400 and rc->timeout is
> not set at all. Maybe it is OK, similar chips supported by the same driver.
The timeout won't have an affect on this problem.
> In rtl2832u_rc_query(), the idle_length is being computed from the last two
> bytes of the IR_RX_BUF buffer. The threshold is 0xc0 and thus
> it can only be exceeded if both last 7-bit bytes are included in the sum.
> Side note: the & 0x7f is redundant, because the most significant bit was
> already tested to be clear:
>
> idle_length = 0;
> if (len > 2) {
> if (!(buf[len - 1] & 0x80))
> idle_length += buf[len - 1] & 0x7f;
> if (!(buf[len - 2] & 0x80))
> idle_length += buf[len - 2] & 0x7f;
> }
>
> dev_dbg(&d->intf->dev, "idle_length=%x\n", idle_length);
>
> if (idle_length < 0xbf)
> return 0;
Yes, you are right. Note that I've observed this problem also we did not
enter the early return here (which I introduced).
> However, I spotted a potential problem here. I may of course be mistaken
> because I do not know how the IR_RX_BUF is supposed to work. Could it happen
> that buf[] contains some IR events, then 2 or more consecutive bytes of no
> pulses (with the total time exceeding 0xbf*51µs), and then again some IR
> events until the very end of the buffer, so that in the above check, we
> would return 0?
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
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.
> Could we in that case discard some IR events? Could that
> explain the glitch that I observed with the NEC protocol?
I'm not really sure this is the problem, that's what not what I observed.
Sean
