[linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Klaus Schmidinger]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

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 <Klaus.Schmidinger@cadsoft.de>


PS: why an API named *S2*API didn't contain this in the first place
    is totally beyond me...

[-- Attachment #2: v4l-dvb-s2api-add-s2-capability.diff --]
[-- Type: text/x-patch, Size: 2046 bytes --]

diff -ru v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c
--- v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c	2008-11-21 23:00:55.000000000 +0100
+++ v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/cx24116.c	2008-11-23 11:36:31.000000000 +0100
@@ -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
 	},
 
diff -ru v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c
--- v4l-dvb-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c	2008-11-21 23:00:55.000000000 +0100
+++ v4l-dvb-2008-11-22-17754ef554b0/linux/drivers/media/dvb/frontends/stb0899_drv.c	2008-11-23 11:37:01.000000000 +0100
@@ -1913,6 +1913,7 @@
 
 		.caps 			= FE_CAN_INVERSION_AUTO	|
 					  FE_CAN_FEC_AUTO	|
+					  FE_CAN_2ND_GEN_MODULATION |
 					  FE_CAN_QPSK
 	},
 
diff -ru v4l-dvb-17754ef554b0/linux/include/linux/dvb/frontend.h v4l-dvb-2008-11-22-17754ef554b0/linux/include/linux/dvb/frontend.h
--- v4l-dvb-17754ef554b0/linux/include/linux/dvb/frontend.h	2008-11-21 23:00:55.000000000 +0100
+++ v4l-dvb-2008-11-22-17754ef554b0/linux/include/linux/dvb/frontend.h	2008-11-23 11:27:21.000000000 +0100
@@ -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

[-- Attachment #3: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Artem Makhutov]

Hello,

Klaus Schmidinger schrieb:
> 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 <Klaus.Schmidinger@cadsoft.de>

Wouldn't it be better to add something like this:

FE_CAN_8PSK
FE_CAN_16APSK
FE_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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[BOUWSMA Barry]

On Mon, 24 Nov 2008, Artem Makhutov wrote:

(quoting Klaus...)
> > 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:


> Wouldn't it be better to add something like this:
> FE_CAN_8PSK
> FE_CAN_16APSK
> FE_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.



> FE_CAN_DVBS2
> Instead of FE_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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Klaus Schmidinger]

On 24.11.2008 08:12, Artem Makhutov wrote:
> Hello,
> 
> Klaus Schmidinger schrieb:
>> 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 <Klaus.Schmidinger@cadsoft.de>
> 
> Wouldn't it be better to add something like this:
> 
> FE_CAN_8PSK
> FE_CAN_16APSK
> FE_CAN_32APSK
> 
> or
> 
> FE_CAN_DVBS2
> 
> Instead 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[vdr]

> 
> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Artem Makhutov]

Hi,

Klaus Schmidinger schrieb:
> On 24.11.2008 08:12, Artem Makhutov wrote:
>> Hello,
>>
>> Klaus Schmidinger schrieb:
>>> 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 <Klaus.Schmidinger@cadsoft.de>
>> Wouldn't it be better to add something like this:
>>
>> FE_CAN_8PSK
>> FE_CAN_16APSK
>> FE_CAN_32APSK
>>
>> or
>>
>> FE_CAN_DVBS2
>>
>> Instead 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 ;-)

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Niels Wagenaar]

-----Original message-----
From: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
Sent: Mon 24-11-2008 10:07
To: linux-dvb@linuxtv.org;
Subject: Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

> On 24.11.2008 08:12, Artem Makhutov wrote:
> > Hello,
> >
> > Klaus Schmidinger schrieb:
> >> 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 <Klaus.Schmidinger@cadsoft.de>
> >
> > Wouldn't it be better to add something like this:
> >
> > FE_CAN_8PSK
> > FE_CAN_16APSK
> > FE_CAN_32APSK
> >
> > or
> >
> > FE_CAN_DVBS2
> >
> > Instead of FE_CAN_2ND_GEN_MODULATION ? It is too generic for me.
>

I agree with Artem on this one.

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

With most software I used on Windows (DVB Viewer Pro and Mediaportal) I
have to enable "DVB-S2" features on my card. Perhaps since we don't have a
FE_CAN_8PSK or an other sollution to check this, this might be the best
option you seek. Or use my very ugly patch (tm) where I check for the
string "DVBS2" in the card's deliverysystem and then set the frontendtype
to SYS_DVBS2 (which is backwards compatible with DVB-S).

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

I don't know multiproto perse and I didn't check the multiproto code
within VDR in general. I just used Igor's S2API patch for VDR 1.7.0 which
only had DVB-S2. I then added the other SYS_ types and added the VUP I
wrote about earlier.

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

With DVB-S2, I rather speak of an enhancement then of second generation.
But this is my oppinion and you can simply ignore this! ;)

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

