[linux-dvb] Scan API

Andrew de Quincey adq_dvb at lidskialf.net
Mon Nov 21 10:44:54 CET 2005


[snip]

> >Userspace will be informed of a new scan result by using the preexisting
> >FE_GET_EVENT ioctl. When a scan result is ready, this will return the same
> >information as when a frequency is locked in normal mode. The scan will
> >automatically be stopped when a new result is ready. Userspace will start
> > it going again using the FE_SCAN_CONTINUE ioctl.
>
> Why do we need a CONTINUE? Why not just issue a new scan command,
> with the new start frequency to be the currently locked frequency plus
> a stepping delta?
>
> >Finally, FE_SCAN_CANCEL will cancel a scan if one is currently occurring.
>
> Just call START the start and end both equal to zero.

[snip]

> >Another way of doing this would be to make FE_GET_FRONTEND return the
> > current parameters being scanned. This would save complicating the API
> > with another new ioctl...
>
> The current API isn't all that cluttered. I don't think that's an issue
> yet.
>
> >My current thought is that DVBS scanning should _only_ scan the current
> >combination of diseqc/polarization/band. It will be up to the userspace
> > app to set up these parameters and call the scan API multiple times for
> > as many different combinations as are necessary.
> >
> >Ideas/suggestions?
>
> Current combination of "diseqc"? You mean switch position?
>
> I concur that for simplicity's sake, that it's the most powerful/robust
> to do
> simple iterations... Makes it easier to pinpoint potential failures, such
> as only locking up a single type of polarization... (i.e. failure to
> generate both voltages).

These are all good points. I'm going to start prototyping now - it'll be 
obvious during that which API calls are the best all round from an API and an 
implementation point of view. 



More information about the linux-dvb mailing list