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
