I demand that Marko M?kel? may or may not have written... > 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. This is true... > 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 don't see how: with the unmodified budget-ci, it's slow enough... > 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 cx88? That'd be the newer Nova-T, not the Nova-T :-) > or ir-common.c. I've posted a set of patches to the v4l list which should be of some help; you should have a look at budget-ci after applying the patches, which you can also get from here: <URL:http://ymbj/progs/linux/dvb-ir-20060129.patch.tar.gz> (You need to apply the keymaps patches first.) [snip] -- | Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk | Debian, | Northumberland | s zap,tartarus,org | RISC OS | Toon Army | @ Say NO to UK ID cards | http://www.no2id.net/ They just buzzed and buzzed... and buzzed.
