Re: [linux-dvb] Multiproto API/Driver Update

Re: [linux-dvb] Multiproto API/Driver Update

[Markus Rechberger]

On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
> Markus Rechberger wrote:
>
>> How many devices are currently supported by the multiproto API
>> compared with the s2 tree?
>
> The initial set of DVB-S2 multistandard devices supported by the
> multiproto tree is follows. This is just the stb0899 based dvb-s2 driver
> alone. There are more additions by 2 more modules (not devices), but for
> the simple comparison here is the quick list of them, for which some of
> the manufacturers have shown support in some way. (There has been quite
> some contributions from the community as well.):
>
> (Also to be noted is that, some BSD chaps also have shown interest in
> the same)
>

they're heavy into moving the whole framework over as far as I've seen
yes, also including yet unmerged drivers.

> * STB0899 based
>
> Anubis
> Typhoon DVB-S2 PCI
>
> Azurewave/Twinhan
> VP-1041
> VP-7050
>
> Digital Now
> AD SP400
> AD SB300
>
> KNC1
> TV Station DVB-S2
> TV Station DVB-S2 Plus
>
> Pinnacle
> PCTV Sat HDTV Pro USB 452e
>
> Satelco
> TV Station DVB-S2
> Easywatch HDTV USB CI
> Easywatch HDTV PCI
>
> Technisat
> Skystar HD
> Skystar HD2
> Skystar USB2 HDCI
>
> Technotrend
> TT S2 3200
> TT S2 3600
> TT S2 3650
>
> Terratec
> Cinergy S2 PCI HD
> Cinergy S2 PCI HDCI
>

those are pullable now against the current tree?

Markus

Re: [linux-dvb] Multiproto API/Driver Update

[Manu Abraham]

Markus Rechberger wrote:
> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
>> Markus Rechberger wrote:
>>
>>> How many devices are currently supported by the multiproto API
>>> compared with the s2 tree?
>> The initial set of DVB-S2 multistandard devices supported by the
>> multiproto tree is follows. This is just the stb0899 based dvb-s2 driver
>> alone. There are more additions by 2 more modules (not devices), but for
>> the simple comparison here is the quick list of them, for which some of
>> the manufacturers have shown support in some way. (There has been quite
>> some contributions from the community as well.):
>>
>> (Also to be noted is that, some BSD chaps also have shown interest in
>> the same)
>>
> 
> they're heavy into moving the whole framework over as far as I've seen
> yes, also including yet unmerged drivers.


Using the same interface, the same applications will work there as well
which is a bonus, but isn't the existing user interface GPL ? (A bit
confused on that aspect)


>> * STB0899 based
>>
>> Anubis
>> Typhoon DVB-S2 PCI
>>
>> Azurewave/Twinhan
>> VP-1041
>> VP-7050
>>
>> Digital Now
>> AD SP400
>> AD SB300
>>
>> KNC1
>> TV Station DVB-S2
>> TV Station DVB-S2 Plus
>>
>> Pinnacle
>> PCTV Sat HDTV Pro USB 452e
>>
>> Satelco
>> TV Station DVB-S2
>> Easywatch HDTV USB CI
>> Easywatch HDTV PCI
>>
>> Technisat
>> Skystar HD
>> Skystar HD2
>> Skystar USB2 HDCI
>>
>> Technotrend
>> TT S2 3200
>> TT S2 3600
>> TT S2 3650
>>
>> Terratec
>> Cinergy S2 PCI HD
>> Cinergy S2 PCI HDCI
>>
> 
> those are pullable now against the current tree?


These devices, depend upon the DVB API update without which it wouldn't
work as they depend heavily on the DVB API framework. Without the
updated framework, it doesn't make any sense to pull them: they won't
even compile. The last but not least reason is that, the stb0899 driver
is a DVB-S2 multistandard device which requires DVB-S2/DSS support
additionally.

Regards,
Manu

Re: [linux-dvb] Multiproto API/Driver Update

[Markus Rechberger]

On Sun, Sep 14, 2008 at 1:31 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
> Markus Rechberger wrote:
>> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
>>> Markus Rechberger wrote:
>>>
>>>> How many devices are currently supported by the multiproto API
>>>> compared with the s2 tree?
>>> The initial set of DVB-S2 multistandard devices supported by the
>>> multiproto tree is follows. This is just the stb0899 based dvb-s2 driver
>>> alone. There are more additions by 2 more modules (not devices), but for
>>> the simple comparison here is the quick list of them, for which some of
>>> the manufacturers have shown support in some way. (There has been quite
>>> some contributions from the community as well.):
>>>
>>> (Also to be noted is that, some BSD chaps also have shown interest in
>>> the same)
>>>
>>
>> they're heavy into moving the whole framework over as far as I've seen
>> yes, also including yet unmerged drivers.
>
>
> Using the same interface, the same applications will work there as well
> which is a bonus, but isn't the existing user interface GPL ? (A bit
> confused on that aspect)
>

I think it's good to have something that competes with Linux, I talked to some
guys at that front too, and they seem to work close with application
developers too
As for the em28xx driver I agreed with pushing all my code (in case of
linux, which
includes unmerged independent drivercode from manufacturers) into their system
using their license.

>
>>> * STB0899 based
>>>
>>> Anubis
>>> Typhoon DVB-S2 PCI
>>>
>>> Azurewave/Twinhan
>>> VP-1041
>>> VP-7050
>>>
>>> Digital Now
>>> AD SP400
>>> AD SB300
>>>
>>> KNC1
>>> TV Station DVB-S2
>>> TV Station DVB-S2 Plus
>>>
>>> Pinnacle
>>> PCTV Sat HDTV Pro USB 452e
>>>
>>> Satelco
>>> TV Station DVB-S2
>>> Easywatch HDTV USB CI
>>> Easywatch HDTV PCI
>>>
>>> Technisat
>>> Skystar HD
>>> Skystar HD2
>>> Skystar USB2 HDCI
>>>
>>> Technotrend
>>> TT S2 3200
>>> TT S2 3600
>>> TT S2 3650
>>>
>>> Terratec
>>> Cinergy S2 PCI HD
>>> Cinergy S2 PCI HDCI
>>>
>>
>> those are pullable now against the current tree?
>
>
> These devices, depend upon the DVB API update without which it wouldn't
> work as they depend heavily on the DVB API framework. Without the
> updated framework, it doesn't make any sense to pull them: they won't
> even compile. The last but not least reason is that, the stb0899 driver
> is a DVB-S2 multistandard device which requires DVB-S2/DSS support
> additionally.
>

as far as I understood here it's that alot code is already available
and has been tested for
a couple of years, a few guys are trying to run their own game since
they already have
 "some" code, and the problem is that people would have to port your
drivers to the
other system without your support. We've seen the same issue with the
em28xx a year ago,
although this one is participating at the BSD and OSX project now too
(which takes the same
source and makes alot more sence in terms of contributions).
As soon as the em28xx code supports the mt2060 and saa7114 devices it
would be ready
to go into the kernel again separated from linuxtv...

Markus

Re: [linux-dvb] Multiproto API/Driver Update

[Steven Toth]

Markus Rechberger wrote:
> On Sun, Sep 14, 2008 at 1:31 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
>> Markus Rechberger wrote:
>>> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
>>>> Markus Rechberger wrote:
>>>>
>>>>> How many devices are currently supported by the multiproto API
>>>>> compared with the s2 tree?
>>>> The initial set of DVB-S2 multistandard devices supported by the
>>>> multiproto tree is follows. This is just the stb0899 based dvb-s2 driver
>>>> alone. There are more additions by 2 more modules (not devices), but for
>>>> the simple comparison here is the quick list of them, for which some of
>>>> the manufacturers have shown support in some way. (There has been quite
>>>> some contributions from the community as well.):
>>>>
>>>> (Also to be noted is that, some BSD chaps also have shown interest in
>>>> the same)
>>>>
>>> they're heavy into moving the whole framework over as far as I've seen
>>> yes, also including yet unmerged drivers.
>>
>> Using the same interface, the same applications will work there as well
>> which is a bonus, but isn't the existing user interface GPL ? (A bit
>> confused on that aspect)
>>
> 
> I think it's good to have something that competes with Linux, I talked to some
> guys at that front too, and they seem to work close with application
> developers too
> As for the em28xx driver I agreed with pushing all my code (in case of
> linux, which
> includes unmerged independent drivercode from manufacturers) into their system
> using their license.

Something that competes with Linux, absolutely, I could not agree more - 
especially if the licenses are compatible and cross O/S pollination of 
ideas/code can occur. Everyone benefits from this.

Hauppauge had a guy from the BSD community contact us and ask for 
datasheets for certain parts. Part of the problem, as I understand it, 
is that the BSD folks can't port the GPL license into BSD because it's 
not compatible.

