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?
