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

[Carsten Juttner]

Felix Domke wrote:

>standard would use the default standard. Dual-Mode-Frontends would
>default to either DVB-S, oder -T or whatever. There could be a tool to
>change the mode. DVB-S2 would simply be not possible without the new
>FE_SET_STANDARD, as the default would be DVB-S.
>  
>

You haven't adressed the issue Rainer had, yet. Should a dual-mode 
(meaning that it can EITHER operate in one OR the other mode) frontend 
be abstracted away as 2 distinct frontends (frontend0..fronend1)?

The advantage of having 2 logical devices in the system is that older 
applications would have to know nothing about switching between the 
modes, they would just open the correct device and check its type and if 
the ioctl is unable to retrieve information it would simply return an error.

The disadvantage is that the user might believe he can use both of them 
at the same time (this raises questions, causes traffic on mailing lists 
and developers spend valuable time answering them).

The advantage of having one logical device is that the application could 
properly describe it in a GUI (with f.ex. a spin box) and that the user 
knows there is only one device.

The disadvantage and also Rainer's concerns were that this puts the 
issue of having to determine which mode is active on the application. If 
for example one application is displaying the current status in 
read-only mode and another application is able to write to the frontend, 
this could cause the first application to get out of sync with the 
frontend because - if using the old ioctls - it would not be able to 
tell just from the struct what mode the frontend is operating in and 
would have to use both FE_GET_INFO/FE_GET_FRONTEND-ioctls to determine 
the type of the frontend and the mode of the struct that is returned.

Another problem is that, if for example a dual-mode device supports both 
DVB-S and -C there would be no "default compatibility mode" that the 
device could enter on startup, so the burden would be put on the user to 
decide (probably by using a module parameter).

Of course all of this is pretty academic unless we really do have those 
devices in widespread use.

Regards,
Carsten Juttner