Re: v4 [PATCH 06/10] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C

[Mauro Carvalho Chehab <mchehab@redhat.com>]

On 12-12-2011 13:00, Manu Abraham wrote:
> On Mon, Dec 12, 2011 at 7:26 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com>  wrote:
>> On 12-12-2011 11:40, Manu Abraham wrote:
>>>
>>> On Mon, Dec 12, 2011 at 6:49 PM, Mauro Carvalho Chehab
>>
>>
>>>> This also means that just doing an alias from FE_QAM and
>>>> SYS_DVBC_ANNEX_AC
>>>> to
>>>> SYS_DVBC_ANNEX_A may break something, as, for most devices,
>>>> SYS_DVBC_ANNEX_AC
>>>> really means both Annex A and C.
>>>
>>>
>>>
>>>
>>> With the current approach, the application can determine whether
>>> the hardware supports through the DELSYS enumeration.
>>>
>>> So, if you have a device that needs to support both ANNEX_A and
>>> ANNEX_C, it should be rather doing
>>>
>>> case DTV_ENUM_DELSYS:
>>>           buffer.data[0] = SYS_DVBC_ANNEX_A;
>>>           buffer.data[1] = SYS_DVBC_ANNEX_C;
>>>           break;
>>
>>
>> Sure, but we'll need a logic to handle queries for SYS_DVBC_ANNEX_AC
>> anyway, if any of the existing DVB-C drivers is currently prepared to
>> support both.
>>
>> I'm not concerned with drx-k. The support for both standards are for
>> kernel 3.3. So, no backward compatibility is needed here.
>>
>> While there is no explicit option, the code for stv0297, stv0367,
>> tda10021 and tda10023 drivers are not clear if they support both
>> (maybe roll-off might be auto-detected?) or just SYS_DVBC_ANNEX_A.
>>
>> That's said, the difference between a 0.15 and a 0.13 rolloff is not big.
>> I won't doubt that a demod set to 0.15 rolloff would be capable of working
>> (non-optimized) with a 0.13 rolloff.
>>
>> What I'm saing is that, if any of the existing drivers currently works
>> with both Annex A and Annex C, we'll need something equivalent to:
>>
>> if (delsys == SYS_DVBC_ANNEX_AC) {
>>         int ret = try_annex_a();
>>         if (ret<  0)
>>                 ret = try_annex_c();
>> }
>>
>> For FE_SET_FRONTEND (and the corresponding v5 logic), in order to avoid
>> regressions.
>
>
> What I was implying:
>
> set_frontend/search()
> {
>       case SYS_DVBC_ANNEX_A:
>                // do whatever you need to do for annex A tuning and return
>                break;
>       case SYS_DVBC_ANNEX_C:
>                // do whatever you need to do for annex C tuning and return
>                break;
> }
>
>
> ANNEX_AC is a link to ANNEX_A;

Yes, I saw your approach.

> We never had any ? users to ANNEX_C, so
> that issue might be simple to ignore.

This is hard to say. What I'm saying is that, if any of the current
drivers works as-is with Annex C, we should assume that someone is using,
as we don't have any evidence otherwise.

I'm sure there are lots of people running Linux in Japan.

How many of them are using the DVB subsystem is hard to say. The low message
traffic at the ML for people *.jp is not a good measure, as due to language
barriers, people may not be posting things there.

A quick grep here on my local copy of the ML traffic (it currently has stored
about 380 days of email, as I moved the older ones to a separate storage space)
still shows 90 messages that has ".jp" inside:

$ grep -l "\.jp" * |wc -l
      90

41 of them has the word DVB inside. Ok, there are some false positives there
too (due to *.jpg), but there are some valid hits also,

Including a commit on this changeset: e38030f3ff02684eb9e25e983a03ad318a10a2ea.
As the cx23885 driver does support DVB-C with stv0367, maybe the committer
might be using it for DVB-C.

Even if not, I suspect that it is likely to have some DVB-C Annex C users
out there.

Regards,
Mauro.