On Tue, Feb 07, 2006 at 06:24:02PM +0000, Darren Salt wrote: > >> 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. Yes, in the RC5 code there is, just like I wrote. > > 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. The RC5 repeat rate is 113.8 ms. If I press the same button twice within that time frame, it does happen. I must admit that this seems to happen with my own patch as well. I'll have to add some debug code to display the RC5 frames to see whether the toggle bit really is toggling. > > (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? 0=key-release 1=key-press 2=key-repeat I see that I should have picked another button than '1', to avoid confusing it with the number of the key-press event. > > 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 240 ms key-release timeout, it will time out if two RC5 frames are lost. If you hold the RCU in the wrong angle or far away from the receiver and press the button longer to ensure that the event will be noticed, you will end up getting multiple keypress events instead of one keypress and multiple repeat events. > 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). I tested patch 3326 of the hg/v4l-dvb tree with your patches dvb-ir-20060206.patch.tar.gz applied. I changed the key-release timeout in cx88-input.c from 120 to 240 ms. Few keys were recognized. Among the working keys were the number keys, although they were shifted by 1 (e.g., '6' would be reported as '7'). The input layer's own repeat handler was not disabled, that is, I think there were too many repeat events. I couldn't figure out how budget-ci.c disables the repeat timer. I was unable to use this driver, because one of the cx88 modules failed to load and the computer crashed after some time. Marko