If I am correct, S2API will handle multiple delivery systems without any
problems. A device can handle multiple delivery systems because the
frontend (/dev/dvb/adapter[0,1,2,etc]/frontend[0,1,2,3,etc]) is the real
device(-location which) will handle the DVB delivery/transport. This can
be DVB-T, DVB-S, DVB-S2 or DVB-C (not and!). And we open a frontend
adapter of the device for tuning and that will only support one DVB
transport (we don't ask the card to tune, we ask the frontend
device-location to tune).

At least, this is the way as I understand how tuning with DVB-cards works
in general. And this is also the way how I implented the S2API patch. But
I'm not 100% sure if the patch does indeed work with MFE devices like the
HVR-3000, HVR-4000, etc because I didn't had the option to check if the
code - which checks the frontend of de device - can handle multiple
frontend device-locations.

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

For the time being I have only two options which will work without any
additional patching in S2API:

- Let the user set this as an option
- Use my VUP (very ugly patch) by checking the deliverystem for the string
"DVBS2".

> Klaus

Niels Wagenaar



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[VDR User]

If the multiproto method is superior, which it certainly seems to be,
why can't that method be adopted into s2api?  It seems silly that this
problem hasn't been addressed in the conception of s2api.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Niels Wagenaar]

Op Ma, 24 november, 2008 16:59, schreef VDR User:
> If the multiproto method is superior, which it certainly seems to be,
> why can't that method be adopted into s2api?  It seems silly that this
> problem hasn't been addressed in the conception of s2api.
>

Is multiproto superior? Perhaps on several points it's indeed better or
more complete. But then again, it was allready 2 years in development so
it's bound to have additional enhancements which S2API doesn't have atm.

But then again, we're comparing multiproto with S2API which was build from
the ground in just little over 3 months. So yeah, it doesn't have it all.

>From my personal POV. I think S2API isn't missing something concerning
tuning. The latest VDR 1.7.0 patch (which I made available on 7-10), still
works in my configuration. And I heard from several others that it works
for them also. Even after updating the v4l repo to the latest editions. So
DVB tuning works with S2API.

So, what we're missing are enhancements! Well, we can add that since it's
OpenSource and all. So add it allready instead of complaining ;)

Regards,

Niels Wagenaar




_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Klaus Schmidinger]

On 24.11.2008 16:55, Niels Wagenaar wrote:
> ...
> For the time being I have only two options which will work without any
> additional patching in S2API:
> 
> - Let the user set this as an option
> - Use my VUP (very ugly patch) by checking the deliverystem for the string
> "DVBS2".

Both are ugly workarounds and any reasonable API requiring them instead
of simply reporting the -S2 capability of a device should
be ashamed, go home and do its homework.

For the time being I'll work with my suggested FE_CAN_2ND_GEN_MODULATION
patch - until somebody can suggest a different way of doing this (without
parsing strings or requiring the user to do it).

Klaus

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Klaus Schmidinger]

On 24.11.2008 17:14, Niels Wagenaar wrote:
> Op Ma, 24 november, 2008 16:59, schreef VDR User:
>> If the multiproto method is superior, which it certainly seems to be,
>> why can't that method be adopted into s2api?  It seems silly that this
>> problem hasn't been addressed in the conception of s2api.
>>
> 
> Is multiproto superior? Perhaps on several points it's indeed better or
> more complete. But then again, it was allready 2 years in development so
> it's bound to have additional enhancements which S2API doesn't have atm.
> 
> But then again, we're comparing multiproto with S2API which was build from
> the ground in just little over 3 months. So yeah, it doesn't have it all.
> 
>>From my personal POV. I think S2API isn't missing something concerning
> tuning. The latest VDR 1.7.0 patch (which I made available on 7-10), still
> works in my configuration. And I heard from several others that it works
> for them also. Even after updating the v4l repo to the latest editions. So
> DVB tuning works with S2API.
> 
> So, what we're missing are enhancements! Well, we can add that since it's
> OpenSource and all. So add it allready instead of complaining ;)

Well, I did - but apparently nobody cares... :-(

Klaus

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[VDR User]

On Mon, Nov 24, 2008 at 8:14 AM, Niels Wagenaar <n.wagenaar@xs4all.nl> wrote:
> Op Ma, 24 november, 2008 16:59, schreef VDR User:
>> If the multiproto method is superior, which it certainly seems to be,
>> why can't that method be adopted into s2api?  It seems silly that this
>> problem hasn't been addressed in the conception of s2api.
>
> Is multiproto superior? Perhaps on several points it's indeed better or
> more complete. But then again, it was allready 2 years in development so
> it's bound to have additional enhancements which S2API doesn't have atm.
>
> But then again, we're comparing multiproto with S2API which was build from
> the ground in just little over 3 months. So yeah, it doesn't have it all.

I was talking about the multiproto method of reporting the cards
capabilities, not the entire api.  There's no need to go on about the
history of multiproto & s2api so please don't turn this thread into
"one of those".  There's one big problem that needs to be addressed
and the less people get OT, the faster it might be resolved.

> From my personal POV. I think S2API isn't missing something concerning
> tuning.

You don't think an api's ability to correctly report a cards
capabilities is a big deal?  It's a very basic & fundamental feature!!
 I guess we will have to agree to disagree.  ;)

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Manu Abraham]

