[linux-dvb] Re: [RFC][ANNOUNCE] blindscan: auto searcheverything

[Roberto Ragusa <mail@robertoragusa.it>]

On Tue, 3 Aug 2004 14:01:19 +0200
Johannes Stezenbach <js@convergence.de> wrote:

> > After rereading what you wrote... are you saying that the core of the
> > blindscan program should be moved into the kernel?
> 
> IIRC Holger told me that the mt3?2 frontends can do the whole scan
> automatically? Doing it in the kernel sounds wrong.

I can only speak about mt312/vp310.
I have to repeat that the word "scan" is not appropriate, I don't think
it's mentioned on the datasheet at all.

Anyway, the vp310/mt312 can not do frequency scans.
It can only do "symbol rate search", that is tuning a signal when you
don't know the sr. The sr ranges are a sort of a hint to the hardware
about where to look. Maybe the hardware does a sort of scan internally
(I define scan as "move the parameter until something happens") because
the word used is "search" (and not, say, "detection"), but this is
completely hidden to us.

> > So the problem is reduced to:
> > - how do we specify a start and end sr?
> > We have one 32 bit field in the tuning struct.
> > We can introduce a struct with 2 32 bit fields, but how do we
> > link it to the tuning struct?
> > Is it reasonable to extend the dvb_qpsk_parameters?
> 
> We cannot break binary compatibilty for the existing tuning API.

I agree, expecially if we have to hack the structure by adding
a field that is not used in 99.5% of the cases and is not readable.

> We can always add new ioctls. To me it doesn't feel right
> to cram the scan functionality into the normal FE_SET_FRONTEND ioctl.

OK, so I propose this:

- you use FE_SET_FRONTEND as usual
- then, you call FE_SET_AUTO_SEARCH passing something as

struct dvb_autosearch {
	fe_autosearch_t	parameter;
	__u32		lower limit;
	__u32		higher limit;
}

typedef enum fe_autosearch_t {
	FE_AUTO_SYMBOL_RATE
}

- then you use FE_GET_FRONTEND to read the sr

This can be easily extended to auto-frequency (if some kind of
hardware can do it).

The only asimmetry is that all the other parameters have a _AUTO
value, while sr has not.
Should we introduce a SYMBOL_RATE_AUTO to use in FE_SET_FRONTEND
before calling FE_AUTO_SEARCH? (something as 0 or 0xffffffff).
This way the frontend is informed that nothing has to be done
before a FE_SET_AUTO_SEARCH arrives.
What about a FE_AUTO_GO|FE_AUTO_SYMBOL_RATE to begin the search
(I'm trying to imagine some hardware where two or more parameters
can be searched at the same time).

Thinking about it, we're converging to the original idea
from Holger.
But we shouldn't merge all the paramers together as he has done
in his example, so we save hw independence.

He proposed many ioctl (START_SCAN, CONTINUE_SCAN, STOP_SCAN),
and they may be useful in the future even if they are not needed
at the moment.

I don't agree to having this scan phase completely separated from
the normal tuning.
Instead:
- first normal tuning (with placeholders if necessary)
- then - scan_set_param
       - scan_set_param
       - scan_set_param
       - scan_start
       - get_frontend until found
       - scan_continue
       - get_frontend until found
       - scan_stop
after that, your hardware is already tuned to the last found thing.
If the hardware needs a reset or mode switch it can be done
in the "stop" call (so "stop" would actually mean "stop scanning and
return to normal behaviour").

I think we're close to a good solution.
Comments? (even on the names of the structures and fields)

Regards.
-- 
   Roberto Ragusa    mail at robertoragusa.it