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

From: Andreas Oberritter <obi@linuxtv.org>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Ralph Metzler <rjkm@metzlerbros.de>, linux-media@vger.kernel.org
Subject: Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Date: Fri, 15 Jul 2011 19:01:06 +0200	[thread overview]
Message-ID: <4E207252.5050506@linuxtv.org> (raw)
In-Reply-To: <4E203FD0.4030503@redhat.com>

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