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

Rainer.scherg 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
>>modes/standards.
> 
> no. They will only deliver all the info for the *currently selected*
> standard.
> 
> 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?

FE_ENUMERATE_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
> 
> 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
> this.

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
"personallity".

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
> here?)

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.


> 
>>Rainer
>>Felix Domke schrieb:
> 
> Du TOFUst :)
> 

...und das mir, einem altem Maus-Netzer... 8]


Rainer




More information about the linux-dvb mailing list