> Nitpick: tuner doesn't have anything to do with FEC, it just provides IQ > outputs to the demodulator. ;-) ya ya :) you knew what I meant, not what I said hehe > Demods support all FEC's relevant to their delivery systems. It's just that > some devices likely do support some additional states. This part I dont understand, what do you mean additional states ? and how would a userland application determine if a demod supports these additional states? > I think DCII FEC5/11 is standard, reading this URL > http://rickcaylor.websitetoolbox.com/post/DCII-Valid-SRFECModulation-Combinations-5827500 > I would say, it is pretty much standard for DCII. yes 5/11 is standard for DCII, but nothing else. > Given that it is pretty much standard, I would say that for DCII; for > the genpix > all you need is a SYS_DCII and or a SYS_DSS addition to the genpix driver, > rather than having a ton of delivery systems mixed with modulations as in > your patch with DCII_QPSK, ... _OQPSK etc. Actually, those are a bit too > superfluous. You shouldn't mix delivery systems and modulations. That was > the whole reason why the delivery system flag was introduced to make > things saner and proper for the frontend API. Yup fair enough, easy to change, I'll get on that and resubmit the patch. > If I am not mistaken, the genpix hardware is a hardware wrapper around the > BCM demodulator. So, it is quite likely that even if you don't set any FEC > parameter, the device could still acquire lock as expected. I am not holding > my breath on this. Maybe someone with a genpix device can prove me right > or wrong. FEC_AUTO works for all but turbo-qpsk on genpix devices. I still think its important to have all the fec supported in the driver though even if FEC_AUTO did work 100% else why even have it as an option at all. > With the STB0899 driver, all you need to tune with it is Frequency, > Symbol Rate and Delivery system > > > With the STV090x driver all you need is Frequency and Symbol Rate. > (It will auto detect delivery system) Same thing, I still think if we allow the user to send a fec value we should make sure its right, else why not just hard code all the drivers to fec-auto that support it and remove the option all together. I dont like that option. > When a driver is not accepting those parameters as inputs, why > should the application/user burden himself with knowing parameters > of no relevance to him ? But it will accept them as inputs. without complaint too. I can send DTV_INNER_FEC w/ FEC_5_11 to stv090x and it doesnt complain at all, even though it doesnt support it. It'll even acquire a lock just because the demod uses blind search. So the driver most definitely does accept fec that it cant use. > Actually with all those redundant FEC bits gone away from relevance, things are > a bit more saner. I dont understand this either. "gone away from relevance" are you meaning just how they really arent used much anymore or something? still though if the demod supports them I think we should too. Honestly I still think the .delsys .delmod .delfec is a cleaner approach then we have now which is ugly and mismatched (modulations mixed in with fec, and only some are defined) its not a perfect solution though so I really dont think its worth fighting for if others dont agree with me. Im just kinda surprised that everyone is perfectly happy with the .delsys / .caps method we use Chris -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
