On Tuesday 15 Nov 2005 23:50, Johannes Stezenbach wrote:
> On Tue, Nov 15, 2005 Andrew de Quincey wrote:
> > I assume it would be something like this?
> >
> > struct dvb_configuration {
> > unsigned char tune_mode:1 /* 0=>normal tuning, 1=>frequency scanning */
> > };
> >
> > #define FE_SET_CONFIGURATION _IOR('o', 81, struct dvb_configuration)
> >
> > And we'd extend dvb_configuration (or whatever) as we need to...
>
> Nah, once we have an ioctl we want to stay binary compatible.
> So just an "unsigned int flags", and I would use #defines
> for the flag values, not a struct with bit fields, because
> I believe this is the preferred coding style for Linux.
OK, no probs. I'll use FE_SET_FRONTEND_TUNE_MODE as you describe then - patch
attached.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tunealgo-5.patch
Type: text/x-diff
Size: 18202 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20051116/e5451c65/tunealgo-5-0001.bin
