[linux-dvb] DVB-S2 and other (new) modulation standards
tmbinc at elitedvb.net
Wed Nov 23 13:30:00 CET 2005
> 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
no. They will only deliver all the info for the *currently selected*
As said - a frontend will change it's "personality" when a new standard
is set. Different capabilities, different structure returned in
> 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...
Yes, but that makes things complicated, in my eyes a LOT more than that
You get exactly the same lock problems as using a single device, so i
belive my "FE_SET_FRONTEND-returns-EBUSY-when-frontend-is-opened" fixes
> Advantage: older application do not break (but there might be errors
> like EBUSY for a decive).
They DO break.
For example enigma2 assumes that all frontends on one adapter can be
used at once, which is IMHO the correct behaviour. (or do you disagree
Having only one frontend would not break this. Of course the secondary
standard couldn't be used, but that's better than NONE (because half of
the time the one frontend works and the other don't, and the rest of the
time it's vice versa. It's totally unpredictable, unless applications
know this new enumeration stuff).
The really only advantage is that simple applications like szap, which
only open ONE frontend, can use a specific one. But I really don't like
passing parameters in the frontend number...
For these simple application, in my proposal, the frontend type has to
be selected with a tiny userspace tool before.
Think of -S2 again. Do you really want to have two logical frontends for
each physical one?
> 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...
I'm not sure if this helps.
Sure, having a FE_GET_API_VERSION is fine for displaying a fancy number,
but does it really help?
FE_SET_STANDARD (or any new IOCTL) will return an errorcode which
indicates that it's not yet available. Then we have capability flags.
Everything else can be kept totally backward compatible.
We shouldn't waste compatibility just because there's a way to detect
With my proposal, an old driver would behave identically like a new one,
which just doesn't support multiple standards. I think that's fine, and
the expected behaviour.
If you want to modify structure (sizes) depending on the API version,
you either a.) have to use the *EXACT* api version in userspace as in
kernel (we certainly don't want this!! Think of all this "wireless
extension v13 doesn't match kernel version v15"), or b.) negotiate the
used API version, and have kernel support for each API version (think of
all that microsoft OLE/active-X stuff, where you need each interface up
to 5 times to support different versions). We don't want this, either.
> Felix Domke schrieb:
Du TOFUst :)
More information about the linux-dvb