I owe it to myself to spend somehime reading the BSD licencing. Maybe 
the GPL is compatible with BSD.

Just my 2 cents.

- Steve

Re: [linux-dvb] Multiproto API/Driver Update

[Markus Rechberger]

On Sun, Sep 14, 2008 at 1:31 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
> Markus Rechberger wrote:
>> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
>>> Markus Rechberger wrote:
>>>
>>>> How many devices are currently supported by the multiproto API
>>>> compared with the s2 tree?
>>> The initial set of DVB-S2 multistandard devices supported by the
>>> multiproto tree is follows. This is just the stb0899 based dvb-s2 driver
>>> alone. There are more additions by 2 more modules (not devices), but for
>>> the simple comparison here is the quick list of them, for which some of
>>> the manufacturers have shown support in some way. (There has been quite
>>> some contributions from the community as well.):
>>>
>>> (Also to be noted is that, some BSD chaps also have shown interest in
>>> the same)
>>>
>>
>> they're heavy into moving the whole framework over as far as I've seen
>> yes, also including yet unmerged drivers.
>
>
> Using the same interface, the same applications will work there as well
> which is a bonus, but isn't the existing user interface GPL ? (A bit
> confused on that aspect)
>
>
>>> * STB0899 based
>>>
>>> Anubis
>>> Typhoon DVB-S2 PCI
>>>
>>> Azurewave/Twinhan
>>> VP-1041
>>> VP-7050
>>>
>>> Digital Now
>>> AD SP400
>>> AD SB300
>>>
>>> KNC1
>>> TV Station DVB-S2
>>> TV Station DVB-S2 Plus
>>>
>>> Pinnacle
>>> PCTV Sat HDTV Pro USB 452e
>>>
>>> Satelco
>>> TV Station DVB-S2
>>> Easywatch HDTV USB CI
>>> Easywatch HDTV PCI
>>>
>>> Technisat
>>> Skystar HD
>>> Skystar HD2
>>> Skystar USB2 HDCI
>>>
>>> Technotrend
>>> TT S2 3200
>>> TT S2 3600
>>> TT S2 3650
>>>
>>> Terratec
>>> Cinergy S2 PCI HD
>>> Cinergy S2 PCI HDCI
>>>
>>
>> those are pullable now against the current tree?
>
>
> These devices, depend upon the DVB API update without which it wouldn't
> work as they depend heavily on the DVB API framework. Without the
> updated framework, it doesn't make any sense to pull them: they won't
> even compile. The last but not least reason is that, the stb0899 driver
> is a DVB-S2 multistandard device which requires DVB-S2/DSS support
> additionally.
>

so the framework is available, and the drivers could be pushed in
right afterwards, I wonder
who is willing to port those drivers to the other API (including testing).
It's not going to happen any time soon I guess, if there's not an
agreement with Manu's
work. Dumping this code would show another step of ignorance and
selfishness against the
people who worked on it.

Markus

Re: [linux-dvb] Multiproto API/Driver Update

[Steven Toth]

Markus Rechberger wrote:
> On Sun, Sep 14, 2008 at 1:31 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
>> Markus Rechberger wrote:
>>> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
>>>> Markus Rechberger wrote:
>>>>
>>>>> How many devices are currently supported by the multiproto API
>>>>> compared with the s2 tree?
>>>> The initial set of DVB-S2 multistandard devices supported by the
>>>> multiproto tree is follows. This is just the stb0899 based dvb-s2 driver
>>>> alone. There are more additions by 2 more modules (not devices), but for
>>>> the simple comparison here is the quick list of them, for which some of
>>>> the manufacturers have shown support in some way. (There has been quite
>>>> some contributions from the community as well.):
>>>>
>>>> (Also to be noted is that, some BSD chaps also have shown interest in
>>>> the same)
>>>>
>>> they're heavy into moving the whole framework over as far as I've seen
>>> yes, also including yet unmerged drivers.
>>
>> Using the same interface, the same applications will work there as well
>> which is a bonus, but isn't the existing user interface GPL ? (A bit
>> confused on that aspect)
>>
>>
>>>> * STB0899 based
>>>>
>>>> Anubis
>>>> Typhoon DVB-S2 PCI
>>>>
>>>> Azurewave/Twinhan
>>>> VP-1041
>>>> VP-7050
>>>>
>>>> Digital Now
>>>> AD SP400
>>>> AD SB300
>>>>
>>>> KNC1
>>>> TV Station DVB-S2
>>>> TV Station DVB-S2 Plus
>>>>
>>>> Pinnacle
>>>> PCTV Sat HDTV Pro USB 452e
>>>>
>>>> Satelco
>>>> TV Station DVB-S2
>>>> Easywatch HDTV USB CI
>>>> Easywatch HDTV PCI
>>>>
>>>> Technisat
>>>> Skystar HD
>>>> Skystar HD2
>>>> Skystar USB2 HDCI
>>>>
>>>> Technotrend
>>>> TT S2 3200
>>>> TT S2 3600
>>>> TT S2 3650
>>>>
>>>> Terratec
>>>> Cinergy S2 PCI HD
>>>> Cinergy S2 PCI HDCI
>>>>
>>> those are pullable now against the current tree?
>>
>> These devices, depend upon the DVB API update without which it wouldn't
>> work as they depend heavily on the DVB API framework. Without the
>> updated framework, it doesn't make any sense to pull them: they won't
>> even compile. The last but not least reason is that, the stb0899 driver
>> is a DVB-S2 multistandard device which requires DVB-S2/DSS support
>> additionally.
>>
> 
> so the framework is available, and the drivers could be pushed in
> right afterwards, I wonder
> who is willing to port those drivers to the other API (including testing).

Me. I'll port the 3200 cards and their derivatives, including the 6100 
and the 0899. I've already said I'd do that.... but it's manu's code and 
he retains all rights. He gets to decide first.


> It's not going to happen any time soon I guess, if there's not an
> agreement with Manu's
> work. Dumping this code would show another step of ignorance and
> selfishness against the
> people who worked on it.


The demod/tuners drivers would be merged with S2API within a few days. I 
have a TT-3200 here. I'd have to re-write various things, and change the 
demod API a little. but I'm prepared to do that.

Judging by the positive response we're having to the S2API tree, I 
suspect a number of people will be willing to offer patches, test time 
and support.

- Steve

Re: [linux-dvb] Multiproto API/Driver Update

[Manu Abraham]

Steven Toth wrote:
> Markus Rechberger wrote:
>> On Sun, Sep 14, 2008 at 1:31 AM, Manu Abraham <abraham.manu@gmail.com>
>> wrote:
>>> Markus Rechberger wrote:
>>>> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham
>>>> <abraham.manu@gmail.com> wrote:
>>>>> Markus Rechberger wrote:
>>>>>
>>>>>> How many devices are currently supported by the multiproto API
>>>>>> compared with the s2 tree?
>>>>> The initial set of DVB-S2 multistandard devices supported by the
>>>>> multiproto tree is follows. This is just the stb0899 based dvb-s2
>>>>> driver
>>>>> alone. There are more additions by 2 more modules (not devices),
>>>>> but for
>>>>> the simple comparison here is the quick list of them, for which
>>>>> some of
>>>>> the manufacturers have shown support in some way. (There has been
>>>>> quite
>>>>> some contributions from the community as well.):
>>>>>
>>>>> (Also to be noted is that, some BSD chaps also have shown interest in
>>>>> the same)
>>>>>
>>>> they're heavy into moving the whole framework over as far as I've seen
>>>> yes, also including yet unmerged drivers.
>>>
>>> Using the same interface, the same applications will work there as well
>>> which is a bonus, but isn't the existing user interface GPL ? (A bit
>>> confused on that aspect)
>>>
>>>
>>>>> * STB0899 based
>>>>>
>>>>> Anubis
>>>>> Typhoon DVB-S2 PCI
>>>>>
>>>>> Azurewave/Twinhan
>>>>> VP-1041
>>>>> VP-7050
>>>>>
>>>>> Digital Now
>>>>> AD SP400
>>>>> AD SB300
>>>>>
>>>>> KNC1
>>>>> TV Station DVB-S2
>>>>> TV Station DVB-S2 Plus
>>>>>
>>>>> Pinnacle
>>>>> PCTV Sat HDTV Pro USB 452e
>>>>>
>>>>> Satelco
>>>>> TV Station DVB-S2
>>>>> Easywatch HDTV USB CI
>>>>> Easywatch HDTV PCI
>>>>>
>>>>> Technisat
>>>>> Skystar HD
>>>>> Skystar HD2
>>>>> Skystar USB2 HDCI
>>>>>
>>>>> Technotrend
>>>>> TT S2 3200
>>>>> TT S2 3600
>>>>> TT S2 3650
>>>>>
>>>>> Terratec
>>>>> Cinergy S2 PCI HD
>>>>> Cinergy S2 PCI HDCI
>>>>>
>>>> those are pullable now against the current tree?
>>>
>>> These devices, depend upon the DVB API update without which it wouldn't
>>> work as they depend heavily on the DVB API framework. Without the
>>> updated framework, it doesn't make any sense to pull them: they won't
>>> even compile. The last but not least reason is that, the stb0899 driver
>>> is a DVB-S2 multistandard device which requires DVB-S2/DSS support
>>> additionally.
>>>
>>
>> so the framework is available, and the drivers could be pushed in
>> right afterwards, I wonder
>> who is willing to port those drivers to the other API (including
>> testing).
> 
> Me. I'll port the 3200 cards and their derivatives, including the 6100
> and the 0899. I've already said I'd do that.... but it's manu's code and
> he retains all rights. He gets to decide first.


