[linux-dvb] Scan API

[Philip Prindeville]

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

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

-Philip