Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices

The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing.
This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though.

Signed-off-by Klaus Schmidinger <[email protected]>

Tested-by Derek Kelly <[email protected]>

include/linux/dvb/frontend.h  2010-04-10 12:08:47.000000000 +0200 renamed from include/linux/dvb/frontend.h.001      2010-04-05 16:13:08.000000000 +0200 +0 -0

@@ -62,6 +62,7 @@
        FE_CAN_8VSB                     = 0x200000,
        FE_CAN_16VSB                    = 0x400000,

       FE_HAS_EXTENDED_CAPS            = 0x800000,   /* We need more bitspace for newer APIs, indicate this. */
+       FE_CAN_PSK_8                    = 0x8000000,  /* frontend supports "8psk modulation" */ FE_CAN_2G_MODULATION            = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */ FE_NEEDS_BENDING                = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER                  = 0x40000000, /* frontend can recover from a cable unplug automatically */

drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.000000000 +0200 renamed from drivers/media/dvb/dvb-usb/gp8psk-fe.c.001     2010-04-05 16:13:08.000000000 +0200 +1 -1

@@ -349,7 +349,7 @@
                         * FE_CAN_QAM_16 is for compatibility
                         * (Myth incorrectly detects Turbo-QPSK as plain QAM-16)
                         */
-                       FE_CAN_QPSK | FE_CAN_QAM_16
+                       FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8
        },
 
        .release = gp8psk_fe_release,

drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.000000000 +0200 renamed from drivers/media/dvb/frontends/cx24116.c.001     2010-04-05 16:13:08.000000000 +0200 +0 -0

@@ -1496,7 +1496,7 @@

                       FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_2G_MODULATION |
-                       FE_CAN_QPSK | FE_CAN_RECOVER
+                       FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8 },

       .release = cx24116_release,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Klaus,

Quoted 6 lines · Klaus Schmidinger

The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing.
This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though.

The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is FE_CAN_TURBO_FEC

FE_CAN_8PSK will be matched by any DVB-S2 capable frontend, so that name is very likely to cause a very large confusion.

Another thing I am not entirely sure though ... The cx24116 requires a separate firmware and maybe some necessary code changes (?) for Turbo FEC to be supported, so I wonder whether applying the flag to the cx24116 driver would be any relevant....

With regards to the Genpix driver, i guess the flag would be necessary.

Quoted 2 lines

Signed-off-by Klaus Schmidinger <[email protected]>

Tested-by Derek Kelly <[email protected]>

Other than for the naming of the Flag (which i suggest strongly to update the patch) and the application to the cx24116 driver, it looks appropriate;

Acked-by Manu Abraham <[email protected]>

Quoted 33 lines

include/linux/dvb/frontend.h 2010-04-10 12:08:47.000000000 +0200 renamed from include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.000000000 +0200 +1 -0

@@ -62,6 +62,7 @@
       FE_CAN_8VSB                     = 0x200000,
       FE_CAN_16VSB                    = 0x400000,
       FE_HAS_EXTENDED_CAPS            = 0x800000,   /* We need more bitspace for newer APIs, indicate this. */
+       FE_CAN_PSK_8                    = 0x8000000,  /* frontend supports "8psk modulation" */
       FE_CAN_2G_MODULATION            = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */
       FE_NEEDS_BENDING                = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */
       FE_CAN_RECOVER                  = 0x40000000, /* frontend can recover from a cable unplug automatically */

drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.000000000 +0200 renamed from drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.000000000 +0200 +1 -1

@@ -349,7 +349,7 @@
                        * FE_CAN_QAM_16 is for compatibility
                        * (Myth incorrectly detects Turbo-QPSK as plain QAM-16)
                        */
-                       FE_CAN_QPSK | FE_CAN_QAM_16
+                       FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8
       },
 
       .release = gp8psk_fe_release,

drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.000000000 +0200 renamed from drivers/media/dvb/frontends/cx24116.c.001 2010-04-05 16:13:08.000000000 +0200 +1 -1

@@ -1496,7 +1496,7 @@
                       FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 |
                       FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
                       FE_CAN_2G_MODULATION |
-                       FE_CAN_QPSK | FE_CAN_RECOVER
+                       FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8
       },
 
       .release = cx24116_release,

Quoted 12 lines · Manu Abraham

Hi Klaus,

Quoted 6 lines · Klaus Schmidinger

The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing.
This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though.

Quoted 2 lines

The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is FE_CAN_TURBO_FEC

Well, when processing the NIT data in VDR, for instance, the possible modulation types that can be used according to the driver's frontend.h are
       QPSK,
       QAM_16,
       QAM_32,
       QAM_64,
       QAM_128,
       QAM_256,
       QAM_AUTO,
       VSB_8,
       VSB_16,
       PSK_8,
       APSK_16,
       APSK_32,
       DQPSK,

There is nothing in frontend.h that would be in any way related to "turbo fec" (whatever that may be).

Of course we can rename FE_CAN_PSK_8 to FE_CAN_TURBO_FEC, but wouldn't something like

 if (Modulation == PSK_8 && !(frontendInfo.caps & FE_CAN_TURBO_FEC)) return false;

be even more irritating than a straight forward

 if (Modulation == PSK_8 && !(frontendInfo.caps & FE_CAN_PSK_8)) return false;

