On Wednesday 16 Nov 2005 23:30, Johannes Stezenbach wrote:
> On Wed, Nov 16, 2005 Andrew de Quincey wrote:
> > Was thinking - maybe we do need to move frequency scanning into the
> > kernel for optimum efficiency. It is going to have to be really frontend
> > specific code to get it as fast as possible, so I don't see we have much
> > choice. We could always implement a "dumb"/slow scanner as a fallback.
> >
> > e.g. something like the following structure passed to an ioctl.
> >
> > struct dvb_frontend_scan {
> > __u32 start_freq;
> > __u32 end_freq;
> > __u32 step;
> > };
> >
> > Perhaps we would want to have other things - e.g. specify a bitmask of
> > what FECs, and other such parameters to test.
> >
> > Felix's suggestion of just generating them as data to be read() from the
> > frontend device sounded ok to me. I suppose another option would be to
> > generate frontend events with the results, but I prefer read() myself.
>
> There were some previous suggestions for a scanning API by
> Roberto Ragusa and Holger Waechtler around Aug 1. 2004:
> http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/threads.html#00003
Thanks, that looks really interesting! I shall read it over.
What should I do with the overridable tuning patch... should I check it in?
Its basically what I posted last, except the userspace API is now:
typedef enum fe_tune_mode_flags {
FE_TUNE_MODE_ONESHOT = 0x01, /* if set, frontend will be oneshot mode */
} fe_tune_mode_flags_t;
#define FE_SET_FRONTEND_TUNE_MODE _IO('o', 81) /* unsigned int */
