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

[Rainer.scherg]

Felix,

there is another disadvantage, when having only one frontend
for combi devices.

You have to enhance the FE_GET_INFO and FE_GET_FRONTEND to
deliver tuning, modulation and capability information for several 
modes/standards.

Using separate frontend devices will avoid this.
What might be needed is a kind of chaining information for frontends.
E.g. a list of frontends on the same card, when querying FE_GET_INFO.

So a FE_GET_INFO on ".../frontend0" has to return add. information like:
    I'm am a super device, and i'm owner of...
     .../frontend0,
     .../frontend1,
     .../frontend2

If we do not get this into FE_GET_INFO without breaking compatibility,
we could do a FE_ENUMERATE or similar... (next new IOCTL).


Advantage: older application do not break (but there might be errors
like EBUSY for a decive).

Newer application have to check API version at runtime(!) if new
IOCTLs are supported by kernel (if not: fallback to old API or just 
abort...). Here again my request for a simple FE_GET_API_VERSION...


Rainer




Felix Domke schrieb:
> Carsten Juttner wrote:
> 
>>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)?
> 
> One frontend.
> 
> With my proposed "locking method" (see below), you have to get the
> current standard (!= modulation!) once, then poll the status.
> 
> Sure, a "standard" field in the frontend structure would be great, but
> it isn't there, and all methods of adding one would raise more backward
> compatibility issues...
> 
> 
>>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.
[...]