Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Frontend experimental patch v1
On Tuesday 09 March 2004 02:54, Andrew de Quincey wrote:
> > > Do you have a particular reason in mind for it returning to AUTO if the
> > > lock is lost?
> >
> > No, this was a simplification. A transponder will hardly ever change
> > signal inversion on the fly. (At least I hope so.)
> >
> > Anyway, someone wrote that there is a transponder which transmits an
> > inverted signal. So it's necessary to return to AUTO when tuning to a
> > new transponder.
>
> Heh. that was me :)
Sorry, my memory chips are somewhat leaky. ;-)
> > Usually the inversion setting won't change. So it is better to try the
> > last working inversion setting first. This will speed up tuning.
>
> IMO, that should be done in userspace... when the apps are first scanning for
> TV signals they should use AUTO.. when they get a lock, they should record
> them and use the non-AUTO values.
Nack. Afaik there are some cards around, which require a different
inversion setting than others. So the application had to store that
inversion setting for each card. That's bad [tm].
So the application should not care about inversion at all.
If the the driver tries the last working inversion setting first, there
should be no performance problem with INVERSION_AUTO.
> The frontend core only does autoinversion if the app requests it in
> SET_FRONTEND with INVERSION_AUTO... I think is how the API is supposed to
> work anyway.
Imho the inversion stuff should be completely removed from the API.
Anyway, when using INVERSION_AUTO, the driver is free to use the last
working inversion setting. It will speed-up tuning.
Oliver
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.
Home |
Main Index |
Thread Index