Re: [linux-dvb] Future of DVB-S2

Re: [linux-dvb] Future of DVB-S2

[Jelle De Loecker]

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

Yet all we need is some clarification on what's going to happen in the 
future.

/Met vriendelijke groeten,/

*Jelle De Loecker*
Kipdola Studios - Tomberg



Hans Werner schreef:
>> An: linux-dvb@linuxtv.org, mchehab@infradead.org, v4l-dvb-maintainer@linuxtv.org
>> Betreff: [linux-dvb] Future of DVB-S2
>>     
>
>   
>> A question to the maintainer:
>>
>> what is your plan for getting DVB-S2 support into the mainline kernel?
>>
>> So many people have put so much time and effort into creating a working
>> API, drivers
>> and applications but I have seen no indications of the direction and
>> timescale anywhere.
>>
>> All this work is of very little value if it does not end up in the
>> mainline kernel. Maintaining
>> out-of-kernel projects and patches over the long term is a terrible waste
>> of effort for
>> maintainers, developers and experienced users. It also makes Linux DVB
>> look less than
>> professional, and is almost worthless to most end users.
>>
>> Working code already exists but it needs to be managed into a form that
>> can be merged
>> with the kernel.
>>
>> So how is it going to be done? It's really not that hard.
>>     
>
> Bump.
>
> It's disappointingly silent so far....
>
> In the interest of making progress I will be more specific.
>  
> It is easily possible to use the work that has already been done to quickly create (and debug
> and merge) kernel patches which will provide support for one or more DVB-S2 cards.
>
> But before such patches can be created,  there needs to be a clear statement about
> which API changes (if any) will be permitted.
>
> How will the API change? Who is going to make the decision? When?
>
> Hopefully,
> Hans
>
>   

