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
