[linux-dvb] [ANNOUNCE] DVB API improvements

[linux-dvb] [ANNOUNCE] DVB API improvements

[Mauro Carvalho Chehab]

After years of discussions, several patch series and two different proposed
approaches, LinuxTV developers finally decided that S2API is the better
technical proposal and should be accepted as the way to allow supporting newer
DTV standards, starting with DVB-S2.

As previously announced at http://linuxtv.org/news.php?entry=2008-09-19.mchehab,
a representative group of active developers at LinuxTV community attended the
first V4L/DVB Summit, that started with the V4L/DVB miniconf at Linux
Plumbers/2008. Several other additional formal (BOF's) and informal meetings
happened there, in the benefit of the improvement of the development of
multimedia drivers and core.

During the miniconf, both Multiproto API (proposed by Manu) and S2API (proposed
by Steven), were presented. A technical discussion was made during the DVB BOF
session in order to compare the two proposals and check for the
need/convenience of other core internal changes to draw an evolution timeline
for DVB.

The DVB BOF had the presence of the following LinuxTV members:

	Douglas Schilling Landgraf
	Hans Verkuil
	Mauro Carvalho Chehab 
	Michael Krufky
	Patrick Boettcher
	Steven Toth
	Thierry Merle
	Manjunath Hadlii

We had also a presence of an end-user listening to the BOF (Brandon Fouts).

During the BOF, the LinuxTV members carefully analyzed the pros and cons for
both proposals. At the end, all people present there agreed that S2API is
technically more reliable in time than Multiproto proposal. So it was decided
that S2API will be merged upstream.

The main arguments in favor of S2API over Multiproto are:

	- Future proof – the proposal for S2API is more flexible, easily
	  allowing the addition of newer features and new standard support;

	- Simplicity – S2API patches are very simple, while Multiproto
	  presented a very complex series of changes. Simpler approaches
	  reduces the time for maintaining the source code;

	- Capability of allowing improvements even on the existing standards,
	  like allowing diversity control that starts to appear on newer DVB
	  devices.

Some improvements were proposed by the LinuxTV developers, in order to improve
the S2API, including:

	- Adding an API command for querying DVB version, to allow an easier
	  detection by userspace applications;

	- Name the DVB API with S2API as DVB version 5;

	- Update DVB API documentation to reflect the API changes;

	- Remove from DVB API the unused API ioctls, to match the API with the
	  existing implementations.

The author of S2API got the task of adding those suggestions at the proposed
standard and send a pull request to the subsystem maintainer, together with
patches for his drivers that use the newer API.

It was also discussed that some of the internal Multiproto API changes may be
needed in other to support some of the other existing DVB-S2 drivers that were
developed considering Multiproto API. Internal changes can be added at any time
without producing problems in the user API.

The group aims to have a unified in-kernel DVB-S2 HVR4000 / TT-3200 tree (that
also supports all of the derivative CX24116 / STB0899 known products) within 4
weeks from the announcement, hopefully in time for kernel 2.6.28. For that, we
would like to ask Manu to port his drivers to the new API.

The end goal is to add proper support for all devices that would have been
supported by multiproto and S2API alike available.

There are already volunteers working or that have offered to work on Kaffeine
and MythTV S2API support.

We still need volunteers to work on dvb-apps support. If you feel that you like
contribute, please be our guest!

We would like to thank you all that contributed for those discussions and
improvements to happen,

Mauro Carvalho Chehab
V4L/DVB Maintainer 

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Janne Grunau]

On Wednesday 24 September 2008 00:06:59 VDR User wrote:
> On Tue, Sep 23, 2008 at 2:16 PM, Mauro Carvalho Chehab
>
> <mchehab@infradead.org> wrote:
> > The DVB BOF had the presence of the following LinuxTV members:
> >
> >        Douglas Schilling Landgraf
> >        Hans Verkuil
> >        Mauro Carvalho Chehab
> >        Michael Krufky
> >        Patrick Boettcher
> >        Steven Toth
> >        Thierry Merle
> >        Manjunath Hadlii
>
> At least half of that list already pledged their support for S2API
> and based on past observations, I seriously doubt the meeting was
> unbiased and a decision made based on strictly technical aspects.

So you doubt anyone who previously stated his opinion on multiproto or 
S2API is unable to make a decision on technical merrits? Since most 
linuxtv devs already gave their opinion on the API proposal nobody is 
able to make a decision. 

> I also believe the panel should consist of people intimately familiar
> with DVB, not half people who aren't and the other half people who've
> already made up their mind.  Call me crazy but I don't see how a
> legitimate discussion can take place under those conditions.

Are you going to sponser and organize a meeting of all linuxtv DVB 
developers?
I agree that it would have been nice if more developers and especially 
Manu would have been at the DVB BOF. But more than 2/3 (849/1245) of 
the commits to drivers/media/dvb in the last 1000 days were done by 
people present at the meeting. It's not completly unreasonable to treat 
a decision of that group as a decission of the linuxtv developers.

> > The main arguments in favor of S2API over Multiproto are:
> >
> >        - Future proof – the proposal for S2API is more flexible,
> > easily allowing the addition of newer features and new standard
> > support;
> >
> >        - Simplicity – S2API patches are very simple, while
> > Multiproto presented a very complex series of changes. Simpler
> > approaches reduces the time for maintaining the source code;
> >
> >        - Capability of allowing improvements even on the existing
> > standards, like allowing diversity control that starts to appear on
> > newer DVB devices.
>
> My previous comment aside, I would like to ask for a more detailed
> explanation that justifies these arguments,

I support that, please be more verbose.

Janne

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Markus Rechberger]

On Wed, Sep 24, 2008 at 2:36 AM, Janne Grunau <janne-dvb@grunau.be> wrote:
> On Wednesday 24 September 2008 00:06:59 VDR User wrote:
>> On Tue, Sep 23, 2008 at 2:16 PM, Mauro Carvalho Chehab
>>
>> <mchehab@infradead.org> wrote:
>> > The DVB BOF had the presence of the following LinuxTV members:
>> >
>> >        Douglas Schilling Landgraf
>> >        Hans Verkuil
>> >        Mauro Carvalho Chehab
>> >        Michael Krufky
>> >        Patrick Boettcher
>> >        Steven Toth
>> >        Thierry Merle
>> >        Manjunath Hadlii
>>
>> At least half of that list already pledged their support for S2API
>> and based on past observations, I seriously doubt the meeting was
>> unbiased and a decision made based on strictly technical aspects.
>
> So you doubt anyone who previously stated his opinion on multiproto or
> S2API is unable to make a decision on technical merrits? Since most
> linuxtv devs already gave their opinion on the API proposal nobody is
> able to make a decision.
>
>> I also believe the panel should consist of people intimately familiar
>> with DVB, not half people who aren't and the other half people who've
>> already made up their mind.  Call me crazy but I don't see how a
>> legitimate discussion can take place under those conditions.
>
> Are you going to sponser and organize a meeting of all linuxtv DVB
> developers?
> I agree that it would have been nice if more developers and especially
> Manu would have been at the DVB BOF. But more than 2/3 (849/1245) of
> the commits to drivers/media/dvb in the last 1000 days were done by
> people present at the meeting. It's not completly unreasonable to treat
> a decision of that group as a decission of the linuxtv developers.
>

sorry to strong reply here, what commits? I respect people who wrote
code on their own
eg. Thierry Merle. But there are just alot commits from other people too.
This also takes my code into account which got taken from my repository.
My code seems to be good enough for adding other copyrights and
hijacking the maintainership (! - em28xx-alsa
which got copied including the existing bugs back then).

Just don't make it up to those commits. A widely public technical
discussion can be done on the ML and
this should be the way to solve that issue.

1. S2API adds another question who's going to port the multiproto drivers
2. who's going to test them, since they are already supported by eg. vdr
3. I know Manu is working on upcoming devices, telling him to use the
S2API would mean to reinvent the wheel I guess, so
how to avoid that best.

>> > The main arguments in favor of S2API over Multiproto are:
>> >
>> >        - Future proof – the proposal for S2API is more flexible,
>> > easily allowing the addition of newer features and new standard
>> > support;
>> >
>> >        - Simplicity – S2API patches are very simple, while
>> > Multiproto presented a very complex series of changes. Simpler
>> > approaches reduces the time for maintaining the source code;
>> >
>> >        - Capability of allowing improvements even on the existing
>> > standards, like allowing diversity control that starts to appear on
>> > newer DVB devices.
>>
>> My previous comment aside, I would like to ask for a more detailed
>> explanation that justifies these arguments,
>
> I support that, please be more verbose.
>

I don't mind about which solution gets used actually, but the
technical part of it should either be more verbose
and not only be a Hauppauge Lab solution for _their_ current products
only, the multiproto drivers have been available
before already so they should be wisely taken into account in order to
not drop them and telling those people who worked
on it redo it.

Markus

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[hermann pitton]

Am Mittwoch, den 24.09.2008, 02:55 +0200 schrieb Markus Rechberger:
> On Wed, Sep 24, 2008 at 2:36 AM, Janne Grunau <janne-dvb@grunau.be> wrote:
> > On Wednesday 24 September 2008 00:06:59 VDR User wrote:
> >> On Tue, Sep 23, 2008 at 2:16 PM, Mauro Carvalho Chehab
> >>
> >> <mchehab@infradead.org> wrote:
> >> > The DVB BOF had the presence of the following LinuxTV members:
> >> >
> >> >        Douglas Schilling Landgraf
> >> >        Hans Verkuil
> >> >        Mauro Carvalho Chehab
> >> >        Michael Krufky
> >> >        Patrick Boettcher
> >> >        Steven Toth
> >> >        Thierry Merle
> >> >        Manjunath Hadlii
> >>
> >> At least half of that list already pledged their support for S2API
> >> and based on past observations, I seriously doubt the meeting was
> >> unbiased and a decision made based on strictly technical aspects.
> >
> > So you doubt anyone who previously stated his opinion on multiproto or
> > S2API is unable to make a decision on technical merrits? Since most
> > linuxtv devs already gave their opinion on the API proposal nobody is
> > able to make a decision.
> >
> >> I also believe the panel should consist of people intimately familiar
> >> with DVB, not half people who aren't and the other half people who've
> >> already made up their mind.  Call me crazy but I don't see how a
> >> legitimate discussion can take place under those conditions.
> >
> > Are you going to sponser and organize a meeting of all linuxtv DVB
> > developers?
> > I agree that it would have been nice if more developers and especially
> > Manu would have been at the DVB BOF. But more than 2/3 (849/1245) of
> > the commits to drivers/media/dvb in the last 1000 days were done by
> > people present at the meeting. It's not completly unreasonable to treat
> > a decision of that group as a decission of the linuxtv developers.
> >
> 
> sorry to strong reply here, what commits? I respect people who wrote
> code on their own
> eg. Thierry Merle. But there are just alot commits from other people too.
> This also takes my code into account which got taken from my repository.
> My code seems to be good enough for adding other copyrights and
> hijacking the maintainership (! - em28xx-alsa
> which got copied including the existing bugs back then).
> 
> Just don't make it up to those commits. A widely public technical
> discussion can be done on the ML and
> this should be the way to solve that issue.
> 
> 1. S2API adds another question who's going to port the multiproto drivers
> 2. who's going to test them, since they are already supported by eg. vdr
> 3. I know Manu is working on upcoming devices, telling him to use the
> S2API would mean to reinvent the wheel I guess, so
> how to avoid that best.
> 
> >> > The main arguments in favor of S2API over Multiproto are:
> >> >
> >> >        - Future proof – the proposal for S2API is more flexible,
> >> > easily allowing the addition of newer features and new standard
> >> > support;
> >> >
> >> >        - Simplicity – S2API patches are very simple, while
> >> > Multiproto presented a very complex series of changes. Simpler
> >> > approaches reduces the time for maintaining the source code;
> >> >
> >> >        - Capability of allowing improvements even on the existing
> >> > standards, like allowing diversity control that starts to appear on
> >> > newer DVB devices.
> >>
> >> My previous comment aside, I would like to ask for a more detailed
> >> explanation that justifies these arguments,
> >
> > I support that, please be more verbose.
> >
> 
> I don't mind about which solution gets used actually, but the
> technical part of it should either be more verbose
> and not only be a Hauppauge Lab solution for _their_ current products
> only, the multiproto drivers have been available
> before already so they should be wisely taken into account in order to
> not drop them and telling those people who worked
> on it redo it.
> 
> Markus
> 

