| Message ID | 4E1FBA6F.10509@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Friday 15 July 2011 05:56:31 Mauro Carvalho Chehab wrote: > Em 14-07-2011 21:47, Mauro Carvalho Chehab escreveu: > > Em 14-07-2011 20:45, Oliver Endriss escreveu: > >> - DVB-T tuning does not work anymore. > > I think that the better is to revert my patch and apply a solution similar > > to cxd2820r_attach. It should work fine if called just once (like ngene/ddbridge) > > or twice (like em28xx). > > I ended by fixing it at the easiest way: Just add a hack at em28xx to work the same > way as ngene/ddbridge. > > The code is not beautiful, but in order to fix, I would also need to touch at > tda18271c2dd. Let's do it on another time. > > [media] Remove the double symbol increment hack from drxk_hard Thanks, module unloading works again. > Both ngene and ddbrige calls dvb_attach once for drxk_attach. > The logic used there, and by tda18271c2dd driver is different > from similar logic on other frontends. > > The right fix is to change them to use the same logic, but, > while we don't do that, we need to patch em28xx-dvb in order > to do cope with ngene/ddbridge magic. I disagree: The right fix is to extend the framework, and drop the secondary frondend completely. The current way of supporting multi-standard tuners is abusing the DVB API. CU Oliver
Oliver Endriss writes: > > Both ngene and ddbrige calls dvb_attach once for drxk_attach. > > The logic used there, and by tda18271c2dd driver is different > > from similar logic on other frontends. > > > > The right fix is to change them to use the same logic, but, > > while we don't do that, we need to patch em28xx-dvb in order > > to do cope with ngene/ddbridge magic. > > I disagree: The right fix is to extend the framework, and drop the > secondary frondend completely. The current way of supporting > multi-standard tuners is abusing the DVB API. > Yes, exactly what I wanted to say. I am just working on yet another C/T combo. This time stv0367 and TDA18212. For both there are existing drivers and our own version again. I am trying to merge them so that there is not yet another discussion regarding new driver versions (but the very first version might still come out with separate drivers). 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. Regards, Ralph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 15-07-2011 05:26, Ralph Metzler escreveu: > Oliver Endriss writes: > > > Both ngene and ddbrige calls dvb_attach once for drxk_attach. > > > The logic used there, and by tda18271c2dd driver is different > > > from similar logic on other frontends. > > > > > > The right fix is to change them to use the same logic, but, > > > while we don't do that, we need to patch em28xx-dvb in order > > > to do cope with ngene/ddbridge magic. > > > > I disagree: The right fix is to extend the framework, and drop the > > secondary frondend completely. The current way of supporting > > multi-standard tuners is abusing the DVB API. > > > > Yes, exactly what I wanted to say. Yeah, I see your point. The current approch, however, is in the mid-term of an unique multi-delivery-system frontend, and two frontend attachments. As such, it require some ugly glue at the bridge driver like: dvb->fe[1]->tuner_priv = dvb->fe[0]->tuner_priv; memcpy(&dvb->fe[1]->ops.tuner_ops, &dvb->fe[0]->ops.tuner_ops, sizeof(dvb->fe[0]->ops.tuner_ops)); My proposal is to keep it as-is for now, changing it after we extend the API to support multi-delivery-system frontend. > I am just working on yet another C/T combo. This time stv0367 and > TDA18212. For both there are existing drivers and our own version again. > I am trying to merge them so that there is not yet another > discussion regarding new driver versions Thanks! > (but the very first version > might still come out with separate drivers). > 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 Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 15-07-2011 14:01, Andreas Oberritter escreveu: > 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. Yes, this would work properly. > > 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. Yes. it currently returns an specific error code for not supported. > > 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. Seems fine for me. > > Regards, > Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. regards Antti
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. 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. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Currently it will shown as: * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T) ** frontend2 (DVB-C) Your new "ideal" solution will be: * adapter0 ** frontend0 (DVB-S/T/C) What really happens (mixed old and new): * adapter0 ** frontend0 (DVB-S) ** frontend1 (DVB-T/C) 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. regards Antti
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. > > 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. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. >> >> 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. 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. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 16 July 2011 16:54:50 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. > > > > 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): Why does this happen? > > * adapter0 > > ** frontend0 (DVB-S) > > ** frontend1 (DVB-T/C) > > What I've said before is that approach 3 is the "ideal" solution. No, sorry. > > 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. Nack. Do not make it more complicated than neccessary! Approach (2) is the way to go. I consider the current way as a clear abuse of the DVB API. It is a bug, not a feature! Originally it was intended to support multiple data paths per adapter. For example, A dual tuner DVB-S card should have been implemented as one adapter: adapterX +--- demux0/frontend0/ca0/dvr0/net0 | +--- demux1/frontend1/ca1/dvr1/net1 (Both tuners can be used concurrently without limitations.) My proposal is: If there is any kind of shared hardware, i.e. the application cannot use both adapters independently, these hardware must be folded into a single frontend. It is not so hard to implement, even for separate chips: The driver just has to "switch" from one set of frontend ops to another. Btw, which applications do really handle this fronten0/1 stuff correctly? VDR definitely does not. Access to the frontend1 fails. CU Oliver
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. >>> >>> 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. regards Antti
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/16/2011 06:53 PM, Andreas Oberritter wrote: > 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. My assumption was that frontends are using shared HW resources for reason or the other and thus only one FE can be used at the time. When there is no shared resources it should be implemented as multiple adapters. >>>>> 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. Hmmm, after all that's not big issue but they send both DVB-C and DVB-T muxes in same network. Most likely to offers some basic channels for customers who does not have DVB-C capable receiver. So setting desired FE to DVB-C mode blocks reception of DVB-T channels. regards Antti
Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : > > 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. They do offer both simultaneously. DNA (formerly Welho) in Helsinki provides both DVB-T and DVB-C on the same cable, obviously on different frequencies.
Em 16-07-2011 12:53, Andreas Oberritter escreveu: > 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. Yes: approach 1 has a simple interface. The only issue on that is that it is not possible to know if fe0 and fe1 can be used simultaneously, or if they're mutually exclusive. Several userspace applications currently don't work on that scenario, where the frontends are mutually exclusive. So, if we're going to use approach 1, we need to properly document that applications should be prepared for that scenario, and, maybe, adding some way for userspace to detect frontend "groups". >> Secondly I like >> approach 2. I think that more API issue than technical. Approach 2 limits the usage of two simultaneous fe, when they're not mutually exclusive. Not sure if this is actually a problem. >>> 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. There are two issues with this approach: - not breaking existing applications; - makes life harder for userspace, as they'll need to support multiple frontends and the delivery system switch. Ralph suggestion may help to solve the backport issue. Userspace applications that support DVB-T2/DVB-S2 already support delivery system switch. So, approach 3 seems feasible for me. >>> 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. As Antti and Rémi pointed, there are issues with some cable operators. Not sure how critical is that, but an userspace application changing it via sysfs might work while the applications are not ported to support both ways. Antti/Rémi, how the current applications work with one physical frontend supporting both DVB-T and DVB-C? Do they allow to change channels from one to the other mode on a transparent way? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 16-07-2011 12:44, Antti Palosaari escreveu: > 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: >>> 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. (not sure who commented this... somehow, I didn't receive the original email - well, I'll just reply on Antti's answer) Yes, an existing application will not know how to handle such fe, but, as the other fe's are still provided, they can swill switch the delivery system by replacing the frontend they're using. There are some alternatives for this approach, like: Approach 5) fe0 is a frontend "superset", initialized to handle the first registered delivery system >>> *adapter0 >>> *frontend0 (DVB-S/DVB-S2), but allows changing to DVB-T/DVB-T2/DVB-C/ISDB-T >>> *frontend1 (DVB-T/DVB-T2) >>> *frontend2 (DVB-C) >>> *frontend3 (ISDB-T) (so, it is something between approach 1 and 4) Being frankly, I think that this would be messy. In any case, I think that, if we decide for something like approach 4 or 5, we should deprecate the support for the extra frontends, after kernel + 2 versions, so, falling back into approach 2 (e. g. just one frontend for all delivery systems). I also think that we should get a decision about that for 3.1, and port DRX-K to the agreed approach before the release of 3.1, as it will be one less driver that we'll need to concern about migrating. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 16.07.2011 18:37, Rémi Denis-Courmont wrote: > Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : >>> 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. > > They do offer both simultaneously. DNA (formerly Welho) in Helsinki provides > both DVB-T and DVB-C on the same cable, obviously on different frequencies. Is there any channel available on DVB-T which isn't available on DVB-C in this cable network? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17.07.2011 02:56, Mauro Carvalho Chehab wrote: > Em 16-07-2011 12:53, Andreas Oberritter escreveu: >> 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. > > Yes: approach 1 has a simple interface. The only issue on that is that it is > not possible to know if fe0 and fe1 can be used simultaneously, or if they're > mutually exclusive. Several userspace applications currently don't work on that > scenario, where the frontends are mutually exclusive. > > So, if we're going to use approach 1, we need to properly document that applications > should be prepared for that scenario, and, maybe, adding some way for userspace > to detect frontend "groups". > >>> Secondly I like >>> approach 2. I think that more API issue than technical. > > Approach 2 limits the usage of two simultaneous fe, when they're not > mutually exclusive. Not sure if this is actually a problem. This would be a problem, of course. If they're not mutually exclusive, then I'd expect the possibility to use them simultaneously. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 17-07-2011 00:02, Andreas Oberritter escreveu: >> Approach 2 limits the usage of two simultaneous fe, when they're not >> mutually exclusive. Not sure if this is actually a problem. > > This would be a problem, of course. If they're not mutually exclusive, > then I'd expect the possibility to use them simultaneously. From userspace perspective, the possibility of using them simultaneously may not actually be useful, provided that they both share the same demux interface. However, I agree that adding an artificial limit there doesn't seem right. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le dimanche 17 juillet 2011 03:56:36 Mauro Carvalho Chehab, vous avez écrit : > >>> 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. > > As Antti and Rémi pointed, there are issues with some cable operators. Not > sure how critical is that, but an userspace application changing it via > sysfs might work while the applications are not ported to support both > ways. Telling applications to use sysfs... I can see many ways that you might regret that in the future... Accessing sysfs directly from an application is against all the good practices I thought I had learnt regarding Linux. There is the theoretical possibility that udev gets "explicit" support for Linux DVB and exposes the properties nicely. But that would be rather inconvenient, and cannot be used to change properties. > Antti/Rémi, how the current applications work with one physical frontend > supporting both DVB-T and DVB-C? Do they allow to change channels from one > to the other mode on a transparent way? I don't know. VLC does not care if you switch from DVB-T to DVB-C, to the DVD drive or to YouTube. Each channel (or at least each multiplex) is a different playlist item. So it'll close the all device nodes and (re)open them. There are obviously other applications at stake.
Le dimanche 17 juillet 2011 05:51:33 Andreas Oberritter, vous avez écrit : > On 16.07.2011 18:37, Rémi Denis-Courmont wrote: > > Le samedi 16 juillet 2011 18:53:16 Andreas Oberritter, vous avez écrit : > >>> 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. > > > > They do offer both simultaneously. DNA (formerly Welho) in Helsinki > > provides both DVB-T and DVB-C on the same cable, obviously on different > > frequencies. > > Is there any channel available on DVB-T which isn't available on DVB-C > in this cable network? Probably, I wouldn't know. My S******g TV won't provision channels from both systems at the same time. And Linux does not support DVB-T on my TT-connect CT-3650 tuner.
Em 17-07-2011 04:39, Rémi Denis-Courmont escreveu: > Le dimanche 17 juillet 2011 03:56:36 Mauro Carvalho Chehab, vous avez écrit : >>>>> 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. >> >> As Antti and Rémi pointed, there are issues with some cable operators. Not >> sure how critical is that, but an userspace application changing it via >> sysfs might work while the applications are not ported to support both >> ways. > > Telling applications to use sysfs... I can see many ways that you might regret > that in the future... I'm expressed it badly. What I meant to say is to have some sort of script or a specific application to allow users to change the delivery system, by changing the modprobe parameter, for the MFE drivers supported on <= 3.0 Kernel that won't fit in the agreed approach, while applications don't support the adopted approach directly. > Accessing sysfs directly from an application is against all the good practices > I thought I had learnt regarding Linux. There is the theoretical possibility > that udev gets "explicit" support for Linux DVB and exposes the properties > nicely. But that would be rather inconvenient, and cannot be used to change > properties. > >> Antti/Rémi, how the current applications work with one physical frontend >> supporting both DVB-T and DVB-C? Do they allow to change channels from one >> to the other mode on a transparent way? > > I don't know. VLC does not care if you switch from DVB-T to DVB-C, to the DVD > drive or to YouTube. Each channel (or at least each multiplex) is a different > playlist item. So it'll close the all device nodes and (re)open them. There > are obviously other applications at stake. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c index d503558..a0e2ff5 100644 --- a/drivers/media/dvb/frontends/drxk_hard.c +++ b/drivers/media/dvb/frontends/drxk_hard.c @@ -6313,12 +6313,10 @@ static int drxk_c_get_tune_settings(struct dvb_frontend *fe, struct dvb_frontend static void drxk_t_release(struct dvb_frontend *fe) { -#if 0 - struct drxk_state *state = fe->demodulator_priv; - - dprintk(1, "\n"); - kfree(state); -#endif + /* + * There's nothing to release here, as the state struct + * is already freed by drxk_c_release. + */ } static int drxk_t_init(struct dvb_frontend *fe) @@ -6451,17 +6449,6 @@ struct dvb_frontend *drxk_attach(const struct drxk_config *config, goto error; *fe_t = &state->t_frontend; -#ifdef CONFIG_MEDIA_ATTACH - /* - * HACK: As this function initializes both DVB-T and DVB-C fe symbols, - * and calling it twice would create the state twice, leading into - * memory leaks, the right way is to call it only once. However, dvb - * release functions will call symbol_put twice. So, the solution is to - * artificially increment the usage count, in order to allow the - * driver to be released. - */ - symbol_get(drxk_attach); -#endif return &state->c_frontend; error: diff --git a/drivers/media/video/em28xx/em28xx-dvb.c b/drivers/media/video/em28xx/em28xx-dvb.c index f8617d2..ab8a740 100644 --- a/drivers/media/video/em28xx/em28xx-dvb.c +++ b/drivers/media/video/em28xx/em28xx-dvb.c @@ -76,9 +76,10 @@ struct em28xx_dvb { struct dmx_frontend fe_mem; struct dvb_net net; - /* Due to DRX-D - probably need changes */ + /* Due to DRX-K - probably need changes */ int (*gate_ctrl)(struct dvb_frontend *, int); struct semaphore pll_mutex; + bool dont_attach_fe1; }; @@ -595,7 +596,7 @@ static void unregister_dvb(struct em28xx_dvb *dvb) if (dvb->fe[1]) dvb_unregister_frontend(dvb->fe[1]); dvb_unregister_frontend(dvb->fe[0]); - if (dvb->fe[1]) + if (dvb->fe[1] && !dvb->dont_attach_fe1) dvb_frontend_detach(dvb->fe[1]); dvb_frontend_detach(dvb->fe[0]); dvb_unregister_adapter(&dvb->adapter); @@ -771,21 +772,22 @@ static int dvb_init(struct em28xx *dev) case EM2884_BOARD_TERRATEC_H5: terratec_h5_init(dev); - /* dvb->fe[1] will be DVB-C, and dvb->fe[0] will be DVB-T */ + dvb->dont_attach_fe1 = 1; + dvb->fe[0] = dvb_attach(drxk_attach, &terratec_h5_drxk, &dev->i2c_adap, &dvb->fe[1]); - if (!dvb->fe[0] || !dvb->fe[1]) { + if (!dvb->fe[0]) { result = -EINVAL; goto out_free; } + /* FIXME: do we need a pll semaphore? */ dvb->fe[0]->sec_priv = dvb; sema_init(&dvb->pll_mutex, 1); dvb->gate_ctrl = dvb->fe[0]->ops.i2c_gate_ctrl; dvb->fe[0]->ops.i2c_gate_ctrl = drxk_gate_ctrl; - dvb->fe[1]->ops.i2c_gate_ctrl = drxk_gate_ctrl; dvb->fe[1]->id = 1; - /* Attach tda18271 */ + /* Attach tda18271 to DVB-C frontend */ if (dvb->fe[0]->ops.i2c_gate_ctrl) dvb->fe[0]->ops.i2c_gate_ctrl(dvb->fe[0], 1); if (!dvb_attach(tda18271c2dd_attach, dvb->fe[0], &dev->i2c_adap, 0x60)) { @@ -794,8 +796,12 @@ static int dvb_init(struct em28xx *dev) } if (dvb->fe[0]->ops.i2c_gate_ctrl) dvb->fe[0]->ops.i2c_gate_ctrl(dvb->fe[0], 0); - if (dvb->fe[1]->ops.i2c_gate_ctrl) - dvb->fe[1]->ops.i2c_gate_ctrl(dvb->fe[1], 1); + + /* Hack - needed by drxk/tda18271c2dd */ + dvb->fe[1]->tuner_priv = dvb->fe[0]->tuner_priv; + memcpy(&dvb->fe[1]->ops.tuner_ops, + &dvb->fe[0]->ops.tuner_ops, + sizeof(dvb->fe[0]->ops.tuner_ops)); break; default: