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