Markus,

it is interesting, that you could not went trough with all of your stuff
at once, 94 patches or so, IIRC, and Manu was the one who tried to
explain to you, that this can't happen this way, since you affect other
drivers.

Short time later, Johannes and Oliver did open simple ways for you, you
came back with the same and asked Mauro to review it within 24 hours or
you would made up a major listing everywhere,  what lamers we are and
that this would immediately show, that you are the only one we need ...

It is still the same ...

By all respect, not that way.

Hermann





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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Janne Grunau]

On Wednesday 24 September 2008 02:55:48 Markus Rechberger wrote:
> On Wed, Sep 24, 2008 at 2:36 AM, Janne Grunau <janne-dvb@grunau.be> 
wrote:
> > I agree that it would have been nice if more developers and
> > especially Manu would have been at the DVB BOF. But more than 2/3
> > (849/1245) of the commits to drivers/media/dvb in the last 1000
> > days were done by people present at the meeting. It's not completly
> > unreasonable to treat a decision of that group as a decission of
> > the linuxtv developers.
>
> sorry to strong reply here, what commits? I respect people who wrote
> code on their own
> eg. Thierry Merle. But there are just alot commits from other people
> too. This also takes my code into account which got taken from my
> repository. My code seems to be good enough for adding other
> copyrights and hijacking the maintainership (! - em28xx-alsa
> which got copied including the existing bugs back then).
>
> Just don't make it up to those commits.

I've just counted commit to drivers/media/dvb, video/em28xx commits 
should be excluded. 

> A widely public technical 
> discussion can be done on the ML and
> this should be the way to solve that issue.

We can try to make that now based on on the second part of this mail to 
which I will reply seperately.

> 1. S2API adds another question who's going to port the multiproto
> drivers

I'm pretty sure that there are enough people to port exiting multiproto 
drivers if they are available under GPL 2.

> 2. who's going to test them, since they are already supported 
> by eg. vdr

Kaffeine supports the new API and there will be patches available for 
mythtv shortly. I'm certain we find enough users who would happily test 
DVB-S2 now. 

> 3. I know Manu is working on upcoming devices, telling him 
> to use the S2API would mean to reinvent the wheel I guess, so
> how to avoid that best.

if it is work in progress he should not need to reinvent the wheel. If 
it's already done porting the API is minor part of writing a driver and 
they will be people doing that work if the driver is available under 
GPL 2.

Janne

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Kristiadi Himawan]

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

Hi,

I want to buy DVB S2 card for my Freebsd machine, does anyone know which
card that already supported for Freebsd.

Thanks.

[-- Attachment #1.2: Type: text/html, Size: 165 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] [ANNOUNCE] DVB API improvements

[BOUWSMA Barry]

On Wed, 24 Sep 2008, Kristiadi Himawan wrote:

> I want to buy DVB S2 card for my Freebsd machine, does anyone know which
> card that already supported for Freebsd.

First of all, you are likely to get a better answer to your
question from the FreeBSD mailing list dedicated to multimedia
support at <multimedia@freebsd.org>, as this list is primarily
focused on Linux (which differs greatly from FreeBSD) or the
Linux-DVB API.

The Linux-DVB and Video4Linux APIen have not, to my knowledge,
been ported to FreeBSD.  The latter API has in fact been merged
into the NetBSD-current tree, and work on the former is underway
but has not yet been merged, so that there can be in-kernel
support at some later time in at least NetBSD, with the 
possibility of merging that into the other BSDen.

Thus any FreeBSD support now will be out-of-kernel, and in fact,
there was mention on the freebsd-multimedia@ list just a few
weeks ago on support for devices based on the CX2388x cards --
search for
Message-ID: <8103ad500809070610k24a0c3c0m981a0c0a82e392d8@mail.gmail.com>
posted on 07.September of this year, for an actual list of
devices which should be supported as well as a report on the
actual status of the support (I haven't looked for any later
messages than this from that week, though).  Apart from this,
supported devices are likely to be few and far between.


If this has not answered your question, then please redirect
it to the appropriate FreeBSD mailing list(s) to get a correct
and up-to-date response that is more relevant to your OS...


thanks,
barry bouwsma

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Patrick Boettcher]

Manu,

On Wed, 24 Sep 2008, Manu Abraham wrote:

> Mauro Carvalho Chehab wrote:
> [..]
>> The main arguments in favor of S2API over Multiproto are:
>>
>
> [..]
>
>> 	- Capability of allowing improvements even on the existing standards,
>> 	  like allowing diversity control that starts to appear on newer DVB
>> 	  devices.
>
>
> I just heard from Patrick, what he meant by this at the meeting and the
> reason why he voted for S2API, due to a fact that he was convinced
> incorrectly. Multiproto _already_has_ this implementation, while it is
> non-existant in S2API.

In order to not have people getting me wrong here, I'm stating now in 
public:

1) I like the idea of having diversity optionally controlled by the 
application.

2) My vote for S2API is final.

It is final, because the S2API is mainly affecting 
include/linux/dvb/frontend.h to add user-API support for new standards. I 
prefer the user-API of S2API over the one of multiproto because of 1).

All the other things around multiproto are dvb-core/dvb_frontend internal.
They have no relation with the user-interface. This I understood during 
the BOF, the microconf and the numberless talks we had around LPC.

Manu, it would be extremely good to have your modifications of 
dvb-core/dvb_frontend within the 4 weeks schedule in order to have the 
maximum number of hardware supported by that time. If you do not have the 
time to do that right now, I'm sure people are willing to help.

However - we can always change dvb_frontend/dvb-core internals at any time 
without breaking the user-interface.

best regards,
Patrick.

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Patrick Boettcher wrote:
> Manu,
> 
> On Wed, 24 Sep 2008, Manu Abraham wrote:
> 
>> Mauro Carvalho Chehab wrote:
>> [..]
>>> The main arguments in favor of S2API over Multiproto are:
>>>
>>
>> [..]
>>
>>>     - Capability of allowing improvements even on the existing
>>> standards,
>>>       like allowing diversity control that starts to appear on newer DVB
>>>       devices.
>>
>>
>> I just heard from Patrick, what he meant by this at the meeting and the
>> reason why he voted for S2API, due to a fact that he was convinced
>> incorrectly. Multiproto _already_has_ this implementation, while it is
>> non-existant in S2API.
> 
> In order to not have people getting me wrong here, I'm stating now in
> public:
> 
> 1) I like the idea of having diversity optionally controlled by the
> application.

You can add in a field for diversity in the relevant delivery system
data structure (in frontend.h) for it to be handled by the application
optionally, that shouldn't be an issue as far as i can see.


> 2) My vote for S2API is final.
> 
> It is final, because the S2API is mainly affecting
> include/linux/dvb/frontend.h to add user-API support for new standards.
> I prefer the user-API of S2API over the one of multiproto because of 1).
> 


Regards,
Manu


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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Patrick Boettcher wrote:
> Manu,
> 
> On Wed, 24 Sep 2008, Manu Abraham wrote:
> 
>> Mauro Carvalho Chehab wrote:
>> [..]
>>> The main arguments in favor of S2API over Multiproto are:
>>>
>>
>> [..]
>>
>>>     - Capability of allowing improvements even on the existing
>>> standards,
>>>       like allowing diversity control that starts to appear on newer DVB
>>>       devices.
>>
>>
>> I just heard from Patrick, what he meant by this at the meeting and the
>> reason why he voted for S2API, due to a fact that he was convinced
>> incorrectly. Multiproto _already_has_ this implementation, while it is
>> non-existant in S2API.
> 
> In order to not have people getting me wrong here, I'm stating now in
> public:
> 
> 1) I like the idea of having diversity optionally controlled by the
> application.
> 
> 2) My vote for S2API is final.
> 
> It is final, because the S2API is mainly affecting
> include/linux/dvb/frontend.h to add user-API support for new standards.
> I prefer the user-API of S2API over the one of multiproto because of 1).

After adding in diversity to frontend.h,

Would you prefer to update the diversity related event on the event list
as well ?


> All the other things around multiproto are dvb-core/dvb_frontend internal.
> They have no relation with the user-interface. This I understood during
> the BOF, the microconf and the numberless talks we had around LPC.
> 
> Manu, it would be extremely good to have your modifications of
> dvb-core/dvb_frontend within the 4 weeks schedule in order to have the
> maximum number of hardware supported by that time. If you do not have
> the time to do that right now, I'm sure people are willing to help.
> 
> However - we can always change dvb_frontend/dvb-core internals at any
> time without breaking the user-interface.


Since the very same can be achieved with multiproto without breaking the
user interface and without porting it to anything else, it makes much
sense to simply add in a field for diversity into the multiproto tree,
is it not ?


Regards,
Manu

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

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

Manu Abraham wrote:
> Patrick Boettcher wrote:
>> Manu,
>>
>> On Wed, 24 Sep 2008, Manu Abraham wrote:
>>
>>> Mauro Carvalho Chehab wrote:
>>> [..]
>>>> The main arguments in favor of S2API over Multiproto are:
>>>>
>>> [..]
>>>
>>>>     - Capability of allowing improvements even on the existing
>>>> standards,
>>>>       like allowing diversity control that starts to appear on newer DVB
>>>>       devices.
>>>
>>> I just heard from Patrick, what he meant by this at the meeting and the
>>> reason why he voted for S2API, due to a fact that he was convinced
>>> incorrectly. Multiproto _already_has_ this implementation, while it is
>>> non-existant in S2API.
>> In order to not have people getting me wrong here, I'm stating now in
>> public:
>>
>> 1) I like the idea of having diversity optionally controlled by the
>> application.
>>
>> 2) My vote for S2API is final.
>>
>> It is final, because the S2API is mainly affecting
>> include/linux/dvb/frontend.h to add user-API support for new standards.
>> I prefer the user-API of S2API over the one of multiproto because of 1).
> 
> After adding in diversity to frontend.h,
> 
> Would you prefer to update the diversity related event on the event list
> as well ?

