Re: FE_CAN-bits

[Antti Palosaari <crope@iki.fi>]

On 11/11/2011 11:55 AM, Patrick Boettcher wrote:
> On Thursday, November 10, 2011 10:20:46 PM Mauro Carvalho Chehab wrote:
>>
>> We should also think on a way to enumerate the supported values for each
>> DVB properties, the enum fe_caps is not enough anymore to store
>> everything. It currently has 30 bits filled (of a total of 32 bits), and
>> we currently have:
>> 	12 code rates (including AUTO/NONE);
>> 	13 modulation types;
>> 	7 transmission modes;
>> 	7 bandwidths;
>> 	8 guard intervals (including AUTO);
>> 	5 hierarchy names;
>> 	4 rolloff's (probably, we'll need to add 2 more, to distinguish between
>> DVB-C Annex A and Annex C).
>>
>> So, if we would need to add one CAN_foo for each of the above, we would
>> need 56 to 58 bits, plus 5-6 bits to the other capabilities that
>> currently exists there. So, even 64 bits won't be enough for the current
>> needs (even having the delivery system caps addressed by something
>> else).
>
> IMHO, we don't need such a fine FE_CAN_-bit distinguishing for most
> standards. A well defined sub-standard definition is sufficient, which can be
> handled with a delivery-system-like query as proposed in the original patch.
> This also will be much simpler for most user-space applications and users.

I agree that. Those are totally useless in general. Let driver return 
error to userspace if it cannot handle.

> DVB-T means:
> - 8K or 2K,
> - 1/4-1/32 Guard,
> - 1/2, 2/3, 3/4, 5/6 and 7/8 coderate,
> - QPSK, 64QAM or 16QAM
>
> DVB-H (RIP as Remi wrote somewhere) would have meant:
> - DVB-T + 4K + in-depth-interleaver mode
>
> The same applies to ISDB-T and ISDB-T 1seg. And for CMMB, CTTB, DVB-SH.
>
> If there are demods which can't do one particular thing, we should forget
> about them. At least this is what almost all applications I have seen so far
> are doing implicitly.

I know only one case where device cannot support all standard 
parameters. It is one TDA10023 device and looks like stream goes too 
wide when QAM256 is used.

> Though, I see at least one inconvenience is if someone is using linux-dvb
> for developping dsp-software and wants to deliver things which aren't done.
> But is this a case we want to "support" within the official API.


regards
Antti


-- 
http://palosaari.fi/