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.


vdr mailing list

Reply via email to