[vdr] VDR user input slowness

Marko Mäkelä marko.makela at hut.fi
Thu Feb 15 17:05:52 CET 2007


On Thu, Feb 15, 2007 at 04:37:16PM +0200, Teemu Suikki wrote:
> > > .. Replying to myself.. The problem seems to be in kernel level after
> > > all, I enabled ir_debug in budget-ci module and the same delay is there
> > > as well, debug log appears at the same time as vdr reacts to the
> > > keypress.
> >
> > This is a known driver problem: a link to a patch was posted a few weeks
> > back which removes this delay. See:
> > http://www.linuxtv.org/pipermail/vdr/2007-February/011994.html
> >
> > I've always had more success with a home-brew LIRC receiver on a serial
> > port.
> 
> I think I'll go for LIRC too.. :( I installed the above patch, it is
> slightly better but not very much.

But are you using the cx88 kernel module?  My patch probably breaks all
other drivers depending on ir-common.c or ir-funtions.c, as it is called
in later 2.6 kernels.  I'm talking about this patch, which I have been
using since I made it:

http://www.iki.fi/~msmakela/software/vdr/linux-2.6.15.2-cx88_input2.patch

As far as I understand, the cx23882 features a 32-bit shift register for
sampling the output of the infrared receiver and generates an interrupt
after every 32 shifted bits.  I don't know the shifting frequency, but
let's assume that the shift register takes 6 samples of each time base
T=16/9 ms.  The duration of a whole RC5 frame is 64*T, or about 114 ms.
The worst case delay of the shift register would then be something like
32*(T/6) = 9.5 ms.  By Nyquist's sampling theorem, the absolute minimum
sampling frequency would be 1/T (because the minimum pulse width in RC5
code is T/2).  Thus, the maximum delay caused by the shift register would
be 32*T = 57 ms.  I don't think that you can notice that kind of delays,
nor that you would get much smaller delays with LIRC.

	Marko



More information about the vdr mailing list