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