Patch attached for the user space API to multiproto, it updates the
event list as well. If it looks ok, i will push this changeset out as well.


Regards,
Manu

[-- Attachment #2: diverisity.diff --]
[-- Type: text/x-patch, Size: 1291 bytes --]

--- multiproto.orig/linux/include/linux/dvb/frontend.h	2008-09-24 14:06:49.000000000 +0400
+++ multiproto/linux/include/linux/dvb/frontend.h	2008-09-24 14:58:02.000000000 +0400
@@ -466,6 +466,7 @@ struct dvbt_params {
 	enum dvbfe_hierarchy		hierarchy;
 	enum dvbfe_alpha		alpha;
 	enum dvbfe_stream_priority	priority;
+	__u8				diversity;
 
 	__u8				pad[32];
 };
@@ -502,6 +503,7 @@ struct dvbh_params {
 	enum dvbfe_mpefec		mpefec;
 	enum dvbfe_timeslicing		timeslicing;
 	enum dvbfe_stream_priority	priority;
+	__u8				diversity;
 
 	__u32				bandwidth;
 	__u8				pad[32];
@@ -566,6 +568,7 @@ struct dvbfe_dvbc_info {
 struct dvbfe_dvbt_info {
 	enum dvbfe_modulation		modulation;
 	enum dvbfe_stream_priority	stream_priority;
+	__u8				diversity;
 
 	__u8				pad[32];
 };
@@ -574,6 +577,7 @@ struct dvbfe_dvbt_info {
 struct dvbfe_dvbh_info {
 	enum dvbfe_modulation		modulation;
 	enum dvbfe_stream_priority	stream_priority;
+	__u8				diversity;
 
 	__u8				pad[32];
 };
@@ -623,6 +627,7 @@ enum dvbfe_status {
 	DVBFE_HAS_SYNC			= (1 <<  3),	/*  SYNC found			*/
 	DVBFE_HAS_LOCK			= (1 <<  4),	/*  OK ..			*/
 	DVBFE_TIMEDOUT			= (1 <<  5),	/*  no lock in last ~2 s	*/
+	DVBFE_DIVERSITY_TOGGLE		= (1 <<  6),    /* signal too low, toggling..	*/
 	DVBFE_STATUS_DUMMY		= (1 << 31)
 };
 

[-- 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] [ANNOUNCE] DVB API improvements

[Mauro Carvalho Chehab]

Manu,

On Wed, 24 Sep 2008, Manu Abraham wrote:

>> 2) My vote for S2API is final.
>>
>> It is final, because the S2API is mainly affecting
>> include/linux/dvb/frontend.h to add user-API support for new standards.
>> I prefer the user-API of S2API over the one of multiproto because of 1).
>
> After adding in diversity to frontend.h,
>
> Would you prefer to update the diversity related event on the event list
> as well ?

The decision were already taken by the group.

It should be noticed also that the public announcement took some time to 
be ready, since we all carefully reviewed it to reflect the understanding 
that the group had.

Both API's work, and people needed to choose between one of the proposals.

Each one there had enough time to read and understand each proposal, since 
the patches were available more than one week before the meeting, and
everybody were aware that the decision are scheduled to happen during LPC.

Each one voted based on their own technical analysis, on a meeting that 
took about 2:30 hours, on the day after the presentations. People had 
enough time there to discuss, explain their ideas with the help of a 
whiteboard, decide and improve the proposal.

S2API was choosen, since it was considered the better proposal for 
everybody there. None of the presents voted for Multiproto.

Now that the decision were already taken, it is not time anymore to argue 
in favor to any other proposals. We need to move ahead and finally add 
support for DVB-S2 and the remaining missing digital TV's at kernel.

Thank you and everyone else involved on adding support for the missing 
standards.

Let's move to the next step: finally add API changes and drivers for 
DVB-S2 and prepare support for the remaining missing standards.

Cheers,
Mauro

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Michael Krufky]

On Wed, Sep 24, 2008 at 10:01 PM, Markus Rechberger
<mrechberger@gmail.com> wrote:
> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
>> <mchehab@infradead.org> wrote:
>>> The decision were already taken by the group.
>>>
>>> It should be noticed also that the public announcement took some time to
>>> be ready, since we all carefully reviewed it to reflect the understanding
>>> that the group had.
>>>
>>> Both API's work, and people needed to choose between one of the proposals.
>>>
>>> Each one there had enough time to read and understand each proposal, since
>>> the patches were available more than one week before the meeting, and
>>> everybody were aware that the decision are scheduled to happen during LPC.
>>>
>>> Each one voted based on their own technical analysis, on a meeting that
>>> took about 2:30 hours, on the day after the presentations. People had
>>> enough time there to discuss, explain their ideas with the help of a
>>> whiteboard, decide and improve the proposal.
>>>
>>> S2API was choosen, since it was considered the better proposal for
>>> everybody there. None of the presents voted for Multiproto.
>>>
>>> Now that the decision were already taken, it is not time anymore to argue
>>> in favor to any other proposals. We need to move ahead and finally add
>>> support for DVB-S2 and the remaining missing digital TV's at kernel.
>>>
>>> Thank you and everyone else involved on adding support for the missing
>>> standards.
>>>
>>> Let's move to the next step: finally add API changes and drivers for
>>> DVB-S2 and prepare support for the remaining missing standards.
>>
>> It's no secret to anyone that there has been foul play, and blatantly
>> clear there is bias against Manu himself, and multiproto as a result,
>> based on personal differences & past conflicts.  You can't possibly
>> expect the dvb community to believe a fair & balanced meeting took
>> place to discuss these proposals when half the people there already
>> signed on for s2api, and the other half don't have the knowledge &
>> experience with dvb to make well-informed decisions.  You can't
>> possibly think people will believe any of you (who've openly admitted
>> support for s2api) spent 2 seconds defending multiproto, or even
>> assessing the proposal from an unbias technical standpoint.
>>
>> It's very convenient that you've completely ignored multiple requests
>> for more in-depth details that actually prove your points have real
>> technical merit and aren't just the result of some self-interest
>> politics and b.s.  Yet, you had no problem writing paragraphs about
>> how the decision has been made and everyone should just accept it.
>> Sorry, people aren't going to just accept it because this whole thing
>> has been tainted by misleading people, misrepresenting the truth, and
>> sometimes flat out lying.
>>
>> Valuable members of the community have turned, and are turning away
>> because of how poorly dvb has been maintained, and how self-serving
>> some people act.  I'm thankful that more people are being exposed &
>> becoming aware of what's been going on in hopes that at the very least
>> some kind of steps will be taken to stop the misuse & abuse of power
>> at the front of the dvb train.
>>
>> Again, if there is truth to your claims that s2api is the best
>> technical solution, then convince us all by providing tangible proof
>> rather then expecting everyone to take your word for it while ignoring
>> our requests for such information.  You have an obligation to the
>> community to justify your actions, and be held accountable for them.
>>
>
> There hasn't been much positive feedback here! How about let's talk to split the
> v4l and dvb development in order to not give Mauro the full authority
> over the whole
> 2 subsystems where he hardly anything contributed (to the second part).
>
> Don't see this as a flamewar, Andrew Morton and a few others are
> following that discussion now.
>
> Mauro as for you try to justify your step technically, the only point
> we've seen for now was from
> Patrick Boettcher (which was a good one from his side) but also the
> other involved people (within that
> 8 people group in Portland should point out their opinion and
> technical objections/reasons now).
>
> Officially it looks like you had 3 people supporting the Stevens
> proposal and 5 people who didn't know about
> the framework at all and explaining them that the DVB-S2 step is the
> better one to go whereas you had
> noone representing the multiproto path. Such a vote is highly doubtful then.
>
> Hans Hverkuil:
> I saw you in IRC that you support that proposal please also state out
> your opinion and/or ask your questions
> what/why things have been done like they are done in the multiproto
> tree and why you don't support it.
>
> It finally can really end up with a good solution either multiproto or
> S2 but everyone should understand and not only
> a few people.
>
> Markus

Markus,

After over two years, a decision has been made.  Up until now, many
people have been unhappy.  Now less people can be unhappy.  An
extension to the api has been merged, and now we can move forward.

There have been enough debates on the mailing lists to date, and there
is enough information available about each proposal and all of the
details surrounding them.  We need not hash this out again here.

Nobody wants to debate this any more -- a better use of our time is to
start working on userspace applications for the new supported
standards.  Please redirect your energy towards something creative.

Make love, not war.

Regards,

Mike Krufky

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Markus Rechberger]

On Thu, Sep 25, 2008 at 4:47 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
> On Wed, Sep 24, 2008 at 10:01 PM, Markus Rechberger
> <mrechberger@gmail.com> wrote:
>> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
>>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
>>> <mchehab@infradead.org> wrote:
>>>> The decision were already taken by the group.
>>>>
>>>> It should be noticed also that the public announcement took some time to
>>>> be ready, since we all carefully reviewed it to reflect the understanding
>>>> that the group had.
>>>>
>>>> Both API's work, and people needed to choose between one of the proposals.
>>>>
>>>> Each one there had enough time to read and understand each proposal, since
>>>> the patches were available more than one week before the meeting, and
>>>> everybody were aware that the decision are scheduled to happen during LPC.
>>>>
>>>> Each one voted based on their own technical analysis, on a meeting that
>>>> took about 2:30 hours, on the day after the presentations. People had
>>>> enough time there to discuss, explain their ideas with the help of a
>>>> whiteboard, decide and improve the proposal.
>>>>
>>>> S2API was choosen, since it was considered the better proposal for
>>>> everybody there. None of the presents voted for Multiproto.
>>>>
>>>> Now that the decision were already taken, it is not time anymore to argue
>>>> in favor to any other proposals. We need to move ahead and finally add
>>>> support for DVB-S2 and the remaining missing digital TV's at kernel.
>>>>
>>>> Thank you and everyone else involved on adding support for the missing
>>>> standards.
>>>>
>>>> Let's move to the next step: finally add API changes and drivers for
>>>> DVB-S2 and prepare support for the remaining missing standards.
>>>
>>> It's no secret to anyone that there has been foul play, and blatantly
>>> clear there is bias against Manu himself, and multiproto as a result,
>>> based on personal differences & past conflicts.  You can't possibly
>>> expect the dvb community to believe a fair & balanced meeting took
>>> place to discuss these proposals when half the people there already
>>> signed on for s2api, and the other half don't have the knowledge &
>>> experience with dvb to make well-informed decisions.  You can't
>>> possibly think people will believe any of you (who've openly admitted
>>> support for s2api) spent 2 seconds defending multiproto, or even
>>> assessing the proposal from an unbias technical standpoint.
>>>
>>> It's very convenient that you've completely ignored multiple requests
>>> for more in-depth details that actually prove your points have real
>>> technical merit and aren't just the result of some self-interest
>>> politics and b.s.  Yet, you had no problem writing paragraphs about
>>> how the decision has been made and everyone should just accept it.
>>> Sorry, people aren't going to just accept it because this whole thing
>>> has been tainted by misleading people, misrepresenting the truth, and
>>> sometimes flat out lying.
>>>
>>> Valuable members of the community have turned, and are turning away
>>> because of how poorly dvb has been maintained, and how self-serving
>>> some people act.  I'm thankful that more people are being exposed &
>>> becoming aware of what's been going on in hopes that at the very least
>>> some kind of steps will be taken to stop the misuse & abuse of power
>>> at the front of the dvb train.
>>>
>>> Again, if there is truth to your claims that s2api is the best
>>> technical solution, then convince us all by providing tangible proof
>>> rather then expecting everyone to take your word for it while ignoring
>>> our requests for such information.  You have an obligation to the
>>> community to justify your actions, and be held accountable for them.
>>>
>>
>> There hasn't been much positive feedback here! How about let's talk to split the
>> v4l and dvb development in order to not give Mauro the full authority
>> over the whole
>> 2 subsystems where he hardly anything contributed (to the second part).
>>
>> Don't see this as a flamewar, Andrew Morton and a few others are
>> following that discussion now.
>>
>> Mauro as for you try to justify your step technically, the only point
>> we've seen for now was from
>> Patrick Boettcher (which was a good one from his side) but also the
>> other involved people (within that
>> 8 people group in Portland should point out their opinion and
>> technical objections/reasons now).
>>
>> Officially it looks like you had 3 people supporting the Stevens
>> proposal and 5 people who didn't know about
>> the framework at all and explaining them that the DVB-S2 step is the
>> better one to go whereas you had
>> noone representing the multiproto path. Such a vote is highly doubtful then.
>>
>> Hans Hverkuil:
>> I saw you in IRC that you support that proposal please also state out
>> your opinion and/or ask your questions
>> what/why things have been done like they are done in the multiproto
>> tree and why you don't support it.
>>
>> It finally can really end up with a good solution either multiproto or
>> S2 but everyone should understand and not only
>> a few people.
>>
>> Markus
>
> Markus,
>
> After over two years, a decision has been made.  Up until now, many
> people have been unhappy.  Now less people can be unhappy.  An
> extension to the api has been merged, and now we can move forward.
>
> There have been enough debates on the mailing lists to date, and there
> is enough information available about each proposal and all of the
> details surrounding them.  We need not hash this out again here.
>
> Nobody wants to debate this any more -- a better use of our time is to
> start working on userspace applications for the new supported
> standards.  Please redirect your energy towards something creative.
>
> Make love, not war.
>

sure state out technical reasons and that's what it is about otherwise
a serious split should happen asap.
I personally invite you to be the first one here!

Markus

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[hermann pitton]

Am Donnerstag, den 25.09.2008, 04:49 +0200 schrieb Markus Rechberger:
> On Thu, Sep 25, 2008 at 4:47 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
> > On Wed, Sep 24, 2008 at 10:01 PM, Markus Rechberger
> > <mrechberger@gmail.com> wrote:
> >> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
> >>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
> >>> <mchehab@infradead.org> wrote:
> >>>> The decision were already taken by the group.
> >>>>
> >>>> It should be noticed also that the public announcement took some time to
> >>>> be ready, since we all carefully reviewed it to reflect the understanding
> >>>> that the group had.
> >>>>
> >>>> Both API's work, and people needed to choose between one of the proposals.
> >>>>
> >>>> Each one there had enough time to read and understand each proposal, since
> >>>> the patches were available more than one week before the meeting, and
> >>>> everybody were aware that the decision are scheduled to happen during LPC.
> >>>>
> >>>> Each one voted based on their own technical analysis, on a meeting that
> >>>> took about 2:30 hours, on the day after the presentations. People had
> >>>> enough time there to discuss, explain their ideas with the help of a
> >>>> whiteboard, decide and improve the proposal.
> >>>>
> >>>> S2API was choosen, since it was considered the better proposal for
> >>>> everybody there. None of the presents voted for Multiproto.
> >>>>
> >>>> Now that the decision were already taken, it is not time anymore to argue
> >>>> in favor to any other proposals. We need to move ahead and finally add
> >>>> support for DVB-S2 and the remaining missing digital TV's at kernel.
> >>>>
> >>>> Thank you and everyone else involved on adding support for the missing
> >>>> standards.
> >>>>
> >>>> Let's move to the next step: finally add API changes and drivers for
> >>>> DVB-S2 and prepare support for the remaining missing standards.
> >>>
> >>> It's no secret to anyone that there has been foul play, and blatantly
> >>> clear there is bias against Manu himself, and multiproto as a result,
> >>> based on personal differences & past conflicts.  You can't possibly
> >>> expect the dvb community to believe a fair & balanced meeting took
> >>> place to discuss these proposals when half the people there already
> >>> signed on for s2api, and the other half don't have the knowledge &
> >>> experience with dvb to make well-informed decisions.  You can't
> >>> possibly think people will believe any of you (who've openly admitted
> >>> support for s2api) spent 2 seconds defending multiproto, or even
> >>> assessing the proposal from an unbias technical standpoint.
> >>>
> >>> It's very convenient that you've completely ignored multiple requests
> >>> for more in-depth details that actually prove your points have real
> >>> technical merit and aren't just the result of some self-interest
> >>> politics and b.s.  Yet, you had no problem writing paragraphs about
> >>> how the decision has been made and everyone should just accept it.
> >>> Sorry, people aren't going to just accept it because this whole thing
> >>> has been tainted by misleading people, misrepresenting the truth, and
> >>> sometimes flat out lying.
> >>>
> >>> Valuable members of the community have turned, and are turning away
> >>> because of how poorly dvb has been maintained, and how self-serving
> >>> some people act.  I'm thankful that more people are being exposed &
> >>> becoming aware of what's been going on in hopes that at the very least
> >>> some kind of steps will be taken to stop the misuse & abuse of power
> >>> at the front of the dvb train.
> >>>
> >>> Again, if there is truth to your claims that s2api is the best
> >>> technical solution, then convince us all by providing tangible proof
> >>> rather then expecting everyone to take your word for it while ignoring
> >>> our requests for such information.  You have an obligation to the
> >>> community to justify your actions, and be held accountable for them.
> >>>
> >>
> >> There hasn't been much positive feedback here! How about let's talk to split the
> >> v4l and dvb development in order to not give Mauro the full authority
> >> over the whole
> >> 2 subsystems where he hardly anything contributed (to the second part).
> >>
> >> Don't see this as a flamewar, Andrew Morton and a few others are
> >> following that discussion now.
> >>
> >> Mauro as for you try to justify your step technically, the only point
> >> we've seen for now was from
> >> Patrick Boettcher (which was a good one from his side) but also the
> >> other involved people (within that
> >> 8 people group in Portland should point out their opinion and
> >> technical objections/reasons now).
> >>
> >> Officially it looks like you had 3 people supporting the Stevens
> >> proposal and 5 people who didn't know about
> >> the framework at all and explaining them that the DVB-S2 step is the
> >> better one to go whereas you had
> >> noone representing the multiproto path. Such a vote is highly doubtful then.
> >>
> >> Hans Hverkuil:
> >> I saw you in IRC that you support that proposal please also state out
> >> your opinion and/or ask your questions
> >> what/why things have been done like they are done in the multiproto
> >> tree and why you don't support it.
> >>
> >> It finally can really end up with a good solution either multiproto or
> >> S2 but everyone should understand and not only
> >> a few people.
> >>
> >> Markus
> >
> > Markus,
> >
> > After over two years, a decision has been made.  Up until now, many
> > people have been unhappy.  Now less people can be unhappy.  An
> > extension to the api has been merged, and now we can move forward.
> >
> > There have been enough debates on the mailing lists to date, and there
> > is enough information available about each proposal and all of the
> > details surrounding them.  We need not hash this out again here.
> >
> > Nobody wants to debate this any more -- a better use of our time is to
> > start working on userspace applications for the new supported
> > standards.  Please redirect your energy towards something creative.
> >
> > Make love, not war.
> >
> 
> sure state out technical reasons and that's what it is about otherwise
> a serious split should happen asap.
> I personally invite you to be the first one here!
> 
> Markus
> 

Markus,

you can't invite anybody, since you stay out of kernel by your own
decision and because Manu did not let you in the way you came :)

Hermann



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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Markus Rechberger]

On Thu, Sep 25, 2008 at 5:04 AM, hermann pitton <hermann-pitton@arcor.de> wrote:
>
> Am Donnerstag, den 25.09.2008, 04:49 +0200 schrieb Markus Rechberger:
>> On Thu, Sep 25, 2008 at 4:47 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
>> > On Wed, Sep 24, 2008 at 10:01 PM, Markus Rechberger
>> > <mrechberger@gmail.com> wrote:
>> >> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
>> >>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
>> >>> <mchehab@infradead.org> wrote:
>> >>>> The decision were already taken by the group.
>> >>>>
>> >>>> It should be noticed also that the public announcement took some time to
>> >>>> be ready, since we all carefully reviewed it to reflect the understanding
>> >>>> that the group had.
>> >>>>
>> >>>> Both API's work, and people needed to choose between one of the proposals.
>> >>>>
>> >>>> Each one there had enough time to read and understand each proposal, since
>> >>>> the patches were available more than one week before the meeting, and
>> >>>> everybody were aware that the decision are scheduled to happen during LPC.
>> >>>>
>> >>>> Each one voted based on their own technical analysis, on a meeting that
>> >>>> took about 2:30 hours, on the day after the presentations. People had
>> >>>> enough time there to discuss, explain their ideas with the help of a
>> >>>> whiteboard, decide and improve the proposal.
>> >>>>
>> >>>> S2API was choosen, since it was considered the better proposal for
>> >>>> everybody there. None of the presents voted for Multiproto.
>> >>>>
>> >>>> Now that the decision were already taken, it is not time anymore to argue
>> >>>> in favor to any other proposals. We need to move ahead and finally add
>> >>>> support for DVB-S2 and the remaining missing digital TV's at kernel.
>> >>>>
>> >>>> Thank you and everyone else involved on adding support for the missing
>> >>>> standards.
>> >>>>
>> >>>> Let's move to the next step: finally add API changes and drivers for
>> >>>> DVB-S2 and prepare support for the remaining missing standards.
>> >>>
>> >>> It's no secret to anyone that there has been foul play, and blatantly
>> >>> clear there is bias against Manu himself, and multiproto as a result,
>> >>> based on personal differences & past conflicts.  You can't possibly
>> >>> expect the dvb community to believe a fair & balanced meeting took
>> >>> place to discuss these proposals when half the people there already
>> >>> signed on for s2api, and the other half don't have the knowledge &
>> >>> experience with dvb to make well-informed decisions.  You can't
>> >>> possibly think people will believe any of you (who've openly admitted
>> >>> support for s2api) spent 2 seconds defending multiproto, or even
>> >>> assessing the proposal from an unbias technical standpoint.
>> >>>
>> >>> It's very convenient that you've completely ignored multiple requests
>> >>> for more in-depth details that actually prove your points have real
>> >>> technical merit and aren't just the result of some self-interest
>> >>> politics and b.s.  Yet, you had no problem writing paragraphs about
>> >>> how the decision has been made and everyone should just accept it.
>> >>> Sorry, people aren't going to just accept it because this whole thing
>> >>> has been tainted by misleading people, misrepresenting the truth, and
>> >>> sometimes flat out lying.
>> >>>
>> >>> Valuable members of the community have turned, and are turning away
>> >>> because of how poorly dvb has been maintained, and how self-serving
>> >>> some people act.  I'm thankful that more people are being exposed &
>> >>> becoming aware of what's been going on in hopes that at the very least
>> >>> some kind of steps will be taken to stop the misuse & abuse of power
>> >>> at the front of the dvb train.
>> >>>
>> >>> Again, if there is truth to your claims that s2api is the best
>> >>> technical solution, then convince us all by providing tangible proof
>> >>> rather then expecting everyone to take your word for it while ignoring
>> >>> our requests for such information.  You have an obligation to the
>> >>> community to justify your actions, and be held accountable for them.
>> >>>
>> >>
>> >> There hasn't been much positive feedback here! How about let's talk to split the
>> >> v4l and dvb development in order to not give Mauro the full authority
>> >> over the whole
>> >> 2 subsystems where he hardly anything contributed (to the second part).
>> >>
>> >> Don't see this as a flamewar, Andrew Morton and a few others are
>> >> following that discussion now.
>> >>
>> >> Mauro as for you try to justify your step technically, the only point
>> >> we've seen for now was from
>> >> Patrick Boettcher (which was a good one from his side) but also the
>> >> other involved people (within that
>> >> 8 people group in Portland should point out their opinion and
>> >> technical objections/reasons now).
>> >>
>> >> Officially it looks like you had 3 people supporting the Stevens
>> >> proposal and 5 people who didn't know about
>> >> the framework at all and explaining them that the DVB-S2 step is the
>> >> better one to go whereas you had
>> >> noone representing the multiproto path. Such a vote is highly doubtful then.
>> >>
>> >> Hans Hverkuil:
>> >> I saw you in IRC that you support that proposal please also state out
>> >> your opinion and/or ask your questions
>> >> what/why things have been done like they are done in the multiproto
>> >> tree and why you don't support it.
>> >>
>> >> It finally can really end up with a good solution either multiproto or
>> >> S2 but everyone should understand and not only
>> >> a few people.
>> >>
>> >> Markus
>> >
>> > Markus,
>> >
>> > After over two years, a decision has been made.  Up until now, many
>> > people have been unhappy.  Now less people can be unhappy.  An
>> > extension to the api has been merged, and now we can move forward.
>> >
>> > There have been enough debates on the mailing lists to date, and there
>> > is enough information available about each proposal and all of the
>> > details surrounding them.  We need not hash this out again here.
>> >
>> > Nobody wants to debate this any more -- a better use of our time is to
>> > start working on userspace applications for the new supported
>> > standards.  Please redirect your energy towards something creative.
>> >
>> > Make love, not war.
>> >
>>
>> sure state out technical reasons and that's what it is about otherwise
>> a serious split should happen asap.
>> I personally invite you to be the first one here!
>>
>> Markus
>>
>
> Markus,
>
> you can't invite anybody, since you stay out of kernel by your own
> decision and because Manu did not let you in the way you came :)
>

