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... 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? 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. Felix
