[linux-dvb] Scan API

Andrew de Quincey adq_dvb at lidskialf.net
Sat Nov 19 01:13:59 CET 2005

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.


More information about the linux-dvb mailing list