On 2/18/06, Johannes Stezenbach <js@xxxxxxxxxxx> wrote: > > I am not sure what to do about mixing software that does not support > > 8PSK modulation with hardware that does. In this case, there is the > > small chance that a program does not initialize the > > dvb_frontend_parameters, structure and that the value in the > > 'modulation' variable equals QPSK_8 or QPSK_B in which case any card > > looking for these will be switched to the wrong mode. > > Hm, breaking source compatibility is not nice :-( One possibility would be to add an ioctl where an APP can enable 8PSK/BPSK support. In this case, cards by default would only do QPSK, and only if the correct command is sent (indicating that the new modes are supported by the app) are the new capabilities enabled. It is a crude approach though. > > > Perhaps an additional 'union' is necessary to prevent that... > > I'm undecided. Does anyone have an opinion? Personally, I'd prefer not to go this way (obviously), as it would definitely slow adoption in apps. But I'll do whatever is requested. > > Is these change sufficient to add full DVB-S2 support, or are > further changes necessary? If so, I'd prefer them to be added > in one go. This I don't know, someone else would need to respond on it. Perhaps DVB-S2 brings enough new configuration that it requires its own union anyhow. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
