On Mon, May 22, 2006, Marcel Siegert wrote: > -------------------------------------------------------------------------------------------- > On Tue, Nov 22, 2005, Marcel Siegert wrote: > hi, > > as dvb-s2 will come along shortly we should be prepared. > > this is a first patch within a series that will appear to support > dvb-s2 within the different apis. > > it just adds the new fec modes and the dvb-s2 rollflag enums. > > -------------------------------------------------------------------------------------------- > > there came a slightly answer: > So far so good, but we should IMHO not commit partial solutions. > I think we should bang out the complete API, with the part which > Felix mentions in his posting. and commit it as one API change. > > Johannes > -------------------------------------------------------------------------------------------- > > so, what should i say? > we started nearly 6 (SIX!) month ago to discuss what we need for DVB-S2 support. If I only knew which of Felix' postings this refers to... Maybe the one where he raises the FE_SET_STANDARD issue? Anyway, it is funny how this discussion went in circles. I didn't know anything about DVB-S2 then (didn't care to read the standard), and it seems I got the impression that the proposal was incomplete. So if someone would have explained to me why it is exactly what we want, the issue would have been settled there and then. Re-reading some of this discussion, my "partial solutions" remark was clearly not about support for obscure DVB-S2 features, but your patch was missing the FE_SET_STANDARD (DVB-S vs. DVB-S2) issue raised in Felix' postings. As such I thought it was incomplete (and I still think so, assuming one needs to switch the demod hardware into DVB-S2 mode explicitly for tuning to work). > but instead of having some real constructive critics ( i do not call you on this, johannes :) ) > we were talking about 3 weeks about how to name a paremeter struct or ioctl. > > of course, FE_SET_FRONTEND_NEW is fine, but what about FE_SET_FRONTEND_NEW_NEW next time? Well, naming of APIs *is* important. But of course function is even more important ;-/ > we all should concentrate on what we really want. 100% ACK Now let's define what we really want ;-) > that should be DVB not feeding google or any other kind of search engine with endless mailing list threads > > Result 1 - 10 of 911 für linuxtv multi protocol. on google today 14:44. Most of these probably for MPE... > no more comments. go for it ( maybe adjusted in some small pieces ) or wait until we have some individual > solutions that already do appear are brought to the universe. everybody needs to have a special > kernel patch for applying a patch that a special application patch recommends. > > thats MUCH more ugly than having _maybe_ 2 or 3 unneeded enum structs within the api interface. > but thats just my opinion. i don't know if anyone counts on it. Sorry, I can't make sense out of that. Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