[-- Attachment #1.2: Type: text/html, Size: 2400 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] Future of DVB-S2

[P. van Gaans]

On 08/23/2008 10:05 PM, Hans Werner wrote:
>> An: linux-dvb@linuxtv.org, mchehab@infradead.org, v4l-dvb-maintainer@linuxtv.org
>> Betreff: [linux-dvb] Future of DVB-S2
> 
>> A question to the maintainer:
>>
>> what is your plan for getting DVB-S2 support into the mainline kernel?
>>
>> So many people have put so much time and effort into creating a working
>> API, drivers
>> and applications but I have seen no indications of the direction and
>> timescale anywhere.
>>
>> All this work is of very little value if it does not end up in the
>> mainline kernel. Maintaining
>> out-of-kernel projects and patches over the long term is a terrible waste
>> of effort for
>> maintainers, developers and experienced users. It also makes Linux DVB
>> look less than
>> professional, and is almost worthless to most end users.
>>
>> Working code already exists but it needs to be managed into a form that
>> can be merged
>> with the kernel.
>>
>> So how is it going to be done? It's really not that hard.
> 
> Bump.
> 
> It's disappointingly silent so far....
> 
> In the interest of making progress I will be more specific.
>  
> It is easily possible to use the work that has already been done to quickly create (and debug
> and merge) kernel patches which will provide support for one or more DVB-S2 cards.
> 
> But before such patches can be created,  there needs to be a clear statement about
> which API changes (if any) will be permitted.
> 
> How will the API change? Who is going to make the decision? When?
> 
> Hopefully,
> Hans
> 

I agree. I wanted to write about this earlier but didn't find time yet.

I bought my TT S2-3200 august 2007, a little over 1 year ago. Look for a 
thread of mine called "[linux-dvb] TT S2-3200 stable, CI, go or no-go?". 
Here a now "funny" quote from Manu Abraham answering the question about 
when S2-support is coming to hg:

"Most probably, if all goes well sometime next month."

That was august 2007. So this obviously didn't happen.

He said this as well:

"Users need to have some amount of patience. The developers do this
mostly out of their free time. It is not that very simple to get
devices working properly. Users pressurizing the developers to release
early, brings in those half baked drivers, so a certain percentage of
the attributes go to the users as well.

It is not easy, when a user comes with a patch for something stating,
well this fixes issue "x" whereas in reality the patch has got nothing
to do with "x".

Moreover we have had just high noise levels alone rather than useful
talks, which hasd additional attributes for developments to crawl."

Okay, I understand that. But it's taking really long now.

Since multiproto exists, it must be known how to write a driver for the 
S2-3200 and similar cards. There are patches for the TT S2-3600/3650 
(USB) that I believe work quite well, but nothing it in-kernel or 
anywhere close getting in-kernel. I believe there is also seperate code 
for some other cards (mantis?).

Here are my thoughts:

I understood some stuff in multiproto is messy and that's why it's not 
getting in hg. And few if any people work on multiproto so it's not 
getting less messy. I would like to ask these questions:

Multiproto was made to support DVB-S2 and possibly some more stuff. Can 
multiproto easily be extended to support future protocols like DVB-T2, 
DVB-C2, DAB, DAB v2, FMeXtra, DMB and unknown future protocols? If the 
answer is NO, I believe even thoughts of getting multiproto to hg should 
be dropped immediately. Why?

Multiproto requires every userspace application to be changed to support 
it (and I heard the compatibility layer for non-S2 cards is a pain from 
dev-POV). The change may not be huge but it's quite a price to pay, and 
nobody wants to go through this again when another protocol becomes popular.

If the answer is "yes", a decision should be made:

DVB-S2 is getting more and more popular. Even with not too many DVB-S2 
streams being around yet, when you're buying a new card right now, you 
prefer to get DVB-S2 so you don't need to upgrade in the near future. 
DVB-S2 needs (in-kernel) support relatively quickly. We can't wait for 
multiproto for another 2 years. I see two options:


1. We decide multiproto is awesome, it's status is not that bad and the 
future path. Fix it and put it in hg.

2. Multiproto is NOT the way to go in the future, or it's too messed up 
and too much work to fix. In that case, forget about any other new 
protocol other than DVB-S2 and port the drivers for the DVB-S2 cards to 
hg. Also, make a small extension to v4l-dvb that makes it possible for 
an application to tell v4l-dvb that the upcoming frequency data is going 
to be DVB-S2 and it wants the tuner to go to DVB-S2 mode. If such a 
signal is NOT send, v4l-dvb should assume DVB-S so old unpatched 
applications work with new S2 cards. If applications want to support S2 
they will need to be patched to send the extra message, but some kind of 
patch for S2 for enduser apps is unavoidable anyway. It's no problem as 
long as unpatched apps can work with DVB-S. Apps will get patched soon 
enough as soon as S2 goes in-kernel.

If it helps, I am willing to have one of the main developers of 
linux-dvb borrow my TT S2-3200 to test stuff on. In fact, if some kind 
of promise for in-kernel support in the short term can be made, I'm 
willing to donate the card, because it is worthless to me right now.

P.

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

Re: [linux-dvb] Future of DVB-S2

[Jelle De Loecker]

P. van Gaans schreef:
> On 08/23/2008 10:05 PM, Hans Werner wrote:
>   
>>> An: linux-dvb@linuxtv.org, mchehab@infradead.org, v4l-dvb-maintainer@linuxtv.org
>>> Betreff: [linux-dvb] Future of DVB-S2
>>>       
>>> A question to the maintainer:
>>>
>>> what is your plan for getting DVB-S2 support into the mainline kernel?
>>>
>>> So many people have put so much time and effort into creating a working
>>> API, drivers and applications but I have seen no indications of the direction and timescale anywhere.
>>> All this work is of very little value if it does not end up in the
>>> mainline kernel. Maintaining out-of-kernel projects and patches over the long term is a terrible waste of effort for maintainers, developers and experienced users. It also makes Linux DVB look less than professional, and is almost worthless to most end users.
>>>
>>> Working code already exists but it needs to be managed into a form that can be merged with the kernel.
>>>       
>> It's disappointingly silent so far....
>>
>> ...
>>
>> Hopefully,
>> Hans
>>     
>
> I agree. I wanted to write about this earlier but didn't find time yet.
>
> ...
>
> [Manu] said this as well:
>
> "Users need to have some amount of patience. The developers do this
> mostly out of their free time. It is not that very simple to get
> devices working properly. Users pressurizing the developers to release
> early, brings in those half baked drivers, so a certain percentage of
> the attributes go to the users as well."
>
> Okay, I understand that. But it's taking really long now.
>
> Since multiproto exists, it must be known how to write a driver for the 
> S2-3200 and similar cards. There are patches for the TT S2-3600/3650 
> (USB) that I believe work quite well, but nothing it in-kernel or 
> anywhere close getting in-kernel. I believe there is also seperate code 
> for some other cards (mantis?).
>
> ...
>
> Multiproto requires every userspace application to be changed to support 
> it (and I heard the compatibility layer for non-S2 cards is a pain from 
> dev-POV). The change may not be huge but it's quite a price to pay, and 
> nobody wants to go through this again when another protocol becomes popular.
>
> If the answer is "yes", a decision should be made:
>
> DVB-S2 is getting more and more popular. Even with not too many DVB-S2 
> streams being around yet, when you're buying a new card right now, you 
> prefer to get DVB-S2 so you don't need to upgrade in the near future. 
> DVB-S2 needs (in-kernel) support relatively quickly. We can't wait for 
> multiproto for another 2 years. I see two options:
>
>
> 1. We decide multiproto is awesome, it's status is not that bad and the 
> future path. Fix it and put it in hg.
>
> 2. Multiproto is NOT the way to go in the future, or it's too messed up 
> and too much work to fix. In that case, forget about any other new 
> protocol other than DVB-S2 and port the drivers for the DVB-S2 cards to 
> hg. Apps will get patched soon enough as soon as S2 goes in-kernel.
>
> ...
>
> If it helps, I am willing to have one of the main developers of 
> linux-dvb borrow my TT S2-3200 to test stuff on. In fact, if some kind 
> of promise for in-kernel support in the short term can be made, I'm 
> willing to donate the card, because it is worthless to me right now.
>
> P.
>   
You're making excellent, valid points!

I just hope the developper understand US.
We know all about the "coding in your free time" and we can only have 
the highest respect for that, but the drivers are completely abandonded, 
and that's how we feel, too.

Forgive my ignorance, but wouldn't development have sped up 
siginificantly if multiproto had been integrated in hg?

Anyway, please, don't sacrifice your entire card!
I'd be willing to donate a bit, too. It's just way too important for me.





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

Re: [linux-dvb] Future of DVB-S2

[Steven Toth]

>> 1. We decide multiproto is awesome, it's status is not that bad and the 
>> future path. Fix it and put it in hg.
>>
>> 2. Multiproto is NOT the way to go in the future, or it's too messed up 
>> and too much work to fix. In that case, forget about any other new 
>> protocol other than DVB-S2 and port the drivers for the DVB-S2 cards to 
>> hg. Apps will get patched soon enough as soon as S2 goes in-kernel.

These aren't the only options.

> I just hope the developper understand US.

... and yes, many people understand you.

> We know all about the "coding in your free time" and we can only have 
> the highest respect for that, but the drivers are completely abandonded, 
> and that's how we feel, too.

No, and that's my HVR4000 code you're talking about (and the good work 
of Darron Broad, which was then picked up by Igor). The driver is 
marginalized, it's not abandoned.

The HVR4000 situation is under review, the wheels are slowly turning.... 
just not fast enough for many of you - I guess.

- Steve

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Hans Werner]

