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
Marko Mäkelä wrote:
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.
I just tested with my RCU here and everything worked fine. Maybe it's a problem with the <linux/input.h> driver or the vdr-softdevice plugin?
Klaus
On Fri, Apr 14, 2006 at 01:31:47PM +0200, Klaus Schmidinger wrote:
I just tested with my RCU here and everything worked fine. Maybe it's a problem with the <linux/input.h> driver or the vdr-softdevice plugin?
It turned out that something falsely sets the k_Repeat flag most of the time. It's most probably the patches to the cx88-input.c, by Darren Salt and me. I'll investigate later.
Marko
On Tue, Apr 18, 2006 at 07:15:15PM +0300, Marko Mäkelä wrote:
On Fri, Apr 14, 2006 at 01:31:47PM +0200, Klaus Schmidinger wrote:
I just tested with my RCU here and everything worked fine. Maybe it's a problem with the <linux/input.h> driver or the vdr-softdevice plugin?
It turned out that something falsely sets the k_Repeat flag most of the time. It's most probably the patches to the cx88-input.c, by Darren Salt and me. I'll investigate later.
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...
On Tue, Apr 18, 2006 at 07:15:15PM +0300, Marko Mäkelä wrote:
On Fri, Apr 14, 2006 at 01:31:47PM +0200, Klaus Schmidinger wrote:
I just tested with my RCU here and everything worked fine. Maybe it's a problem with the <linux/input.h> driver or the vdr-softdevice plugin?
It turned out that something falsely sets the k_Repeat flag most of the time. It's most probably the patches to the cx88-input.c, by Darren Salt and me. I'll investigate later.
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.
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:
I demand that Marko Mäkelä may or may not have written...
On Tue, Apr 18, 2006 at 07:15:15PM +0300, Marko Mäkelä wrote:
On Fri, Apr 14, 2006 at 01:31:47PM +0200, Klaus Schmidinger wrote:
I just tested with my RCU here and everything worked fine. Maybe it's a problem with the <linux/input.h> driver or the vdr-softdevice plugin?
It turned out that something falsely sets the k_Repeat flag most of the time. It's most probably the patches to the cx88-input.c, by Darren Salt and me. I'll investigate later.
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.
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...
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]
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.
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...
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.
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).
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.
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 :-)
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.
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:
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.
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).
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?
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.
Quite possible, yes...
[snip RC5 repeat timings]
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.
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:
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".
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
Marko Mäkelä wrote:
On Sun, Apr 09, 2006 at 10:38:06PM +0300, Marko Mäkelä wrote:
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".
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.
Can you please try the attached, slightly modified version of this patch? It avoids the rather complex "xor" expression and also some extra NORMALKEY().
Klaus
On Sun, Apr 23, 2006 at 01:42:10PM +0200, Klaus Schmidinger wrote:
Can you please try the attached, slightly modified version of this patch? It avoids the rather complex "xor" expression and also some extra NORMALKEY().
Done. It works equally well. Thank you!
Marko
-
Darren Salt -
Klaus Schmidinger -
Marko Mäkelä