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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
