Roberto Ragusa wrote:
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
If I understand it correctly, all parameters passed to FE_SET_FRONTEND would be set to AUTO, except for the frequency? If so, then it would make more sense to me to add the frequency to struct dvb_autosearch, and not use FE_SET_FRONTEND for scanning. This also needs to avoid the zigzag scan which FE_SET_FRONTEND normally does.
(BTW, typedefs are deprecated for kernel code (only allowed for explicitly opaque data types)).
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.
These are only useful if the hardware can indeed scan a frequency range automatically. If not, they are useless as userspace can only check (a small band around) one frequency, and retrieve the result (no signal, or a full parameter set). So please check the data sheets again (for mt352 and mt312) to see if this is true.
the MT352 can do true searches, IIRC the ZL10312 too. Not sure about it's predecessors, the MT312 and the VP310.
Holger