Klaus Schmidinger wrote:
> On 24.11.2008 16:55, Niels Wagenaar wrote:
>> ...
>> For the time being I have only two options which will work without any
>> additional patching in S2API:
>>
>> - Let the user set this as an option
>> - Use my VUP (very ugly patch) by checking the deliverystem for the string
>> "DVBS2".
> 
> Both are ugly workarounds and any reasonable API requiring them instead
> of simply reporting the -S2 capability of a device should
> be ashamed, go home and do its homework.

ACK

> For the time being I'll work with my suggested FE_CAN_2ND_GEN_MODULATION
> patch - until somebody can suggest a different way of doing this (without
> parsing strings or requiring the user to do it).

ACK.

That is a saner way of doing it rather than anything else, as it stands.

Anyway, we won't be seeing professional device support as it stands with
the current API anytime soon, so as it stands the better alternative is
thus.

But it would be nice to have something shorter: say FE_IS_2G or
something that way, for the minimal typing.


Regards,
Manu


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Klaus Schmidinger]

On 24.11.2008 20:33, Manu Abraham wrote:
> Klaus Schmidinger wrote:
>> On 24.11.2008 16:55, Niels Wagenaar wrote:
>>> ...
>>> For the time being I have only two options which will work without any
>>> additional patching in S2API:
>>>
>>> - Let the user set this as an option
>>> - Use my VUP (very ugly patch) by checking the deliverystem for the string
>>> "DVBS2".
>> Both are ugly workarounds and any reasonable API requiring them instead
>> of simply reporting the -S2 capability of a device should
>> be ashamed, go home and do its homework.
> 
> ACK
> 
>> For the time being I'll work with my suggested FE_CAN_2ND_GEN_MODULATION
>> patch - until somebody can suggest a different way of doing this (without
>> parsing strings or requiring the user to do it).
> 
> ACK.
> 
> That is a saner way of doing it rather than anything else, as it stands.
> 
> Anyway, we won't be seeing professional device support as it stands with
> the current API anytime soon, so as it stands the better alternative is
> thus.
> 
> But it would be nice to have something shorter: say FE_IS_2G or
> something that way, for the minimal typing.

Well, I don't really care about the actual name - as long as I can
get the information... ;-)

Klaus

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Niels Wagenaar]

Op Ma, 24 november, 2008 20:33, schreef Manu Abraham:
> Klaus Schmidinger wrote:
>> On 24.11.2008 16:55, Niels Wagenaar wrote:
>>> ...
>>> For the time being I have only two options which will work without any
>>> additional patching in S2API:
>>>
>>> - Let the user set this as an option
>>> - Use my VUP (very ugly patch) by checking the deliverystem for the
>>> string
>>> "DVBS2".
>>
>> Both are ugly workarounds and any reasonable API requiring them instead
>> of simply reporting the -S2 capability of a device should
>> be ashamed, go home and do its homework.
>
> ACK
>

And still, I see many popular/free/commercial DVB software on the Windows
platform where you need to select the DVB-S2 option on the DVB-card. So I
wouldn't just throw away this option as an ugly work-around.

In fact, I would like to set the specific type for my DVB cards if I
could. So an override option is definately not a ugly work-around and for
several people this will not be problem.

But, the other option is definately a very ugly work-around. But then
again, it works ;)

>> For the time being I'll work with my suggested FE_CAN_2ND_GEN_MODULATION
>> patch - until somebody can suggest a different way of doing this
>> (without
>> parsing strings or requiring the user to do it).
>
> ACK.
>
> That is a saner way of doing it rather than anything else, as it stands.
>
> Anyway, we won't be seeing professional device support as it stands with
> the current API anytime soon, so as it stands the better alternative is
> thus.
>
> But it would be nice to have something shorter: say FE_IS_2G or
> something that way, for the minimal typing.
>

I disagree on both of the proposals. Add an other flag is indeed the way
(I ACK that), but not a general one like you both proposed. When DVB-T2
(or DVB-S3 or DVB-C2 or whatever new enhancement of past DVB standards)
becomes mainstream we get the exact same discussion again.

IMHO, an non-general flag like FE_CAN_DVBT, FE_CAN_DVBS, FE_CAN_DVBS2,
FE_CAN_DVBC, etc would be more clearer. Since it's an DVB standard, it
must support certain modulation types, etc. So if the driver set its
frontendtype to FE_CAN_DVBT, you know for sure what tuning types it
supports.

