> [...] > >>You have to enhance the FE_GET_INFO and FE_GET_FRONTEND to > >>deliver tuning, modulation and capability information for several > >>modes/standards. > > > > no. They will only deliver all the info for the *currently selected* > > standard. > > > > As said - a frontend will change it's "personality" when a new standard > > is set. Different capabilities, different structure returned in > > FE_GET_FRONTEND/FE_SET_FRONTEND etc. > > > So how do you know the standards which the device is capable of? > > FE_ENUMERATE_STANDARDS? all actual fe driver will return a EOPNOTSUPP for the FE_SET/GET_STANDARD this will keep all older applications compatible. userspace apps can rely on FE_GET_INFO for fetype and capabilities . if FE_SET/GET_STANDARD does return values, the application can perform a FE_GET_INFO and check for the fe_type_t value within the info struct which in case _could_ contain or'ed values. to keep binary compatibility with old applications that would expect only one explicit value within the frontend type, frontends should internally keep a flag that only if a FE_GET_STANDARD has been done, they could mix up the return value within the info struct. if an old application is asking for the FE_GET_INFO the fe_type could be filled with the normally fall back option like FE_QPSK instead of FE_8PSK or what the new frontends will be enumerated to. comments? regards marcel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20051123/142681cc/attachment.pgp