The STB0899 based devices are much different from the crappy handicapped
Hauppauge S2 cards and hence the API that you work upon is quite limited
to what you see with regards to the Hauppauge (CX24116 based) cards.

Even the bare specifications from Conexant point to a handicapped DVB-S2
demodulator.

Attempts to do so, will break those devices at least for most of the
features and more yet to come. The DVB-S2 transport is a bit more
advanced delivery system than what your API based on the CX24116
demodulator.

At least it will be great for Hauppauge as you can point to people that
Hauppauge hardware is much better, for the marketing aspects as you have
done in the past on IRC lists.

Very good marketing strategy, Steven keep it up, you have earned more
sales for the Hauppauge cards ...
<claps hands>

>> It's not going to happen any time soon I guess, if there's not an
>> agreement with Manu's
>> work. Dumping this code would show another step of ignorance and
>> selfishness against the
>> people who worked on it.
> 
> 
> The demod/tuners drivers would be merged with S2API within a few days. I
> have a TT-3200 here. I'd have to re-write various things, and change the
> demod API a little. but I'm prepared to do that.

Just having a TT 3200 won't help working on the STB0899. Almost everyone
who has a STB0899 based knows that, except you.

No need for you to break the compliant devices in favour of your
mediocre cards. As i wrote just above, the STB0899 is not the only one
device using the said features. Also i can guarantee that the CX24116
(HVR4000) is the most handicapped DVB-S2 device that you are basing the
DVB-S2 API on: and i can guarantee that what you do will be just be
broken as you have done for other devices in the past.

Also i do not understand, why you have to make a lot of noise to port
the STB0899 drivers to your crap, when all your cards work as expected
by you with the multiproto tree. I don't see any reason why the STB0899
has to be ported to the handicapped API of yours, handicapping the
STB0899 based devices.

HTH
Manu

Re: [linux-dvb] Multiproto API/Driver Update

[Andy Walls]

On Sun, 2008-09-14 at 22:51 +0400, Manu Abraham wrote:
> Steven Toth wrote:
> > Markus Rechberger wrote:
> >> On Sun, Sep 14, 2008 at 1:31 AM, Manu Abraham <abraham.manu@gmail.com>
> >> wrote:
> >>> Markus Rechberger wrote:
> >>>> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham
> >>>> <abraham.manu@gmail.com> wrote:
> >>>>> Markus Rechberger wrote:

 
> > Me. I'll port the 3200 cards and their derivatives, including the 6100
> > and the 0899. I've already said I'd do that.... but it's manu's code and
> > he retains all rights. He gets to decide first.
> 
> 
> The STB0899 based devices are much different from the crappy handicapped
> Hauppauge S2 cards and hence the API that you work upon is quite limited
> to what you see with regards to the Hauppauge (CX24116 based) cards.
> 
> Even the bare specifications from Conexant point to a handicapped DVB-S2
> demodulator.
> 
> Attempts to do so, will break those devices at least for most of the
> features and more yet to come. The DVB-S2 transport is a bit more
> advanced delivery system than what your API based on the CX24116
> demodulator.
> 
> At least it will be great for Hauppauge as you can point to people that
> Hauppauge hardware is much better, for the marketing aspects as you have
> done in the past on IRC lists.
> 
> Very good marketing strategy, Steven keep it up, you have earned more
> sales for the Hauppauge cards ...
> <claps hands>


Manu,

Though I can't read much German, after looking at the jusst.de website I
can't help but think that you as well have financial interests driving
your actions.  If so, then your statements display quite a bit of
hypocrisy.

Manipulating (i.e. stalling) the timing of Multiproto being merged into
the v4l-dvb tree or kernel, for you or your employer's gain, would be
little different from the motivations you allege Steve of having.

Since the major gripe I'm reading on the list "is that multiproto has
taken too long" and since it seems to me the only thing that shook it
loose was a competing proposal, please save the venom for when you
actually have some clear moral high-ground to stand on.  I don't see it
from here.
 


As for the technical superiority of either API proposal; that probably
just doesn't matter.  I've seen policy/political decisions force
suboptimal technical solutions at work time and time again.  If you
really believe you have a superior product technically; then perhaps you
should work to make it superior politically as well.  Mud-slinging can't
be a good long term strategy toward that end.



Regards,
Andy

Re: [linux-dvb] Multiproto API/Driver Update

[Manu Abraham]

Andy,


Andy Walls wrote:

> Manu,
> 
> Though I can't read much German, after looking at the jusst.de website I
> can't help but think that you as well have financial interests driving
> your actions.  If so, then your statements display quite a bit of
> hypocrisy.

To your utter disappointment as i should say, i am not working for any
vendor, but just get device support out to the community.

The jusst.de domain is owned by Julian Scheel who runs Jusst
Technologies, just happened to offer me hosting for me repositories for
my work, using full ssh access, so that my workflow is easier.

Not that i have anything to do with jusst.de otherwise. OTOH, i do have
the patches at kernel.org

Maybe Julian can comment on this to make things more clearer on the
financial interests.


> Manipulating (i.e. stalling) the timing of Multiproto being merged into
> the v4l-dvb tree or kernel, for you or your employer's gain, would be
> little different from the motivations you allege Steve of having.


I am not manipulating any timing of multiproto being merged. In fact i
had been away, for a few months due to certain reasons, that you are
perfectly aware by now as far as i can understand. So the points that
you raise are quite baseless.


> Since the major gripe I'm reading on the list "is that multiproto has
> taken too long" and since it seems to me the only thing that shook it
> loose was a competing proposal, please save the venom for when you
> actually have some clear moral high-ground to stand on.  I don't see it
> from here.

Crap, just read above.


> As for the technical superiority of either API proposal; that probably
> just doesn't matter.  I've seen policy/political decisions force
> suboptimal technical solutions at work time and time again.  If you
> really believe you have a superior product technically; then perhaps you
> should work to make it superior politically as well.  Mud-slinging can't
> be a good long term strategy toward that end.


I don't have to do any mud-slinging, just wrote the exact facts out here.


Regards,
Manu

Re: [linux-dvb] Multiproto API/Driver Update

[Andy Walls]

On Mon, 2008-09-15 at 01:01 +0400, Manu Abraham wrote:
> Andy,
> 
> 
> Andy Walls wrote:
> 
> > Manu,
> > 
> > Though I can't read much German, after looking at the jusst.de website I
> > can't help but think that you as well have financial interests driving
> > your actions.  If so, then your statements display quite a bit of
> > hypocrisy.
> 
> To your utter disappointment as i should say, i am not working for any
> vendor, but just get device support out to the community.

Not to my disappointment.  I'm glad to hear it.  Someone who appears to
have an EE background without corporate bias can be an asset to the
community. 


> The jusst.de domain is owned by Julian Scheel who runs Jusst
> Technologies, just happened to offer me hosting for me repositories for
> my work, using full ssh access, so that my workflow is easier.
> 
> Not that i have anything to do with jusst.de otherwise. OTOH, i do have
> the patches at kernel.org
> 
> Maybe Julian can comment on this to make things more clearer on the
> financial interests.

Then what I perceived was wrong.  My apologies.



> > Manipulating (i.e. stalling) the timing of Multiproto being merged into
> > the v4l-dvb tree or kernel, for you or your employer's gain, would be
> > little different from the motivations you allege Steve of having.
> 
> 
> I am not manipulating any timing of multiproto being merged. In fact i
> had been away, for a few months due to certain reasons, that you are
> perfectly aware by now as far as i can understand.

I was aware you were away.  For what dates I do not know (I have emails
from you in May 2008).  For what reasons, I do not know for sure (nor do
I feel is it my business).



>  So the points that
> you raise are quite baseless.