> ... and yes, many people understand you.

:) Thanks to everyone who replied so far. I am glad people care about this.

> > We know all about the "coding in your free time" and we can only have 
> > the highest respect for that, but the drivers are completely abandonded,
> > and that's how we feel, too.
> 
> No, and that's my HVR4000 code you're talking about (and the good work 
> of Darron Broad, which was then picked up by Igor). The driver is 
> marginalized, it's not abandoned.

I hope your and Darron's drivers (http://dev.kewl.org/hauppauge) are not seen as
marginalized. The multifrontend (MFE) patch by you and Darron is the driver that I
actually *use* for watching TV. It works nicely with Kaffeine without modification. And I,
for one, appreciate your sane approach and the simplicity of the techniques you used to
add DVB-S2 support (using sysctls for the SFE driver, and wrapping two ioctls to pull in
extra parameters for the MFE driver). If the kernel API is changed sensibly it should be
easy and quick to adapt your drivers to fit in.
 
> The HVR4000 situation is under review, the wheels are slowly turning.... 
If you are able to say anything about that I would be very interested.

Now, to show how simple I think all this could be, here is a PATCH implementing what
I think is the *minimal* API required to support DVB-S2.

Notes:

* same API structure, I just added some new enums and variables, nothing removed
* no changes required to any existing drivers (v4l-dvb still compiles)
* no changes required to existing applications (just need to be recompiled)
* no drivers, but I think the HVR4000 MFE patch could be easily adapted

I added the fe_caps2 enum because we're running out of bits in the capabilities bitfield.
More elegant would be to have separate bitfields for FEC capabilities and modulation
capabilities but that would require (easy) changes to (a lot of) drivers and applications.

Why should we not merge something simple like this immediately? This could have been done
years ago. If it takes several rounds of API upgrades to reach all the feature people want then
so be it, but a long journey begins with one step.

Regards.
Hans

diff -r a4843e1304e6 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.h	Sun Aug 24 12:28:11 2008 -0300
+++ b/linux/include/linux/dvb/frontend.h	Fri Aug 29 16:22:47 2008 +0100
@@ -36,6 +36,15 @@
 	FE_ATSC
 } fe_type_t;
 
+typedef enum fe_standard {
+	DVBS,
+	DVBS2,
+	DVBT,
+	DVBH,
+	DVBC,
+	DSS,
+	ATSC
+} fe_standard_t;
 
 typedef enum fe_caps {
 	FE_IS_STUPID			= 0,
@@ -67,6 +76,16 @@
 	FE_CAN_MUTE_TS			= 0x80000000  // frontend can stop spurious TS data output
 } fe_caps_t;
 
+typedef enum fe_caps2 {
+	FE_CAN_FEC_1_3			= 0x0,
+	FE_CAN_FEC_1_4			= 0x1,
+	FE_CAN_FEC_2_5			= 0x2,
+	FE_CAN_FEC_3_5			= 0x4,
+	FE_CAN_FEC_9_10			= 0x8,
+	FE_CAN_8PSK			= 0x10,
+	FE_CAN_16APSK			= 0x20,
+	FE_CAN_32APSK			= 0x40
+} fe_caps2_t;
 
 struct dvb_frontend_info {
 	char       name[128];
@@ -80,6 +99,7 @@
 	__u32      symbol_rate_tolerance;	/* ppm */
 	__u32      notifier_delay;		/* DEPRECATED */
 	fe_caps_t  caps;
+	fe_caps2_t caps2;
 };
 
 
@@ -140,19 +160,27 @@
 typedef enum fe_code_rate {
 	FEC_NONE = 0,
 	FEC_1_2,
+	FEC_1_3,
+	FEC_1_4,
 	FEC_2_3,
+	FEC_2_5,
 	FEC_3_4,
+	FEC_3_5,
 	FEC_4_5,
 	FEC_5_6,
 	FEC_6_7,
 	FEC_7_8,
 	FEC_8_9,
+	FEC_9_10,
 	FEC_AUTO
 } fe_code_rate_t;
 
 
 typedef enum fe_modulation {
 	QPSK,
+	PSK_8,
+	APSK_16,
+	APSK_32,
 	QAM_16,
 	QAM_32,
 	QAM_64,
@@ -194,10 +222,25 @@
 	HIERARCHY_AUTO
 } fe_hierarchy_t;
 
