Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: cinergyT2: which kernel/usb module to use?



Holger Waechtler wrote:
> Johannes Stezenbach wrote:
> >Holger Waechtler wrote:
> >>the FE_GET_EVENT ioctl was simply not implemented (I already rendered it 
> >>obsolete in my mind, since GET_STATUS and GET_FRONTEND provide the same 
> >>functionality...).
> >>please try again,
> >
> >Nah, I won't try because to me the currect code looks
> >suspiciously like an endless recursion.
> >
> >It would also not work the way you tried to implement it,
> >as VDR does the following before tuning:
> >
> >	while (GetFrontendEvent(event))
> >		; // discard stale events
> >
> >Which would run into an endless loop if you create
> >frontend events "on demand".
> 
> The above code is in any case wrong, you assume that the hardware 
> delivers less events than you process, this is surely in most cases 
> right but definitely not safe.

This code is correct. It's the same code that Convergence has
been using for ages. I also had it in an early szap version.
What it does is to flush the event queue before tuning. Sure,
we could've added FE_FLUSH_EVENTS but what the hell...

> The correct implementation is this:
> 
>        while (!exit) {
>                select(fd, ...);
>                ioctl(fd, FE_READ_STATUS, &status);
>                /* process/display status */
>        };

Select what? If the driver sees an event so it can wake up poll(),
it surely can generate a frontend event, no?
Certainly it is valid to call FE_READ_STATUS instead of looking
at the event retrieved with FE_GET_EVENT, but the API guarantees
that FE_GET_EVENT will also give you the tuning status.

Johannes




Home | Main Index | Thread Index