But it al depends if people want to add this in the v4l driver also. If
they don't, it doesn't matter which proposal or patch makes it. And for
that a manual override or setting would become very handy.

> Regards,
> Manu
>

Look, I'm not an developer perse and you can ignore what I just wrote. But
my logic tells me that an manual override or a non-general FE_CAN flag for
the current DVB standards is a very clean sollution. Just my € 0,02.

Regards,

Niels Wagenaar



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Klaus Schmidinger]

On 25.11.2008 09:46, Niels Wagenaar wrote:
> Op Ma, 24 november, 2008 20:33, schreef Manu Abraham:
>> Klaus Schmidinger wrote:
>>> On 24.11.2008 16:55, Niels Wagenaar wrote:
>>>> ...
>>>> For the time being I have only two options which will work without any
>>>> additional patching in S2API:
>>>>
>>>> - Let the user set this as an option
>>>> - Use my VUP (very ugly patch) by checking the deliverystem for the
>>>> string
>>>> "DVBS2".
>>> Both are ugly workarounds and any reasonable API requiring them instead
>>> of simply reporting the -S2 capability of a device should
>>> be ashamed, go home and do its homework.
>> ACK
>>
> 
> And still, I see many popular/free/commercial DVB software on the Windows
> platform where you need to select the DVB-S2 option on the DVB-card. So I
> wouldn't just throw away this option as an ugly work-around.
> 
> In fact, I would like to set the specific type for my DVB cards if I
> could. So an override option is definately not a ugly work-around and for
> several people this will not be problem.
> 
> But, the other option is definately a very ugly work-around. But then
> again, it works ;)
> 
>>> For the time being I'll work with my suggested FE_CAN_2ND_GEN_MODULATION
>>> patch - until somebody can suggest a different way of doing this
>>> (without
>>> parsing strings or requiring the user to do it).
>> ACK.
>>
>> That is a saner way of doing it rather than anything else, as it stands.
>>
>> Anyway, we won't be seeing professional device support as it stands with
>> the current API anytime soon, so as it stands the better alternative is
>> thus.
>>
>> But it would be nice to have something shorter: say FE_IS_2G or
>> something that way, for the minimal typing.
>>
> 
> I disagree on both of the proposals. Add an other flag is indeed the way
> (I ACK that), but not a general one like you both proposed. When DVB-T2
> (or DVB-S3 or DVB-C2 or whatever new enhancement of past DVB standards)
> becomes mainstream we get the exact same discussion again.
> 
> IMHO, an non-general flag like FE_CAN_DVBT, FE_CAN_DVBS, FE_CAN_DVBS2,
> FE_CAN_DVBC, etc would be more clearer. Since it's an DVB standard, it
> must support certain modulation types, etc. So if the driver set its
> frontendtype to FE_CAN_DVBT, you know for sure what tuning types it
> supports.
> 
> But it al depends if people want to add this in the v4l driver also. If
> they don't, it doesn't matter which proposal or patch makes it. And for
> that a manual override or setting would become very handy.
> 
>> Regards,
>> Manu
>>
> 
> Look, I'm not an developer perse and you can ignore what I just wrote. But
> my logic tells me that an manual override or a non-general FE_CAN flag for
> the current DVB standards is a very clean sollution. Just my € 0,02.

I find it a completely unacceptable thing to have the user tell
the application what type of DVB devices the hardware provides.
This is pretty much the first and simplest thing the *DRIVER* has
to do. If a driver (API) doesn't allow this in a clean way, it's
worthless!

I don't care if this is a specific or a general flag, as long as
it allows the application to clearly find out the kind of hardware
that's available. It leaves me dumbfounded that this is suddenly
such a big problem...

If my proposal is not acceptable, then please can one of the S2API
experts come up with a solution that better fits the S2API way of
thinking?

<conspiracy_theory><sarcasm>
Or is the S2API already "dead", and it's sole purpose was to
prevent "multiproto" to make its way into the kernel? And now that
this has been achieved, nodody really cares whether it can be used
in real life?
</sarcasm></conspiracy_theory>

Klaus

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[jean-paul]

When can we get a final version of multiproto. I hate al the  
discussions around over bits and bytes without carry on  customers and  
working versions. There are more then 1000 pathes around and it takes  
weeks to get some things work.   Is it really to mach work to makes  
thinks
work on a simple way?

Can I say, if I want to have a working system, switch to windows?

Please crow up and  let thinks make working as it shoot be.






_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Manu Abraham]

jean-paul@goedee.nl wrote:
> When can we get a final version of multiproto.

The final (broadcast) version is here: http://jusst.de/hg/multiproto

Note that the support for professional use cases is incomplete.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[jean-paul]

