[linux-dvb] Scan API

[Andrew de Quincey]

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.

Finally, FE_SCAN_CANCEL will cancel a scan if one is currently occurring.

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

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

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?