Add missing S2 caps flag to S2API
PATCH 1/1 Add missing S2 caps flag to S2API
The attached patch adds a capability flag that allows an application to determine whether a particular device can handle "second generation modulation" transponders. This is necessary in order for applications to be able to decide which device to use for a given channel in a multi device environment, where DVB-S and DVB-S2 devices are mixed.
It is assumed that a device capable of handling "second generation modulation" can implicitly handle "first generation modulation". The flag is not named anything with DVBS2 in order to allow its use with future DVBT2 devices as well (should they ever come).
Signed-off by: Klaus Schmidinger <[email protected]>
PS: why an API named *S2*API didn't contain this in the first place
is totally beyond me...
linux/drivers/media/dvb/frontends/cx24116.c +1 -0
@@ -1459,6 +1459,7 @@FE_CAN_FEC_1_2 |FE_CAN_FEC_2_3 |FE_CAN_FEC_3_4 |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_2ND_GEN_MODULATION |FE_CAN_QPSK |FE_CAN_RECOVER },
linux/drivers/media/dvb/frontends/stb0899_drv.c +1 -0
@@ -1913,6 +1913,7 @@ .caps = FE_CAN_INVERSION_AUTO |FE_CAN_FEC_AUTO | +FE_CAN_2ND_GEN_MODULATION |FE_CAN_QPSK },
linux/include/linux/dvb/frontend.h +1 -0
@@ -63,6 +63,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_2ND_GEN_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 FE_CAN_MUTE_TS =0x80000000 // frontend can stop spurious TS data output
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
PATCH 1/1 Add Compro VideoMate E650F (DVB-T part only)
From: Igor M. Liplianin <[email protected]>
Add Compro VideoMate E650F (DVB-T part only).
The card based on cx23885 PCI-Express chip, xc3028 tuner and ce6353 demodulator.
---
linux/drivers/media/video/cx23885/cx23885-cards.c +12 -0
@@ -159,6 +159,10 @@ .name = "Leadtek Winfast PxDVR3200 H", .portc = CX23885_MPEG_DVB, }, + [CX23885_BOARD_COMPRO_VIDEOMATE_E650F] = { + .name = "Compro VideoMate E650F", + .portc = CX23885_MPEG_DVB, + }, };const unsigned int cx23885_bcount =ARRAY_SIZE (cx23885_boards);
@@ -238,6 +242,10 @@ .subvendor = 0x107d, .subdevice = 0x6681, .card = CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H, + }, { + .subvendor = 0x185b, + .subdevice = 0xe800, + .card = CX23885_BOARD_COMPRO_VIDEOMATE_E650F, }, };const unsigned int cx23885_idcount =ARRAY_SIZE (cx23885_subids);
@@ -391,6 +399,7 @@case CX23885_BOARD_HAUPPAUGE_HVR1500 :case CX23885_BOARD_HAUPPAUGE_HVR1500Q :case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H : +case CX23885_BOARD_COMPRO_VIDEOMATE_E650F :/* Tuner Reset Command */ bitmask =0x04 ;break ;
@@ -531,6 +540,7 @@cx_set (GP0_IO ,0x000f000f );break ;case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H : +case CX23885_BOARD_COMPRO_VIDEOMATE_E650F :/* GPIO-2 xc3028 tuner reset */ /* The following GPIO's are on the internal AVCore (cx25840) */
@@ -631,6 +641,7 @@case CX23885_BOARD_HAUPPAUGE_HVR1700 :case CX23885_BOARD_HAUPPAUGE_HVR1400 :case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H : +case CX23885_BOARD_COMPRO_VIDEOMATE_E650F :default : ts2->gen_ctrl_val =0xc ;/* Serial bus + punctured clock */ ts2->ts_clk_en_val =0x1 ;/* Enable TS_CLK */
@@ -645,6 +656,7 @@case CX23885_BOARD_HAUPPAUGE_HVR1800lp:case CX23885_BOARD_HAUPPAUGE_HVR1700 :case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H : +case CX23885_BOARD_COMPRO_VIDEOMATE_E650F :request_module ("cx25840" );break ; }
linux/drivers/media/video/cx23885/cx23885-dvb.c +1 -0
@@ -503,6 +503,7 @@break ; }case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H : +case CX23885_BOARD_COMPRO_VIDEOMATE_E650F : i2c_bus = &dev->i2c_bus[0 ]; fe0->dvb.frontend = dvb_attach(zl10353_attach,
linux/drivers/media/video/cx23885/cx23885.h +1 -0
@@ -67,6 +67,7 @@#define CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP 10#define CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP 11#define CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H 12 +#define CX23885_BOARD_COMPRO_VIDEOMATE_E650F 13/* Currently unsupported by the driver: PAL/H, NTSC/Kr, SECAM B/G/H/LC */ #define CX23885_NORMS (\
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Hello,
Quoted 6 lines · Klaus Schmidinger
The attached patch adds a capability flag that allows an application to determine whether a particular device can handle "second generation modulation" transponders. This is necessary in order for applications to be able to decide which device to use for a given channel in a multi device environment, where DVB-S and DVB-S2 devices are mixed.
Quoted 6 lines
It is assumed that a device capable of handling "second generation modulation" can implicitly handle "first generation modulation". The flag is not named anything with DVBS2 in order to allow its use with future DVBT2 devices as well (should they ever come).
Signed-off by: Klaus Schmidinger <[email protected]>
Wouldn't it be better to add something like this:
FE_CAN_8PSKFE_CAN_16APSKFE_CAN_32APSK
or
FE_CAN_DVBS2
Instead of FE_CAN_2ND_GEN_MODULATION ? It is too generic for me.
Regards, Artem
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
On Mon, 24 Nov 2008, Artem Makhutov wrote:
(quoting Klaus...)
Quoted 4 lines
Quoted 4 lines
It is assumed that a device capable of handling "second generation modulation" can implicitly handle "first generation modulation". The flag is not named anything with DVBS2 in order to allow its use with future DVBT2 devices as well (should they ever come).
I am sure than DVB-T2 devices will appear soon enough, as that's going to go into regular service in the UK in a year's time. Other countries will lag, if they even make the jump at all -- it depends how their plans for signal delivery via terrestrial matches the frequency allocations and the demand for these frequencies -- some countries have explicitly stated their intent to treat DVB-T as an unwanted child, while in others, HD bandwidth demand could easily outstrip allocated frequencies and the political division thereof between broadcasters. That is, perhaps outside of the UK one will have to search rather intensively to find such devices for some time.
My question is about overlapping capability, which I'll try to explain below:
Quoted 4 lines
Wouldn't it be better to add something like this:
FE_CAN_8PSKFE_CAN_16APSKFE_CAN_32APSK
Agreed. In the case of DVB-T2, which I don't know by heart, there are additional modulation modes, some of which are already covered by existing capabilities or definitions. But I don't know if there are backwards incompatibilities that aren't covered by the modulation methods.
In particular, I'm thinking of DVB-S2 use of QPSK. This is something I haven't wrapped my head around, but I do know that my DVB-S receivers and tuners cannot tune to those DVB-S2 QPSK frequencies (listed in part in an earlier mail I sent).
To go off-topic, can someone explain to me, simply, in words of one syllable, just what it is that differentiates a DVB-S2 QPSK transponder from a DVB-S QPSK transponder, and better as something that can be plugged into the definitions of the existing API -- like, say, rolloff or something.
Looking at it from the perspective of the UK, where DVB-T was introduced early using 2k FFT modulation, but as part of DSO this is being changed to 8k, yet early consumer equipment cut costs and corners in several ways to make those devices incompatible (split-NIT, 8k mode) today -- definitions included within the capabilities for devices under linux-dvb. Wait, that's not a sentence. I mean, can-dvb-t' for those devices is something like can-qpsk' in the dvb-s/s2 case. Am I making sense? I need sleep.
Quoted 2 lines
FE_CAN_DVBS2
Instead ofFE_CAN_2ND_GEN_MODULATION? It is too generic for me.
Maybe also a bit too overbroad/generic? In the case that DVB-S2 includes things not supported by existing consumer products, intended for professional broadcasters, or future data delivery, or something.
Feel free to ignore me, as I'm sort of commenting from the sidelines, and I don't know what I'm talking about, and I'm in desperate need of sleep.
thanks
barry bouwsmna
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 22 lines · Artem Makhutov
Hello,
Quoted 6 lines · Klaus Schmidinger
The attached patch adds a capability flag that allows an application to determine whether a particular device can handle "second generation modulation" transponders. This is necessary in order for applications to be able to decide which device to use for a given channel in a multi device environment, where DVB-S and DVB-S2 devices are mixed.
Quoted 6 lines
It is assumed that a device capable of handling "second generation modulation" can implicitly handle "first generation modulation". The flag is not named anything with DVBS2 in order to allow its use with future DVBT2 devices as well (should they ever come).
Signed-off by: Klaus Schmidinger <[email protected]>
Wouldn't it be better to add something like this:
FE_CAN_8PSKFE_CAN_16APSKFE_CAN_32APSK
Quoted 5 lines
or
FE_CAN_DVBS2Instead of
FE_CAN_2ND_GEN_MODULATION? It is too generic for me.
Well, it's bad enough that we have to "guess" which kind of delivery system it is by looking at feinfo.type. If it's FE_QPSK then it's DVB-S (or DVB-S2), if it's FE_OFDM then it's DVB-T etc., etc. The "multiproto" API had this cleaned up and introduced a clean way of finding out the delivery systems(!) a particular device can handle. Unfortunately, as we all know, this approach has been dismissed.
Using some additional flags for "guessing" whether it's DVB-S2 doesn't seem like a clean solution to me. Why not simply state the obvious? After all, the DVB standard for DVB-S2 speaks of "second generation modulation", that's why I named this flag that way. And since S2API can only handle a single delivery system at a time (as opposed to multiproto, where the delivery systems were flags, so a device could support several of them), it somehow made sense to me to have a flag that could later also be used for "second generation DVB-T" devices.
But I don't want to start another political fight here. All I need is a way to determine whether or not a device supports DVB-S2. If the commonly agreed on way to do this is to guess it by looking at FE_CAN_xyPSK capability flags, so be it. However, so far none of the "experts" cared about answering my initial question "How to determine DVB-S2 capability in S2API?", so I guessed the only way to get something to work was doing something about it ;-)
Klaus
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 6 lines
However, so far none of the "experts" cared about answering my initial question "How to determine DVB-S2 capability in S2API?", so I guessed the only way to get something to work was doing something about it ;-)
Luckily I am not the only one with this problem :)
I can ask questions, post patches and tell the list about being frustrated that no one cares about it, and the last item will ever be confirmed ;)
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi,
Quoted 46 lines · Klaus Schmidinger
Quoted 21 lines · Artem Makhutov
Hello,
Quoted 6 lines · Klaus Schmidinger
The attached patch adds a capability flag that allows an application to determine whether a particular device can handle "second generation modulation" transponders. This is necessary in order for applications to be able to decide which device to use for a given channel in a multi device environment, where DVB-S and DVB-S2 devices are mixed.
Quoted 6 lines
It is assumed that a device capable of handling "second generation modulation" can implicitly handle "first generation modulation". The flag is not named anything with DVBS2 in order to allow its use with future DVBT2 devices as well (should they ever come).
Signed-off by: Klaus Schmidinger <[email protected]>
Wouldn't it be better to add something like this:
FE_CAN_8PSKFE_CAN_16APSKFE_CAN_32APSKQuoted 5 lines
or
FE_CAN_DVBS2Instead of
FE_CAN_2ND_GEN_MODULATION? It is too generic for me.Well, it's bad enough that we have to "guess" which kind of delivery system it is by looking at feinfo.type. If it's
FE_QPSKthen it's DVB-S (or DVB-S2), if it'sFE_OFDMthen it's DVB-T etc., etc. The "multiproto" API had this cleaned up and introduced a clean way of finding out the delivery systems(!) a particular device can handle. Unfortunately, as we all know, this approach has been dismissed.Using some additional flags for "guessing" whether it's DVB-S2 doesn't seem like a clean solution to me. Why not simply state the obvious? After all, the DVB standard for DVB-S2 speaks of "second generation modulation", that's why I named this flag that way. And since S2API can only handle a single delivery system at a time (as opposed to multiproto, where the delivery systems were flags, so a device could support several of them), it somehow made sense to me to have a flag that could later also be used for "second generation DVB-T" devices.
Quoted 8 lines
But I don't want to start another political fight here. All I need is a way to determine whether or not a device supports DVB-S2. If the commonly agreed on way to do this is to guess it by looking at
FE_CAN_xyPSKcapability flags, so be it. However, so far none of the "experts" cared about answering my initial question "How to determine DVB-S2 capability in S2API?", so I guessed the only way to get something to work was doing something about it ;-)
I fully understand what you mean. I would also like to adress the remarks of Berry:
http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030539.html
So here is an other proposal for this:
typedef enum fe_type {
FE_QPSK,
FE_QAM,
FE_OFDM,
FE_ATSC,
FE_DVBS,
FE_DVBS2,
FE_DVBT,
FE_DVBT2,
[...]
} fe_type_t;typedef enum fe_caps {
FE_IS_STUPID = 0,
FE_CAN_INVERSION_AUTO = 0x1,
FE_CAN_FEC_1_2 = 0x2,
FE_CAN_FEC_2_3 = 0x4,
FE_CAN_FEC_3_4 = 0x8,
FE_CAN_FEC_4_5 = 0x10,
FE_CAN_FEC_5_6 = 0x20,
FE_CAN_FEC_6_7 = 0x40,
FE_CAN_FEC_7_8 = 0x80,
FE_CAN_FEC_8_9 = 0x100,
FE_CAN_FEC_AUTO = 0x200,
FE_CAN_QPSK = 0x400,
FE_CAN_QAM_16 = 0x800,
FE_CAN_QAM_32 = 0x1000,
FE_CAN_QAM_64 = 0x2000,
FE_CAN_QAM_128 = 0x4000,
FE_CAN_QAM_256 = 0x8000,
FE_CAN_QAM_AUTO = 0x10000,
FE_CAN_TRANSMISSION_MODE_AUTO = 0x20000,
FE_CAN_BANDWIDTH_AUTO = 0x40000,
FE_CAN_GUARD_INTERVAL_AUTO = 0x80000,
FE_CAN_HIERARCHY_AUTO = 0x100000,
FE_CAN_8VSB = 0x200000,
FE_CAN_16VSB = 0x400000,
FE_HAS_EXTENDED_CAPS = 0x800000,
FE_NEEDS_BENDING = 0x20000000,
FE_CAN_RECOVER = 0x40000000,
FE_CAN_MUTE_TS = 0x80000000,
FE_CAN_8PSK = 0x100000000,
FE_CAN_16APSK = 0x200000000,
FE_CAN_32APSK = 0x400000000,
[...]
} fe_caps_t;Here we can define the frontend type and check if it is DVB-S or DVB-S2 or whatever and also define the modulations that the frontend is capable to handle (in case a device won't work with the "professional" modulations like 16APSK).
Applications like VDR can check the fe_type flags, and applications that require more info could check fe_caps.
I am not sure about this all, and I would like to see some comments from some people that are more familiar it. Specially changing fe_type looks like it will break the binary compatibility, so maybe it would be better to define a new enum for this flags...
Regards, Artem
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 9 lines · Artem Makhutov
Quoted 3 lines · Klaus Schmidinger
The attached patch adds a capability flag that allows an application to determine whether a particular device can handle "second generation modulation" transponders.
Wouldn't it be better to add something like this:
FE_CAN_8PSKFE_CAN_16APSKFE_CAN_32APSK
Without knowing enough about the differences between -S and -S2 tuners and whatever cards are on the market, I'll try to step back and give this my 2c point of view:
What does a DVB app need to know? A DVB app probably just needs to know "What devices are capable of tuning to channel XYZ?". The API could answer this the same way as it would tune to channel XYZ, just without actually doing it. Try-before-you-buy.
This would also give maximum flexibility to the driver, as a device that supports some -S2 features could offer these, or a device that has known bugs on some tuning modes could also deny these. Non-standard modes could be offered without requiring yet another FE_CAN_XYZ.
Cheers,
Udo
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 9 lines · Udo Richter
Without knowing enough about the differences between -S and -S2 tuners and whatever cards are on the market, I'll try to step back and give this my 2c point of view:
What does a DVB app need to know? A DVB app probably just needs to know "What devices are capable of tuning to channel XYZ?". The API could answer this the same way as it would tune to channel XYZ, just without actually doing it. Try-before-you-buy.
Quoted 4 lines
This would also give maximum flexibility to the driver, as a device that supports some -S2 features could offer these, or a device that has known bugs on some tuning modes could also deny these. Non-standard modes could be offered without requiring yet another
FE_CAN_XYZ.
Assuming you have 3 cards, one DVB-S2 and 2xDVB-S.
In case of DVB-S channel, all the cards will be able to record it, what will be the decision? Random?
You might select DVB-S2 card for DVB-S recording, while it might be used to record DVB-S2 channel that no other card is capable to do.
I agree that driver should tell whenever it able to tune to a channel when its ordered to perform tuning. There shouldn't be any guess just by checking the LOCK status.
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi,
Quoted 20 lines · Udo Richter
Quoted 9 lines · Artem Makhutov
Quoted 3 lines · Klaus Schmidinger
The attached patch adds a capability flag that allows an application to determine whether a particular device can handle "second generation modulation" transponders.
Wouldn't it be better to add something like this:
FE_CAN_8PSKFE_CAN_16APSKFE_CAN_32APSKWithout knowing enough about the differences between -S and -S2 tuners and whatever cards are on the market, I'll try to step back and give this my 2c point of view:
What does a DVB app need to know? A DVB app probably just needs to know "What devices are capable of tuning to channel XYZ?". The API could answer this the same way as it would tune to channel XYZ, just without actually doing it. Try-before-you-buy.
Quoted 4 lines
This would also give maximum flexibility to the driver, as a device that supports some -S2 features could offer these, or a device that has known bugs on some tuning modes could also deny these. Non-standard modes could be offered without requiring yet another
FE_CAN_XYZ.
If I understand you correct you would like to call an function like:
bool ItWorks = DoFakeTune(a lot of Paramters);
Sure, this would work, but it would make the implementation more difficult for both the driver and the application.
So in this case the application would have to call DoFakeTune() for a lot of different modulations, FEC's and so on and interprete the results.
The application must then call
DoFakeTune(DVB-S,FEC_AUTO);DoFakeTune(DVB-S,FEC_3_4);DoFakeTune(DVB-S,FEC_2_4);DoFakeTune(DVB-S,FEC_4_5);DoFakeTune(DVB-S2,FEC_AUTO);
[...]DoFakeTune(DVB-T,FEC_XYZ);DoFakeTune(DVB-T2,FEC_XYZ);
This would not make much fun and this could be achieved much easier using some kind of capability flags.
Regards, Artem
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Does anyone here actually disagree that the approach multiproto takes is a great solution that should be adopted (if possible)?
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 2 lines · VDR User
Does anyone here actually disagree that the approach multiproto takes is a great solution that should be adopted (if possible)?
Does anyone here disagree that the above question is a troll?
My point is that silence on internet mailing lists is not concurrence.
This is especially the case if people are trying to avoid conflict by not reacting to people trolling for conflict.
Regards,
Andy
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 10 lines · Andy Walls
Quoted 2 lines · VDR User
Does anyone here actually disagree that the approach multiproto takes is a great solution that should be adopted (if possible)?
Does anyone here disagree that the above question is a troll?
My point is that silence on internet mailing lists is not concurrence.
This is especially the case if people are trying to avoid conflict by not reacting to people trolling for conflict.
I hope you don't expect to be taken seriously after your absurd comment. This conversation is about addressing and finding a solution to a problem. I'm not even the person who originally brought up the solution used in multiproto but as far as I can see, it does seem to be a great solution so I question why that method shouldn't be adopted.
It's ridiculous I need to point any of this out to you but one possible reason is that _you_ are in fact the one trolling here. Afterall, the only posting you've made has absolutely nothing to do with the subject, while all of mine do. Please contribute something relevant or find some other thread to infect.
And by the way, most of us have accepted the outcome of the s2api/multiproto controversy. Maybe it's about time you find a way to move on as well. Good luck to you.
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 2 lines · VDR User
This conversation is about addressing and finding a solution to a problem.
Agreed.
Quoted 5 lines
I'm not even the person who originally brought up the solution used in multiproto but as far as I can see, it does seem to be a great solution so I question why that method shouldn't be adopted.
Fair enough, and upon casual inspection, it sounds like the multiproto method is done well and can be adopted ... so lets move towards that direction with that in mind and with whatever other good suggestions can be fleshed out of the discussion.
Quoted 12 lines
I hope you don't expect to be taken seriously after your absurd comment.
....
It's ridiculous I need to point any of this out to you but one possible reason is that _you_ are in fact the one trolling here. Afterall, the only posting you've made has absolutely nothing to do with the subject, while all of mine do.
...
And by the way, most of us have accepted the outcome of the s2api/multiproto controversy. Maybe it's about time you find a way to move on as well.
Andy's comment might have been harsh, but your earlier comments (
http://marc.info/?l=linux-dvb&m=122763079609781&w=2) have, shall we say, been a touch on the harsh side too and there is plenty of reason why those might have drawn the ire of someone like Andy; specifically:
a) "How could you possibly miss such a fundamental element?!"
Retort: As has already been pointed out: stuff happens, gets overlooked ... Second, from a developers perspective (like Andy's), it gets exceedingly annoying when users bitch and complain about how lacking or (as a gross exaggeration) "brain dead" some developer's code is ... such cases are obviously not ripe with constructive commentary, nor do they provide much incentive for developers to continue with projects if the users prove to be ungrateful for the free lunch
b) "I have yet to hear any response from any of them about this issue.Seems as though when the issue was beating multiproto, communication was at the peak. Now that the decision has been made, good luck to get a reply. :\"
Retort: By its very nature, this is a provocative comment.
In addition to the point made by Andy (and I too am not lining up on either side of the Multiproto vs S2API holy war), I will note the inherent contextual error in "the silence is deafening" stance and why it doesn't float squat:
Manu was absent from the lists and activity, for personal reasons, for a sustained period (5-6 months?). That's not a knock on him, its just a fact. Steven has been absent from the lists and activity for, what, 3-4 weeks? Suddenly this is an international incident that demands immediate resolve? Come on! Fact of the matter is, the whole S2 thing is long in coming, and likely has a number of areas that will need to be ironed out in future -- this would be the case regardless of whether it is Multiproto or S2API that is pressed forth. Things WILL get resolved. Give them time. Tone back expectations.
As a second point of issue, perhaps you have not noticed, but meaningful traffic on the mail lists would appear to be down substantially over the last while -- though, on the flip side, the number of "is this device supported" and "can someone write a driver for this" posts is increasing disproportionately to the number of interested or available developers. So, the point (once again), is that the absence of discussion, even upon meaningful subject matters, is not necessarily indicative of anything further then there being a lack of discussion at this point in time. Silence does not a conspiracy make.
c) "Hey, stranger things have happened. Not much surprised me these days."
Retort: This, of course, was in response to Klaus', self described, sarcastic conspiracy comment. Though your own later comment ("most of us have accepted the outcome of the s2api/multiproto controversy") does not specifically indicate that you include yourself within that group of accepting individuals, it strikes me that if you truly were a member, then you would have passed up on providing such a response to Klaus -- instead, you availed yourself to the opportunity to stoke the flame.
[For the record -- I don't particularly like the way the whole S2 situation played out. BUT I see it as a case of where there is blame on both sides. However, being a pragmatist, I (like many others) would like to see that whole issue put to rest and, instead, press forth in a progressive manner. I believe that the best of both works can be or should be adopted. Perhaps it is naive on my part, but I can't see why one is inherently or universally better than the other -- then again, that argument is relatively moot to me -- there is no singular solution other than to adapt and continuously try to improve. I hate rigidity, whether it is idealogical or otherwise.]
Quoted 1 line
Please contribute something relevant or find some other thread to infect.
Andy is a developer and contributes to the v4l-dvb code base on a regular basis. That's pretty darn relevant to me. If you did not like his comment, then perhaps you could have ignored it, or perhaps you could have reflected inwards upon how your own loose comments, as illustrated above, might have been viewed as contemptuous by some.
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
В сообщении от 27 November 2008 17:21:33 Andy Walls написал(а):
Quoted 5 lines · VDR User
Quoted 2 lines
Does anyone here actually disagree that the approach multiproto takes is a great solution that should be adopted (if possible)?
Does anyone here disagree that the above question is a troll?
You don't shake your fist when the fight is over.
You came the day after the fair.
And so on.
Quoted 17 lines
My point is that silence on internet mailing lists is not concurrence.
This is especially the case if people are trying to avoid conflict by not reacting to people trolling for conflict.
Regards,
Andy_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Signature · 7 lines
Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks _______________________________________________ linux-dvb mailing list [email protected] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 7 lines · VDR User
Quoted 6 lines · Andy Walls
Quoted 2 lines · VDR User
Does anyone here actually disagree that the approach multiproto takes is a great solution that should be adopted (if possible)?
Does anyone here disagree that the above question is a troll?
Quoted 7 lines
Quoted 4 lines
My point is that silence on internet mailing lists is not concurrence.
This is especially the case if people are trying to avoid conflict by not reacting to people trolling for conflict.
I hope you don't expect to be taken seriously after your absurd comment.
Derek,
I never expected for that response to be taken at face value. It was to encourage reflection on the way your original question was phrased and to point out it's inability to get a conclusive answer.
Also devoid of any fragments of the previous conversation in the thread, your original question can be construed as inflammatory (i.e. a troll). Even the most benign tone and intent won't always be conveyed in a written medium.
Quoted 9 lines
This conversation is about addressing and finding a solution to a problem. I'm not even the person who originally brought up the solution used in multiproto but as far as I can see, it does seem to be a great solution so I question why that method shouldn't be adopted.
It's ridiculous I need to point any of this out to you but one possible reason is that _you_ are in fact the one trolling here.
The first and third line of my response were crafted such that it could possibly be construed as a troll. A bit of irony I was hoping people would catch.
Quoted 4 lines
Afterall, the only posting you've made has absolutely nothing to do with the subject, while all of mine do.
Please contribute something
relevant or find some other thread to infect.
And I could say the same thing. Open ended survey questions that can't yield conclusive results, with no surrounding context in the message, and yet addressed to a wide audience (i.e. "anyone here") are not productive, IMO.
I admire the passion you have about the state of v4l-dvb in your writings. So why can't I see that passion in your work?
I'd encourage you to take that energy and passion you have and write some improvements, go through unit testing, and submit some patches. It's open source, you can make a difference - you can even author some of those differences. If you think it's broken, help us fix it. If you don't think you can write code yourself, find a friend who can help you. I echo your sentiment back to you whole-heartedly: please contribute!
Quoted 3 lines
And by the way, most of us have accepted the outcome of the s2api/multiproto controversy. Maybe it's about time you find a way to move on as well. Good luck to you.
Who says I haven't moved on? My peeve is inflammatory and derisive comments and destructive criticism. These things weigh heavily on me when I see them.
As CityK rightly guessed, your history of somewhat provocative comments in postings colored my opinion on your survey question with which I took issue. Without context, it appears to be just another in a series.
Regards,
Andy
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Am Donnerstag, den 27.11.2008, 09:19 -0800 schrieb VDR User:
Quoted 19 lines · Andy Walls
Quoted 10 lines · VDR User
Quoted 2 lines
Does anyone here actually disagree that the approach multiproto takes is a great solution that should be adopted (if possible)?
Does anyone here disagree that the above question is a troll?
My point is that silence on internet mailing lists is not concurrence.
This is especially the case if people are trying to avoid conflict by not reacting to people trolling for conflict.
I hope you don't expect to be taken seriously after your absurd comment. This conversation is about addressing and finding a solution to a problem. I'm not even the person who originally brought up the solution used in multiproto but as far as I can see, it does seem to be a great solution so I question why that method shouldn't be adopted.
Quoted 2 lines
It's ridiculous I need to point any of this out to you but one possible reason is that _you_ are in fact the one trolling here.
Yes, after all, we know for sure Andy is a troll.
Go away.
Quoted 4 lines
Afterall, the only posting you've made has absolutely nothing to do with the subject, while all of mine do. Please contribute something relevant or find some other thread to infect.
Quoted 8 lines
And by the way, most of us have accepted the outcome of the s2api/multiproto controversy. Maybe it's about time you find a way to move on as well. Good luck to you.
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Am Donnerstag, den 27.11.2008, 14:20 -0500 schrieb CityK:
Quoted 30 lines
Quoted 2 lines · VDR User
This conversation is about addressing and finding a solution to a problem.
Agreed.
Quoted 5 lines
I'm not even the person who originally brought up the solution used in multiproto but as far as I can see, it does seem to be a great solution so I question why that method shouldn't be adopted.
Fair enough, and upon casual inspection, it sounds like the multiproto method is done well and can be adopted ... so lets move towards that direction with that in mind and with whatever other good suggestions can be fleshed out of the discussion.
Quoted 12 lines
I hope you don't expect to be taken seriously after your absurd comment.
....
It's ridiculous I need to point any of this out to you but one possible reason is that _you_ are in fact the one trolling here. Afterall, the only posting you've made has absolutely nothing to do with the subject, while all of mine do.
...
And by the way, most of us have accepted the outcome of the s2api/multiproto controversy. Maybe it's about time you find a way to move on as well.
Quoted 4 lines
Andy's comment might have been harsh, but your earlier comments (
http://marc.info/?l=linux-dvb&m=122763079609781&w=2) have, shall we say, been a touch on the harsh side too and there is plenty of reason why those might have drawn the ire of someone like Andy; specifically:
CityK,
by all respect, Andy is a highly qualified developer and VDR.user is just a troll.
Don't confuse any more on it, or we will have a developer only list very soon and this decision will not be up to you.
Cheers,
Hermann
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Considering that writing my own retorts to quotes will only bring this discussion further off-topic, I'll refrain by only saying that anyone who finds my opinions too abrasive for their ears should elect to ignore my posts. I don't think people should be expected to censor themselves or walk on eggshells for fear of someone taking it the wrong way. Of course unless people engage in name-calling, excessive profanity, etc. Aside of the "troll" word being tossed around a couple times, I don't see that happening. That being said, no harm no foul.. Let's move on.
CityK said it best:
"Fair enough, and upon casual inspection, it sounds like the multiproto method is done well and can be adopted ... so lets move towards that direction with that in mind and with whatever other good suggestions can be fleshed out of the discussion."
Agreed.
With regard,
-Derek
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 6 lines · Klaus Schmidinger
The attached patch adds a capability flag that allows an application to determine whether a particular device can handle "second generation modulation" transponders. This is necessary in order for applications to be able to decide which device to use for a given channel in a multi device environment, where DVB-S and DVB-S2 devices are mixed.
Quoted 6 lines
It is assumed that a device capable of handling "second generation modulation" can implicitly handle "first generation modulation". The flag is not named anything with DVBS2 in order to allow its use with future DVBT2 devices as well (should they ever come).
Signed-off by: Klaus Schmidinger <[email protected]>
This looks good.
- Steve
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 10 lines · Artem Makhutov
I fully understand what you mean. I would also like to adress the remarks of Berry:
http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030539.html
Here we can define the frontend type and check if it is DVB-S or DVB-S2 or whatever and also define the modulations that the frontend is capable to handle (in case a device won't work with the "professional" modulations like 16APSK).
Quoted 8 lines
Applications like VDR can check the
fe_typeflags, and applications that require more info could checkfe_caps.I am not sure about this all, and I would like to see some comments from some people that are more familiar it. Specially changing
fe_typelooks like it will break the binary compatibility, so maybe it would be better to define a new enum for this flags...
I think, it can be a (or the) solution. Why nobody answered on this? Have I not read something? Is a solution found?
Regards,
Thomas
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 4 lines · Udo Richter
What does a DVB app need to know? A DVB app probably just needs to know "What devices are capable of tuning to channel XYZ?". The API could answer this the same way as it would tune to channel XYZ, just without actually doing it. Try-before-you-buy.
After some insights to S2API interface, this looks even better to me:
properties.num = 1;
properties.props[0].cmd = DTV_DELIVERY_SYSTEM;
properties.props[0].u.data = SYS_DVBS2;
if (ioctl(d, FE_CAP_SET_PROPERTY, &properties) >= 0) {
// has S2 capability
}A generic frontend test function that delivers the necessary S2 capability information, and many other capabilities too. And there are a lot more delivery systems that seem to be hard to detect, so a query function 'can do SYS_XXXX' seems necessary anyway.
Cheers,
Udo
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hello Udo
Quoted 5 lines
After some insights to S2API interface, this looks even better to me:
properties.num = 1;
properties.props[0].cmd =DTV_DELIVERY_SYSTEM;
properties.props[0].u.data =SYS_DVBS2;
Quoted 11 lines
if (ioctl(d, FE_CAP_SET_PROPERTY, &properties) >= 0) { // has S2 capability }A generic frontend test function that delivers the necessary S2 capability information, and many other capabilities too. And there are a lot more delivery systems that seem to be hard to detect, so a query function 'can do
SYS_XXXX' seems necessary anyway.
That's a good approach, but I doubt that anyone takes care of it. This mailing list is like WOM (Write only Memory) when you post patches or make suggestions :(
Signature · 7 lines
Helmut Auer, [email protected] _______________________________________________ linux-dvb mailing list [email protected] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Quoted 25 lines · On Thu, 25 Dec 2008 16:35:05 +0100 hermann pitton <[email protected]>…
Hi,
Am Donnerstag, den 25.12.2008, 10:44 +0100 schrieb Helmut Auer:
Quoted 17 lines
Hello Udo
Quoted 5 lines
After some insights to S2API interface, this looks even better to me:
properties.num = 1;
properties.props[0].cmd =DTV_DELIVERY_SYSTEM;
properties.props[0].u.data =SYS_DVBS2;Quoted 11 lines
if (ioctl(d, FE_CAP_SET_PROPERTY, &properties) >= 0) { // has S2 capability }A generic frontend test function that delivers the necessary S2 capability information, and many other capabilities too. And there are a lot more delivery systems that seem to be hard to detect, so a query function 'can do
SYS_XXXX' seems necessary anyway.Quoted 4 lines
That's a good approach, but I doubt that anyone takes care of it. This mailing list is like WOM (Write only Memory) when you post patches or make suggestions :(
Quoted 8 lines
if I get the status right for this one, we have from Klaus a fully qualified patch according to README.patches.
http://www.spinics.net/lists/linux-dvb/msg30371.html
Further we have at least an ACK from Steven and no NACK so far.
After reviewing the thread, it seems that Manu also ACKed:
http://www.spinics.net/lists/linux-dvb/msg30422.html
He only suggested to use a shorter name.
I also prefer a shorter name, but both ways work fine. I'll let Klaus to decide to take one of the suggested names.
IMO, "2G" Is clearer than "2ND_GEN". Also, maybe we should keep the association with "MODULATION" at the naming. So, I vote for this name:
FE_CAN_2G_MODULATION
Quoted 6 lines
But that ACK also means that he will not forward it himself to Mauro through one of his development repositories by a pull request.
In this case direct mail to Mauro is requested to let him know a patch on the list is considered to be ready, or wait until he gets aware of it.
Yes, please. I generally wait for people to agree on such changes, then someone will get the acks and commit on his tree, or reply at the thread asking me to get the final patch.
Klaus,
could you prepare the final patch? and send it to me, keeping the ML C/C?
---
I can't avoid to comment a small CodingStyle issue I noticed at the patch:
+ FE_CAN_2ND_GEN_MODULATION = 0x10000000, // frontend supports "2nd generation modulation" (DVB-S2)
"//" for comments shouldn't happen, since it violates C99 syntax that it is used on kernel.
Cheers,
Mauro
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi Kaus,
Quoted 5 lines · On Wed, 31 Dec 2008 12:52:06 +0100 Klaus Schmidinger…
Quoted 2 lines
"//" for comments shouldn't happen, since it violates C99 syntax that it is used on kernel.
I just used the same comment characters as the other lines that were already there ;-)
Yes, I know. We need to sanitize the file ;)
I'll write a separate patch fixing this after merging yours.
Quoted 2 lines
Klaus
You just forgot to send me a patch description with your SOB and Stoth's ack ;) Except for that, the patch seems sane on my eyes.
Maybe we may commit it as two separate patches:
The first one with the core changes, and the second one with the driver (cx24116 and stb0899) ones. API changes are important enough to deserve their own separate commit.
Cheers,
Mauro.
Quoted 27 lines
diff -ru
linux/drivers/media/dvb/frontends/cx24116.clinux/drivers/media/dvb/frontends/cx24116.cdrivers/media/dvb/frontends/cx24116.c +1
-0@@ -1480,6 +1480,7 @@FE_CAN_FEC_1_2 |FE_CAN_FEC_2_3 |FE_CAN_FEC_3_4 |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 },diff -ru
linux/drivers/media/dvb/frontends/stb0899_drv.clinux/drivers/media/dvb/frontends/stb0899_drv.cdrivers/media/dvb/frontends/stb0899_drv.c +1
-0@@ -1913,6 +1913,7 @@ .caps = FE_CAN_INVERSION_AUTO |FE_CAN_FEC_AUTO | +FE_CAN_2G_MODULATION |FE_CAN_QPSK },diff -ru
linux/include/linux/dvb/frontend.hlinux/include/linux/dvb/frontend.h
include/linux/dvb/frontend.h line 69
Quoted 7 lines
include/linux/dvb/frontend.h +1
-0@@ -63,6 +63,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_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 FE_CAN_MUTE_TS =0x80000000 // frontend can stop spurious TS data output
Cheers,
Mauro
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
On Wed, Dec 31, 2008 at 12:52:06PM +0100, Klaus Schmidinger wrote:
Then vdr-1.7.2 should also be patched :-)
Quoted 38 lines
I just used the same comment characters as the other lines that were already there ;-)
Klaus
diff -ru
linux/drivers/media/dvb/frontends/cx24116.clinux/drivers/media/dvb/frontends/cx24116.cdrivers/media/dvb/frontends/cx24116.c +1
-0@@ -1480,6 +1480,7 @@FE_CAN_FEC_1_2 |FE_CAN_FEC_2_3 |FE_CAN_FEC_3_4 |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 },diff -ru
linux/drivers/media/dvb/frontends/stb0899_drv.clinux/drivers/media/dvb/frontends/stb0899_drv.cdrivers/media/dvb/frontends/stb0899_drv.c +1
-0@@ -1913,6 +1913,7 @@ .caps = FE_CAN_INVERSION_AUTO |FE_CAN_FEC_AUTO | +FE_CAN_2G_MODULATION |FE_CAN_QPSK },diff -ru
linux/include/linux/dvb/frontend.hlinux/include/linux/dvb/frontend.hinclude/linux/dvb/frontend.h +1
-0@@ -63,6 +63,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_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 FE_CAN_MUTE_TS =0x80000000 // frontend can stop spurious TS data output
Signature · 7 lines
Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org
http://picasaweb.google.com/Gregoire.Favre
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvbQuoted 7 lines · On Wed, 31 Dec 2008 13:57:09 +0100 Klaus Schmidinger…
Quoted 5 lines
Maybe we may commit it as two separate patches:
The first one with the core changes, and the second one with the driver (cx24116 and stb0899) ones. API changes are important enough to deserve their own separate commit.
That's all fine with me.
Committed, thanks.
Cheers,
Mauro
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb