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] -- | Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk | Debian, | Northumberland | s zap,tartarus,org | RISC OS | Toon Army | @ | Retrocomputing: a PC card in a Risc PC I'd like to, but I'm waiting to see if I'm already a winner.