+typedef enum fe_rolloff {
+	ROLLOFF_035,
+	ROLLOFF_025,
+	ROLLOFF_020,
+	ROLLOFF_UNKNOWN
+} fe_rolloff_t;
+
+typedef enum fe_pilot {
+	PILOT_OFF,
+	PILOT_ON,
+	PILOT_AUTO
+} fe_pilot_t;
 
 struct dvb_qpsk_parameters {
 	__u32		symbol_rate;  /* symbol rate in Symbols per second */
 	fe_code_rate_t	fec_inner;    /* forward error correction (see above) */
+	fe_modulation_t	modulation;   /* DVB-S2 allows modulations QPSK plus 8PSK,16APSK,32APSK */
+	fe_rolloff_t 	rolloff;      /* for DVB-S2*/
+	fe_pilot_t	pilot;        /* for DVB-S2*/
 };
 
 struct dvb_qam_parameters {
@@ -225,6 +268,7 @@
 	__u32 frequency;     /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
 			     /* intermediate frequency in kHz for QPSK */
 	fe_spectral_inversion_t inversion;
+	fe_standard_t           standard;   /* use to set DVBS/DVBS2/DVBT etc */
 	union {
 		struct dvb_qpsk_parameters qpsk;
 		struct dvb_qam_parameters  qam;


-- 
Release early, release often. Really, you should.

GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Michael Krufky]

On Fri, Aug 29, 2008 at 11:43 AM, Hans Werner <HWerner4@gmx.de> wrote:
>> ... and yes, many people understand you.
>
> :) Thanks to everyone who replied so far. I am glad people care about this.
>
>> > We know all about the "coding in your free time" and we can only have
>> > the highest respect for that, but the drivers are completely abandonded,
>> > and that's how we feel, too.
>>
>> No, and that's my HVR4000 code you're talking about (and the good work
>> of Darron Broad, which was then picked up by Igor). The driver is
>> marginalized, it's not abandoned.
>
> I hope your and Darron's drivers (http://dev.kewl.org/hauppauge) are not seen as
> marginalized. The multifrontend (MFE) patch by you and Darron is the driver that I
> actually *use* for watching TV. It works nicely with Kaffeine without modification. And I,
> for one, appreciate your sane approach and the simplicity of the techniques you used to
> add DVB-S2 support (using sysctls for the SFE driver, and wrapping two ioctls to pull in
> extra parameters for the MFE driver). If the kernel API is changed sensibly it should be
> easy and quick to adapt your drivers to fit in.
>
>> The HVR4000 situation is under review, the wheels are slowly turning....
> If you are able to say anything about that I would be very interested.
>
> Now, to show how simple I think all this could be, here is a PATCH implementing what
> I think is the *minimal* API required to support DVB-S2.
>
> Notes:
>
> * same API structure, I just added some new enums and variables, nothing removed
> * no changes required to any existing drivers (v4l-dvb still compiles)
> * no changes required to existing applications (just need to be recompiled)
> * no drivers, but I think the HVR4000 MFE patch could be easily adapted
>
> I added the fe_caps2 enum because we're running out of bits in the capabilities bitfield.
> More elegant would be to have separate bitfields for FEC capabilities and modulation
> capabilities but that would require (easy) changes to (a lot of) drivers and applications.
>
> Why should we not merge something simple like this immediately? This could have been done
> years ago. If it takes several rounds of API upgrades to reach all the feature people want then
> so be it, but a long journey begins with one step.

This will break binary compatibility with existing apps.  You're right
-- those apps will work with a recompile, but I believe that as a
whole, the linux-dvb kernel and userspace developers alike are looking
to avoid breaking binary compatibility.

Regards,

Mike

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Steven Toth]

Michael Krufky wrote:
> On Fri, Aug 29, 2008 at 11:43 AM, Hans Werner <HWerner4@gmx.de> wrote:
>>> ... and yes, many people understand you.
>> :) Thanks to everyone who replied so far. I am glad people care about this.
>>
>>>> We know all about the "coding in your free time" and we can only have
>>>> the highest respect for that, but the drivers are completely abandonded,
>>>> and that's how we feel, too.
>>> No, and that's my HVR4000 code you're talking about (and the good work
>>> of Darron Broad, which was then picked up by Igor). The driver is
>>> marginalized, it's not abandoned.
>> I hope your and Darron's drivers (http://dev.kewl.org/hauppauge) are not seen as
>> marginalized. The multifrontend (MFE) patch by you and Darron is the driver that I
>> actually *use* for watching TV. It works nicely with Kaffeine without modification. And I,
>> for one, appreciate your sane approach and the simplicity of the techniques you used to
>> add DVB-S2 support (using sysctls for the SFE driver, and wrapping two ioctls to pull in
>> extra parameters for the MFE driver). If the kernel API is changed sensibly it should be
>> easy and quick to adapt your drivers to fit in.
>>
>>> The HVR4000 situation is under review, the wheels are slowly turning....
>> If you are able to say anything about that I would be very interested.
>>
>> Now, to show how simple I think all this could be, here is a PATCH implementing what
>> I think is the *minimal* API required to support DVB-S2.
>>
>> Notes:
>>
>> * same API structure, I just added some new enums and variables, nothing removed
>> * no changes required to any existing drivers (v4l-dvb still compiles)
>> * no changes required to existing applications (just need to be recompiled)
>> * no drivers, but I think the HVR4000 MFE patch could be easily adapted
>>
>> I added the fe_caps2 enum because we're running out of bits in the capabilities bitfield.
>> More elegant would be to have separate bitfields for FEC capabilities and modulation
>> capabilities but that would require (easy) changes to (a lot of) drivers and applications.
>>
>> Why should we not merge something simple like this immediately? This could have been done
>> years ago. If it takes several rounds of API upgrades to reach all the feature people want then
>> so be it, but a long journey begins with one step.
> 
> This will break binary compatibility with existing apps.  You're right
> -- those apps will work with a recompile, but I believe that as a
> whole, the linux-dvb kernel and userspace developers alike are looking
> to avoid breaking binary compatibility.

Hans, thanks for your kind words.

I've seen patches similar to this from a number of people, but this only 
solves today's problem, it doesn't help with ISDB-T, DVB-H, CMMB, 
ATSC-MH etc.

As mkrufky says, it also breaks compatibility.

... as I say, the wheels are turning so keep watching this mailing list.

- Steve


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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Hans Werner]

