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 <Klaus.Schmidinger@tvdr.de>
Tested-by: Derek Kelly <user.vdr@gmail.com>


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Hi Klaus,

On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger
<Klaus.Schmidinger@tvdr.de> wrote:
> 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.

> Signed-off-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>
> Tested-by: Derek Kelly <user.vdr@gmail.com>

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 <manu@linuxtv.org>




>
>
> --- linux/include/linux/dvb/frontend.h.001      2010-04-05 16:13:08.000000000 +0200
> +++ linux/include/linux/dvb/frontend.h  2010-04-10 12:08:47.000000000 +0200
> @@ -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 */
> --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001     2010-04-05 16:13:08.000000000 +0200
> +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.000000000 +0200
> @@ -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,
> --- linux/drivers/media/dvb/frontends/cx24116.c.001     2010-04-05 16:13:08.000000000 +0200
> +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.000000000 +0200
> @@ -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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 15.04.2010 22:21, Manu Abraham wrote:
> Hi Klaus,
> 
> On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger
> <Klaus.Schmidinger@tvdr.de> wrote:
>> 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

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 ;-).

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

I chose FE_CAN_PSK_8 over FE_CAN_8PSK, because the modulation itself
is named PSK_8. This allows for easily finding all PSK_8 related places
with 'grep'. Personally I find the FE_CAN_8VSB and FE_CAN_16VSB misnomers,
because the modulations are named VSB_8 and VSB_16, respectively. They
should have been named FE_CAN_VSB_8 and FE_CAN_VSB_16 in the first place.
But that's, of course, a different story...

Klaus Schmidinger

> 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.
> 
>> Signed-off-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>
>> Tested-by: Derek Kelly <user.vdr@gmail.com>
> 
> 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 <manu@linuxtv.org>
> 
> 
> 
> 
>>
>> --- linux/include/linux/dvb/frontend.h.001      2010-04-05 16:13:08.000000000 +0200
>> +++ linux/include/linux/dvb/frontend.h  2010-04-10 12:08:47.000000000 +0200
>> @@ -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 */
>> --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001     2010-04-05 16:13:08.000000000 +0200
>> +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.000000000 +0200
>> @@ -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,
>> --- linux/drivers/media/dvb/frontends/cx24116.c.001     2010-04-05 16:13:08.000000000 +0200
>> +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.000000000 +0200
>> @@ -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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sun, Apr 18, 2010 at 5:19 PM, Klaus Schmidinger
<Klaus.Schmidinger@tvdr.de> wrote:
> On 15.04.2010 22:21, Manu Abraham wrote:
>> Hi Klaus,
>>
>> On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger
>> <Klaus.Schmidinger@tvdr.de> wrote:
>>> 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
>
> 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 ;-).


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.

Regards,
Manu
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 18.04.2010 16:51, Manu Abraham wrote:
> On Sun, Apr 18, 2010 at 5:19 PM, Klaus Schmidinger
> <Klaus.Schmidinger@tvdr.de> wrote:
>> On 15.04.2010 22:21, Manu Abraham wrote:
>>> Hi Klaus,
>>>
>>> On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger
>>> <Klaus.Schmidinger@tvdr.de> wrote:
>>>> 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
>> 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 ;-).
> 
> 
> 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.

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.

> 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.

> 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.

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).

Klaus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sun, Apr 18, 2010 at 10:34 PM, Klaus Schmidinger
<Klaus.Schmidinger@tvdr.de> wrote:

>> 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.
>
>> 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.


I guess, in the long run, FE_CAN_8PSK or FE_CAN_PSK8 or whatever scheme; might
not make any difference between FE_CAN_2G_MODULATION for a satellite delivery
system in the long run.

Additionally, Turbo FEC is not restricted to 8PSK modulation scheme alone ..
http://www.comtechefdata.com/datasheets/ds-cdm600-600L.pdf
http://www.datasheetdir.com/CX24114+download

That said, I don't really care about the exact naming of the flag, was
just a logical thought
that came to me between the difference in the error correction mode
alone, with no difference
to the modulation schema ...



>> 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.
>
> 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).

(I have no real life experience with the Turbo FEC stream),
with regards to the satellite_delivrey_system_descriptor:
modulation_system will be always DVB-S  with regards to Turbo FEC
streams and not DVB-S2
while
modulation_type will be 8PSK or QPSK for the Turbo FEC capable devices.
Maybe someone having a Turbo FEC device can verify this ?


Eventually, you would be able to use the flags or a combination of it
at the driver side;

and with regards to the SI: modulation_system and modulation_type it's
possible to handle a 8PSK Turbo FEC stream, but it might be a bit more
trickier to handle a QPSK Turbo FEC stream.


Regards,
Manu
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html