Hi Marko, On Sat, Feb 12, 2022 at 11:16:21AM +0000, Sean Young wrote: > 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. So I've sent two patches (you're on the cc) which should fix the issue. Please can you test if this solves the issue? These patches touch nearly every rc-core driver so they will need a good testing. Thanks Sean
