[vdr] Key-repeat or release magic in RCU drivers
marko.makela at hut.fi
Sun Jan 29 23:12:19 CET 2006
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
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:
More information about the vdr