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