Hi Marko, On Wed, Feb 09, 2022 at 10:12:34AM +0200, Marko Mäkelä wrote: > Tue, Feb 08, 2022 at 04:46:31PM +0000, Sean Young wrote: > > On Sat, Jan 29, 2022 at 07:15:57PM +0200, Marko Mäkelä wrote: > > > 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? I've spent some more time debugging this. The problem is that we need to increase the timeout to prevent key up events from arriving to early, but the same timeout is used for the raw IR timeout. I think rc-core needs a little refactoring to split out the timeout into keyup_timeout and rawir_timeout. For this driver, the rawir_timeout needs to be set to 0xbf * 51us, and the keyup_timeout to the query interval (which 200ms). My patch increased the timeout to 210ms but the IR receiver never sends a space that long. So this IR will only get processed once *more* IR arrives, so you get ghost key presses. Sean
