[vdr] Key-repeat or release magic in RCU drivers
linux at youmustbejoking.demon.co.uk
Tue Feb 7 19:24:02 CET 2006
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,
> 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
| 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.
More information about the vdr