Pfffff No TT 3650CI in it. Ok i try to make it by my self (or as  
usual; find a working patch).


Citeren Manu Abraham <abraham.manu@gmail.com>:

> jean-paul@goedee.nl wrote:
>> When can we get a final version of multiproto.
>
> The final (broadcast) version is here: http://jusst.de/hg/multiproto
>
> Note that the support for professional use cases is incomplete.
>




_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[VDR User]

On Tue, Nov 25, 2008 at 1:05 AM, Klaus Schmidinger
<Klaus.Schmidinger@cadsoft.de> wrote:
> I find it a completely unacceptable thing to have the user tell
> the application what type of DVB devices the hardware provides.
> This is pretty much the first and simplest thing the *DRIVER* has
> to do. If a driver (API) doesn't allow this in a clean way, it's
> worthless!
>
> I don't care if this is a specific or a general flag, as long as
> it allows the application to clearly find out the kind of hardware
> that's available. It leaves me dumbfounded that this is suddenly
> such a big problem...

You are not alone in that boat my friend.  Especially after reading
the comments about how "thought out" the api is.  How could you
possibly miss such a fundamental element?!

> If my proposal is not acceptable, then please can one of the S2API
> experts come up with a solution that better fits the S2API way of
> thinking?

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

> <conspiracy_theory><sarcasm>
> Or is the S2API already "dead", and it's sole purpose was to
> prevent "multiproto" to make its way into the kernel? And now that
> this has been achieved, nodody really cares whether it can be used
> in real life?
> </sarcasm></conspiracy_theory>

Hey, stranger things have happened.  Not much surprised me these days.
 Hopefully somebody will get this sorted out and fixed very soon as it
shouldn't even be an issue at this point!!

-Derek

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Morgan Tørvolt]

> I find it a completely unacceptable thing to have the user tell
> the application what type of DVB devices the hardware provides.
> This is pretty much the first and simplest thing the *DRIVER* has
> to do. If a driver (API) doesn't allow this in a clean way, it's
> worthless!

I think you are overreacting here. Worthless is a strong word. Yes, it
imo also a major flaw, but it does not make the driver worthless, just
more cumbersome to use. In all honesty, having this as a user setting,
it would only need to be set once, which hardly qualify as hard work.
Try being a bit more friendly. Calling something worthless because of
a relatively small feature-lack is not.

> I don't care if this is a specific or a general flag, as long as
> it allows the application to clearly find out the kind of hardware
> that's available. It leaves me dumbfounded that this is suddenly
> such a big problem...

This has not suddenly become a big problem. The problem has been there
the whole time, it's just you and others making this into a big
problem. Really it is not. Of course everyone this fixed. Having a
good discussion about it is the best way of achieving that.

> You are not alone in that boat my friend.  Especially after reading
> the comments about how "thought out" the api is.  How could you
> possibly miss such a fundamental element?!

Stuff gets left out sometimes. I bet you forgot something sometime as
well. This is done by humans.

>> <conspiracy_theory><sarcasm>
>> Or is the S2API already "dead", and it's sole purpose was to
>> prevent "multiproto" to make its way into the kernel? And now that
>> this has been achieved, nodody really cares whether it can be used
>> in real life?
>> </sarcasm></conspiracy_theory>
>
> Hey, stranger things have happened.  Not much surprised me these days.
>  Hopefully somebody will get this sorted out and fixed very soon as it
> shouldn't even be an issue at this point!!

This is just ridiculous and has no place on this mailing list. I hope
that if you think about it, you will agree.

> From my personal POV. I think S2API isn't missing something concerning
> tuning.

If someone is missing a feature that obviously should be supported,
then something is missing. If you do not need that feature I guess
that is good for you :-)


Regarding the actual problem, I have never been happy with the
"FE_QPSK" and "FE_OFDM" enum fe_types. This imho does not make much
sense. I would like to know what a card is supposed to receive. One
modulation type is not locked to a transmission medium, nor frequency
range, and QPSK can easily be used in a cable network if one wished to
do so. I second the proposed solution of Artem, but I would do it with
a twist.

If possible, I would keep the old system for backwards compatibility,
and create a different command where this confusing QPSK/OFDM/QAM gets
removed altogether. I would have a enum frontend type that would
indicate what standard is being followed, if any. An additional
indication of all the different modulation types that is supported is
a must. In addition to what Artem proposed, I would like to be able to
read a supported frequency range ( i.e 950-2150 for satellite tuners
), and supported symbol rates. The last part there about symbol rate
could be different for different modulation types. Most people would
not need this, but some do. I don't think I have a good solution for
how one would solve that, but one way would be if you could do as with
the ca_types supported that is returned from different CAMs. One could
return a list of stucts with modulation types and their respective
limits and parameters. I don't know if this is really useful, but I
remember that on some of the satellite modems we used, the symbol rate
was limited by the center frequency of the carrier. If you got to
close to the max and min, the carrier bandwidth would have to be
reduced. There might be some equipment out there that has such
limitations, and it could be worth adding support for that I guess.