Not entirely, there is a basis for the timing point.  The pull requests
seemed to have come in short order when confronted with a competing
proposal.  Yet the project had been ongoing for at least over a year (as
far as I can ascertain).  Here's a gripe about delays from Jan 2008:
http://www.mail-archive.com/linux-dvb@linuxtv.org/msg28606.html

There seemed to have been no other visible motivation for the pull
requests except competition.  



> > Since the major gripe I'm reading on the list "is that multiproto has
> > taken too long" and since it seems to me the only thing that shook it
> > loose was a competing proposal, please save the venom for when you
> > actually have some clear moral high-ground to stand on.  I don't see it
> > from here.
> 
> Crap, just read above.

OK, then you do have some high ground.  But you also had essentially a
monopoly position and now you have competition.  That is not crap. 


> > As for the technical superiority of either API proposal; that probably
> > just doesn't matter.  I've seen policy/political decisions force
> > suboptimal technical solutions at work time and time again.  If you
> > really believe you have a superior product technically; then perhaps you
> > should work to make it superior politically as well.  Mud-slinging can't
> > be a good long term strategy toward that end.
> 
> 
> I don't have to do any mud-slinging, just wrote the exact facts out here.

No, you are mud slinging.  Let's count the derogatory terms you use in
addressing your competition in the following quote:

"No need for you to break the compliant devices in favour of your
mediocre cards. As i wrote just above, the STB0899 is not the only one
device using the said features. Also i can guarantee that the CX24116
(HVR4000) is the most handicapped DVB-S2 device that you are basing the
DVB-S2 API on: and i can guarantee that what you do will be just be
broken as you have done for other devices in the past."

"Also i do not understand, why you have to make a lot of noise to port
the STB0899 drivers to your crap, when all your cards work as expected
by you with the multiproto tree. I don't see any reason why the STB0899
has to be ported to the handicapped API of yours, handicapping the
STB0899 based devices."


1 mediocre
3 handicap (or variation thereof)
1 crap
2 break (or variation thereof) when referring to competing work
1 noise, when referring to another offer to do work competing work

And that's just part of the email.  I'd hate to read when you actually
claim to be mud-slinging.

Regards,
Andy

> Regards,
> Manu

Re: [linux-dvb] Multiproto API/Driver Update

[Manu Abraham]

Andy Walls wrote:
> On Mon, 2008-09-15 at 01:01 +0400, Manu Abraham wrote:
>> Andy,
>>
>>
>> Andy Walls wrote:
>>
>>> Manu,
>>>
>>> Though I can't read much German, after looking at the jusst.de website I
>>> can't help but think that you as well have financial interests driving
>>> your actions.  If so, then your statements display quite a bit of
>>> hypocrisy.
>> To your utter disappointment as i should say, i am not working for any
>> vendor, but just get device support out to the community.
> 
> Not to my disappointment.  I'm glad to hear it.  Someone who appears to
> have an EE background without corporate bias can be an asset to the
> community. 
> 
> 
>> The jusst.de domain is owned by Julian Scheel who runs Jusst
>> Technologies, just happened to offer me hosting for me repositories for
>> my work, using full ssh access, so that my workflow is easier.
>>
>> Not that i have anything to do with jusst.de otherwise. OTOH, i do have
>> the patches at kernel.org
>>
>> Maybe Julian can comment on this to make things more clearer on the
>> financial interests.
> 
> Then what I perceived was wrong.  My apologies.
> 
> 
> 
>>> Manipulating (i.e. stalling) the timing of Multiproto being merged into
>>> the v4l-dvb tree or kernel, for you or your employer's gain, would be
>>> little different from the motivations you allege Steve of having.
>>
>> I am not manipulating any timing of multiproto being merged. In fact i
>> had been away, for a few months due to certain reasons, that you are
>> perfectly aware by now as far as i can understand.
> 
> I was aware you were away.  For what dates I do not know (I have emails
> from you in May 2008).  For what reasons, I do not know for sure (nor do
> I feel is it my business).
> 
> 
> 
>>  So the points that
>> you raise are quite baseless.
> 
> Not entirely, there is a basis for the timing point.  The pull requests
> seemed to have come in short order when confronted with a competing
> proposal.  Yet the project had been ongoing for at least over a year (as
> far as I can ascertain).  Here's a gripe about delays from Jan 2008:
> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg28606.html
> 
> There seemed to have been no other visible motivation for the pull
> requests except competition.


I got back on the beginning of September.


>>> Since the major gripe I'm reading on the list "is that multiproto has
>>> taken too long" and since it seems to me the only thing that shook it
>>> loose was a competing proposal, please save the venom for when you
>>> actually have some clear moral high-ground to stand on.  I don't see it
>>> from here.
>> Crap, just read above.
> 
> OK, then you do have some high ground.  But you also had essentially a
> monopoly position and now you have competition.  That is not crap. 
> 

Monopoly, competition .. sounds nonsense to me.


>>> As for the technical superiority of either API proposal; that probably
>>> just doesn't matter.  I've seen policy/political decisions force
>>> suboptimal technical solutions at work time and time again.  If you
>>> really believe you have a superior product technically; then perhaps you
>>> should work to make it superior politically as well.  Mud-slinging can't
>>> be a good long term strategy toward that end.
>>
>> I don't have to do any mud-slinging, just wrote the exact facts out here.
> 
> No, you are mud slinging.  Let's count the derogatory terms you use in
> addressing your competition in the following quote:
> 
> "No need for you to break the compliant devices in favour of your
> mediocre cards. As i wrote just above, the STB0899 is not the only one
> device using the said features. Also i can guarantee that the CX24116
> (HVR4000) is the most handicapped DVB-S2 device that you are basing the


Conexant themselves mentions what their demodulators can do. (In fact,
they stopped their satellite demodulator businesses and sold it to NXP,
AFAIK) I don't know what you want to add more into it, what Conexant
hasn't. Only basic 8PSK NBC mode of operation. The DVB-S2 specification
and supported devices do a lot more than that.


> DVB-S2 API on: and i can guarantee that what you do will be just be
> broken as you have done for other devices in the past."


> "Also i do not understand, why you have to make a lot of noise to port
> the STB0899 drivers to your crap, when all your cards work as expected
> by you with the multiproto tree. I don't see any reason why the STB0899
> has to be ported to the handicapped API of yours, handicapping the
> STB0899 based devices."


True it is.


Regards,
Manu

Re: [linux-dvb] Multiproto API/Driver Update

[hermann pitton]

Am Sonntag, den 14.09.2008, 18:20 -0400 schrieb Andy Walls:
> On Mon, 2008-09-15 at 01:01 +0400, Manu Abraham wrote:
> > Andy,
> > 
> > 
> > Andy Walls wrote:
> > 
> > > Manu,
> > > 
> > > Though I can't read much German, after looking at the jusst.de website I
> > > can't help but think that you as well have financial interests driving
> > > your actions.  If so, then your statements display quite a bit of
> > > hypocrisy.
> > 
> > To your utter disappointment as i should say, i am not working for any
> > vendor, but just get device support out to the community.
> 
> Not to my disappointment.  I'm glad to hear it.  Someone who appears to
> have an EE background without corporate bias can be an asset to the
> community. 
> 
> 
> > The jusst.de domain is owned by Julian Scheel who runs Jusst
> > Technologies, just happened to offer me hosting for me repositories for
> > my work, using full ssh access, so that my workflow is easier.
> > 
> > Not that i have anything to do with jusst.de otherwise. OTOH, i do have
> > the patches at kernel.org
> > 
> > Maybe Julian can comment on this to make things more clearer on the
> > financial interests.
> 
> Then what I perceived was wrong.  My apologies.
> 
> 
> 
> > > Manipulating (i.e. stalling) the timing of Multiproto being merged into
> > > the v4l-dvb tree or kernel, for you or your employer's gain, would be
> > > little different from the motivations you allege Steve of having.
> > 
> > 
> > I am not manipulating any timing of multiproto being merged. In fact i
> > had been away, for a few months due to certain reasons, that you are
> > perfectly aware by now as far as i can understand.
> 
> I was aware you were away.  For what dates I do not know (I have emails
> from you in May 2008).  For what reasons, I do not know for sure (nor do
> I feel is it my business).
> 
> 
> 
> >  So the points that
> > you raise are quite baseless.
> 
> Not entirely, there is a basis for the timing point.  The pull requests
> seemed to have come in short order when confronted with a competing
> proposal.  Yet the project had been ongoing for at least over a year (as
> far as I can ascertain).  Here's a gripe about delays from Jan 2008:
> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg28606.html
> 
> There seemed to have been no other visible motivation for the pull
> requests except competition.  
> 
> 
> 
> > > Since the major gripe I'm reading on the list "is that multiproto has
> > > taken too long" and since it seems to me the only thing that shook it
> > > loose was a competing proposal, please save the venom for when you
> > > actually have some clear moral high-ground to stand on.  I don't see it
> > > from here.
> > 
> > Crap, just read above.
> 
> OK, then you do have some high ground.  But you also had essentially a
> monopoly position and now you have competition.  That is not crap. 
> 
> 
> > > As for the technical superiority of either API proposal; that probably
> > > just doesn't matter.  I've seen policy/political decisions force
> > > suboptimal technical solutions at work time and time again.  If you
> > > really believe you have a superior product technically; then perhaps you
> > > should work to make it superior politically as well.  Mud-slinging can't
> > > be a good long term strategy toward that end.
> > 
> > 
> > I don't have to do any mud-slinging, just wrote the exact facts out here.
> 
> No, you are mud slinging.  Let's count the derogatory terms you use in
> addressing your competition in the following quote:
> 
> "No need for you to break the compliant devices in favour of your
> mediocre cards. As i wrote just above, the STB0899 is not the only one
> device using the said features. Also i can guarantee that the CX24116
> (HVR4000) is the most handicapped DVB-S2 device that you are basing the
> DVB-S2 API on: and i can guarantee that what you do will be just be
> broken as you have done for other devices in the past."
> 
> "Also i do not understand, why you have to make a lot of noise to port
> the STB0899 drivers to your crap, when all your cards work as expected
> by you with the multiproto tree. I don't see any reason why the STB0899
> has to be ported to the handicapped API of yours, handicapping the
> STB0899 based devices."
> 
> 
> 1 mediocre
> 3 handicap (or variation thereof)
> 1 crap
> 2 break (or variation thereof) when referring to competing work
> 1 noise, when referring to another offer to do work competing work
> 
> And that's just part of the email.  I'd hate to read when you actually
> claim to be mud-slinging.
> 
> Regards,
> Andy
> 
> > Regards,
> > Manu
> 

