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. > What's the exact difference between HW and ADAPTIVE? Isn't "it's done in > hardware" the same as "it's done in the frontend driver", as far as the > API is concerned? It was because for HW cards you effectively just send one tune command, and then wait for it to lock. For ADAPTIVE, it is likely to need extra support from within the frontend code - so I gave it an extra mode so that could be accommodated. Of course - as I haven't thought about what would be required for ADAPTIVE yet, I should maybe just have SW+SIMPLE+HW for the moment. Then we can add ADAPTIVE later if need be. Since that stuff would be entirely internal after I do my new patch above, that isn't a great deal. > Some frontends support blindscanning, but require heavy software support > for this (Fujitsu mb86a15 for example). Such code is not really suitable > in the kernel (it sleeps, includes complicated algorithms etc.), so i > think the best would be to make it a userspace library with frontend > specific private ioctls, providing more or less direct register (or even > i2c) access. What do you think? > > Blindscanning on DVB-T would require the same - most demods can do this > way better than any generic API could handle. I'll need to think about that more... this is the sort of thing I was thinking about investigating during the ADAPTIVE stuff.