> >> I hope your and Darron's drivers (http://dev.kewl.org/hauppauge) are
> not seen as
> >> marginalized. The multifrontend (MFE) patch by you and Darron is the
> driver that I
> >> actually *use* for watching TV. It works nicely with Kaffeine without
> modification. And I,
> >> for one, appreciate your sane approach and the simplicity of the
> techniques you used to
> >> add DVB-S2 support (using sysctls for the SFE driver, and wrapping two
> ioctls to pull in
> >> extra parameters for the MFE driver). If the kernel API is changed
> sensibly it should be
> >> easy and quick to adapt your drivers to fit in.
> >>
> >>> The HVR4000 situation is under review, the wheels are slowly
> turning....
> >> If you are able to say anything about that I would be very interested.
> >>
> >> Now, to show how simple I think all this could be, here is a PATCH
> implementing what
> >> I think is the *minimal* API required to support DVB-S2.
> >>
> >> Notes:
> >>
> >> * same API structure, I just added some new enums and variables,
> nothing removed
> >> * no changes required to any existing drivers (v4l-dvb still compiles)
> >> * no changes required to existing applications (just need to be
> recompiled)
> >> * no drivers, but I think the HVR4000 MFE patch could be easily adapted
> >>

> >>
> >> Why should we not merge something simple like this immediately? This
> could have been done
> >> years ago. If it takes several rounds of API upgrades to reach all the
> feature people want then
> >> so be it, but a long journey begins with one step.
> > 
> > This will break binary compatibility with existing apps.  You're right
> > -- those apps will work with a recompile, but I believe that as a
> > whole, the linux-dvb kernel and userspace developers alike are looking
> > to avoid breaking binary compatibility.
> 

> Hans, thanks for your kind words.

You're welcome.

> I've seen patches similar to this from a number of people

Good, it was faster to write it than search for someone else's.

> but this only 
> solves today's problem, it doesn't help with ISDB-T, DVB-H, CMMB, 
> ATSC-MH etc.

I think today's problem (really yesterday's) is large enough to justify being solved 
-- DVB-S2 hardware is now very common amongst end users and popular and drivers
are written and working. It would allow most of the out-of-kernel drivers to be merged
wouldn't it?

Of course it would be nicer to support lots of other hardware but so far nobody has
merged the more capable multiproto API. It seems to be too big a pill to swallow.

Even if a more capable API were merged today, it would be unwise to consider the API 
fixed forever. It will need to continue to change as new hardware standards are developed.
Three of the four standards you mentioned are not even explicitly supported in multiproto
(is ATSC-M/H even final?). Anyway, perhaps by concentrating on solving the current problems
we can create an example and precedent of how to complete API upgrades successfully
without going off the rails for years.

> ... as I say, the wheels are turning so keep watching this mailing list.

Tantalising.... Do you mean you and Darron are working on something? Or you 
know of something else specific?

Hans

-- 
Release early, release often. Really, you should.

GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Steven Toth]

> 
>> ... as I say, the wheels are turning so keep watching this mailing list.
> 
> Tantalising.... Do you mean you and Darron are working on something? Or you 
> know of something else specific?

You should of seen a bigger DVB-S2 multiproto statement on list ML by now.

- Steve

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Hans Werner]

> > Now, to show how simple I think all this could be, here is a PATCH
> implementing what
> > I think is the *minimal* API required to support DVB-S2.
> >
> > Notes:
> >
> > * same API structure, I just added some new enums and variables, nothing
> removed
> > * no changes required to any existing drivers (v4l-dvb still compiles)
> > * no changes required to existing applications (just need to be
> recompiled)
> > * no drivers, but I think the HVR4000 MFE patch could be easily adapted
> >
> > I added the fe_caps2 enum because we're running out of bits in the
> capabilities bitfield.
> > More elegant would be to have separate bitfields for FEC capabilities
> and modulation
> > capabilities but that would require (easy) changes to (a lot of) drivers
> and applications.
> >
> > Why should we not merge something simple like this immediately? This
> could have been done
> > years ago. If it takes several rounds of API upgrades to reach all the
> feature people want then
> > so be it, but a long journey begins with one step.
> 
> This will break binary compatibility with existing apps.  You're right
> -- those apps will work with a recompile, but I believe that as a
> whole, the linux-dvb kernel and userspace developers alike are looking
> to avoid breaking binary compatibility.

Michael,
thank you for your comment.

I understand, but I think binary compatibility *should* be broken in this case. It makes
everything else simpler.

I know that not breaking binary compatibility *can* be done (as in the HVR4000 SFE and
MFE patches) but at what cost?  The resulting code is very odd. Look at multiproto which 
bizarrely implements both the 3.2 and the 3.3 API and a compatibility layer as well, at huge cost
in terms of development time and complexity of understanding. The wrappers used in the MFE
patches are a neat and simple trick, but not something you would release in the kernel.

If you take the position the binary interface cannot *ever* change then you are severely
restricting the changes that can be made and you doom yourself to an API that is no longer
suited to the job. And the complexity kills. As we have seen, it makes the whole process grind to a
halt. 

Recompilation is not a big deal. All distros recompile every application for each release (in fact much more frequently -- updates too), so most users will never even notice.  It is much better to make the right, elegant changes to the API and require a recompilation. It's better for the application developers because they get a sane evolution of the API and can more easily add new features. Anyone who
really cannot recompile existing userspace binaries will also have plenty of other restrictions and
should not be trying to drop a new kernel into a fixed userspace.

I would be interested to hear your opinion on how we can move forward rapidly.

Regards,
Hans

-- 
Release early, release often. Really, you should.

GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Jelle De Loecker]

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

I wasn't really focusing the haupage drivers, more the multiproto 
drivers manu created.

I have a TT S2-3200.

You're talking about upcoming change in the HVR4000 world? Do you know 
anything about our little technotrend cards?

/Met vriendelijke groeten,/

*Jelle De Loecker*
Kipdola Studios - Tomberg



