[vdr] Key-repeat or release magic in RCU drivers

Marko Mäkelä 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
> 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:


More information about the vdr mailing list