Em 11-11-2011 09:36, Antti Palosaari escreveu: > 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. > If you take a look at DVB-C, for example, The reference used by the DVB subsystem seems to be the ITU-T J.83, as the delivery systems are named according to ITU-T J.83 annexes: Annex A - European DVB-C (also defined on EN 300 429) Annex B - American DOCSYS Annex C - Japanese variant of Annex A, optimized for 6 MHz Bw According with ITU-T J.83/1997 (from where Annex A, B and C are referenced), we have: Annex A: - modulation: QAM 16, 32 and 64 Mentions that QAM 128 and 256 could be used in future - rolloff: 0.15 Annex B: - Modulation: QAM 64, 256 Annex C: - Modulation: QAM 64 - rolloff: 0.13 ITU-T Annex A is also defined at ETSI as EN 300 429/1998. There, we have: - modulation: QAM 16, 32, 64, 128 and 256 - rolloff: 0.15 As the same delivery system is used for both Annex A and Annex C, the "minimum" requirement for SYS_DVBC_ANNEX_AC is to support QAM64 (as it can be a device that implements only Annex C). So, just assuming some default from the delivery system is dangerous. Also, as specs may change with time (as J.83 -> EN 300 429 addition for QAM 128 and 256), this may lead into troubles in the future. Btw, DVB-C2, as defined on ITU-T J.122 is even more complex, offering a myriad of mandatory and optional formats, as shown at item 6.2.3: The upstream demodulator MAY support QPSK and 16QAM differential modulation for TDMA. The upstream demodulator MUST support QPSK, 16QAM, and 64QAM modulations for TDMA and S-CDMA channels. The upstream demodulator MAY support 8QAM and 32QAM modulation for TDMA and S-CDMA channels. The upstream demodulator MAY support QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM TCM encoded modulations for S-CDMA channels. What I think we can do is to provide macros for the capabilities, like: #define FE_CAN_DVBT FE_CAN_1_2 | FE_CAN_3_4 | ... With regards to the idea of returning an error, this may not work on all cases. For example, my 1seg stick is capable of retrieving channel info from 3-seg and full-seg streams, even not being able of actually watching those. Ideally, userspace should be capable of disabling the 3seg/full-seg channels if they aren't actually supported by the plugged device. Regards, Mauro -- 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