Andy,

you are straight into it, at the point.

Don't believe any other, or say it was me, giving you a bad hint.

Hermann

Re: [linux-dvb] Multiproto API/Driver Update

[Manu Abraham]

Andy,


Andy Walls wrote:

> Manu,
> 
> Though I can't read much German, after looking at the jusst.de website I


A piece that i forgot to write. Just like what you said, i too can't
read German that much what you can even.


Regards,
Manu

Re: [linux-dvb] Multiproto API/Driver Update

[Julian Scheel]

Andy,

just to clarify things a bit I'll give a short statement now.

Andy Walls schrieb:
> Though I can't read much German, after looking at the jusst.de website I
> can't help but think that you as well have financial interests driving
> your actions.  If so, then your statements display quite a bit of
> hypocrisy.
>   
The role of jusst technologies in the whole multiproto story is as 
following:
The time when DVB-S2 came up this was of course of major interest for 
jusst technologies, so we searched for people working on drivers. At 
that not many people did seem to care about this stuff - but Manu did. 
So we got in contact and tried to help him as much as we can, which 
included making up connections to KNC1 for technical questions and 
datasheets, provide a KNC1 testing board and later then give free 
web/codespace to Manu.
Furthermore we of course did lots of testing of multiproto. But never we 
did pay Manu for any of this work.
Reading that you should recognize that there can't be much financial 
interests for Manu.

Seeing that you impute hyprocrisy to Manu due to "facts" you don't have 
proven in any way makes me a bit contemplative. I don't like being 
political when talking about technical terms (which linuxtv in first 
place should be about imho) - anyway this one time I will give a 
somewhat political statement, too.
All you guys who are blaming Manu to do some wrong or bad stuff, what is 
your point? - I see you searching quote where Manu did talk in a 
somewhat unpolite manner just to blame him of being the wrong person 
introducing a new API? - I have no interest in doing the same quoting 
with your postings or the so called competitors postings, but I'd bed I 
could quote almost any of you in a not less distracting manner than you 
like to do with Manu.
> Manipulating (i.e. stalling) the timing of Multiproto being merged into
> the v4l-dvb tree or kernel, for you or your employer's gain, would be
> little different from the motivations you allege Steve of having.
>
> Since the major gripe I'm reading on the list "is that multiproto has
> taken too long" and since it seems to me the only thing that shook it
> loose was a competing proposal, please save the venom for when you
> actually have some clear moral high-ground to stand on.  I don't see it
> from here.
>   
Using "taking too long" as an argument against an API proposal is really 
interesting. What did you expect? - A quick shot which is not well 
thought about wouldn't have be a good thing for anyone.
I'm absolutely fine if anyone would came up with real technical 
arguments, but reading many postings so far I couldn't find much of such 
statements.
> As for the technical superiority of either API proposal; that probably
> just doesn't matter.  I've seen policy/political decisions force
> suboptimal technical solutions at work time and time again.  If you
> really believe you have a superior product technically; then perhaps you
> should work to make it superior politically as well.  Mud-slinging can't
> be a good long term strategy toward that end.
>   
To be political again: Thank you for blaming jusst being not interested 
in proper technical solutions. What makes you thinking of this? - Just 
the fact that you recognize jusst as a commercial company? Very interesting.

I really have a feeling that many people here are mostly interested in 
making politics instead of thinking about technical solutions which 
makes all this a horrible topic for all that people who are interested 
in a working solution (which Manu has proven to deliver) - mainly the users.

So far this is my statement (in representation for jusst technologies) 
for the moment.

Best regards,
Julian

Re: [linux-dvb] Multiproto API/Driver Update

[Michael Krufky]

On Mon, Sep 15, 2008 at 1:50 AM, Julian Scheel <julian@jusst.de> wrote:
> Andy,
>
> just to clarify things a bit I'll give a short statement now.
>
> Andy Walls schrieb:
>> Though I can't read much German, after looking at the jusst.de website I
>> can't help but think that you as well have financial interests driving
>> your actions.  If so, then your statements display quite a bit of
>> hypocrisy.
>>
> The role of jusst technologies in the whole multiproto story is as
> following:
> The time when DVB-S2 came up this was of course of major interest for
> jusst technologies, so we searched for people working on drivers. At
> that not many people did seem to care about this stuff - but Manu did.
> So we got in contact and tried to help him as much as we can, which
> included making up connections to KNC1 for technical questions and
> datasheets, provide a KNC1 testing board and later then give free
> web/codespace to Manu.
> Furthermore we of course did lots of testing of multiproto. But never we
> did pay Manu for any of this work.
> Reading that you should recognize that there can't be much financial
> interests for Manu.
>
> Seeing that you impute hyprocrisy to Manu due to "facts" you don't have
> proven in any way makes me a bit contemplative. I don't like being
> political when talking about technical terms (which linuxtv in first
> place should be about imho) - anyway this one time I will give a
> somewhat political statement, too.
> All you guys who are blaming Manu to do some wrong or bad stuff, what is
> your point? - I see you searching quote where Manu did talk in a
> somewhat unpolite manner just to blame him of being the wrong person
> introducing a new API? - I have no interest in doing the same quoting
> with your postings or the so called competitors postings, but I'd bed I
> could quote almost any of you in a not less distracting manner than you
> like to do with Manu.
>> Manipulating (i.e. stalling) the timing of Multiproto being merged into
>> the v4l-dvb tree or kernel, for you or your employer's gain, would be
>> little different from the motivations you allege Steve of having.
>>
>> Since the major gripe I'm reading on the list "is that multiproto has
>> taken too long" and since it seems to me the only thing that shook it
>> loose was a competing proposal, please save the venom for when you
>> actually have some clear moral high-ground to stand on.  I don't see it
>> from here.
>>
> Using "taking too long" as an argument against an API proposal is really
> interesting. What did you expect? - A quick shot which is not well
> thought about wouldn't have be a good thing for anyone.
> I'm absolutely fine if anyone would came up with real technical
> arguments, but reading many postings so far I couldn't find much of such
> statements.
>> As for the technical superiority of either API proposal; that probably
>> just doesn't matter.  I've seen policy/political decisions force
>> suboptimal technical solutions at work time and time again.  If you
>> really believe you have a superior product technically; then perhaps you
>> should work to make it superior politically as well.  Mud-slinging can't
>> be a good long term strategy toward that end.
>>
> To be political again: Thank you for blaming jusst being not interested
> in proper technical solutions. What makes you thinking of this? - Just
> the fact that you recognize jusst as a commercial company? Very interesting.
>
> I really have a feeling that many people here are mostly interested in
> making politics instead of thinking about technical solutions which
> makes all this a horrible topic for all that people who are interested
> in a working solution (which Manu has proven to deliver) - mainly the users.
>
> So far this is my statement (in representation for jusst technologies)
> for the moment.


Julien,

In summary, the bottom line is this:

Manu did a great job with the multiproto API, people were happy using
it, and all of the LinuxDVB developer community was happy with the
work that was done, and we all wanted to merge it ~ two years ago.

