On 16.07.2011 17:44, Antti Palosaari wrote: > On 07/16/2011 06:40 PM, Andreas Oberritter wrote: >> On 16.07.2011 16:54, Mauro Carvalho Chehab wrote: >>> Em 16-07-2011 11:16, Antti Palosaari escreveu: >>>> On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: >>>>> Em 15-07-2011 20:41, Antti Palosaari escreveu: >>>>>> On 07/15/2011 08:01 PM, Andreas Oberritter wrote: >>>>>>> On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: >>>>>>>> Em 15-07-2011 05:26, Ralph Metzler escreveu: >>>>>>>>> At the same time I want to add delivery system properties to >>>>>>>>> support everything in one frontend device. >>>>>>>>> Adding a parameter to select C or T as default should help in most >>>>>>>>> cases where the application does not support switching yet. >>>>>>>> >>>>>>>> If I understood well, creating a multi-delivery type of frontend >>>>>>>> for >>>>>>>> devices like DRX-K makes sense for me. >>>>>>>> >>>>>>>> We need to take some care about how to add support for them, to >>>>>>>> avoid >>>>>>>> breaking userspace, or to follow kernel deprecating rules, by >>>>>>>> adding >>>>>>>> some legacy compatibility glue for a few kernel versions. So, >>>>>>>> the sooner >>>>>>>> we add such support, the better, as less drivers will need to >>>>>>>> support >>>>>>>> a "fallback" mechanism. >>>>>>>> >>>>>>>> The current DVB version 5 API doesn't prevent some userspace >>>>>>>> application >>>>>>>> to change the delivery system[1] for a given frontend. This >>>>>>>> feature is >>>>>>>> actually used by DVB-T2 and DVB-S2 drivers. This actually >>>>>>>> improved the >>>>>>>> DVB API multi-fe support, by avoiding the need of create of a >>>>>>>> secondary >>>>>>>> frontend for T2/S2. >>>>>>>> >>>>>>>> Userspace applications can detect that feature by using >>>>>>>> FE_CAN_2G_MODULATION >>>>>>>> flag, but this mechanism doesn't allow other types of changes like >>>>>>>> from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that >>>>>>>> allow such >>>>>>>> type of delivery system switch, using the same chip ended by >>>>>>>> needing to >>>>>>>> add two frontends. >>>>>>>> >>>>>>>> Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to >>>>>>>> fe_caps_t, and >>>>>>>> add a way to query the type of delivery systems supported by a >>>>>>>> driver. >>>>>>>> >>>>>>>> [1] >>>>>>>> http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM >>>>>>>> >>>>>>> >>>>>>> I don't think it's necessary to add a new flag. It should be >>>>>>> sufficient >>>>>>> to add a property like "DTV_SUPPORTED_DELIVERY_SYSTEMS", which >>>>>>> should be >>>>>>> read-only and return an array of type fe_delivery_system_t. >>>>>>> >>>>>>> Querying this new property on present kernels hopefully fails with a >>>>>>> non-zero return code. in which case FE_GET_INFO should be used to >>>>>>> query >>>>>>> the delivery system. >>>>>>> >>>>>>> In future kernels we can provide a default implementation, returning >>>>>>> exactly one fe_delivery_system_t for unported drivers. Other drivers >>>>>>> should be able to override this default implementation in their >>>>>>> get_property callback. >>>>>> >>>>>> One thing I want to say is that consider about devices which does >>>>>> have MFE using two different *physical* demods, not integrated to >>>>>> same silicon. >>>>>> >>>>>> If you add such FE delsys switch mechanism it needs some more glue >>>>>> to bind two physical FEs to one virtual FE. I see much easier to >>>>>> keep all FEs as own - just register those under the same adapter >>>>>> if FEs are shared. >>>>> >>>>> In this case, the driver should just create two frontends, as >>>>> currently. >>>>> >>>>> There's a difference when there are two physical FE's and just one FE: >>>>> with 2 FE's, the userspace application can just keep both opened at >>>>> the same time. Some applications (like vdr) assumes that all multi-fe >>>>> are like that. >>>> >>>> Does this mean demod is not sleeping (.init() called)? >>>> >>>>> When there's just a single FE, but the driver needs to "fork" it in >>>>> two >>>>> due to the API troubles, the driver needs to prevent the usage of both >>>>> fe's, either at open or at the ioctl level. So, applications like vdr >>>>> will only use the first frontend. >>>> >>>> Lets take example. There is shared MFE having DVB-S, DVB-T and >>>> DVB-C. DVB-T and DVB-C are integrated to one chip whilst DVB-S have >>>> own. One remark: In my previous mail I assumed that in your example DVB-S and either DVB-C or DVB-T can be tuned simultaneously, i.e. there are two antenna connectors and two tuners in addition to the two demod chips. If this assumtion was wrong, then of course approach 2 is the sane one, not approach 3. >>>> Currently it will shown as: >>> >>> Let me name the approaches: >>> >>> Approach 1) >>>> * adapter0 >>>> ** frontend0 (DVB-S) >>>> ** frontend1 (DVB-T) >>>> ** frontend2 (DVB-C) >>> >>> Approach 2) >>>> Your new "ideal" solution will be: >>>> * adapter0 >>>> ** frontend0 (DVB-S/T/C) >>> >>> Approach 3) >>>> What really happens (mixed old and new): >>>> * adapter0 >>>> ** frontend0 (DVB-S) >>>> ** frontend1 (DVB-T/C) >>> >>> What I've said before is that approach 3 is the "ideal" solution. >>> >>>> It does not look very good to offer this kind of mixed solution, >>>> since it is possible to offer only one solution for userspace, new >>>> or old, but not mixing. >>> >>> Good point. >>> >>> There's an additional aspect to handle: if a driver that uses >>> approach 1, a conversion >>> to either approach 2 or 3 would break existing applications that >>> can't handle with >>> the new approach. >>> >>> There's a 4th posibility: always offering fe0 with MFE capabilities, >>> and creating additional fe's >>> for old applications that can't cope with the new mode. >>> For example, on a device that supports >>> DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T, it will be shown as: >>> >>> Approach 4) fe0 is a frontend "superset" >>> >>> *adapter0 >>> *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset >>> *frontend1 (DVB-S/DVB-S2) >>> *frontend2 (DVB-T/DVB-T2) >>> *frontend3 (DVB-C) >>> *frontend4 (ISDB-T) >>> >>> fe0 will need some special logic to allow redirecting a FE call to >>> the right fe, if >>> there are more than one physical frontend bound into the FE API. >>> >>> I'm starting to think that (4) is the better approach, as it won't >>> break legacy >>> applications, and it will provide an easier way for new applications >>> to control >>> the frontend with just one frontend. >> >> Approach 4 would break existing applications, because suddenly they'd >> have to cope with an additional device. It would be impossible for an >> existing application to tell whether frontend0 (from your example) was a >> real device or not. >> >> Approach 2 doesn't make any sense to me. > > I like approach 1 since it is very simple interface. Secondly I like > approach 2. I think that more API issue than technical. > > >> The only sane approach is 3, because it creates one device node per >> demod chip. As Ralph already suggested, an easy way to not break >> applications is to add a module parameter which selects the default mode >> (DVB-C or DVB-T in Antti's example). One could also write a small >> command line application to switch modes independently from VDR et al. >> After all, you cannot connect both a DVB-C cable and a DVB-T antenna at >> the same time, so the vast majority of users won't ever want to switch >> modes at all. > > You are wrong, actually you can. At least here in Finland some cable > networks offers DVB-T too. I know that there are cable operators which use DVB-T, but they don't use DVB-C simultaneously. This wouldn't make sense, unless they didn't want their customers to receive their signals. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