Hermann,

I never decided to stay outside of the kernel and if only for serious reasons.
For every pro why my stuff should be in the kernel I can get some
people up to discuss why it should
not be in the kernel right now. The split off is independent of the
rest of the code and won't affect anything else
and just add support for alot new devices in the end. Follow the
Mailinglist for the em28xx driver and you might see.

If anyone wants to have the driver code from mcentral.de in the kernel
as it is (including knowing what the bad things are
currently) I'm open for an immediately merge. For sure this also
depends if Linus is open to merge it. BSD people were open
for a merge without that stupid "submit small patches comment"
immediately especially since it's only about a driver which runs
on its own.

The codebase doesn't affect any other driver nor any framework as it
is right now only the driver itself.

Also think about writing more than 20k lines of code. This won't
happen over night.

Markus

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Christophe Thommeret]

Le Thursday 25 September 2008 04:49:36 Markus Rechberger, vous avez écrit :
> On Thu, Sep 25, 2008 at 4:47 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
> > On Wed, Sep 24, 2008 at 10:01 PM, Markus Rechberger
> >
> > <mrechberger@gmail.com> wrote:
> >> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
> >>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
> >>>
> >>> <mchehab@infradead.org> wrote:
> >>>> The decision were already taken by the group.
> >>>>
> >>>> It should be noticed also that the public announcement took some time
> >>>> to be ready, since we all carefully reviewed it to reflect the
> >>>> understanding that the group had.
> >>>>
> >>>> Both API's work, and people needed to choose between one of the
> >>>> proposals.
> >>>>
> >>>> Each one there had enough time to read and understand each proposal,
> >>>> since the patches were available more than one week before the
> >>>> meeting, and everybody were aware that the decision are scheduled to
> >>>> happen during LPC.
> >>>>
> >>>> Each one voted based on their own technical analysis, on a meeting
> >>>> that took about 2:30 hours, on the day after the presentations. People
> >>>> had enough time there to discuss, explain their ideas with the help of
> >>>> a whiteboard, decide and improve the proposal.
> >>>>
> >>>> S2API was choosen, since it was considered the better proposal for
> >>>> everybody there. None of the presents voted for Multiproto.
> >>>>
> >>>> Now that the decision were already taken, it is not time anymore to
> >>>> argue in favor to any other proposals. We need to move ahead and
> >>>> finally add support for DVB-S2 and the remaining missing digital TV's
> >>>> at kernel.
> >>>>
> >>>> Thank you and everyone else involved on adding support for the missing
> >>>> standards.
> >>>>
> >>>> Let's move to the next step: finally add API changes and drivers for
> >>>> DVB-S2 and prepare support for the remaining missing standards.
> >>>
> >>> It's no secret to anyone that there has been foul play, and blatantly
> >>> clear there is bias against Manu himself, and multiproto as a result,
> >>> based on personal differences & past conflicts.  You can't possibly
> >>> expect the dvb community to believe a fair & balanced meeting took
> >>> place to discuss these proposals when half the people there already
> >>> signed on for s2api, and the other half don't have the knowledge &
> >>> experience with dvb to make well-informed decisions.  You can't
> >>> possibly think people will believe any of you (who've openly admitted
> >>> support for s2api) spent 2 seconds defending multiproto, or even
> >>> assessing the proposal from an unbias technical standpoint.
> >>>
> >>> It's very convenient that you've completely ignored multiple requests
> >>> for more in-depth details that actually prove your points have real
> >>> technical merit and aren't just the result of some self-interest
> >>> politics and b.s.  Yet, you had no problem writing paragraphs about
> >>> how the decision has been made and everyone should just accept it.
> >>> Sorry, people aren't going to just accept it because this whole thing
> >>> has been tainted by misleading people, misrepresenting the truth, and
> >>> sometimes flat out lying.
> >>>
> >>> Valuable members of the community have turned, and are turning away
> >>> because of how poorly dvb has been maintained, and how self-serving
> >>> some people act.  I'm thankful that more people are being exposed &
> >>> becoming aware of what's been going on in hopes that at the very least
> >>> some kind of steps will be taken to stop the misuse & abuse of power
> >>> at the front of the dvb train.
> >>>
> >>> Again, if there is truth to your claims that s2api is the best
> >>> technical solution, then convince us all by providing tangible proof
> >>> rather then expecting everyone to take your word for it while ignoring
> >>> our requests for such information.  You have an obligation to the
> >>> community to justify your actions, and be held accountable for them.
> >>
> >> There hasn't been much positive feedback here! How about let's talk to
> >> split the v4l and dvb development in order to not give Mauro the full
> >> authority over the whole
> >> 2 subsystems where he hardly anything contributed (to the second part).
> >>
> >> Don't see this as a flamewar, Andrew Morton and a few others are
> >> following that discussion now.
> >>
> >> Mauro as for you try to justify your step technically, the only point
> >> we've seen for now was from
> >> Patrick Boettcher (which was a good one from his side) but also the
> >> other involved people (within that
> >> 8 people group in Portland should point out their opinion and
> >> technical objections/reasons now).
> >>
> >> Officially it looks like you had 3 people supporting the Stevens
> >> proposal and 5 people who didn't know about
> >> the framework at all and explaining them that the DVB-S2 step is the
> >> better one to go whereas you had
> >> noone representing the multiproto path. Such a vote is highly doubtful
> >> then.
> >>
> >> Hans Hverkuil:
> >> I saw you in IRC that you support that proposal please also state out
> >> your opinion and/or ask your questions
> >> what/why things have been done like they are done in the multiproto
> >> tree and why you don't support it.
> >>
> >> It finally can really end up with a good solution either multiproto or
> >> S2 but everyone should understand and not only
> >> a few people.
> >>
> >> Markus
> >
> > Markus,
> >
> > After over two years, a decision has been made.  Up until now, many
> > people have been unhappy.  Now less people can be unhappy.  An
> > extension to the api has been merged, and now we can move forward.
> >
> > There have been enough debates on the mailing lists to date, and there
> > is enough information available about each proposal and all of the
> > details surrounding them.  We need not hash this out again here.
> >
> > Nobody wants to debate this any more -- a better use of our time is to
> > start working on userspace applications for the new supported
> > standards.  Please redirect your energy towards something creative.
> >
> > Make love, not war.
>
> sure state out technical reasons and that's what it is about otherwise
> a serious split should happen asap.
> I personally invite you to be the first one here!
>
> Markus

Markus,

As a reminder, the democracy way is :

1) debates
2) vote

not the other way round ;)

-- 
Christophe Thommeret


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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Markus Rechberger]

On Thu, Sep 25, 2008 at 5:05 AM, Christophe Thommeret <hftom@free.fr> wrote:
> Le Thursday 25 September 2008 04:49:36 Markus Rechberger, vous avez écrit :
>> On Thu, Sep 25, 2008 at 4:47 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
>> > On Wed, Sep 24, 2008 at 10:01 PM, Markus Rechberger
>> >
>> > <mrechberger@gmail.com> wrote:
>> >> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
>> >>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
>> >>>
>> >>> <mchehab@infradead.org> wrote:
>> >>>> The decision were already taken by the group.
>> >>>>
>> >>>> It should be noticed also that the public announcement took some time
>> >>>> to be ready, since we all carefully reviewed it to reflect the
>> >>>> understanding that the group had.
>> >>>>
>> >>>> Both API's work, and people needed to choose between one of the
>> >>>> proposals.
>> >>>>
>> >>>> Each one there had enough time to read and understand each proposal,
>> >>>> since the patches were available more than one week before the
>> >>>> meeting, and everybody were aware that the decision are scheduled to
>> >>>> happen during LPC.
>> >>>>
>> >>>> Each one voted based on their own technical analysis, on a meeting
>> >>>> that took about 2:30 hours, on the day after the presentations. People
>> >>>> had enough time there to discuss, explain their ideas with the help of
>> >>>> a whiteboard, decide and improve the proposal.
>> >>>>
>> >>>> S2API was choosen, since it was considered the better proposal for
>> >>>> everybody there. None of the presents voted for Multiproto.
>> >>>>
>> >>>> Now that the decision were already taken, it is not time anymore to
>> >>>> argue in favor to any other proposals. We need to move ahead and
>> >>>> finally add support for DVB-S2 and the remaining missing digital TV's
>> >>>> at kernel.
>> >>>>
>> >>>> Thank you and everyone else involved on adding support for the missing
>> >>>> standards.
>> >>>>
>> >>>> Let's move to the next step: finally add API changes and drivers for
>> >>>> DVB-S2 and prepare support for the remaining missing standards.
>> >>>
>> >>> It's no secret to anyone that there has been foul play, and blatantly
>> >>> clear there is bias against Manu himself, and multiproto as a result,
>> >>> based on personal differences & past conflicts.  You can't possibly
>> >>> expect the dvb community to believe a fair & balanced meeting took
>> >>> place to discuss these proposals when half the people there already
>> >>> signed on for s2api, and the other half don't have the knowledge &
>> >>> experience with dvb to make well-informed decisions.  You can't
>> >>> possibly think people will believe any of you (who've openly admitted
>> >>> support for s2api) spent 2 seconds defending multiproto, or even
>> >>> assessing the proposal from an unbias technical standpoint.
>> >>>
>> >>> It's very convenient that you've completely ignored multiple requests
>> >>> for more in-depth details that actually prove your points have real
>> >>> technical merit and aren't just the result of some self-interest
>> >>> politics and b.s.  Yet, you had no problem writing paragraphs about
>> >>> how the decision has been made and everyone should just accept it.
>> >>> Sorry, people aren't going to just accept it because this whole thing
>> >>> has been tainted by misleading people, misrepresenting the truth, and
>> >>> sometimes flat out lying.
>> >>>
>> >>> Valuable members of the community have turned, and are turning away
>> >>> because of how poorly dvb has been maintained, and how self-serving
>> >>> some people act.  I'm thankful that more people are being exposed &
>> >>> becoming aware of what's been going on in hopes that at the very least
>> >>> some kind of steps will be taken to stop the misuse & abuse of power
>> >>> at the front of the dvb train.
>> >>>
>> >>> Again, if there is truth to your claims that s2api is the best
>> >>> technical solution, then convince us all by providing tangible proof
>> >>> rather then expecting everyone to take your word for it while ignoring
>> >>> our requests for such information.  You have an obligation to the
>> >>> community to justify your actions, and be held accountable for them.
>> >>
>> >> There hasn't been much positive feedback here! How about let's talk to
>> >> split the v4l and dvb development in order to not give Mauro the full
>> >> authority over the whole
>> >> 2 subsystems where he hardly anything contributed (to the second part).
>> >>
>> >> Don't see this as a flamewar, Andrew Morton and a few others are
>> >> following that discussion now.
>> >>
>> >> Mauro as for you try to justify your step technically, the only point
>> >> we've seen for now was from
>> >> Patrick Boettcher (which was a good one from his side) but also the
>> >> other involved people (within that
>> >> 8 people group in Portland should point out their opinion and
>> >> technical objections/reasons now).
>> >>
>> >> Officially it looks like you had 3 people supporting the Stevens
>> >> proposal and 5 people who didn't know about
>> >> the framework at all and explaining them that the DVB-S2 step is the
>> >> better one to go whereas you had
>> >> noone representing the multiproto path. Such a vote is highly doubtful
>> >> then.
>> >>
>> >> Hans Hverkuil:
>> >> I saw you in IRC that you support that proposal please also state out
>> >> your opinion and/or ask your questions
>> >> what/why things have been done like they are done in the multiproto
>> >> tree and why you don't support it.
>> >>
>> >> It finally can really end up with a good solution either multiproto or
>> >> S2 but everyone should understand and not only
>> >> a few people.
>> >>
>> >> Markus
>> >
>> > Markus,
>> >
>> > After over two years, a decision has been made.  Up until now, many
>> > people have been unhappy.  Now less people can be unhappy.  An
>> > extension to the api has been merged, and now we can move forward.
>> >
>> > There have been enough debates on the mailing lists to date, and there
>> > is enough information available about each proposal and all of the
>> > details surrounding them.  We need not hash this out again here.
>> >
>> > Nobody wants to debate this any more -- a better use of our time is to
>> > start working on userspace applications for the new supported
>> > standards.  Please redirect your energy towards something creative.
>> >
>> > Make love, not war.
>>
>> sure state out technical reasons and that's what it is about otherwise
>> a serious split should happen asap.
>> I personally invite you to be the first one here!
>>
>> Markus
>
> Markus,
>
> As a reminder, the democracy way is :
>
> 1) debates
> 2) vote
>
> not the other way round ;)
>

Exactly just a reminder

having 3 people  supporting one party and the rest (4-5) having no
decision ... and one party being completely absent in order to state
out the own opinion to those undecided people isn't right either.

sorry just fairness counts here. If Manu loses then the right way and
then support for 18 devices can be dumped.

Markus

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Simon Kenyon]

Markus Rechberger wrote:
> sure state out technical reasons and that's what it is about otherwise
> a serious split should happen asap.
> I personally invite you to be the first one here!
>   

why do i even bother?

there doesn't have to be a good technical reason
there doesn't have to be a good technical reason
there doesn't have to be a good technical reason

it is the path of least resistance and will lead to more supported 
hardware in linux

now for the love of all that is holy (not swearing or mocking any 
religion here - although sorely tempted) would you all stop squabbling 
like children and move on

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Michael Krufky wrote:

> After over two years, a decision has been made.  Up until now, many
> people have been unhappy.  Now less people can be unhappy.  An
> extension to the api has been merged, and now we can move forward.

A discussion between people who were already decided what to state
beforehand, i must say.

> There have been enough debates on the mailing lists to date, and there
> is enough information available about each proposal and all of the
> details surrounding them.  We need not hash this out again here.

The last time you tried to mangle up the history, somebody else had to
dig up all the history on it.


Regards,
Manu

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Mauro Carvalho Chehab]

On Thu, 25 Sep 2008, Manu Abraham wrote:

> A discussion between people who were already decided what to state
> beforehand, i must say.

Not true at all.

Only 3 persons were Americans. Yet, 2 of them living at the oposite coast 
of US. So, even for they, a long trip (5 hours of time fuse).

All the others there came from other continents: Europe, South America, 
Asia. On most cases, people took 2 days to arrive there, and 2 other days 
to return back home, for a 2,5 day meeting.

Some of them even payed the expenses from their own pockets.

We all suffered a lot from Jet Leg effects, geting 5 or more hours of 
difference at the time fuse.

We all now have a big list of pending work that accumulated due to the 1 
week spent with the trips.

People woudln't do at all such big efforts just to say: "me too", or to do 
some sort of political arrangement. If there was a previous decision, it 
would be a way easy to announce it via email.

People went there because:
 	- They want a better future for video input infrastructure;
 	- They think that people make difference;
 	- They want to solve pending things;
 	- They believe that being together is the way for fixing social 
issues at the community.

So, all people there put a lot of resources for what they believe 
it is the right way to do. Please respect.

I understand that you are unhappy with the results of the vote, but it 
was a fair decision.

Cheers,
Mauro.

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Janne Grunau]

On Thursday 25 September 2008 12:45:51 Markus Rechberger wrote:
> what's the matter of merging both? please let us discuss that, the
> APIs shouldn't have a big impact on each other.
> Does it break someone's neck to have both?

They will stick both forever in the kernel and either applications or 
drivers have to support both. Realistically both drivers and 
applications will support both.

This is a stupid compromise which doesn't solve anything. A decision was 
made we should live with it.

Janne



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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Markus Rechberger]

On Thu, Sep 25, 2008 at 1:13 PM, Janne Grunau <janne-dvb@grunau.be> wrote:
> On Thursday 25 September 2008 12:45:51 Markus Rechberger wrote:
>> what's the matter of merging both? please let us discuss that, the
>> APIs shouldn't have a big impact on each other.
>> Does it break someone's neck to have both?
>
> They will stick both forever in the kernel and either applications or
> drivers have to support both. Realistically both drivers and
> applications will support both.
>
> This is a stupid compromise which doesn't solve anything. A decision was
> made we should live with it.
>

Janne, as from my side we already delivered vendor specific drivers
with vendor specific interfaces
to a couple of customers and also patched the enduser applications for
it since the API didn't provide the necessary
features.
I don't see that there's a restriction on a single API for it, BSD
guys simply put a compatibility layer infront of their API
in order to support linux applications while having the full flexibility.
Although it's your opinion and I respect it.

Markus

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Devin Heitmueller]

Hello Derek,

On Fri, Sep 26, 2008 at 11:12 AM, VDR User <user.vdr@gmail.com> wrote:
> Regardless of this api mess (which I accept either way), there are
> many people who are unhappy with Mauro Chehab as dvb maintainer and
> have been for some time.  I suspect more of this will become public
> since things have finally reached a point of enough-is-enough.

Perhaps your comments would carry more credibility if you would
provide your full name and the number of commits you have made to the
v4l-dvb codebase in the last year.

This is a open source developers list, which generally makes it a
meritocracy.  If Mauro were actually incompetent, I am quite confident
that the developers who are *actively committing code* would not stand
for it.  The reality is though that the people who work with him on a
regular basis are in most cases the same people who have backed the
S2API proposal.  It's not a coincidence that the same people that
supported the proposal are major contributors to the project.

Are there communication/personality issues?  Certainly.  However,
unless you are actively contributing code to the project, please leave
the developers to work through this issue without your help.

Thank you,

Devin Heitmueller

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[VDR User]

On Fri, Sep 26, 2008 at 8:37 AM, Devin Heitmueller
<devin.heitmueller@gmail.com> wrote:
> Perhaps your comments would carry more credibility if you would
> provide your full name and the number of commits you have made to the
> v4l-dvb codebase in the last year.

So I'm understand you correctly, can you clarify that only people who
provide their full name and number of commits have any "credibility"?
As well, I'm under the premise that everyone is entitled to their
opinions and free to express them as they see fit.  And in doing so,
all others may interpret those opinions any way they choose, but no
single opinion is any less or more "valid" then any other.

> This is a open source developers list, which generally makes it a
> meritocracy.  If Mauro were actually incompetent, I am quite confident
> that the developers who are *actively committing code* would not stand
> for it.

I'm going to have to disagree with you.  I've seen negative comments
towards Mauro made first-hand in #linuxtv but those same people
unwilling to do so when Mauro has been present.  I'm sure there are
logs that can be searched if anyone is so inclined to see for
themselves.

> The reality is though that the people who work with him on a
> regular basis are in most cases the same people who have backed the
> S2API proposal.  It's not a coincidence that the same people that
> supported the proposal are major contributors to the project.
>
> Are there communication/personality issues?  Certainly.  However,
> unless you are actively contributing code to the project, please leave
> the developers to work through this issue without your help.

Everyone here has the right to post their thoughts whether you
(dis)like or (dis)agree with them.  Your opinions are no more valid
and mine as no less valid.  As I've stated before, I have no personal
or financial interest in what happens and that allows me to speak more
freely because I have nothing to lose.  You are welcome to skip over
any of my posts or ignore my thoughts completely, but I'm not going to
shut up because a couple people don't like what I have to say.  That's
not how this works, sorry.

Cheers,
**  DEREK KELLY  **

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Devin Heitmueller]

On Fri, Sep 26, 2008 at 12:07 PM, VDR User <user.vdr@gmail.com> wrote:
> On Fri, Sep 26, 2008 at 8:37 AM, Devin Heitmueller
> <devin.heitmueller@gmail.com> wrote:
>> Perhaps your comments would carry more credibility if you would
>> provide your full name and the number of commits you have made to the
>> v4l-dvb codebase in the last year.
>
> So I'm understand you correctly, can you clarify that only people who
> provide their full name and number of commits have any "credibility"?
> As well, I'm under the premise that everyone is entitled to their
> opinions and free to express them as they see fit.  And in doing so,
> all others may interpret those opinions any way they choose, but no
> single opinion is any less or more "valid" then any other.

Yes, I believe that on an open source developers mailing list, the
opinions of people who are active contributors to the project are more
credible than random users who jump on the list occasionally to call
for ousting of the subsystem maintainer.

> Everyone here has the right to post their thoughts whether you
> (dis)like or (dis)agree with them.  Your opinions are no more valid
> and mine as no less valid.  As I've stated before, I have no personal
> or financial interest in what happens and that allows me to speak more
> freely because I have nothing to lose.  You are welcome to skip over
> any of my posts or ignore my thoughts completely, but I'm not going to
> shut up because a couple people don't like what I have to say.  That's
> not how this works, sorry.

Ok.  Keep posting then.  I was just trying to establish whether you
have made any actual contributions of code to the project.

Regards,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Hans Verkuil]

> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
>> <mchehab@infradead.org> wrote:
>>> The decision were already taken by the group.
>>>
>>> It should be noticed also that the public announcement took some time
>>> to
>>> be ready, since we all carefully reviewed it to reflect the
>>> understanding
>>> that the group had.
>>>
>>> Both API's work, and people needed to choose between one of the
>>> proposals.
>>>
>>> Each one there had enough time to read and understand each proposal,
>>> since
>>> the patches were available more than one week before the meeting, and
>>> everybody were aware that the decision are scheduled to happen during
>>> LPC.
>>>
>>> Each one voted based on their own technical analysis, on a meeting that
>>> took about 2:30 hours, on the day after the presentations. People had
>>> enough time there to discuss, explain their ideas with the help of a
>>> whiteboard, decide and improve the proposal.
>>>
>>> S2API was choosen, since it was considered the better proposal for
>>> everybody there. None of the presents voted for Multiproto.
>>>
>>> Now that the decision were already taken, it is not time anymore to
>>> argue
>>> in favor to any other proposals. We need to move ahead and finally add
>>> support for DVB-S2 and the remaining missing digital TV's at kernel.
>>>
>>> Thank you and everyone else involved on adding support for the missing
>>> standards.
>>>
>>> Let's move to the next step: finally add API changes and drivers for
>>> DVB-S2 and prepare support for the remaining missing standards.
>>
>> It's no secret to anyone that there has been foul play, and blatantly
>> clear there is bias against Manu himself, and multiproto as a result,
>> based on personal differences & past conflicts.  You can't possibly
>> expect the dvb community to believe a fair & balanced meeting took
>> place to discuss these proposals when half the people there already
>> signed on for s2api, and the other half don't have the knowledge &
>> experience with dvb to make well-informed decisions.  You can't
>> possibly think people will believe any of you (who've openly admitted
>> support for s2api) spent 2 seconds defending multiproto, or even
>> assessing the proposal from an unbias technical standpoint.
>>
>> It's very convenient that you've completely ignored multiple requests
>> for more in-depth details that actually prove your points have real
>> technical merit and aren't just the result of some self-interest
>> politics and b.s.  Yet, you had no problem writing paragraphs about
>> how the decision has been made and everyone should just accept it.
>> Sorry, people aren't going to just accept it because this whole thing
>> has been tainted by misleading people, misrepresenting the truth, and
>> sometimes flat out lying.
>>
>> Valuable members of the community have turned, and are turning away
>> because of how poorly dvb has been maintained, and how self-serving
>> some people act.  I'm thankful that more people are being exposed &
>> becoming aware of what's been going on in hopes that at the very least
>> some kind of steps will be taken to stop the misuse & abuse of power
>> at the front of the dvb train.
>>
>> Again, if there is truth to your claims that s2api is the best
>> technical solution, then convince us all by providing tangible proof
>> rather then expecting everyone to take your word for it while ignoring
>> our requests for such information.  You have an obligation to the
>> community to justify your actions, and be held accountable for them.
>>
>
> There hasn't been much positive feedback here! How about let's talk to
> split the
> v4l and dvb development in order to not give Mauro the full authority
> over the whole
> 2 subsystems where he hardly anything contributed (to the second part).
>
> Don't see this as a flamewar, Andrew Morton and a few others are
> following that discussion now.
>
> Mauro as for you try to justify your step technically, the only point
> we've seen for now was from
> Patrick Boettcher (which was a good one from his side) but also the
> other involved people (within that
> 8 people group in Portland should point out their opinion and
> technical objections/reasons now).
>
> Officially it looks like you had 3 people supporting the Stevens
> proposal and 5 people who didn't know about
> the framework at all and explaining them that the DVB-S2 step is the
> better one to go whereas you had
> noone representing the multiproto path. Such a vote is highly doubtful
> then.
>
> Hans Hverkuil:
> I saw you in IRC that you support that proposal please also state out
> your opinion and/or ask your questions
> what/why things have been done like they are done in the multiproto
> tree and why you don't support it.
>
> It finally can really end up with a good solution either multiproto or
> S2 but everyone should understand and not only
> a few people.

These are my reasons for voting in favor of the S2 API. Note that I looked
at the public API part as that is the hard part of these patches. I've
created several V4L2 APIs in the past so I know how important that is.

1) It's pretty much guaranteed to be future proof by its very design. It
is next to impossible to predict what they will come up with next in the
future, so this is a very important property.

2) It makes it easy to set separate properties, so you can 'fine-tune' the
tuner, so to speak. Or retrieve other tuner properties that way. Basically
it gives the application fine-grained control of the tuner properties,
which is rather nice.

3) A consideration for me is that this API can be used equally well for
the V4L2 analog tuner side. There is nothing DVB specific about it. It
would solve some long-standing issues I have with LNA in analog tuners and
I'm seriously thinking of adding support for this to V4L2. It's nice to be
able to use the same external and internal APIs for tuners in both
subsystems.

No doubt the discussions would have been more lively had Manu been
present, but I doubt it would have made any difference. The discussions
were kept on a technical level, there were no conspiracy plots or any of
that nonsense. It's an API for crying out loud, not the end of the world.
Just work with Steve to convert the current devices in the multiproto tree
to use this API. If there is anything missing kick Steve and he'll have to
add whatever is needed. That's *his* responsibility and he accepted that
during the discussions.

The only reason I replied at all is that I thought it a fair request to
have more detailed information on the reasoning behind the decision.

I do not intend to discuss this further, mostly because all this has been
discussed to death already. Two competing APIs, one 'wins'. That's life
and it sucks if your API doesn't get in. I can totally understand that
Manu is unhappy. Just take a vacation from driver programming for a week
or so (that worked for me in the past) and when you're over it start
making sure your drivers are supported by the kernel and your users are
happy. That's where the real satisfaction of kernel programming comes
from, after all: that users can just install Fedora or Ubuntu and having
their hardware supported out of the box thanks to our collective hard
work.

Best regards,

       Hans


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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Hans Verkuil wrote:
>> On Wed, Sep 24, 2008 at 11:41 PM, VDR User <user.vdr@gmail.com> wrote:
>>> On Wed, Sep 24, 2008 at 8:21 AM, Mauro Carvalho Chehab
>>> <mchehab@infradead.org> wrote:
>>>> The decision were already taken by the group.
>>>>
>>>> It should be noticed also that the public announcement took some time
>>>> to
>>>> be ready, since we all carefully reviewed it to reflect the
>>>> understanding
>>>> that the group had.
>>>>
>>>> Both API's work, and people needed to choose between one of the
>>>> proposals.
>>>>
>>>> Each one there had enough time to read and understand each proposal,
>>>> since
>>>> the patches were available more than one week before the meeting, and
>>>> everybody were aware that the decision are scheduled to happen during
>>>> LPC.
>>>>
>>>> Each one voted based on their own technical analysis, on a meeting that
>>>> took about 2:30 hours, on the day after the presentations. People had
>>>> enough time there to discuss, explain their ideas with the help of a
>>>> whiteboard, decide and improve the proposal.
>>>>
>>>> S2API was choosen, since it was considered the better proposal for
>>>> everybody there. None of the presents voted for Multiproto.
>>>>
>>>> Now that the decision were already taken, it is not time anymore to
>>>> argue
>>>> in favor to any other proposals. We need to move ahead and finally add
>>>> support for DVB-S2 and the remaining missing digital TV's at kernel.
>>>>
>>>> Thank you and everyone else involved on adding support for the missing
>>>> standards.
>>>>
>>>> Let's move to the next step: finally add API changes and drivers for
>>>> DVB-S2 and prepare support for the remaining missing standards.
>>> It's no secret to anyone that there has been foul play, and blatantly
>>> clear there is bias against Manu himself, and multiproto as a result,
>>> based on personal differences & past conflicts.  You can't possibly
>>> expect the dvb community to believe a fair & balanced meeting took
>>> place to discuss these proposals when half the people there already
>>> signed on for s2api, and the other half don't have the knowledge &
>>> experience with dvb to make well-informed decisions.  You can't
>>> possibly think people will believe any of you (who've openly admitted
>>> support for s2api) spent 2 seconds defending multiproto, or even
>>> assessing the proposal from an unbias technical standpoint.
>>>
>>> It's very convenient that you've completely ignored multiple requests
>>> for more in-depth details that actually prove your points have real
>>> technical merit and aren't just the result of some self-interest
>>> politics and b.s.  Yet, you had no problem writing paragraphs about
>>> how the decision has been made and everyone should just accept it.
>>> Sorry, people aren't going to just accept it because this whole thing
>>> has been tainted by misleading people, misrepresenting the truth, and
>>> sometimes flat out lying.
>>>
>>> Valuable members of the community have turned, and are turning away
>>> because of how poorly dvb has been maintained, and how self-serving
>>> some people act.  I'm thankful that more people are being exposed &
>>> becoming aware of what's been going on in hopes that at the very least
>>> some kind of steps will be taken to stop the misuse & abuse of power
>>> at the front of the dvb train.
>>>
>>> Again, if there is truth to your claims that s2api is the best
>>> technical solution, then convince us all by providing tangible proof
>>> rather then expecting everyone to take your word for it while ignoring
>>> our requests for such information.  You have an obligation to the
>>> community to justify your actions, and be held accountable for them.
>>>
>> There hasn't been much positive feedback here! How about let's talk to
>> split the
>> v4l and dvb development in order to not give Mauro the full authority
>> over the whole
>> 2 subsystems where he hardly anything contributed (to the second part).
>>
>> Don't see this as a flamewar, Andrew Morton and a few others are
>> following that discussion now.
>>
>> Mauro as for you try to justify your step technically, the only point
>> we've seen for now was from
>> Patrick Boettcher (which was a good one from his side) but also the
>> other involved people (within that
>> 8 people group in Portland should point out their opinion and
>> technical objections/reasons now).
>>
>> Officially it looks like you had 3 people supporting the Stevens
>> proposal and 5 people who didn't know about
>> the framework at all and explaining them that the DVB-S2 step is the
>> better one to go whereas you had
>> noone representing the multiproto path. Such a vote is highly doubtful
>> then.
>>
>> Hans Hverkuil:
>> I saw you in IRC that you support that proposal please also state out
>> your opinion and/or ask your questions
>> what/why things have been done like they are done in the multiproto
>> tree and why you don't support it.
>>
>> It finally can really end up with a good solution either multiproto or
>> S2 but everyone should understand and not only
>> a few people.
> 
> These are my reasons for voting in favor of the S2 API. Note that I looked
> at the public API part as that is the hard part of these patches. I've
> created several V4L2 APIs in the past so I know how important that is.


Thanks for the explanation on your position. I should explain some
aspects as well.


> 1) It's pretty much guaranteed to be future proof by its very design. It
> is next to impossible to predict what they will come up with next in the
> future, so this is a very important property.

The multiproto API is just as future proof as S2API. This was the very
basic cause for the evolution of multiproto, if you see the history.

We've had lots of discussions on having it on the same mailing lists abd
is future proof and thus it evolved. All the discussion threads are
archived.


> 2) It makes it easy to set separate properties, so you can 'fine-tune' the
> tuner, so to speak. Or retrieve other tuner properties that way. Basically
> it gives the application fine-grained control of the tuner properties,
> which is rather nice.

You don't manually control a tuner, whereas a demodulator controls a
tuner, for the relevant operation. For analog operations, a tuner is
more important, but we are not dealing with analog operations here, we
are dealing with adding a new Digital standard for user applications to
talk to a frontend: ie a demodulator + tuner. The tuner happens to be
running in tandem to the algorithm which the demodulator is run basically.


> 3) A consideration for me is that this API can be used equally well for
> the V4L2 analog tuner side. There is nothing DVB specific about it. It
> would solve some long-standing issues I have with LNA in analog tuners and
> I'm seriously thinking of adding support for this to V4L2. It's nice to be
> able to use the same external and internal APIs for tuners in both
> subsystems.


An existing API shouldn't be dependant on another API.


> No doubt the discussions would have been more lively had Manu been
> present, but I doubt it would have made any difference. The discussions
> were kept on a technical level, there were no conspiracy plots or any of
> that nonsense. It's an API for crying out loud, not the end of the world.
> Just work with Steve to convert the current devices in the multiproto tree
> to use this API. If there is anything missing kick Steve and he'll have to
> add whatever is needed. That's *his* responsibility and he accepted that
> during the discussions.


It can be the reverse way too ..


> The only reason I replied at all is that I thought it a fair request to
> have more detailed information on the reasoning behind the decision.
> 
> I do not intend to discuss this further, mostly because all this has been
> discussed to death already. Two competing APIs, one 'wins'. That's life
> and it sucks if your API doesn't get in. I can totally understand that
> Manu is unhappy.


True, with all those backstabbing going on.


> Just take a vacation from driver programming for a week
> or so (that worked for me in the past) and when you're over it start
> making sure your drivers are supported by the kernel and your users are
> happy. That's where the real satisfaction of kernel programming comes
> from, after all: that users can just install Fedora or Ubuntu and having
> their hardware supported out of the box thanks to our collective hard
> work.

The same can be said, on the other side as well.

Regards,
Manu




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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Hans Verkuil wrote:

> Just work with Steve to convert the current devices in the multiproto tree
> to use this API. If there is anything missing kick Steve and he'll have to
> add whatever is needed. That's *his* responsibility and he accepted that
> during the discussions.

With the multiproto tree, you _don't_need_ to convert any devices to use
the new infrastructure, whereas with S2API you need to do that. This is
a major drawback. In the multiproto tree, all devices work just without
any conversion of any kind, also it is completely backward compatible.

The aspect of backward compatibility and drivers not getting converted
had been a major issue, when the original DVB-S2 discussions came up.
This had been a design goal for the multiproto tree.


Regards,
Manu

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Christophe Thommeret]

Le Thursday 25 September 2008 05:57:18 Manu Abraham, vous avez écrit :
> Hans Verkuil wrote:
> > Just work with Steve to convert the current devices in the multiproto
> > tree to use this API. If there is anything missing kick Steve and he'll
> > have to add whatever is needed. That's *his* responsibility and he
> > accepted that during the discussions.
>
> With the multiproto tree, you _don't_need_ to convert any devices to use
> the new infrastructure, whereas with S2API you need to do that. This is
> a major drawback. In the multiproto tree, all devices work just without
> any conversion of any kind, also it is completely backward compatible.
>
> The aspect of backward compatibility and drivers not getting converted
> had been a major issue, when the original DVB-S2 discussions came up.
> This had been a design goal for the multiproto tree.

I'm not sure to get you Manu.
Do you mean that existing drivers have to be "converted" to work with s2api ?



-- 
Christophe Thommeret


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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Christophe Thommeret wrote:
> Le Thursday 25 September 2008 05:57:18 Manu Abraham, vous avez écrit :
>> Hans Verkuil wrote:
>>> Just work with Steve to convert the current devices in the multiproto
>>> tree to use this API. If there is anything missing kick Steve and he'll
>>> have to add whatever is needed. That's *his* responsibility and he
>>> accepted that during the discussions.
>> With the multiproto tree, you _don't_need_ to convert any devices to use
>> the new infrastructure, whereas with S2API you need to do that. This is
>> a major drawback. In the multiproto tree, all devices work just without
>> any conversion of any kind, also it is completely backward compatible.
>>
>> The aspect of backward compatibility and drivers not getting converted
>> had been a major issue, when the original DVB-S2 discussions came up.
>> This had been a design goal for the multiproto tree.


Please do not trim CC's.

> I'm not sure to get you Manu.
> Do you mean that existing drivers have to be "converted" to work with s2api ?

Yes, one of the existing drivers had to be converted. eg: CinergyT2

Also, the stb0899 driver (from the multiproto tree) also needs to be
converted, as far as anyone who is able to see, or from the posts
themselves.

The CX24116 is already existing in the multiproto tree, from Steven
himself. I did not pull this driver into the tree that i used for
testing because of all those mails Steven wrote: just wanted to stay
clear of it. But somebody else is having the same tree. Eventhough many
people had asked me to pull that driver in, because of all those mails,
i just stood clear of it.

You can read it from the public archives here on the same.

Regards,
Manu


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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Christophe Thommeret]

Le Thursday 25 September 2008 06:13:14 Manu Abraham, vous avez écrit :
> Christophe Thommeret wrote:
> > Le Thursday 25 September 2008 05:57:18 Manu Abraham, vous avez écrit :
> >> Hans Verkuil wrote:
> >>> Just work with Steve to convert the current devices in the multiproto
> >>> tree to use this API. If there is anything missing kick Steve and he'll
> >>> have to add whatever is needed. That's *his* responsibility and he
> >>> accepted that during the discussions.
> >>
> >> With the multiproto tree, you _don't_need_ to convert any devices to use
> >> the new infrastructure, whereas with S2API you need to do that. This is
> >> a major drawback. In the multiproto tree, all devices work just without
> >> any conversion of any kind, also it is completely backward compatible.
> >>
> >> The aspect of backward compatibility and drivers not getting converted
> >> had been a major issue, when the original DVB-S2 discussions came up.
> >> This had been a design goal for the multiproto tree.
>
> Please do not trim CC's.
>
> > I'm not sure to get you Manu.
> > Do you mean that existing drivers have to be "converted" to work with
> > s2api ?
>
> Yes, one of the existing drivers had to be converted. eg: CinergyT2

Ok, the cinergyT2 was indeed out of dvb-core, but a dvb-core driver already 
exists, so no problem :)

> Also, the stb0899 driver (from the multiproto tree) also needs to be
> converted, as far as anyone who is able to see, or from the posts
> themselves.

Of course :)
But this is not what i call an "existing" (in kernel) driver.

> The CX24116 is already existing in the multiproto tree, from Steven
> himself. I did not pull this driver into the tree that i used for
> testing because of all those mails Steven wrote: just wanted to stay
> clear of it. But somebody else is having the same tree. Eventhough many
> people had asked me to pull that driver in, because of all those mails,
> i just stood clear of it.
>
> You can read it from the public archives here on the same.

I know the story Manu.
But 2 years to get a new API is really too much. And during these 2 years, 2 
different trees for 2 differents drivers was totally insane. We (applications 
devs) are always making our best to bring DVB to users as easily as possible. 
And trust me, the multiproto story has complicated users life A LOT.
This must NEVER happen again.

-- 
Christophe Thommeret


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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Christophe Thommeret wrote:

>> You can read it from the public archives here on the same.
> 
> I know the story Manu.
> But 2 years to get a new API is really too much. And during these 2 years, 2 
> different trees for 2 differents drivers was totally insane.

Your history is incorrect.

> We (applications 
> devs) are always making our best to bring DVB to users as easily as possible. 
> And trust me, the multiproto story has complicated users life A LOT.

True. but much better to state the addition of DVB-S2 delivery system to
make it general.

> This must NEVER happen again. 

True.

Regards,
Manu

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

Re: [linux-dvb] [ANNOUNCE] DVB API improvements

[Manu Abraham]

Christophe Thommeret wrote:
> Le Thursday 25 September 2008 06:13:14 Manu Abraham, vous avez écrit :
>> Christophe Thommeret wrote:
>>> Le Thursday 25 September 2008 05:57:18 Manu Abraham, vous avez écrit :
>>>> Hans Verkuil wrote:
>>>>> Just work with Steve to convert the current devices in the multiproto
>>>>> tree to use this API. If there is anything missing kick Steve and he'll
>>>>> have to add whatever is needed. That's *his* responsibility and he
>>>>> accepted that during the discussions.
>>>> With the multiproto tree, you _don't_need_ to convert any devices to use
>>>> the new infrastructure, whereas with S2API you need to do that. This is
>>>> a major drawback. In the multiproto tree, all devices work just without
>>>> any conversion of any kind, also it is completely backward compatible.
>>>>
>>>> The aspect of backward compatibility and drivers not getting converted
>>>> had been a major issue, when the original DVB-S2 discussions came up.
>>>> This had been a design goal for the multiproto tree.
>> Please do not trim CC's.
>>
>>> I'm not sure to get you Manu.
>>> Do you mean that existing drivers have to be "converted" to work with
>>> s2api ?
>> Yes, one of the existing drivers had to be converted. eg: CinergyT2
> 
> Ok, the cinergyT2 was indeed out of dvb-core, but a dvb-core driver already 
> exists, so no problem :)


config DVB_CINERGYT2
	tristate "Terratec CinergyT2/qanu USB2 DVB-T receiver"
	depends on DVB_CORE && USB && INPUT
	help
	  Support for "TerraTec CinergyT2" USB2.0 Highspeed DVB Receivers

The reworked/modified one doesn't work as good as the original one as
was written by somebody else.


>> Also, the stb0899 driver (from the multiproto tree) also needs to be
>> converted, as far as anyone who is able to see, or from the posts
>> themselves.
> 
> Of course :)
> But this is not what i call an "existing" (in kernel) driver.


What i meant is that no driver, needs to be modified with multiproto
whatsoever your argument is.

Regards,
Manu


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