Back then, Manu said that it wasnt ready, so for some time we waited
for him in hopes that he would agree that it was ready for merge.

As more months went by, Manu was asked if he would be merging his
changes, and he kept answering to the effect of "it's not ready yet,
but should be in a few weeks"

Months and months and months went by since then, with an occasional
ping to Manu, with the reply "not ready yet" ...

Two years is a very long time to wait for a new API, especially
considering that it was functional from the start.  It was looking
like Manu may not have had any intention at all to merge his work into
the master v4l/dvb development repository --  It should be not be
surprising at all that Steven Toth felt the need to come up with his
own solution.

Steven posted a proposal for his API expansion solution, and he
received positive feedback.  Immediately, Manu broke out of his
silence and sent in a pull request.


Is there malice here??  No.  There is development, and developers
looking to move forward.  Nobody is at fault.


I have posted the above just to clarify what the "politics" actually
are, here.  The only real politics going around are those that are
accusing others of politics themselves.

Had Manu been willing to merge his work earlier, this would have all
been a non-issue.  However, now there is an alternative proposal on
the table, which appears to be more robust and may have more potential
that the multiproto proposal.

Does that mean multiproto is disqualified?   Absolutely not.

Does the fact that multiproto was there first mean that it will be
merged without question now that it is suddenly available?  No, not
necessarily.

What does it mean?  It means that now there are two proposals on the
table.  Two ways to solve a problem using different ideas and methods.

The end users that have piped into the discussion are mostly concerned
with which API demonstration repository already contains support for
their device.  This should have no bearing whatsoever on the decision
of the linuxDVB API extension.  All drivers will be ported to
whichever solution is decided upon.

Now is the time to examine these solutions from a developer point of
view, in terms of how this affects kernel developers and application
developers alike.  There is no reason to rush into things just because
a pull request has been made -- the outcome of this decision is highly
important, and we will have to live with the decision for a good long
time.

Regards,

Michael Krufky

Re: [linux-dvb] Multiproto API/Driver Update

[Julian Scheel]

Michael,

On Monday 15 September 2008 17:42:06 Michael Krufky wrote:
> In summary, the bottom line is this:
>
> Manu did a great job with the multiproto API, people were happy using
> it, and all of the LinuxDVB developer community was happy with the
> work that was done, and we all wanted to merge it ~ two years ago.
>
> Back then, Manu said that it wasnt ready, so for some time we waited
> for him in hopes that he would agree that it was ready for merge.
>
> As more months went by, Manu was asked if he would be merging his
> changes, and he kept answering to the effect of "it's not ready yet,
> but should be in a few weeks"
>
> Months and months and months went by since then, with an occasional
> ping to Manu, with the reply "not ready yet" ...
>
> Two years is a very long time to wait for a new API, especially
> considering that it was functional from the start.  It was looking
> like Manu may not have had any intention at all to merge his work into
> the master v4l/dvb development repository --  It should be not be
> surprising at all that Steven Toth felt the need to come up with his
> own solution.
>
> Steven posted a proposal for his API expansion solution, and he
> received positive feedback.  Immediately, Manu broke out of his
> silence and sent in a pull request.
>
>
> Is there malice here??  No.  There is development, and developers
> looking to move forward.  Nobody is at fault.
>
>
> I have posted the above just to clarify what the "politics" actually
> are, here.  The only real politics going around are those that are
> accusing others of politics themselves.
>
> Had Manu been willing to merge his work earlier, this would have all
> been a non-issue.  However, now there is an alternative proposal on
> the table, which appears to be more robust and may have more potential
> that the multiproto proposal.
>
> Does that mean multiproto is disqualified?   Absolutely not.
>
> Does the fact that multiproto was there first mean that it will be
> merged without question now that it is suddenly available?  No, not
> necessarily.
>
> What does it mean?  It means that now there are two proposals on the
> table.  Two ways to solve a problem using different ideas and methods.
>
> The end users that have piped into the discussion are mostly concerned
> with which API demonstration repository already contains support for
> their device.  This should have no bearing whatsoever on the decision
> of the linuxDVB API extension.  All drivers will be ported to
> whichever solution is decided upon.
>
> Now is the time to examine these solutions from a developer point of
> view, in terms of how this affects kernel developers and application
> developers alike.  There is no reason to rush into things just because
> a pull request has been made -- the outcome of this decision is highly
> important, and we will have to live with the decision for a good long
> time.

Thanks for your version of the history. I just have to say I can't really 
agree with the way you describe the history. To point this out I looked up 
some of the old threads...

So everything started in 2005 with initial proposals for a DVB-S2 extension of 
the API by Marcel. In early 2006 there were some discussions about it on the 
lists:
http://thread.gmane.org/gmane.linux.drivers.dvb/23914/focus=24030
http://thread.gmane.org/gmane.linux.drivers.dvb/24239

At that thought not much (if any) capable hardware was available, so the idea 
was put off for the moment.
Then in April 2006 Manu started to work at the things and provided a first 
draft based on the changes from Marcel:
http://thread.gmane.org/gmane.linux.drivers.dvb/25401

An initial driver for KNC cards was provided by Manu based on this API 
proposal. After some discussions on 05 May 2006 Manu requested for a pull of 
the API:
http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-May/001006.html

Immediately followed by Johannes stating that he is not satisfied with the API 
yet and suggested a rework:
http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-May/001007.html

At that time rework began while in parallel some people (including jusst 
technologies) started testing the first drivers. As expected they were still 
far away from running perfect.

So it took a while to come to obvious progress. In January 2007 Manu announced 
the mp-stb0899-c5 tree - not even the current multiproto tree - which included 
the results of the rework. Some testing was done on that by more people.
http://thread.gmane.org/gmane.linux.drivers.dvb/31146/focus=31159

In February Steven came up with initial support for HVR 4000 in the multiproto 
tree.
http://thread.gmane.org/gmane.linux.drivers.dvb/31605/focus=31644

Furthermore at this time the dvb-apps (at least parts of) were started to be 
extended by multiproto support, so that more people (which do not write their 
own applications...) could start testing.
http://thread.gmane.org/gmane.linux.drivers.dvb/31726/focus=31729

In March Steven asked for the status of multiproto. Manu noted that the API 
should be fine, but also asked Steve to look into dvb_frontend where Manu was 
not sure of not having introduced new issues.
http://thread.gmane.org/gmane.linux.drivers.dvb/31938/focus=32144

End of May 2007 still problems in dvb-core, which were related to the new API 
came up and were fixed:
http://thread.gmane.org/gmane.linux.drivers.dvb/33893

Then in Sept 2007 discussions came up how to integrate the multiproto API, 
doing this as experimental or non-experimental.
http://thread.gmane.org/gmane.linux.drivers.dvb/36082/focus=36411

In Oct 2007 Steven abandons his support for multiproto, due to delays caused 
by several reasons. Political, surely also personal, but also technical.
http://thread.gmane.org/gmane.linux.drivers.dvb/36583/focus=36670

At the same time some more sophisticated DVB-S2 featues were requestes by the 
users:
http://thread.gmane.org/gmane.linux.drivers.dvb/36785/focus=36789

Finally in Nov 2007 Oliver did a full review of the new code, which was 
necessary for merging. Still he asked for more reviewers.
http://article.gmane.org/gmane.linux.drivers.dvb/37665

In January 2008 another user-initialised thread came up:
http://thread.gmane.org/gmane.linux.drivers.dvb/38529/focus=38544
Still testing is obviously needed as bugs still come up.

In Apr 2008 VDR announced support for multiproto tree, so that more testing 
can be done by many users.

End of May Manu left for travelling and personal stuff until August, just with 
short breaks apllying some minor patches. Still some users report issues with 
multiproro, which were not fully taken care of.

After his vacation Manu came back on this topic and did another shot at a pull 
request.

---

So this is how I see the history. Still 2 years is a very long time, but 
everyone should keep in mind that introduction of DVB-S2 support has been 
(still is) a big task with many problems. At first of course it is a big API 
extension, which is always problematic.
Furthermore it is an API extension for a hardware which still is not spread 
too widely and especially was not spread in 2006. And even those who had 
proper cards for receiving DVB-S2 still were not able to make any use out of 
the received data. To properly do testing at user side it was really necessary 
to at least have a way to watch some of the distributed content, just to be 
sure it is working well.
This was not possible for a long time due to lacing features in ffmpeg and 
missing alternatives. Still I think the only really working way is using a 
binary Windows codec named CoreAVC.

Keeping all this in mind two years are not too long in my eyes.

So this are just my 2 cents on this topic. All that I am interested in is a 
properly working API with wide application and driver support. Which proposal 
ever fits better - but decided on a technical base and not on historical or 
personal terms.

Regards,
Julian