After all it's

 if (Modulation == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256)) return false;

Please advise. Whatever you prefer is fine with me.
All I need in VDR is a flag that allows me to detect whether a device can handle a given transponder's modulation. I don't really care how that flag is named ;-).

Quoted 47 lines · Klaus Schmidinger

Quoted 11 lines · Manu Abraham

Hi Klaus,

Quoted 6 lines · Klaus Schmidinger

The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing.
This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though.

Quoted 2 lines

The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is FE_CAN_TURBO_FEC

Well, when processing the NIT data in VDR, for instance, the possible modulation types that can be used according to the driver's frontend.h are

       QPSK,
       QAM_16,
       QAM_32,
       QAM_64,
       QAM_128,
       QAM_256,
       QAM_AUTO,
       VSB_8,
       VSB_16,
       PSK_8,
       APSK_16,
       APSK_32,
       DQPSK,

There is nothing in frontend.h that would be in any way related to "turbo fec" (whatever that may be).

Of course we can rename FE_CAN_PSK_8 to FE_CAN_TURBO_FEC, but wouldn't something like

if (Modulation == PSK_8 && !(frontendInfo.caps & FE_CAN_TURBO_FEC))
return false;

be even more irritating than a straight forward

if (Modulation == PSK_8 && !(frontendInfo.caps & FE_CAN_PSK_8))
return false;

After all it's

Quoted 7 lines

if (Modulation == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256))
return false;

Please advise. Whatever you prefer is fine with me.
All I need in VDR is a flag that allows me to detect whether a device can handle a given transponder's modulation. I don't really care how that flag is named ;-).

Maybe I wasn't clear enough, why I stated that ...

consider any DVB-S2 frontend: stb0899, cx24116, stv090x, ds3000 or any other any frontend ..
All these devices are capable of demodulating 8PSK. Now, if people start adding capabilities that which the devices are capable, then it will cause a lot of problems for the applications themselves, since you don't get the differentiation between the frontends that you were originally looking for.

Now looking at another angle ..

consider the Genpix frontend, can it tune to 8PSK ? Yes, it can..

Eventually, it implies that, all DVB-S2 devices are 8PSK capable, but not all 8PSK capable devices are DVB-S2 capable.

Now, assume the FE_CAN_PSK8 or FE_CAN8PSK flag; Does it really make any sense, when it is applied to the whole group of 8PSK frontends ? I guess not. You would require a flag that is capable of distinguishing between the S2 8PSK category and the other category.

Looking back at history, originally France Telecom introduced the superior Error Correction scheme called Turbo Mode or so called Concatenated FEC mode on a 8PSK modulated carrier. This was a great approach, but they wanted to people to pay them a royalty and hence the general acceptance for it went down. In the initial phase, it was implemented in the Americas and for small clients alone. Eventually, the rest of the world wanted a royalty free approach and thus came LDPC which is just as good.

So eventually while the difference between these 2 carriers is that while both are 8PSK modulated stream, the Error correction used with France Telecom's proprietary stream is Concatenated Codes, while for S2 and DVB.org it became LDPC.

As you can see, the discriminating factor is the FEC, in this condition and nothing else. You will need a flag to discriminate between the FEC types, rather than the modulation, if things were to look more logical.

Quoted 2 lines

Eventually, it implies that, all DVB-S2 devices are 8PSK capable, but not all 8PSK capable devices are DVB-S2 capable.

Since there are already FE_CAN_* flags for all but PSK_8, I guess it would make sense that all devices that support PSK_8 set the related FE_CAN_PSK_8 flag (or FE_CAN_8PSK, if you insist in continuing the suboptimal naming scheme), independent of the "Turbo FEC" thing.

Quoted 4 lines

Now, assume the FE_CAN_PSK8 or FE_CAN8PSK flag; Does it really make any sense, when it is applied to the whole group of 8PSK frontends ? I guess not. You would require a flag that is capable of distinguishing between the S2 8PSK category and the other category.

There already is such a flag: FE_CAN_2G_MODULATION.

Quoted 14 lines

Looking back at history, originally France Telecom introduced the superior Error Correction scheme called Turbo Mode or so called Concatenated FEC mode on a 8PSK modulated carrier. This was a great approach, but they wanted to people to pay them a royalty and hence the general acceptance for it went down. In the initial phase, it was implemented in the Americas and for small clients alone. Eventually, the rest of the world wanted a royalty free approach and thus came LDPC which is just as good.

So eventually while the difference between these 2 carriers is that while both are 8PSK modulated stream, the Error correction used with France Telecom's proprietary stream is Concatenated Codes, while for S2 and DVB.org it became LDPC.

Quoted 4 lines

As you can see, the discriminating factor is the FEC, in this condition and nothing else. You will need a flag to discriminate between the FEC types, rather than the modulation, if things were to look more logical.

I guess the problem, as I can see now, is that there is now way of telling from the SI data that a transponder uses "8psk turbo fec", or is there?

Would it make sense to differentiate this in the following way:

- an 8psk transponder on DVB-S is "turbo fec"
- an 8psk transponder on DVB-S2 is  *not* "turbo fec"

? So an "8psk/DVB-S" transpoder will require a device that has FE_CAN_TURBO_FEC set, while an "8psk/DVB-S2" transpoder simply requires a DVB-S2 device (since there is no FE_CAN_PSK_8).