Hans Werner schreef:
>>> Now, to show how simple I think all this could be, here is a PATCH
>>>       
>> implementing what
>>     
>>> I think is the *minimal* API required to support DVB-S2.
>>>
>>> Notes:
>>>
>>> * same API structure, I just added some new enums and variables, nothing
>>>       
>> removed
>>     
>>> * no changes required to any existing drivers (v4l-dvb still compiles)
>>> * no changes required to existing applications (just need to be
>>>       
>> recompiled)
>>     
>>> * no drivers, but I think the HVR4000 MFE patch could be easily adapted
>>>
>>> I added the fe_caps2 enum because we're running out of bits in the
>>>       
>> capabilities bitfield.
>>     
>>> More elegant would be to have separate bitfields for FEC capabilities
>>>       
>> and modulation
>>     
>>> capabilities but that would require (easy) changes to (a lot of) drivers
>>>       
>> and applications.
>>     
>>> Why should we not merge something simple like this immediately? This
>>>       
>> could have been done
>>     
>>> years ago. If it takes several rounds of API upgrades to reach all the
>>>       
>> feature people want then
>>     
>>> so be it, but a long journey begins with one step.
>>>       
>> This will break binary compatibility with existing apps.  You're right
>> -- those apps will work with a recompile, but I believe that as a
>> whole, the linux-dvb kernel and userspace developers alike are looking
>> to avoid breaking binary compatibility.
>>     
>
> Michael,
> thank you for your comment.
>
> I understand, but I think binary compatibility *should* be broken in this case. It makes
> everything else simpler.
>
> I know that not breaking binary compatibility *can* be done (as in the HVR4000 SFE and
> MFE patches) but at what cost?  The resulting code is very odd. Look at multiproto which 
> bizarrely implements both the 3.2 and the 3.3 API and a compatibility layer as well, at huge cost
> in terms of development time and complexity of understanding. The wrappers used in the MFE
> patches are a neat and simple trick, but not something you would release in the kernel.
>
> If you take the position the binary interface cannot *ever* change then you are severely
> restricting the changes that can be made and you doom yourself to an API that is no longer
> suited to the job. And the complexity kills. As we have seen, it makes the whole process grind to a
> halt. 
>
> Recompilation is not a big deal. All distros recompile every application for each release (in fact much more frequently -- updates too), so most users will never even notice.  It is much better to make the right, elegant changes to the API and require a recompilation. It's better for the application developers because they get a sane evolution of the API and can more easily add new features. Anyone who
> really cannot recompile existing userspace binaries will also have plenty of other restrictions and
> should not be trying to drop a new kernel into a fixed userspace.
>
> I would be interested to hear your opinion on how we can move forward rapidly.
>
> Regards,
> Hans
>
>   

[-- Attachment #1.2: Type: text/html, Size: 4538 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] Future of DVB-S2

[Hans Werner]

> 
> 
> Hans Werner schreef:
> >>> Now, to show how simple I think all this could be, here is a PATCH
> >>>       
> >> implementing what
> >>     
> >>> I think is the *minimal* API required to support DVB-S2.
> >>>
> >>> Notes:
> >>>
> >>> * same API structure, I just added some new enums and variables,
> nothing
> >>>       
> >> removed
> >>     
> >>> * no changes required to any existing drivers (v4l-dvb still compiles)
> >>> * no changes required to existing applications (just need to be
> >>>       
> >> recompiled)
> >>     
> >>> * no drivers, but I think the HVR4000 MFE patch could be easily
> adapted
> >>>
> >>> I added the fe_caps2 enum because we're running out of bits in the
> >>>       
> >> capabilities bitfield.
> >>     
> >>> More elegant would be to have separate bitfields for FEC capabilities
> >>>       
> >> and modulation
> >>     
> >>> capabilities but that would require (easy) changes to (a lot of)
> drivers
> >>>       
> >> and applications.
> >>     
> >>> Why should we not merge something simple like this immediately? This
> >>>       
> >> could have been done
> >>     
> >>> years ago. If it takes several rounds of API upgrades to reach all the
> >>>       
> >> feature people want then
> >>     
> >>> so be it, but a long journey begins with one step.
> >>>       
> >> This will break binary compatibility with existing apps.  You're right
> >> -- those apps will work with a recompile, but I believe that as a
> >> whole, the linux-dvb kernel and userspace developers alike are looking
> >> to avoid breaking binary compatibility.
> >>     
> >
> > Michael,
> > thank you for your comment.
> >
> > I understand, but I think binary compatibility *should* be broken in
> this case. It makes
> > everything else simpler.
> >
> > I know that not breaking binary compatibility *can* be done (as in the
> HVR4000 SFE and
> > MFE patches) but at what cost?  The resulting code is very odd. Look at
> multiproto which 
> > bizarrely implements both the 3.2 and the 3.3 API and a compatibility
> layer as well, at huge cost
> > in terms of development time and complexity of understanding. The
> wrappers used in the MFE
> > patches are a neat and simple trick, but not something you would release
> in the kernel.
> >
> > If you take the position the binary interface cannot *ever* change then
> you are severely
> > restricting the changes that can be made and you doom yourself to an API
> that is no longer
> > suited to the job. And the complexity kills. As we have seen, it makes
> the whole process grind to a
> > halt. 
> >
> > Recompilation is not a big deal. All distros recompile every application
> for each release (in fact much more frequently -- updates too), so most
> users will never even notice.  It is much better to make the right, elegant
> changes to the API and require a recompilation. It's better for the
> application developers because they get a sane evolution of the API and can more
> easily add new features. Anyone who
> > really cannot recompile existing userspace binaries will also have
> plenty of other restrictions and
> > should not be trying to drop a new kernel into a fixed userspace.
> >
> > I would be interested to hear your opinion on how we can move forward
> rapidly.
> >
> > Regards,
> > Hans
> >
> >   

Jelle De Loecker wrote up there and I moved it down here:
-------- Original-Nachricht --------
> Datum: Fri, 29 Aug 2008 18:50:23 +0200
> Von: Jelle De Loecker <skerit@kipdola.com>
> An: linux-dvb@linuxtv.org
> Betreff: Re: [linux-dvb] [PATCH] Future of DVB-S2

> I wasn't really focusing the haupage drivers, more the multiproto 
> drivers manu created.
> 
> I have a TT S2-3200.
> 
> You're talking about upcoming change in the HVR4000 world? Do you know 
> anything about our little technotrend cards?
> 
> /Met vriendelijke groeten,/
> 
> *Jelle De Loecker*
> Kipdola Studios - Tomberg
> 

Jelle,
yes I know you're interested in the TT S2-3200, but the issues are the same for all the DVB-S2
cards (which are already numerous and popular). There is a multiproto driver for the HVR4000 too,
but in addition there are some drivers written by Steven and Darron which take different (and 
illuminating) approaches to providing DVB-S2 support. Once the issues blocking DVB-S2 support 
in the kernel are sorted out we should hope that all the out-of-kernel DVB-S2 drivers will move
into the kernel quickly, including the TT S2-3200 driver.  We need to break the deadlock as soon
as possible.
Hans


-- 
Release early, release often. Really, you should

GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Steven Toth]

