[vdr] Key-repeat or release magic in RCU drivers

Darren Salt 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,

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.



More information about the vdr mailing list