[linux-dvb] DVB-S2 and other (new) modulation standards
Rainer.Scherg at t-online.de
Wed Nov 23 14:39:34 CET 2005
Felix Domke schrieb:
> Hi Rainer,
> Rainer.scherg wrote:
>>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
> FE_GET_FRONTEND/FE_SET_FRONTEND etc.
So how do you know the standards which the device is capable of?
>>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
> single IOCTL.
> 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
Agreed, busy-problems have to be solved in both cases.
Abut again, what happens, if e.g. VDR is switching "personallity" of
a device and another (old) user application is reading/polling current
FE information (e.g. dvbsnoop -s feinfo). In this case the application
might assume a QPSK struct, but reading a QAM struct due to switched
Your idea is not bad for a new API, but has IMO some compatibility
problems with the present one.
>>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
maybe, you might get a EBUSY.
So what would be the worst case?
What would happens today? Would you have one frontend or two
for a C/T frontend.
> 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).
Correct, only new application could handle this.
Old application are failing on one device (as they would do today).
> 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...
I do not understand, you will open the fe device anyway.
> For these simple application, in my proposal, the frontend type has to
> be selected with a tiny userspace tool before.
uhh, not really? IMO a bad solution.
> Think of -S2 again. Do you really want to have two logical frontends for
> each physical one?
DVB-S2 you only will have one frontend only.
>>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.
FE_GET_API_VERSION is a different discussion and will not solve
the frontend problem.
But determining the current API type on a machine by #ifdef's in
the sourcecode is IMO braindead. This only works when you are
compiling applications for yourself. How can an application determine
the current DVB-API on a customer machine? (by guessing/probing
currently the device pathes - hoping these are not renamed/relocated?)
There are better and easier ways to do this job... 8)
> Sure, having a FE_GET_API_VERSION is fine for displaying a fancy number,
> but does it really help?
An application should be able to check it's environment at runntime.
So, a runtime API version check is IMO basically missing.
>>Felix Domke schrieb:
> Du TOFUst :)
...und das mir, einem altem Maus-Netzer... 8]
More information about the linux-dvb