I demand that Marko Mäkelä may or may not have written...
On Tue, Feb 07, 2006 at 01:17:56AM +0000, Darren Salt wrote:
I made a quick&dirty patch to ir-common.c and cx88-input.c that maps each incoming RC5 frame to a key-press or a key-repeat event. [...]
I've altered ir-functions.c:ir_input_keydown() here to make this easier: there should no longer any need for other modules to alter ir->keypressed. If you have a new keypress, call ir_input_nokey() then ir_input_keydown(), else call ir_input_keydown() only and the patched code will notice that it's for the same key and cause a repeat event instead.
This sounds reasonable. However, how do you distinguish rapid keypresses from repeat? In RC5 code, there is a toggle bit that changes state at a new keypress. In other codes, the repeat code may differ from the code of the first keypress.
There's a toggle bit: bit 5 of the second byte.
I think that ir_input_keydown() or equivalent function should take the repeat flag as a parameter.
No need. If you want a keypress not to be flagged as a repeat, call ir_input_nokey() first. For a key to be flagged as being repeated, don't call ir_input_nokey() between two successive calls to ir_input_keydown().
The function should never convert a repeat code to a keypress or vice versa. Two examples:
(1) If I press the '1' key two times very quickly, I want VDR to see '11'. In your scheme, I'm afraid it will produce '1' and '1'|kRepeat, and VDR will ignore the second keypress.
That won't be a problem unless interrupts are being missed. AFAICT (printk), that isn't happening.
(2) When I press the '1' button close to the maximum range of the remote (which is not much with the Hauppauge receiver that is driven out of spec), the driver should deliver the events 12022020 instead of 12012010,
Meaning what?
so that VDR will switch to channel 1 and not 111.
Well... it'll generate a repeat for each received signal (assuming that the key is held down) and it may time out, causing the next received signal to be treated as a key-down event.
With the /other/ scheme (using the input layer's own repeat handler), you will get repeats - and maybe a few more 1s (although I'm enforcing lower limits on the repeat/delay times, and the timeout is shorter than the repeat time).
[snip]