Jelle De Loecker wrote:
> I wasn't really focusing the haupage drivers, more the multiproto 
> drivers manu created.

ok.

> 
> I have a TT S2-3200.
> 
> You're talking about upcoming change in the HVR4000 world? Do you know 
> anything about our little technotrend cards?

I have one, if that's what you mean.

- Steve



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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Oliver Endriss]

Hans Werner wrote:
> 
> > > Now, to show how simple I think all this could be, here is a PATCH
> > implementing what
> > > I think is the *minimal* API required to support DVB-S2.
> > >
> > > Notes:
> > >
> > > * same API structure, I just added some new enums and variables, nothing
> > removed
> > > * no changes required to any existing drivers (v4l-dvb still compiles)
> > > * no changes required to existing applications (just need to be
> > recompiled)
> > > * no drivers, but I think the HVR4000 MFE patch could be easily adapted
> > >
> > > I added the fe_caps2 enum because we're running out of bits in the
> > capabilities bitfield.
> > > More elegant would be to have separate bitfields for FEC capabilities
> > and modulation
> > > capabilities but that would require (easy) changes to (a lot of) drivers
> > and applications.
> > >
> > > Why should we not merge something simple like this immediately? This
> > could have been done
> > > years ago. If it takes several rounds of API upgrades to reach all the
> > feature people want then
> > > so be it, but a long journey begins with one step.
> > 
> > This will break binary compatibility with existing apps.  You're right
> > -- those apps will work with a recompile, but I believe that as a
> > whole, the linux-dvb kernel and userspace developers alike are looking
> > to avoid breaking binary compatibility.
> 
> Michael,
> thank you for your comment.
> 
> I understand, but I think binary compatibility *should* be broken in this case. It makes
> everything else simpler.

No way. Breaking binary compatibility is a no-go.

> I know that not breaking binary compatibility *can* be done (as in the HVR4000 SFE and
> MFE patches) but at what cost?  The resulting code is very odd. Look at multiproto which 
> bizarrely implements both the 3.2 and the 3.3 API and a compatibility layer as well, at huge cost
> in terms of development time and complexity of understanding. The wrappers used in the MFE
> patches are a neat and simple trick, but not something you would release in the kernel.

The only way to support DVB-S2 in a reasonable way is adding a new API.
Multiproto does this.

> If you take the position the binary interface cannot *ever* change then you are severely
> restricting the changes that can be made and you doom yourself to an API that is no longer
> suited to the job. And the complexity kills. As we have seen, it makes the whole process grind to a
> halt. 
> 
> Recompilation is not a big deal. All distros recompile every application for each release (in fact much more frequently -- updates too), so most users will never even notice.  It is much better to make the right, elegant changes to the API and require a recompilation. It's better for the application developers because they get a sane evolution of the API and can more easily add new features. Anyone who
> really cannot recompile existing userspace binaries will also have plenty of other restrictions and
> should not be trying to drop a new kernel into a fixed userspace.

The linux distribution maintainers would kill you.
Applications must continue to run after a kernel update.

> I would be interested to hear your opinion on how we can move forward rapidly.

Multiproto should be merged asap.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Manu Abraham]

