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.