[linux-dvb] DVB-S2 and other (new) modulation standards

Marcel Siegert mws at linuxtv.org
Wed Nov 23 15:00:53 CET 2005


> [...]
> >>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


More information about the linux-dvb mailing list