Oliver Endriss wrote:
> Hans Werner wrote:
>>>> Now, to show how simple I think all this could be, here is a PATCH
>>> implementing what
>>>> I think is the *minimal* API required to support DVB-S2.
>>>>
>>>> Notes:
>>>>
>>>> * same API structure, I just added some new enums and variables, nothing
>>> removed
>>>> * no changes required to any existing drivers (v4l-dvb still compiles)
>>>> * no changes required to existing applications (just need to be
>>> recompiled)
>>>> * no drivers, but I think the HVR4000 MFE patch could be easily adapted
>>>>
>>>> I added the fe_caps2 enum because we're running out of bits in the
>>> capabilities bitfield.
>>>> More elegant would be to have separate bitfields for FEC capabilities
>>> and modulation
>>>> capabilities but that would require (easy) changes to (a lot of) drivers
>>> and applications.
>>>> Why should we not merge something simple like this immediately? This
>>> could have been done
>>>> years ago. If it takes several rounds of API upgrades to reach all the
>>> feature people want then
>>>> so be it, but a long journey begins with one step.
>>> This will break binary compatibility with existing apps.  You're right
>>> -- those apps will work with a recompile, but I believe that as a
>>> whole, the linux-dvb kernel and userspace developers alike are looking
>>> to avoid breaking binary compatibility.
>> Michael,
>> thank you for your comment.
>>
>> I understand, but I think binary compatibility *should* be broken in this case. It makes
>> everything else simpler.
> 
> No way. Breaking binary compatibility is a no-go.
> 
>> I know that not breaking binary compatibility *can* be done (as in the HVR4000 SFE and
>> MFE patches) but at what cost?  The resulting code is very odd. Look at multiproto which 
>> bizarrely implements both the 3.2 and the 3.3 API and a compatibility layer as well, at huge cost
>> in terms of development time and complexity of understanding. The wrappers used in the MFE
>> patches are a neat and simple trick, but not something you would release in the kernel.
> 
> The only way to support DVB-S2 in a reasonable way is adding a new API.
> Multiproto does this.
> 
>> If you take the position the binary interface cannot *ever* change then you are severely
>> restricting the changes that can be made and you doom yourself to an API that is no longer
>> suited to the job. And the complexity kills. As we have seen, it makes the whole process grind to a
>> halt. 
>>
>> Recompilation is not a big deal. All distros recompile every application for each release (in fact much more frequently -- updates too), so most users will never even notice.  It is much better to make the right, elegant changes to the API and require a recompilation. It's better for the application developers because they get a sane evolution of the API and can more easily add new features. Anyone who
>> really cannot recompile existing userspace binaries will also have plenty of other restrictions and
>> should not be trying to drop a new kernel into a fixed userspace.
> 
> The linux distribution maintainers would kill you.
> Applications must continue to run after a kernel update.
> 
>> I would be interested to hear your opinion on how we can move forward rapidly.
> 
> Multiproto should be merged asap.


True. Sorry about the long delay, just got back after quite a long
journey. Will do so these following days.

Regards,
Manu

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

Re: [linux-dvb] [PATCH] Future of DVB-S2

[Jelle De Loecker]

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

Wait, where are you going to merge the multiproto drivers to? Am I 
reading it correct that you'll get them in the dvb-4vl tree or.. What am 
I missing here? :)

This has been one hell of a day!

/Met vriendelijke groeten,/

*Jelle De Loecker*
Kipdola Studios - Tomberg 


Manu Abraham schreef:
> Oliver Endriss wrote:
>   
>> Hans Werner wrote:
>>     
>>>>> Now, to show how simple I think all this could be, here is a PATCH
>>>>>           
>>>> implementing what
>>>>         
>>>>> I think is the *minimal* API required to support DVB-S2.
>>>>>
>>>>> Notes:
>>>>>
>>>>> * same API structure, I just added some new enums and variables, nothing
>>>>>           
>>>> removed
>>>>         
>>>>> * no changes required to any existing drivers (v4l-dvb still compiles)
>>>>> * no changes required to existing applications (just need to be
>>>>>           
>>>> recompiled)
>>>>         
>>>>> * no drivers, but I think the HVR4000 MFE patch could be easily adapted
>>>>>
>>>>> I added the fe_caps2 enum because we're running out of bits in the
>>>>>           
>>>> capabilities bitfield.
>>>>         
>>>>> More elegant would be to have separate bitfields for FEC capabilities
>>>>>           
>>>> and modulation
>>>>         
>>>>> capabilities but that would require (easy) changes to (a lot of) drivers
>>>>>           
>>>> and applications.
>>>>         
>>>>> Why should we not merge something simple like this immediately? This
>>>>>           
>>>> could have been done
>>>>         
>>>>> years ago. If it takes several rounds of API upgrades to reach all the
>>>>>           
>>>> feature people want then
>>>>         
>>>>> so be it, but a long journey begins with one step.
>>>>>           
>>>> This will break binary compatibility with existing apps.  You're right
>>>> -- those apps will work with a recompile, but I believe that as a
>>>> whole, the linux-dvb kernel and userspace developers alike are looking
>>>> to avoid breaking binary compatibility.
>>>>         
>>> Michael,
>>> thank you for your comment.
>>>
>>> I understand, but I think binary compatibility *should* be broken in this case. It makes
>>> everything else simpler.
>>>       
>> No way. Breaking binary compatibility is a no-go.
>>
>>     
>>> I know that not breaking binary compatibility *can* be done (as in the HVR4000 SFE and
>>> MFE patches) but at what cost?  The resulting code is very odd. Look at multiproto which 
>>> bizarrely implements both the 3.2 and the 3.3 API and a compatibility layer as well, at huge cost
>>> in terms of development time and complexity of understanding. The wrappers used in the MFE
>>> patches are a neat and simple trick, but not something you would release in the kernel.
>>>       
>> The only way to support DVB-S2 in a reasonable way is adding a new API.
>> Multiproto does this.
>>
>>     
>>> If you take the position the binary interface cannot *ever* change then you are severely
>>> restricting the changes that can be made and you doom yourself to an API that is no longer
>>> suited to the job. And the complexity kills. As we have seen, it makes the whole process grind to a
>>> halt. 
>>>
>>> Recompilation is not a big deal. All distros recompile every application for each release (in fact much more frequently -- updates too), so most users will never even notice.  It is much better to make the right, elegant changes to the API and require a recompilation. It's better for the application developers because they get a sane evolution of the API and can more easily add new features. Anyone who
>>> really cannot recompile existing userspace binaries will also have plenty of other restrictions and
>>> should not be trying to drop a new kernel into a fixed userspace.
>>>       
>> The linux distribution maintainers would kill you.
>> Applications must continue to run after a kernel update.
>>
>>     
>>> I would be interested to hear your opinion on how we can move forward rapidly.
>>>       
>> Multiproto should be merged asap.
>>     
>
>
> True. Sorry about the long delay, just got back after quite a long
> journey. Will do so these following days.
>
> Regards,
> Manu
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>   

[-- Attachment #1.2: Type: text/html, Size: 6002 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