Hi, Am Dienstag, den 25.11.2008, 10:05 +0100 schrieb Klaus Schmidinger:> On 25.11.2008 09:46, Niels Wagenaar wrote:> > Op Ma, 24 november, 2008 20:33, schreef Manu Abraham:> >> Klaus Schmidinger wrote:> >>> On 24.11.2008 16:55, Niels Wagenaar wrote:> >>>> ...> >>>> For the time being I have only two options which will work without any> >>>> additional patching in S2API:> >>>>> >>>> - Let the user set this as an option> >>>> - Use my VUP (very ugly patch) by checking the deliverystem for the> >>>> string> >>>> "DVBS2".> >>> Both are ugly workarounds and any reasonable API requiring them instead> >>> of simply reporting the -S2 capability of a device should> >>> be ashamed, go home and do its homework.> >> ACK> >>> > > > And still, I see many popular/free/commercial DVB software on the Windows> > platform where you need to select the DVB-S2 option on the DVB-card. So I> > wouldn't just throw away this option as an ugly work-around.> > > > In fact, I would like to set the specific type for my DVB cards if I> > could. So an override option is definately not a ugly work-around and for> > several people this will not be problem.> > > > But, the other option is definately a very ugly work-around. But then> > again, it works ;)> > > >>> For the time being I'll work with my suggested FE_CAN_2ND_GEN_MODULATION> >>> patch - until somebody can suggest a different way of doing this> >>> (without> >>> parsing strings or requiring the user to do it).> >> ACK.> >>> >> That is a saner way of doing it rather than anything else, as it stands.> >>> >> Anyway, we won't be seeing professional device support as it stands with> >> the current API anytime soon, so as it stands the better alternative is> >> thus.> >>> >> But it would be nice to have something shorter: say FE_IS_2G or> >> something that way, for the minimal typing.> >>> > > > I disagree on both of the proposals. Add an other flag is indeed the way> > (I ACK that), but not a general one like you both proposed. When DVB-T2> > (or DVB-S3 or DVB-C2 or whatever new enhancement of past DVB standards)> > becomes mainstream we get the exact same discussion again.> > > > IMHO, an non-general flag like FE_CAN_DVBT, FE_CAN_DVBS, FE_CAN_DVBS2,> > FE_CAN_DVBC, etc would be more clearer. Since it's an DVB standard, it> > must support certain modulation types, etc. So if the driver set its> > frontendtype to FE_CAN_DVBT, you know for sure what tuning types it> > supports.> > > > But it al depends if people want to add this in the v4l driver also. If> > they don't, it doesn't matter which proposal or patch makes it. And for> > that a manual override or setting would become very handy.> > > >> Regards,> >> Manu> >>> > > > Look, I'm not an developer perse and you can ignore what I just wrote. But> > my logic tells me that an manual override or a non-general FE_CAN flag for> > the current DVB standards is a very clean sollution. Just my € 0,02.> > I find it a completely unacceptable thing to have the user tell> the application what type of DVB devices the hardware provides.> This is pretty much the first and simplest thing the *DRIVER* has> to do. If a driver (API) doesn't allow this in a clean way, it's> worthless! the "superior" _other_ stuff hangs in it too and much more. > I don't care if this is a specific or a general flag, as long as> it allows the application to clearly find out the kind of hardware> that's available. It leaves me dumbfounded that this is suddenly> such a big problem...> > If my proposal is not acceptable, then please can one of the S2API> experts come up with a solution that better fits the S2API way of> thinking? Steven did not work on S2API for fun, he was excluded from multiprotoover years, and tried all previously to overcome this. He might have a break currently, but if you want your patches reviewedand included, Manu can forward them as well for you, or you try to postto Mauro directly too, since he is often in delay reading the lists, butthat won't make any difference, since he will ask for feedback from allinvolved anyway, before applying patches. Believe it or not. > <conspiracy_theory><sarcasm>> Or is the S2API already "dead", and it's sole purpose was to> prevent "multiproto" to make its way into the kernel? And now that> this has been achieved, nodody really cares whether it can be used> in real life?> </sarcasm></conspiracy_theory>> > Klaus> Cheers,Hermann _______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
