On Sun, Jan 29, 2006 at 05:23:13PM +0100, Luca Olivetti wrote:
Well, maybe this is a general flaw of cLircRemote? Doesn't LIRC provide the information that the key has been released? That would make it unnecessary to wait for such a long time (REPEATDELAY) before signaling a "release".
I don't think it does (at least irw doesn't report anything on key release), but even if it did surely it'd have to use a timeout to detect that there's nothing more coming from the remote, so the problem would be the same (unless the remote itself sends something to signal a key release).
I don't think any remote sends anything on key release. The codes usually allow distinguishing initial keypress events from key-repeat events. At key-release, the transmission simply stops.
For what it is worth, the driver of the bundled Hauppauge Nova-T RCU in the Linux kernel 2.6.12 and later will even map key-repeat to a timer. That is, if it gets a repeated RC5 frame within the timeout, it will keep generating key-repeat events, at a different rate. This makes many things inaccurate, such as scrolling in menus.
I would very much like to have a direct correspondence between repeated RC5 frames and key-repeat events, but I could not figure out how to do this in cx88-input.c or ir-common.c.
There's also a bug in cx88-input.c: if a RC5 frame is lost (e.g., when the RCU is almost out-of-range), the kernel driver will generate a key-press event instead of key-repeat. Similarly, if one presses a key in very rapid succession (at 10 Hz), repeat events will be generated instead of key-press. I managed to fix the first bug: http://www.iki.fi/~msmakela/software/vdr/#cx88-repeat
Marko