On Mon, Dec 12, 2011 at 7:26 PM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> 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; We never had any ? users to ANNEX_C, so
that issue might be simple to ignore.
--
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
