On Thursday 02 March 2006 15:18, Johannes Stezenbach wrote: > On Thu, Mar 02, 2006, Marcel Siegert wrote: > > On Thursday 02 March 2006 13:54, Johannes Stezenbach wrote: > > > > > > I think FE_GET_INFO should only return the old values 0...3. > > > We can add a WARN_ON() in dvb_frontend.c to check that > > > drivers conform. > > and how will we report to an application that we have an e.g. FE_DVB_T (that would be single reported as FE_OFDM) frontend > > combined with FE_DVB_C ( that would be single reported as FE_QAM )? > > i mean if we do a return FE_OFDM | FE_QAM we will get a numeric return value of 3 that would equal an FE_ATSC in this case. > > > > or, should combo frontends be reported in a different kind? got any solutions already in mind? > > Two mails earlier I wrote: > > | FE_GET_INFO returns the default frontend type, an application > | which wants to use the new features sees the > | FE_HAS_EXTENDED_CAN_VALUES flag (bad name, IMHO), does > | FE_GET_EXTENDED_INFO (or maybe better a more generic FE_GET_CAPS > | in the style of V4 API DVB_VIDEO_GET_CAPS?), and so discovers > | the supported FE types, which it can then switch via FE_SET_STANDARD. > > It means one has to pick a default. Old apps don't know > how to switch, one could add a module parameter/sysfs attribute > to the particular driver as a workaround (switch FE type, > restart legacy app). > > Johannes > oh, now i see. i must apologise i missed that. regards marcel _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
