On Tue, Sep 26, 2006 at 03:26:17PM +0100, Torgeir Veimo wrote: > >An older version of the vdr-remote plugin was confused by type 0 > >events > >(IIRC), which were reported by the cx88 driver. However, that was > >fixed > >a few months ago after I reported it. I still don't use the plugin, > >because it seems to significantly lower the repeat rate. I prefer the > >built-in 114 ms repeat rate of the RC5 protocol. > > I think it's the build in 114ms repeat rate that I find too fast, > often being interpreted as two button presses. The kernel driver for cx88-input does not use the RC5 repeat rate, but instead it uses a software-based repeat timer whose repeat rate is somewhat lower. The problem with that is that it is not accurate. You can get one or two extra repeat events after releasing the button on the remote control unit. When the software-based timer is bypassed with a kernel patch, it becomes possible to scroll down a menu to a desired position by releasing the button when the selection is approaching the desired line. > I found this article interesting: http://www.linuxjournal.com/ > articles/lj/0107/6429/6429l12.html . It describes how one can set the > repeat rate and delay using the EVIOCGREP ioctl. It would be > interesting to get in a patch into the remote plugin to do this, but > for now I'm just using the attached small program. I thought that the remote plugin implements its own repeat timer (yes, that would make two software-based timers in cascade when using cx88-input.ko). At least when I tested it, the repeat rate was much lower than the fixed 114 ms reported by my patched 2.6.16 or 2.6.17 kernel. Thanks for mentioning this ioctl. (The article seems to be available from <http://www.linuxjournal.com/article/6429>.) By setting the repeat rate and delay to multiples of the RC5 frame rate, it might be possible to get satisfactory accuracy from the vanilla kernel, unless some cumulative rounding errors will come into the play. I will check that after upgrading my vdr to a 2.6.18 kernel. Marko
