[snip] > >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. [snip] > >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). These are all good points. I'm going to start prototyping now - it'll be obvious during that which API calls are the best all round from an API and an implementation point of view.
