[linux-dvb] Re: Frontend experimental patch v1

[Oliver Endriss <o.endriss@gmx.de>]

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.