-Morgan-

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Alex Betis]

[-- Attachment #1.1: Type: text/plain, Size: 2318 bytes --]

On Tue, Nov 25, 2008 at 8:34 PM, Morgan Tørvolt <morgan.torvolt@gmail.com>wrote:

> Regarding the actual problem, I have never been happy with the
> "FE_QPSK" and "FE_OFDM" enum fe_types. This imho does not make much
> sense. I would like to know what a card is supposed to receive. One
> modulation type is not locked to a transmission medium, nor frequency
> range, and QPSK can easily be used in a cable network if one wished to
> do so. I second the proposed solution of Artem, but I would do it with
> a twist.
>
> If possible, I would keep the old system for backwards compatibility,
> and create a different command where this confusing QPSK/OFDM/QAM gets
> removed altogether. I would have a enum frontend type that would
> indicate what standard is being followed, if any. An additional
> indication of all the different modulation types that is supported is
> a must. In addition to what Artem proposed, I would like to be able to
> read a supported frequency range ( i.e 950-2150 for satellite tuners
> ), and supported symbol rates. The last part there about symbol rate
> could be different for different modulation types. Most people would
> not need this, but some do. I don't think I have a good solution for
> how one would solve that, but one way would be if you could do as with
> the ca_types supported that is returned from different CAMs. One could
> return a list of stucts with modulation types and their respective
> limits and parameters. I don't know if this is really useful, but I
> remember that on some of the satellite modems we used, the symbol rate
> was limited by the center frequency of the carrier. If you got to
> close to the max and min, the carrier bandwidth would have to be
> reduced. There might be some equipment out there that has such
> limitations, and it could be worth adding support for that I guess.

If we're talking(writing) about enhanced capabilities, I'll throw my 2 cents
as well...
The driver has to return what settings it will accept in tune command (or
maybe other commands as well).
For example, there is a chipset (don't remember the name) that doesn't
support AUTO settings for modulation, FEC and rolloff.
If that info will be available to the application (such as scan I'm dealing
with), it will be very useful.

[-- Attachment #1.2: Type: text/html, Size: 2718 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[hermann pitton]

Hi,

Am Dienstag, den 25.11.2008, 10:05 +0100 schrieb Klaus Schmidinger:
> On 25.11.2008 09:46, Niels Wagenaar wrote:
> > Op Ma, 24 november, 2008 20:33, schreef Manu Abraham:
> >> Klaus Schmidinger wrote:
> >>> On 24.11.2008 16:55, Niels Wagenaar wrote:
> >>>> ...
> >>>> For the time being I have only two options which will work without any
> >>>> additional patching in S2API:
> >>>>
> >>>> - Let the user set this as an option
> >>>> - Use my VUP (very ugly patch) by checking the deliverystem for the
> >>>> string
> >>>> "DVBS2".
> >>> Both are ugly workarounds and any reasonable API requiring them instead
> >>> of simply reporting the -S2 capability of a device should
> >>> be ashamed, go home and do its homework.
> >> ACK
> >>
> > 
> > And still, I see many popular/free/commercial DVB software on the Windows
> > platform where you need to select the DVB-S2 option on the DVB-card. So I
> > wouldn't just throw away this option as an ugly work-around.
> > 
> > In fact, I would like to set the specific type for my DVB cards if I
> > could. So an override option is definately not a ugly work-around and for
> > several people this will not be problem.
> > 
> > But, the other option is definately a very ugly work-around. But then
> > again, it works ;)
> > 
> >>> For the time being I'll work with my suggested FE_CAN_2ND_GEN_MODULATION
> >>> patch - until somebody can suggest a different way of doing this
> >>> (without
> >>> parsing strings or requiring the user to do it).
> >> ACK.
> >>
> >> That is a saner way of doing it rather than anything else, as it stands.
> >>
> >> Anyway, we won't be seeing professional device support as it stands with
> >> the current API anytime soon, so as it stands the better alternative is
> >> thus.
> >>
> >> But it would be nice to have something shorter: say FE_IS_2G or
> >> something that way, for the minimal typing.
> >>
> > 
> > I disagree on both of the proposals. Add an other flag is indeed the way
> > (I ACK that), but not a general one like you both proposed. When DVB-T2
> > (or DVB-S3 or DVB-C2 or whatever new enhancement of past DVB standards)
> > becomes mainstream we get the exact same discussion again.
> > 
> > IMHO, an non-general flag like FE_CAN_DVBT, FE_CAN_DVBS, FE_CAN_DVBS2,
> > FE_CAN_DVBC, etc would be more clearer. Since it's an DVB standard, it
> > must support certain modulation types, etc. So if the driver set its
> > frontendtype to FE_CAN_DVBT, you know for sure what tuning types it
> > supports.
> > 
> > But it al depends if people want to add this in the v4l driver also. If
> > they don't, it doesn't matter which proposal or patch makes it. And for
> > that a manual override or setting would become very handy.
> > 
> >> Regards,
> >> Manu
> >>
> > 
> > Look, I'm not an developer perse and you can ignore what I just wrote. But
> > my logic tells me that an manual override or a non-general FE_CAN flag for
> > the current DVB standards is a very clean sollution. Just my € 0,02.
> 
> I find it a completely unacceptable thing to have the user tell
> the application what type of DVB devices the hardware provides.
> This is pretty much the first and simplest thing the *DRIVER* has
> to do. If a driver (API) doesn't allow this in a clean way, it's
> worthless!

the "superior" _other_ stuff hangs in it too and much more.

> I don't care if this is a specific or a general flag, as long as
> it allows the application to clearly find out the kind of hardware
> that's available. It leaves me dumbfounded that this is suddenly
> such a big problem...
> 
> If my proposal is not acceptable, then please can one of the S2API
> experts come up with a solution that better fits the S2API way of
> thinking?

Steven did not work on S2API for fun, he was excluded from multiproto
over years, and tried all previously to overcome this.

He might have a break currently, but if you want your patches reviewed
and included, Manu can forward them as well for you, or you try to post
to Mauro directly too, since he is often in delay reading the lists, but
that won't make any difference, since he will ask for feedback from all
involved anyway, before applying patches. Believe it or not.

> <conspiracy_theory><sarcasm>
> Or is the S2API already "dead", and it's sole purpose was to
> prevent "multiproto" to make its way into the kernel? And now that
> this has been achieved, nodody really cares whether it can be used
> in real life?
> </sarcasm></conspiracy_theory>
> 
> Klaus
> 

Cheers,
Hermann



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Seppo Ingalsuo]

Morgan Tørvolt wrote:
> In all honesty, having this as a user setting,
> it would only need to be set once, which hardly qualify as hard work.
>   
I fully support Klaus' opinion. My motherboard bios and udev initialize 
my three DVB cards into "random" order that is depending whether the 
boot was cold or warm. Application level setting of dvbN device 
capabilities would not work for me reliably.

Best Regards,
Seppo


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Christophe Thommeret]

