Re: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 15.04.2010 22:21, Manu Abraham wrote: Hi Klaus, On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger klaus.schmidin...@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.schmidin...@tvdr.de Tested-by: Derek Kelly user@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 m...@linuxtv.org --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-10 12:08:47.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB= 0x40, FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8= 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING= 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.0 +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.0 +0200 +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.0 +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 majord...@vger.kernel.org More
Re: [linux-media] Re: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 18.04.2010 16:51, Manu Abraham wrote: On Sun, Apr 18, 2010 at 5:19 PM, Klaus Schmidinger klaus.schmidin...@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.schmidin...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On Sun, Apr 18, 2010 at 10:34 PM, Klaus Schmidinger klaus.schmidin...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
Hi Klaus, On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger klaus.schmidin...@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.schmidin...@tvdr.de Tested-by: Derek Kelly user@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 m...@linuxtv.org --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-10 12:08:47.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB = 0x40, FE_HAS_EXTENDED_CAPS = 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8 = 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION = 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING = 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.0 +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.0 +0200 +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.0 +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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 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.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-10 12:08:47.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB= 0x40, FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8= 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING= 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.0 +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.0 +0200 +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.0 +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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
