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

[Andreas Oberritter <obi@linuxtv.org>]

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.