On Tuesday 15 Nov 2005 18:40, Manu Abraham wrote: > Andrew de Quincey wrote: > >On Tuesday 15 Nov 2005 18:07, Felix Domke wrote: > >>Andrew de Quincey wrote: > >>>Hi, this patch allows frontends (and the user) to select from one of > >>>several different tuning algorithms. The patch adds four possibilities: > >>>1) SW - the current dvb-kernel software zigzag code. > >>>2) HW - the hardware supports zigzagging internally (e.g. DST), so use > >>>that as it will be faster. > >>>3) ADAPTIVE - frontend-specific code exploiting frontend-specific > >>>features. 4) SIMPLE - just set the frontend once and do nothing else > >>>(e.g. for frequency scanner apps). > >> > >>Though I didn't test this, i strongly agree that we need this. I don't > >>think it should be user selectable, though (except for the "SIMPLE" > >>mode) - either the frontends supports a specific algorithm or not. > >>Otherwise i fear that user applications start to workaround frontend > >>driver bugs by selecting another algorithm... > > > >Hmm, yeah thats a good point. The userspace API should _really_ just be > >switchable between "standard" and "scan" mode. > > > >What constitutes "normal" mode is then up to the innards of the driver. > > OK, will update the patch to reflect this. > > But that will apply to the adaptive algo only probably, since there > cannot be an alternative for the HW_ALGO as it will be implemented in > Hardware and no point in doing it otherwise. So the only 2 cases left > would be S/W and and ADAPTIVE, so switching between "standard" and scan" > mode might not make any difference.. ? > > Or do you mean that the user does not have any option to switch between > ADAPTIVE and SW .. ? Yup, the second one. I want the user to be able to switch between "normal" and "scan" mode. It perhaps isn't useful for the DST, but it would be for most other frontends.
