[linux-dvb] Multiproto API/Driver Update

[barry bouwsma]

--- On Tue, 9/9/08, hermann pitton <hermann-pitton at arcor.de> wrote:

> following your thoughts, you are likely right. DVB-T2 likely indicates
> that you need new hardware, like it is for sure on DVB-S2.

Servus,

Disclaimer:  I'm only an outsider, not a programmer, and not
familiar with the digital broadcast specs or the DVB API, so
I will both not know what I'm talking about, and be asking
stupid questions.


I decided to look again at DVB-T2, as it's likely to be the
next change that will be in need of Linux support in a year
or so, at least in the UK, when hardware becomes available.

My stupid question is, will DVB-T2, in Transport Stream mode,
be similar enough to existing DVB-T, apart from the extended
modulation parameters, that it can be fit into the existing
API, or am I overlooking something in my ignorance of the API?

This seems to me somewhat like the case of existing DVB-C,
where some hardware is incapable of 256QAM and so cannot tune
all the carriers, but I really haven't tried to understand
the API or how it can be extended without breaking things...


In looking at the Wikipedia article on DVB-T, it appears that
at least the following diffs to include/dvb/frontend.h might
be needed to support the additional possibilities that a DVB-T2
tuner would be likely to support -- diff against the S2API, as
this file is unchanged in multiproto, while S2API already has
the additional FEC values present...

goto Disclaimer;


--- /lost+found/CVSUP/SRC/HG-src/dvb-s2-api/linux/include/linux/dvb/frontend.h  2008-09-04 15:21:59.000000000 +0200
+++ /tmp/frontend.h     2008-09-09 13:10:29.574976974 +0200
@@ -171,24 +171,34 @@ typedef enum fe_modulation {
 } fe_modulation_t;
 
 typedef enum fe_transmit_mode {
+       TRANSMISSION_MODE_1K,
        TRANSMISSION_MODE_2K,
+       TRANSMISSION_MODE_4K,
        TRANSMISSION_MODE_8K,
+       TRANSMISSION_MODE_16K,
+       TRANSMISSION_MODE_32K,
        TRANSMISSION_MODE_AUTO
 } fe_transmit_mode_t;
 
 typedef enum fe_bandwidth {
+       BANDWIDTH_10_MHZ,
        BANDWIDTH_8_MHZ,
        BANDWIDTH_7_MHZ,
        BANDWIDTH_6_MHZ,
+       BANDWIDTH_5_MHZ,
+       BANDWIDTH_1.7_MHZ,
        BANDWIDTH_AUTO
 } fe_bandwidth_t;
 
 
 typedef enum fe_guard_interval {
+       GUARD_INTERVAL_1_128,
        GUARD_INTERVAL_1_32,
        GUARD_INTERVAL_1_16,
        GUARD_INTERVAL_1_8,
        GUARD_INTERVAL_1_4,
+       GUARD_INTERVAL_19_256,
+       GUARD_INTERVAL_19_128,
        GUARD_INTERVAL_AUTO
 } fe_guard_interval_t;
 
@@ -324,6 +334,7 @@ typedef enum fe_delivery_system {
        SYS_DVBC_ANNEX_AC,
        SYS_DVBC_ANNEX_B,
        SYS_DVBT,
+       SYS_DVBT2,
        SYS_DVBS,
        SYS_DVBS2,
        SYS_DVBH,
@@ -335,6 +346,7 @@ typedef enum fe_delivery_system {
        SYS_DMBTH,
        SYS_CMMB,
        SYS_DAB,
+       SYS_TDMB,       /* XXX is different from DMB-TH, no?  */
 } fe_delivery_system_t;
 
 struct tv_cmds_h {


 The reason I became interested in this is due to the choice of
 naming -- S2API sounded to me like the focus would be on DVB-S2,
 possibly ignoring -T2 and eventually -C2, not to mention the
 other existing alternatives to DVB, rather than a Second Generation
 (as the specs I've looked at refer to the update) DVB-API, but
 then, I really don't know what I'm talking about.


 thanks,
 barry bouwsma