Le mercredi 26 novembre 2008 20:45:36 Seppo Ingalsuo, vous avez écrit :
> Morgan Tørvolt wrote:
> > In all honesty, having this as a user setting,
> > it would only need to be set once, which hardly qualify as hard work.
>
> I fully support Klaus' opinion. My motherboard bios and udev initialize
> my three DVB cards into "random" order that is depending whether the
> boot was cold or warm. Application level setting of dvbN device
> capabilities would not work for me reliably.

Since there is no way to uniquely identify a device, your problem could 
remain.
Anyway, i agree that querying such capabilities (and more in future) is 
needed.
Just a matter of time.
Klaus' proposal would work, but i'm not sure it's the right way, looks old 
fashion. I think the right way is to use the new API. Steven already had ideas 
in this matter but was too buzy. Let's hope he comes soon on this issue. 
(maybe end of week)

-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Udo Richter]

Artem Makhutov wrote:
> Klaus Schmidinger schrieb:
>> 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_8PSK
> FE_CAN_16APSK
> FE_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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Alex Betis]

[-- Attachment #1.1: Type: text/plain, Size: 1249 bytes --]

On Wed, Nov 26, 2008 at 11:56 PM, Udo Richter <udo_richter@gmx.de> wrote:

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

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.

[-- Attachment #1.2: Type: text/html, Size: 1616 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Artem Makhutov]

Hi,

On Wed, Nov 26, 2008 at 10:56:05PM +0100, Udo Richter wrote:
> Artem Makhutov wrote:
> > Klaus Schmidinger schrieb:
> >> 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_8PSK
> > FE_CAN_16APSK
> > FE_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.

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[VDR User]

Does anyone here actually disagree that the approach multiproto takes
is a great solution that should be adopted (if possible)?

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Andy Walls]

On Thu, 2008-11-27 at 06:08 -0800, VDR User wrote:
> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[VDR User]

On Thu, Nov 27, 2008 at 7:21 AM, Andy Walls <awalls@radix.net> wrote:
> On Thu, 2008-11-27 at 06:08 -0800, VDR User wrote:
>> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[CityK]

VDR User wrote:
> This conversation is about addressing and finding a solution
> to a problem.  

Agreed.

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

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

> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Igor M. Liplianin]

В сообщении от 27 November 2008 17:21:33 Andy Walls написал(а):
> On Thu, 2008-11-27 at 06:08 -0800, VDR User wrote:
> > 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.