Re: [linux-dvb] Multiproto API/Driver Update

[VDR User]

Julian, thanks for taking the time to dig into the history deeper!  As
I've stated before, there is much more to the story (both in terms of
technical and personal) and it's obvious that certain people are
trying to shape the users perception (even if it means misleading
them) in order to gain their support.  Dirty tactics in my opinion but
I guess when you want to win that bad, you will do whatever it takes @
any cost.

Best regards.

(I apologize if this was posted twice to the ml.)

Re: [linux-dvb] Multiproto API/Driver Update

[Oliver Endriss]

Julian Scheel wrote:
> Michael,
> 
> On Monday 15 September 2008 17:42:06 Michael Krufky wrote:
> > In summary, the bottom line is this:
> >
> > Manu did a great job with the multiproto API, people were happy using
> > it, and all of the LinuxDVB developer community was happy with the
> > work that was done, and we all wanted to merge it ~ two years ago.
> >
> > Back then, Manu said that it wasnt ready, so for some time we waited
> > for him in hopes that he would agree that it was ready for merge.
> >
> > As more months went by, Manu was asked if he would be merging his
> > changes, and he kept answering to the effect of "it's not ready yet,
> > but should be in a few weeks"
> >
> > Months and months and months went by since then, with an occasional
> > ping to Manu, with the reply "not ready yet" ...
> >
> > Two years is a very long time to wait for a new API, especially
> > considering that it was functional from the start.  It was looking
> > like Manu may not have had any intention at all to merge his work into
> > the master v4l/dvb development repository --  It should be not be
> > surprising at all that Steven Toth felt the need to come up with his
> > own solution.
> >
> > Steven posted a proposal for his API expansion solution, and he
> > received positive feedback.  Immediately, Manu broke out of his
> > silence and sent in a pull request.
> >
> >
> > Is there malice here??  No.  There is development, and developers
> > looking to move forward.  Nobody is at fault.
> >
> >
> > I have posted the above just to clarify what the "politics" actually
> > are, here.  The only real politics going around are those that are
> > accusing others of politics themselves.
> >
> > Had Manu been willing to merge his work earlier, this would have all
> > been a non-issue.  However, now there is an alternative proposal on
> > the table, which appears to be more robust and may have more potential
> > that the multiproto proposal.
> >
> > Does that mean multiproto is disqualified?   Absolutely not.
> >
> > Does the fact that multiproto was there first mean that it will be
> > merged without question now that it is suddenly available?  No, not
> > necessarily.
> >
> > What does it mean?  It means that now there are two proposals on the
> > table.  Two ways to solve a problem using different ideas and methods.
> >
> > The end users that have piped into the discussion are mostly concerned
> > with which API demonstration repository already contains support for
> > their device.  This should have no bearing whatsoever on the decision
> > of the linuxDVB API extension.  All drivers will be ported to
> > whichever solution is decided upon.
> >
> > Now is the time to examine these solutions from a developer point of
> > view, in terms of how this affects kernel developers and application
> > developers alike.  There is no reason to rush into things just because
> > a pull request has been made -- the outcome of this decision is highly
> > important, and we will have to live with the decision for a good long
> > time.
> 
> Thanks for your version of the history. I just have to say I can't really 
> agree with the way you describe the history. To point this out I looked up 
> some of the old threads...
> 
> So everything started in 2005 with initial proposals for a DVB-S2 extension of 
> the API by Marcel. In early 2006 there were some discussions about it on the 
> lists:
> http://thread.gmane.org/gmane.linux.drivers.dvb/23914/focus=24030
> http://thread.gmane.org/gmane.linux.drivers.dvb/24239
> 
> At that thought not much (if any) capable hardware was available, so the idea 
> was put off for the moment.
> Then in April 2006 Manu started to work at the things and provided a first 
> draft based on the changes from Marcel:
> http://thread.gmane.org/gmane.linux.drivers.dvb/25401
> 
> An initial driver for KNC cards was provided by Manu based on this API 
> proposal. After some discussions on 05 May 2006 Manu requested for a pull of 
> the API:
> http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-May/001006.html
> 
> Immediately followed by Johannes stating that he is not satisfied with the API 
> yet and suggested a rework:
> http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-May/001007.html
> 
> At that time rework began while in parallel some people (including jusst 
> technologies) started testing the first drivers. As expected they were still 
> far away from running perfect.
> 
> So it took a while to come to obvious progress. In January 2007 Manu announced 
> the mp-stb0899-c5 tree - not even the current multiproto tree - which included 
> the results of the rework. Some testing was done on that by more people.
> http://thread.gmane.org/gmane.linux.drivers.dvb/31146/focus=31159
> 
> In February Steven came up with initial support for HVR 4000 in the multiproto 
> tree.
> http://thread.gmane.org/gmane.linux.drivers.dvb/31605/focus=31644
> 
> Furthermore at this time the dvb-apps (at least parts of) were started to be 
> extended by multiproto support, so that more people (which do not write their 
> own applications...) could start testing.
> http://thread.gmane.org/gmane.linux.drivers.dvb/31726/focus=31729
> 
> In March Steven asked for the status of multiproto. Manu noted that the API 
> should be fine, but also asked Steve to look into dvb_frontend where Manu was 
> not sure of not having introduced new issues.
> http://thread.gmane.org/gmane.linux.drivers.dvb/31938/focus=32144
> 
> End of May 2007 still problems in dvb-core, which were related to the new API 
> came up and were fixed:
> http://thread.gmane.org/gmane.linux.drivers.dvb/33893
> 
> Then in Sept 2007 discussions came up how to integrate the multiproto API, 
> doing this as experimental or non-experimental.
> http://thread.gmane.org/gmane.linux.drivers.dvb/36082/focus=36411
> 
> In Oct 2007 Steven abandons his support for multiproto, due to delays caused 
> by several reasons. Political, surely also personal, but also technical.
> http://thread.gmane.org/gmane.linux.drivers.dvb/36583/focus=36670
> 
> At the same time some more sophisticated DVB-S2 featues were requestes by the 
> users:
> http://thread.gmane.org/gmane.linux.drivers.dvb/36785/focus=36789
> 
> Finally in Nov 2007 Oliver did a full review of the new code, which was 
> necessary for merging. Still he asked for more reviewers.
> http://article.gmane.org/gmane.linux.drivers.dvb/37665
> 
> In January 2008 another user-initialised thread came up:
> http://thread.gmane.org/gmane.linux.drivers.dvb/38529/focus=38544
> Still testing is obviously needed as bugs still come up.
> 
> In Apr 2008 VDR announced support for multiproto tree, so that more testing 
> can be done by many users.
> 
> End of May Manu left for travelling and personal stuff until August, just with 
> short breaks apllying some minor patches. Still some users report issues with 
> multiproro, which were not fully taken care of.
> 
> After his vacation Manu came back on this topic and did another shot at a pull 
> request.
> 
> ---
> 
> So this is how I see the history. Still 2 years is a very long time, but 
> everyone should keep in mind that introduction of DVB-S2 support has been 
> (still is) a big task with many problems. At first of course it is a big API 
> extension, which is always problematic.
> Furthermore it is an API extension for a hardware which still is not spread 
> too widely and especially was not spread in 2006. And even those who had 
> proper cards for receiving DVB-S2 still were not able to make any use out of 
> the received data. To properly do testing at user side it was really necessary 
> to at least have a way to watch some of the distributed content, just to be 
> sure it is working well.
> This was not possible for a long time due to lacing features in ffmpeg and 
> missing alternatives. Still I think the only really working way is using a 
> binary Windows codec named CoreAVC.
> 
> Keeping all this in mind two years are not too long in my eyes.
> 
> So this are just my 2 cents on this topic. All that I am interested in is a 
> properly working API with wide application and driver support. Which proposal 
> ever fits better - but decided on a technical base and not on historical or 
> personal terms.
> 
> Regards,
> Julian

Thanks for the detailed (and imho correct) description of the history.

CU
Oliver

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

Re: [linux-dvb] Multiproto API/Driver Update

[Andy Walls]

On Mon, 2008-09-15 at 07:50 +0200, Julian Scheel wrote:
> Andy,
> 
> just to clarify things a bit I'll give a short statement now.
> 
> Andy Walls schrieb:
> > Though I can't read much German, after looking at the jusst.de website I
> > can't help but think that you as well have financial interests driving
> > your actions.  If so, then your statements display quite a bit of
> > hypocrisy.
> >   
> The role of jusst technologies in the whole multiproto story is as 
> following:
> The time when DVB-S2 came up this was of course of major interest for 
> jusst technologies, so we searched for people working on drivers. At 
> that not many people did seem to care about this stuff - but Manu did. 
> So we got in contact and tried to help him as much as we can, which 
> included making up connections to KNC1 for technical questions and 
> datasheets, provide a KNC1 testing board and later then give free 
> web/codespace to Manu.

