[linux-dvb] Scan API

Philip Prindeville philipp_subx at redfish-solutions.com
Mon Nov 21 05:36:59 CET 2005

Andrew de Quincey wrote:

>OK, restarting the discussion on the scan API. The last proposal was from 
>Holger, and I like it for the most part. Here is a combination of that 
>proposal with my thoughts:
>struct dvb_fe_scan_spec {
> unsigned freq_start;
> unsigned freq_end;
> unsigned srate_start;
> unsigned srate_end;
>I like the structure. Its clean, and contains exactly what you need. And I 
>agree that to exploit the maximum capability of all hardware, it needs to be 
>entirely in kernel space, since that is where the frontend drivers reside.
>For IOCTLs, I would suggest:
>FE_SCAN_START -- this takes a struct dvb_fe_scan_spec, and starts the scan 
>immediately. I can't see the reason to have a seperate FE_SCAN_PREPARE 
>followed by an FE_SCAN_START, so I suggest doing away with FE_SCAN_PREPARE.  
>Although if someone can suggest a good reason... please do!
>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.

>I will implement a dumb default "swscanner" function in dvb_frontend.c - much 
>like the "swzigzag" functions used during normal tuning. A frontend driver 
>can override this behaviour by defining the "scan" function pointer which 
>will be added to struct dvb_frontend_ops.
>Do we need an FE_SCAN_STATUS ioctl? Although FE_GET_EVENT will return _valid_ 
>frontend parameters, is it highly likely that a userspace app will want to 
>show a progress bar. The FE_GET_EVENT results are unsuitable for this as the 
>bar will show no progess and then suddenly jump when something is found (an 
>MS-style progress bar ;-P).  

It will also be useful in debugging glitchy drivers or firmware that
wedge in the middle of a scan...

>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.

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).

API's that do too much for you make it hard to sift through failure
scenarios and isolate faults.


More information about the linux-dvb mailing list