Key-repeat or release magic in RCU drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

I think that ir_input_keydown() or equivalent function should take the repeat
flag as a parameter.  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.

(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.

> FWIW, my current patch sets are linked from
>   <URL:http://www.youmustbejoking.demon.co.uk/progs.linux.html#dvb>
> 
> And we need to take this to the v4l list :-)

Sure.

	Marko


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux