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 _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
