Rainer.scherg wrote:
> Felix Domke schrieb:
>> Rainer.scherg wrote:
>> 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?
By extending the currently available capability flags. There are some
bits left which could be used for "FE_CAN_STANDARD_DVBS",
"FE_CAN_STANDARD_DVBC", "FE_CAN_STANDARD_DVBS2",
"FE_CAN_STANDARD_DVBT",... (i.e.: the available choices for
FE_SET_STANDARD).
> 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".
An application should open the frontend once, then query its type, then
use that information.
While the frontend is open (by another application), FE_SET_STANDARD
would fail. It only works when the frontend is only opened once.
The only case where this fails is when an application opens the
frontend, queries the type, closes it, then open it again and assumes
that "nothing has changed". But thats a more generic error - somebody
could have re-enumerated the frontends, re-plug the usb stick or whatever.
>> 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?
The user selects a channel, the tune fails. The user retries, it works
(because somebody freed the "other" frontend).
Explain this to the user.
> What would happens today? Would you have one frontend or two
> for a C/T frontend.
One. (unless they work in parallel, of course.)
>> 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).
NO.
They are failing randomly on one device, in an unpretictable way.
Correct - old - applications would fail, whereas with my approach, they
would continue work, of course only with the pre-selectable standard.
>> 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.
Effectively you're passing the "wanted standard" in the filename of the
frontend device ("frontend0" / "frontend1"). This isn't really what I
thought an API should do.
>> 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.
The alternative is breaking current applications for no real reason.
>> 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.
Ah.
How do you expect the API to handle THIS?
Why is a DVB-S/S2 frontend a different thing than DVB-C/T ? (from a
technical standpoint, of course.) The behaviour is EXACTLY the same: you
need different tuning parameters, and only one "transponder"/channel
works at a time.
Why should the API handle this differently?
> FE_GET_API_VERSION is a different discussion and will not solve
> the frontend problem.
yes.
> 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)
v1 is obsolete (yes, this comes from my mouth ;).
v3 never had such problems.
>> 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.
You need to open the .. frontend device? .. anyway. How do you know the
path of that, without probing?
When you already found it, why bother if it's the correct API, when
everything with the same file name is binary compatible?
Felix