>
>
> 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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[hermann pitton]

Am Donnerstag, den 27.11.2008, 09:19 -0800 schrieb VDR User:
> On Thu, Nov 27, 2008 at 7:21 AM, Andy Walls <awalls@radix.net> wrote:
> > On Thu, 2008-11-27 at 06:08 -0800, VDR User wrote:
> >> 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.

Yes, after all, we know for sure Andy is a troll.

Go away.

> 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
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Andy Walls]

On Thu, 2008-11-27 at 09:19 -0800, VDR User wrote: 
> On Thu, Nov 27, 2008 at 7:21 AM, Andy Walls <awalls@radix.net> wrote:
> > On Thu, 2008-11-27 at 06:08 -0800, VDR User wrote:
> >> 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.

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.


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


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


> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[hermann pitton]

Am Donnerstag, den 27.11.2008, 14:20 -0500 schrieb CityK:
> VDR User wrote:
> > This conversation is about addressing and finding a solution
> > to a problem.  
> 
> Agreed.
> 
> > 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.
> 
> > 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:

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[VDR User]

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Steven Toth]

Klaus Schmidinger wrote:
> 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 <Klaus.Schmidinger@cadsoft.de>

This looks good.

Acked-By: Steven Toth <stoth@linuxtv.org>

- Steve

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Thomas Creutz]

Artem Makhutov schrieb:
> 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).
> 
> 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...
> 

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Udo Richter]

On 26.11.2008 22:56, Udo Richter wrote:
> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Helmut Auer]

Hello Udo
> 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.
>
>
>   
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 :(

-- 
Helmut Auer, helmut@helmutauer.de 


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Mauro Carvalho Chehab]

On Thu, 25 Dec 2008 16:35:05 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> Hi,
> 
> Am Donnerstag, den 25.12.2008, 10:44 +0100 schrieb Helmut Auer:
> > Hello Udo
> > > 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.
> > >
> > >
> > >   
> > 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 :(
> > 
> 
> 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.
> 
> http://www.spinics.net/lists/linux-dvb/msg30817.html

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

> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Mauro Carvalho Chehab]

Hi Kaus,
On Wed, 31 Dec 2008 12:52:06 +0100
Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote:

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

> 
> diff -ru linux/drivers/media/dvb/frontends/cx24116.c linux/drivers/media/dvb/frontends/cx24116.c
> --- linux/drivers/media/dvb/frontends/cx24116.c	2008-11-21 23:00:55.000000000 +0100
> +++ linux/drivers/media/dvb/frontends/cx24116.c	2008-11-23 11:36:31.000000000 +0100
> @@ -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.c linux/drivers/media/dvb/frontends/stb0899_drv.c
> --- linux/drivers/media/dvb/frontends/stb0899_drv.c	2008-11-21 23:00:55.000000000 +0100
> +++ linux/drivers/media/dvb/frontends/stb0899_drv.c	2008-11-23 11:37:01.000000000 +0100
> @@ -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.h linux/include/linux/dvb/frontend.h
> --- linux/include/linux/dvb/frontend.h	2008-11-21 23:00:55.000000000 +0100
> +++ linux/include/linux/dvb/frontend.h	2008-11-23 11:27:21.000000000 +0100
> @@ -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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Gregoire Favre]

On Wed, Dec 31, 2008 at 12:52:06PM +0100, Klaus Schmidinger wrote:

Then vdr-1.7.2 should also be patched :-)

> I just used the same comment characters as the other lines that were
> already there ;-)
> 
> Klaus

> diff -ru linux/drivers/media/dvb/frontends/cx24116.c linux/drivers/media/dvb/frontends/cx24116.c
> --- linux/drivers/media/dvb/frontends/cx24116.c	2008-11-21 23:00:55.000000000 +0100
> +++ linux/drivers/media/dvb/frontends/cx24116.c	2008-11-23 11:36:31.000000000 +0100
> @@ -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.c linux/drivers/media/dvb/frontends/stb0899_drv.c
> --- linux/drivers/media/dvb/frontends/stb0899_drv.c	2008-11-21 23:00:55.000000000 +0100
> +++ linux/drivers/media/dvb/frontends/stb0899_drv.c	2008-11-23 11:37:01.000000000 +0100
> @@ -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.h linux/include/linux/dvb/frontend.h
> --- linux/include/linux/dvb/frontend.h	2008-11-21 23:00:55.000000000 +0100
> +++ linux/include/linux/dvb/frontend.h	2008-11-23 11:27:21.000000000 +0100
> @@ -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


-- 
Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org
               http://picasaweb.google.com/Gregoire.Favre

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Add missing S2 caps flag to S2API

[Mauro Carvalho Chehab]

On Wed, 31 Dec 2008 13:57:09 +0100
Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote:

> > 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb