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
--
http://palosaari.fi/
--
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
