The number buttons on my RCU carry auxiliary labels "ABC", "DEF", etc. These buttons work somewhat when editing the names of recordings. I can always get the first letter of the label, e.g., "a", "d", "g", "j", "m", and so on. However, when I press the same button again, VDR will usually interpret it as a "cursor right" event. Key-repeat events are ignored.
For instance, when I start editing the string "Euronews" by pressing the Right button in the "Edit timer" menu, it will display as follows:
Right-> [E]uronews 2-> [A]uronews 2-> Au[a]onews
If I keep a longer pause between the two keypresses of the button "2", the string will change to "Aaronews".
While testing this, I once got the correct behaviour: [A]uronews -> [B]uronews -> [C]uronews. Could the code forget to initialize some variable properly? Am I the only one who is experiencing this?
In case it matters, I'm using LC_CTYPE=fi_FI.iso-8859-1, and the remote control unit is driven by the <linux/input.h> driver of cx88-input.c. The key-press and key-repeat events are delivered by the vdr-softdevice plugin, which gets them via the linuxinput driver of DirectFB. Key-release events are not delivered.
Marko
On Tue, Apr 18, 2006 at 07:15:15PM +0300, Marko Mäkelä wrote:
Also the vanilla cx88-input.c in linux-2.6.16.9 is buggy and sets the repeat flag when it shouldn't (when a button is pressed in rapid succession). I'll try to come up with a working kernel patch later.
Marko
I demand that Marko Mäkelä may or may not have written...
In the Hauppauge section of the switch block in cx88_ir_irq, watch for the state of bit 11 of ircode being changed between successive reads. I'll stick something in my patchset...
On Thu, Apr 27, 2006 at 06:00:02PM +0100, Darren Salt wrote:
Rather than watching the toggle bit, I'd compare whole codes. It leads to a simpler program, and it avoids losing events. For instance, if three buttons are pressed, A, B, and C, and the code for B is lost, then watching only the toggle bit would cause all events for C to be discarded.
FWIW, the culprit was not the patched cx88-input.c, but instead the RCU would not flip the toggle bit when a button is pressed in rapid succession. So, it would misreport rapid keypress events as repeat events.
My patch against 2.6.15.2 applies cleanly on 2.6.16.9 and fixes the problem. It is a quick hack, because it modifies ir-common.c, wrongly assuming that the parameter ir_raw contains a RC5 code word. Please consider incorporating a similar fix to your patchset.
http://www.iki.fi/~msmakela/software/vdr/linux-2.6.15.2-cx88_input2.patch
Marko
I demand that Marko Mäkelä may or may not have written...
On Thu, Apr 27, 2006 at 06:00:02PM +0100, Darren Salt wrote:
I demand that Marko Mäkelä may or may not have written...
[snip]
I don't think so: in ir_input_keydown, the different key code will cause ir->keypressed to be set to 0 and the key to be released (although the test probably should be on ir_key, not the translated value).
I see this here too: both R808 and A415 show this, so my budget-ci patch is affected too. Obviously, there's nothing that can be done about this if the *same* key is repeatedly pressed rapidly :-)
Agreed; it's up to the driver to do the check and to call ir_input_keydown or ir_input_nokey accordingly. That said, I'm not convinced that there's a problem with my testing of bit 11.
Putting the first-repeat discard in ir_input_keydown (as you've done) seems reasonable to me; anybody else?
On Thu, Apr 27, 2006 at 10:44:31PM +0100, Darren Salt wrote:
You're probably right. I didn't consider the extra status variable (ir->keypressed).
Putting the first-repeat discard in ir_input_keydown (as you've done) seems reasonable to me; anybody else?
Originally, I did not implement that feature, but it is truly necessary for RC5 remotes. For instance, when you press the Down button in a menu, the cursor may easily end up moving two lines instead of one. While I press the buttons shorter than 0.1 seconds most of the time, it seems appropriate to have a longer key-repeat delay. RC5 frames are repeated every 0.113777... seconds. Discarding the first repeat frame yields a repeat delay of 0.227555... seconds. (The values are 64*T and 2*64*T, with T=16/9 ms being the RC5 time base.)
I don't know about other RCUs. Could it be that some RCUs implement key-repeat delay on their own? If yes (which I would doubt), the first-repeat discard should be done in the upper layer.
Marko
I demand that Marko Mäkelä may or may not have written...
On Thu, Apr 27, 2006 at 10:44:31PM +0100, Darren Salt wrote:
[snip]
Putting the first-repeat discard in ir_input_keydown (as you've done) seems reasonable to me; anybody else?
Quite possible, yes...
[snip RC5 repeat timings]
Agreed. It's easy enough to add a simple repeat check if it's needed - basically ir_input_keydown() without the calls to input_*(), and returning true if ir->keypressed is 1 and would be set to 2.
On Sun, Apr 09, 2006 at 10:38:06PM +0300, Marko Mäkelä wrote:
This is because my RCU (the new Hauppauge RCU) erroneously will not flip the RC5 toggle bit when the button is pressed in rapid succession. Also, the unpatched cx88-input.c in Linux 2.6.x (where 12<=x<=16) would map rapidly arriving key-press events to key-repeat.
The fix is simple:
--- menuitems.c.orig 2006-04-22 18:51:36.000000000 +0300 +++ menuitems.c 2006-04-22 19:04:00.000000000 +0300 @@ -351,7 +351,7 @@ char cMenuEditStrItem::Inc(char c, bool
eOSState cMenuEditStrItem::ProcessKey(eKeys Key) { - bool SameKey = Key == lastKey; + bool SameKey = !((Key ^ lastKey) & ~k_Repeat); if (Key != kNone) lastKey = Key; else if (!newchar && k0 <= NORMALKEY(lastKey) && NORMALKEY(lastKey) <= k9 && autoAdvanceTimeout.TimedOut()) { @@ -460,7 +460,7 @@ eOSState cMenuEditStrItem::ProcessKey(eK } if (!currentChar || !*currentChar || *currentChar == '\t') { // find the beginning of the character map entry for Key- int n = Key - k0; + int n = NORMALKEY(Key) - k0; currentChar = charMap; while (n > 0 && *currentChar) { if (*currentChar++ == '\t')
Without the second patch, the k0..k9|k_Repeat event would be ignored when *currentChar=='\t' is reached.
Marko
-
Darren Salt -
Klaus Schmidinger -
Marko Mäkelä