Julian

First let me acknowledge jusst technologies contribution.  It seems
generous.  Thank you for clarifying.


> Furthermore we of course did lots of testing of multiproto. But never we 
> did pay Manu for any of this work.
> Reading that you should recognize that there can't be much financial 
> interests for Manu.

Manu clarified this.



> Seeing that you impute hyprocrisy to Manu due to "facts" you don't have 
> proven in any way makes me a bit contemplative.

This is where you misrepresent my words: "I can't help but think..." is
phrase that doesn't not imply certainty but indicates my *perception*.
I did not assert this as fact, as the following statement started "If
so, ..." which is a conditional clause.

Maybe this subtlety is lost in translation.  




>  I don't like being 
> political when talking about technical terms (which linuxtv in first 
> place should be about imho) - anyway this one time I will give a 
> somewhat political statement, too.
> All you guys who are blaming Manu to do some wrong or bad stuff,

No.  It was my ill researched, emotive response to Manu attacking
someone.


>  what is 
> your point?


My point was to suggest to Manu that there were more productive ways to
further his cause than to throw stones at people.

Manu, who you support, BTW, was the one who initially introduced
allegations of a developer introducing corporate politics. 


>  - I see you searching quote where Manu did talk in a 
> somewhat unpolite manner

There was no searching involved.  That quote was text I cut out in my
initial response.  I reinserted it to refute Manu's denial.



>  just to blame him of being the wrong person 
> introducing a new API? 


> - I have no interest in doing the same quoting 
> with your postings or the so called competitors postings, but I'd bed I 
> could quote almost any of you in a not less distracting manner than you 
> like to do with Manu.
> > Manipulating (i.e. stalling) the timing of Multiproto being merged into
> > the v4l-dvb tree or kernel, for you or your employer's gain, would be
> > little different from the motivations you allege Steve of having.
> >
> > Since the major gripe I'm reading on the list "is that multiproto has
> > taken too long" and since it seems to me the only thing that shook it
> > loose was a competing proposal, please save the venom for when you
> > actually have some clear moral high-ground to stand on.  I don't see it
> > from here.
> >   
> Using "taking too long" as an argument against an API proposal is really 
> interesting. What did you expect? - A quick shot which is not well 
> thought about wouldn't have be a good thing for anyone.
> I'm absolutely fine if anyone would came up with real technical 
> arguments, but reading many postings so far I couldn't find much of such 
> statements.

Let me help you.  Please read these postings of mine and give me your
honest feedback:

http://linuxtv.org/pipermail/linux-dvb/2008-September/028651.html
http://linuxtv.org/pipermail/linux-dvb/2008-September/028727.html


Are these the emails of someone who doesn't care about the technical
aspects?

I didn't post them to the LKML because I didn't think the issue needed
expand to there.



> > As for the technical superiority of either API proposal; that probably
> > just doesn't matter.  I've seen policy/political decisions force
> > suboptimal technical solutions at work time and time again.  If you
> > really believe you have a superior product technically; then perhaps you
> > should work to make it superior politically as well.  Mud-slinging can't
> > be a good long term strategy toward that end.
> >   
> To be political again: Thank you for blaming jusst being not interested 
> in proper technical solutions. What makes you thinking of this?

I said no such thing.  The implication was that politics often
(tragically IMO) often weigh heavier than technical merit in making
decision.   This was my recommendation to Manu not to neglect that
aspect, lest he get shortchanged.  I was trying to help/advise.  Maybe
that was not clear.



>  - Just 
> the fact that you recognize jusst as a commercial company? Very interesting.


> I really have a feeling that many people here are mostly interested in 
> making politics instead of thinking about technical solutions which 
> makes all this a horrible topic

Then tell Manu not to initiate with unkind allegations, and he won't
evoke the same in return.  Again, the horror of the whole mess is what
moved me to respond. 

I couldn't give $0.02 about the new API.  I don't think I'll ever need
it myself.  That's a selfish US user's perspective, but it also
validates my motivation for responding: to try and stop the animosity.


>  for all that people who are interested 
> in a working solution (which Manu has proven to deliver) - mainly the users.
> 
> So far this is my statement (in representation for jusst technologies) 
> for the moment.

I'm sorry if you feel I've somehow injured the name of jusst
technologies.  That certainly wasn't any intention of mine.

Regards,
Andy

> Best regards,
> Julian
> 

Re: [linux-dvb] Multiproto API/Driver Update

[hermann pitton]

Am Montag, den 15.09.2008, 19:10 -0400 schrieb Andy Walls:
> On Mon, 2008-09-15 at 07:50 +0200, Julian Scheel wrote:
> > Andy,
> > 
> > just to clarify things a bit I'll give a short statement now.
> > 
> > Andy Walls schrieb:
> > > Though I can't read much German, after looking at the jusst.de website I
> > > can't help but think that you as well have financial interests driving
> > > your actions.  If so, then your statements display quite a bit of
> > > hypocrisy.
> > >   
> > The role of jusst technologies in the whole multiproto story is as 
> > following:
> > The time when DVB-S2 came up this was of course of major interest for 
> > jusst technologies, so we searched for people working on drivers. At 
> > that not many people did seem to care about this stuff - but Manu did. 
> > So we got in contact and tried to help him as much as we can, which 
> > included making up connections to KNC1 for technical questions and 
> > datasheets, provide a KNC1 testing board and later then give free 
> > web/codespace to Manu.
> 
> Julian
> 
> First let me acknowledge jusst technologies contribution.  It seems
> generous.  Thank you for clarifying.
> 
> 
> > Furthermore we of course did lots of testing of multiproto. But never we 
> > did pay Manu for any of this work.
> > Reading that you should recognize that there can't be much financial 
> > interests for Manu.
> 
> Manu clarified this.
> 

I don't doubt it.

But holding the members of a whole community as captives over several
years is a even much more severe issue.

Alone for reading the thousands of mails, how can I build the f*, there
is no compensation and that alone is a reason to have serious doubts
about such kind of support or keep that out of linuxtv too.

To accuse Steve now, his major captive, of something, Manu is far away
to even come close to be allowed to do such, if you look at it in whole,
is a further proof, that it will never end until he has v4l-dvb :)

This would cure him immediately in that direction and I seriously
suggested it.

The underlying problem is deeper, you can't allow something important,
like S2 HDTV support on GNU/Linux, to be in the hand of a single
developer and related NDAs.

The guy might be as fine like Manu, but what comes down to him from all
sides behind the scenes will make even the best soon uncomfortable and
others scratch their had, damned, why he always bites and would this
ever end?

In between others spend their time tracking down some old issue someone
is coming back with after years, but on that shiny new driver this will
of course never happen again ...

Cheers,
Hermann
 

Re: [linux-dvb] Multiproto API/Driver Update

[hermann pitton]

Am Sonntag, den 14.09.2008, 00:56 +0200 schrieb Markus Rechberger:
> On Sun, Sep 14, 2008 at 12:46 AM, Manu Abraham <abraham.manu@gmail.com> wrote:
> > Markus Rechberger wrote:
> >
> >> How many devices are currently supported by the multiproto API
> >> compared with the s2 tree?
> >
> > The initial set of DVB-S2 multistandard devices supported by the
> > multiproto tree is follows. This is just the stb0899 based dvb-s2 driver
> > alone. There are more additions by 2 more modules (not devices), but for
> > the simple comparison here is the quick list of them, for which some of
> > the manufacturers have shown support in some way. (There has been quite
> > some contributions from the community as well.):
> >
> > (Also to be noted is that, some BSD chaps also have shown interest in
> > the same)
> >
> 
> they're heavy into moving the whole framework over as far as I've seen
> yes, also including yet unmerged drivers.

:) any problems?

> > * STB0899 based
> >
> > Anubis
> > Typhoon DVB-S2 PCI
> >
> > Azurewave/Twinhan
> > VP-1041
> > VP-7050
> >
> > Digital Now
> > AD SP400
> > AD SB300
> >
> > KNC1
> > TV Station DVB-S2
> > TV Station DVB-S2 Plus
> >
> > Pinnacle
> > PCTV Sat HDTV Pro USB 452e
> >
> > Satelco
> > TV Station DVB-S2
> > Easywatch HDTV USB CI
> > Easywatch HDTV PCI
> >
> > Technisat
> > Skystar HD
> > Skystar HD2
> > Skystar USB2 HDCI
> >
> > Technotrend
> > TT S2 3200
> > TT S2 3600
> > TT S2 3650
> >
> > Terratec
> > Cinergy S2 PCI HD
> > Cinergy S2 PCI HDCI
> >
> 
> those are pullable now against the current tree?
> 
> Markus
>