Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux