I demand that Marko Mäkelä may or may not have written...
On Thu, Apr 27, 2006 at 06:00:02PM +0100, Darren Salt wrote:
I demand that Marko Mäkelä may or may not have written...
[snip]
Also the vanilla cx88-input.c in linux-2.6.16.9 is buggy and sets the repeat flag when it shouldn't (when a button is pressed in rapid succession). I'll try to come up with a working kernel patch later.
In the Hauppauge section of the switch block in cx88_ir_irq, watch for the state of bit 11 of ircode being changed between successive reads. I'll stick something in my patchset...
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).
FWIW, the culprit was not the patched cx88-input.c, but instead the RCU would not flip the toggle bit when a button is pressed in rapid succession. So, it would misreport rapid keypress events as repeat events.
I see this here too: both R808 and A415 show this, so my budget-ci patch is affected too. Obviously, there's nothing that can be done about this if the *same* key is repeatedly pressed rapidly :-)
My patch against 2.6.15.2 applies cleanly on 2.6.16.9 and fixes the problem. It is a quick hack, because it modifies ir-common.c, wrongly assuming that the parameter ir_raw contains a RC5 code word.
Agreed; it's up to the driver to do the check and to call ir_input_keydown or ir_input_nokey accordingly. That said, I'm not convinced that there's a problem with my testing of bit 11.
Putting the first-repeat discard in ir_input_keydown (as you've done) seems reasonable to me; anybody else?