On Thu, Apr 27, 2006 at 10:44:31PM +0100, Darren Salt wrote: > > Rather than watching the toggle bit, I'd compare whole codes. It leads to > > a simpler program, and it avoids losing events. For instance, if three > > buttons are pressed, A, B, and C, and the code for B is lost, then watching > > only the toggle bit would cause all events for C to be discarded. > > I don't think so: in ir_input_keydown, the different key code will cause > ir->keypressed to be set to 0 and the key to be released (although the test > probably should be on ir_key, not the translated value). You're probably right. I didn't consider the extra status variable (ir->keypressed). > Putting the first-repeat discard in ir_input_keydown (as you've done) seems > reasonable to me; anybody else? Originally, I did not implement that feature, but it is truly necessary for RC5 remotes. For instance, when you press the Down button in a menu, the cursor may easily end up moving two lines instead of one. While I press the buttons shorter than 0.1 seconds most of the time, it seems appropriate to have a longer key-repeat delay. RC5 frames are repeated every 0.113777... seconds. Discarding the first repeat frame yields a repeat delay of 0.227555... seconds. (The values are 64*T and 2*64*T, with T=16/9 ms being the RC5 time base.) I don't know about other RCUs. Could it be that some RCUs implement key-repeat delay on their own? If yes (which I would doubt), the first-repeat discard should be done in the upper layer. Marko
