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

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

[barry bouwsma]

--- On Mon, 9/8/08, Georg Acher <acher@in.tum.de> wrote:

> > Or is DAB/T-DMB too different from DVB and related technologies,
> 
> DAB itself is totally different to DVB, as it has no transport stream
> equivalent. The different subchannels have different frame/packet lengths,

First, many herzlichen dank for your reply.  Now I'm going to
ask a question about something that I've just read about in
the last minutes...

Would this be somewhat comparable to the Generic Stream (GS)
of DVB-S2, particularly the Continuous mode, as opposed to the
packetised mode?


If there is to be added DVB-S2/GS ability to the relevant API,
which I suspect will be eventually necessary, as the Transport
Stream mode is a compatibility mode with DVB-S, then I am
wondering if that is reasonably close to how whatever DAB
hardware would deliver the modulated multiplex data on its
interface.

Of course, I really do not know what I'm talking about, yet.


> depending on their bitrate allocation and FEC. Also the service information
> (FIGs) has no similarity to DVB.

I would have to ask either someone familiar with the hardware
which I have, or someone who has viewed its datastream, but
if I understand what I've read so far, I should expect to need
to write a demultiplexer in userspace in order to get the
interesting data from the (1,5Mbit/sec-ish) multiplex datastream.

Anything more than that would require extending whatever API.



> closer inspection
> also shows some differences in the allowed video and audio
> codecs and how SI are handled.

If I understand correctly, the difference between DAB and DAB+
has nothing to do with the modulation -- unlike the newly-
being-tested DVB-T2, so my hardware from an API perspective
won't be magically obsoleted -- only the software player needs
AAC audio decoding ability.

Whereas, all my DVB-T devices (and DVB-C) will be obsolete in
the event that the nearby countries of interest decide to
introduce DVB-T2 -- which is not likely soon, but could happen
with the introduction of terrestrial HDTV, should those countries
actually do so, following the UK.


thanks,
barry bouwsma
P.S.:  sorry if I've posted personal mail back to the list;
using a webmail+text-browser means I don't pay attention to
things that a Real Mail Client would make clear


      


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

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

[hermann pitton]

Hello Barry,

Am Montag, den 08.09.2008, 17:43 -0700 schrieb barry bouwsma:
> --- On Mon, 9/8/08, Georg Acher <acher@in.tum.de> wrote:
> 
> > > Or is DAB/T-DMB too different from DVB and related technologies,
> > 
> > DAB itself is totally different to DVB, as it has no transport stream
> > equivalent. The different subchannels have different frame/packet lengths,
> 
> First, many herzlichen dank for your reply.  Now I'm going to
> ask a question about something that I've just read about in
> the last minutes...
> 
> Would this be somewhat comparable to the Generic Stream (GS)
> of DVB-S2, particularly the Continuous mode, as opposed to the
> packetised mode?
> 
> 
> If there is to be added DVB-S2/GS ability to the relevant API,
> which I suspect will be eventually necessary, as the Transport
> Stream mode is a compatibility mode with DVB-S, then I am
> wondering if that is reasonably close to how whatever DAB
> hardware would deliver the modulated multiplex data on its
> interface.
> 
> Of course, I really do not know what I'm talking about, yet.
> 
> 
> > depending on their bitrate allocation and FEC. Also the service information
> > (FIGs) has no similarity to DVB.
> 
> I would have to ask either someone familiar with the hardware
> which I have, or someone who has viewed its datastream, but
> if I understand what I've read so far, I should expect to need
> to write a demultiplexer in userspace in order to get the
> interesting data from the (1,5Mbit/sec-ish) multiplex datastream.
> 
> Anything more than that would require extending whatever API.
> 
> 
> 
> > closer inspection
> > also shows some differences in the allowed video and audio
> > codecs and how SI are handled.
> 
> If I understand correctly, the difference between DAB and DAB+
> has nothing to do with the modulation -- unlike the newly-
> being-tested DVB-T2, so my hardware from an API perspective
> won't be magically obsoleted -- only the software player needs
> AAC audio decoding ability.
> 
> Whereas, all my DVB-T devices (and DVB-C) will be obsolete in
> the event that the nearby countries of interest decide to
> introduce DVB-T2 -- which is not likely soon, but could happen
> with the introduction of terrestrial HDTV, should those countries
> actually do so, following the UK.

following your thoughts, you are likely right. DVB-T2 likely indicates
that you need new hardware, like it is for sure on DVB-S2.

I also agree, that DVB-S h.264 stuff, like we have it currently on
BBC-HD, might switch over to DVB-S2 in the near future. At least it is a
requirement for supported DVB receivers to be S2 capable too and they
stay open to it.

It seems to be guaranteed at least, that it will not be encrypted.
The ITV HD solution looks somehow mad to me currently and might change
too.

French/German and others ARTE HD uses DVB-S2 now, so very likely they
will be all on it in 2010, when the major channels switch to HD too.

It is still not totally clear, but likely we don't come through it
without T2/S2 capable devices.

This could be a question of politics, but I'm currently not
interested ;)

Cheers,
Hermann


 








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

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

[barry bouwsma]

--- On Tue, 9/9/08, hermann pitton <hermann-pitton@arcor.de> wrote:

> following your thoughts, you are likely right. DVB-T2 likely indicates
> that you need new hardware, like it is for sure on DVB-S2.

Servus,

Disclaimer:  I'm only an outsider, not a programmer, and not
familiar with the digital broadcast specs or the DVB API, so
I will both not know what I'm talking about, and be asking
stupid questions.


I decided to look again at DVB-T2, as it's likely to be the
next change that will be in need of Linux support in a year
or so, at least in the UK, when hardware becomes available.

My stupid question is, will DVB-T2, in Transport Stream mode,
be similar enough to existing DVB-T, apart from the extended
modulation parameters, that it can be fit into the existing
API, or am I overlooking something in my ignorance of the API?

This seems to me somewhat like the case of existing DVB-C,
where some hardware is incapable of 256QAM and so cannot tune
all the carriers, but I really haven't tried to understand
the API or how it can be extended without breaking things...


In looking at the Wikipedia article on DVB-T, it appears that
at least the following diffs to include/dvb/frontend.h might
be needed to support the additional possibilities that a DVB-T2
tuner would be likely to support -- diff against the S2API, as
this file is unchanged in multiproto, while S2API already has
the additional FEC values present...

goto Disclaimer;


--- /lost+found/CVSUP/SRC/HG-src/dvb-s2-api/linux/include/linux/dvb/frontend.h  2008-09-04 15:21:59.000000000 +0200
+++ /tmp/frontend.h     2008-09-09 13:10:29.574976974 +0200
@@ -171,24 +171,34 @@ typedef enum fe_modulation {
 } fe_modulation_t;
 
 typedef enum fe_transmit_mode {
+       TRANSMISSION_MODE_1K,
        TRANSMISSION_MODE_2K,
+       TRANSMISSION_MODE_4K,
        TRANSMISSION_MODE_8K,
+       TRANSMISSION_MODE_16K,
+       TRANSMISSION_MODE_32K,
        TRANSMISSION_MODE_AUTO
 } fe_transmit_mode_t;
 
 typedef enum fe_bandwidth {
+       BANDWIDTH_10_MHZ,
        BANDWIDTH_8_MHZ,
        BANDWIDTH_7_MHZ,
        BANDWIDTH_6_MHZ,
+       BANDWIDTH_5_MHZ,
+       BANDWIDTH_1.7_MHZ,
        BANDWIDTH_AUTO
 } fe_bandwidth_t;
 
 
 typedef enum fe_guard_interval {
+       GUARD_INTERVAL_1_128,
        GUARD_INTERVAL_1_32,
        GUARD_INTERVAL_1_16,
        GUARD_INTERVAL_1_8,
        GUARD_INTERVAL_1_4,
+       GUARD_INTERVAL_19_256,
+       GUARD_INTERVAL_19_128,
        GUARD_INTERVAL_AUTO
 } fe_guard_interval_t;
 
@@ -324,6 +334,7 @@ typedef enum fe_delivery_system {
        SYS_DVBC_ANNEX_AC,
        SYS_DVBC_ANNEX_B,
        SYS_DVBT,
+       SYS_DVBT2,
        SYS_DVBS,
        SYS_DVBS2,
        SYS_DVBH,
@@ -335,6 +346,7 @@ typedef enum fe_delivery_system {
        SYS_DMBTH,
        SYS_CMMB,
        SYS_DAB,
+       SYS_TDMB,       /* XXX is different from DMB-TH, no?  */
 } fe_delivery_system_t;
 
 struct tv_cmds_h {


 The reason I became interested in this is due to the choice of
 naming -- S2API sounded to me like the focus would be on DVB-S2,
 possibly ignoring -T2 and eventually -C2, not to mention the
 other existing alternatives to DVB, rather than a Second Generation
 (as the specs I've looked at refer to the update) DVB-API, but
 then, I really don't know what I'm talking about.


 thanks,
 barry bouwsma


      


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

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

[Rudy Zijlstra]

barry bouwsma wrote:
> --- On Tue, 9/9/08, hermann pitton <hermann-pitton@arcor.de> wrote:
>
>   
>> following your thoughts, you are likely right. DVB-T2 likely indicates
>> that you need new hardware, like it is for sure on DVB-S2.
>>     
>
> Servus,
>
> Disclaimer:  I'm only an outsider, not a programmer, and not
> familiar with the digital broadcast specs or the DVB API, so
> I will both not know what I'm talking about, and be asking
> stupid questions.
>
>
> I decided to look again at DVB-T2, as it's likely to be the
> next change that will be in need of Linux support in a year
> or so, at least in the UK, when hardware becomes available.
>   
Likely true, DVB-T2 is well on the way in development.
> My stupid question is, will DVB-T2, in Transport Stream mode,
> be similar enough to existing DVB-T, apart from the extended
> modulation parameters, that it can be fit into the existing
> API, or am I overlooking something in my ignorance of the API?
>   
TS is unchanged from DVB-T, simply higher capacity. The changes are in 
the modulation (and additional table entries)
> This seems to me somewhat like the case of existing DVB-C,
> where some hardware is incapable of 256QAM and so cannot tune
> all the carriers, but I really haven't tried to understand
> the API or how it can be extended without breaking things...
>   
That is old... QAM256 is pretty standard now. Only rather old HW should 
be incapable of handling QAM-256.

>
> In looking at the Wikipedia article on DVB-T, it appears that
> at least the following diffs to include/dvb/frontend.h might
> be needed to support the additional possibilities that a DVB-T2
> tuner would be likely to support -- diff against the S2API, as
> this file is unchanged in multiproto, while S2API already has
>   
> the additional FEC values present...
>   

 From my understanding, S2API is a generic approach, and should not have 
troubles supporting these standards.
> goto Disclaimer;
>
>   


DVB-C2, i do not expect to get beyond definition stage, as - unless 
someone is really willing to pay for it - it seems unlikely there will 
be a market for it.
Too many significantly cheaper solutions to solve the problem on cable.

Cheers,

Rudy

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

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

[Markus Rechberger]

On Tue, Sep 9, 2008 at 2:12 PM, Rudy Zijlstra
<rudy@grumpydevil.homelinux.org> wrote:
> barry bouwsma wrote:
>> --- On Tue, 9/9/08, hermann pitton <hermann-pitton@arcor.de> wrote:
>>
>>
>>> following your thoughts, you are likely right. DVB-T2 likely indicates
>>> that you need new hardware, like it is for sure on DVB-S2.
>>>
>>
>> Servus,
>>
>> Disclaimer:  I'm only an outsider, not a programmer, and not
>> familiar with the digital broadcast specs or the DVB API, so
>> I will both not know what I'm talking about, and be asking
>> stupid questions.
>>
>>
>> I decided to look again at DVB-T2, as it's likely to be the
>> next change that will be in need of Linux support in a year
>> or so, at least in the UK, when hardware becomes available.
>>
> Likely true, DVB-T2 is well on the way in development.
>> My stupid question is, will DVB-T2, in Transport Stream mode,
>> be similar enough to existing DVB-T, apart from the extended
>> modulation parameters, that it can be fit into the existing
>> API, or am I overlooking something in my ignorance of the API?
>>
> TS is unchanged from DVB-T, simply higher capacity. The changes are in
> the modulation (and additional table entries)
>> This seems to me somewhat like the case of existing DVB-C,
>> where some hardware is incapable of 256QAM and so cannot tune
>> all the carriers, but I really haven't tried to understand
>> the API or how it can be extended without breaking things...
>>
> That is old... QAM256 is pretty standard now. Only rather old HW should
> be incapable of handling QAM-256.
>
>>
>> In looking at the Wikipedia article on DVB-T, it appears that
>> at least the following diffs to include/dvb/frontend.h might
>> be needed to support the additional possibilities that a DVB-T2
>> tuner would be likely to support -- diff against the S2API, as
>> this file is unchanged in multiproto, while S2API already has
>>
>> the additional FEC values present...
>>
>
>  From my understanding, S2API is a generic approach, and should not have
> troubles supporting these standards.
>> goto Disclaimer;
>>
>>
>
>
> DVB-C2, i do not expect to get beyond definition stage, as - unless
> someone is really willing to pay for it - it seems unlikely there will
> be a market for it.
> Too many significantly cheaper solutions to solve the problem on cable.
>

How many devices are currently supported by the multiproto API
compared with the s2 tree?
I know the same happened with the em28xx tree initially where a few
10k lines just got burned in
favor of having something else. The same should just not happen again I'd say.
Since I went through retesting many devices and since I'm now still
not completely done with that
this should seriously be avoided, especially in terms of delaying
support for many devices.
As from my side I have to write it was a good move for the em28xx to
make it independent especially
since business customers use the improved version now and don't have
to fear any uncoordinated
breakage.
Although back to the first question - this is the interesting one.

Markus

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

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

[Simon Kenyon]

On Tue, 2008-09-09 at 17:33 +0200, Markus Rechberger wrote:
> As from my side I have to write it was a good move for the em28xx to
> make it independent especially
> since business customers use the improved version now and don't have
> to fear any uncoordinated
> breakage.

as i said before (and to which you did not respond), this may be good
for you, but it is not good for the rest of us.
--
simon


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

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

[Markus Rechberger]

On Tue, Sep 9, 2008 at 10:59 PM, Simon Kenyon <simon@koala.ie> wrote:
> On Tue, 2008-09-09 at 17:33 +0200, Markus Rechberger wrote:
>> As from my side I have to write it was a good move for the em28xx to
>> make it independent especially
>> since business customers use the improved version now and don't have
>> to fear any uncoordinated
>> breakage.
>
> as i said before (and to which you did not respond), this may be good
> for you, but it is not good for the rest of us.

You seem to forget that some developers broke kernel modules which the
em28xx depends on.
Noone cared to fix it even after pointing out to the bug (nor to
revert anything), breaking it was easy.

You might have a single device and don't get the whole impact on
everything there.
That I decline the work of a community wouldn't be true either, I'm
glad about any participation the patches show
up a constant contribution by the community which doesn't fight and
it's smoothly getting in there - but in
a managed manner. Try to get any v4l device work on the Acer Aspire
One, you'll very likely fail with a couple
of things there.

We're doing full service on everything not just the driver, without
having an impact on the rest of the system.

Anyway I'd appreciate to get back to the topic again and the question
which I pointed out to, how many devices
are supported by Steven's patch and how many by the work which Manu
used to managed for years with a couple of
people. There are multiple ways which can lead to success, the beauty
of a patch or framework won't matter too much (nevermind
if Steven's or Manu's work seems to be more prettier to someone).

Markus

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

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

[Steven Toth]

> Anyway I'd appreciate to get back to the topic again and the question
> which I pointed out to, how many devices
> are supported by Steven's patch and how many by the work which Manu
> used to managed for years with a couple of
> people. There are multiple ways which can lead to success, the beauty
> of a patch or framework won't matter too much (nevermind
> if Steven's or Manu's work seems to be more prettier to someone).

I'm going to post this notice in a new thread, as this is getting long 
but, to respond generally....

I merged patches from Igor today, so the S2API tree has five S2 devices.

HVR4000 S/S2 card
HVR4000LITE (Also known as the S2 Lite) S/S2 card
TeVii S460 S/S2 card
TeVii S650 S2 card
DvbWorld DVB-S/S2 USB2.0 S/S2

It's a pretty good start, thanks to Igor.

- Steve

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

[linux-dvb] How to measure API "goodness"?

[Andy Walls]

On Tue, 2008-09-09 at 23:14 +0200, Markus Rechberger wrote:
> On Tue, Sep 9, 2008 at 10:59 PM, Simon Kenyon <simon@koala.ie> wrote:
> > On Tue, 2008-09-09 at 17:33 +0200, Markus Rechberger wrote:


>  There are multiple ways which can lead to success, the beauty
> of a patch or framework won't matter too much (nevermind
> if Steven's or Manu's work seems to be more prettier to someone).

This leads into something I've been thinking about the past few days
that's probably worth discussion out loud: 

What are the attributes to measure for comparing APIs or API proposals?
How can each attribute be measure objectively (if possible)?
What are the units for each measurement attribute?
What weight should be given to each attribute?

I've seen several suggestions in the threads already for attributes that
could be considered in a comparison:

1. Complexity (internal to the kernel)
2. Complexity (visible to the application)
3. Extensibility/Future adaptability
4. Implementation maturity (if one exists already)
5. Number of currently supported devices
6. Number of applications already using an implementation
7. Status of an implementation in the kernel (already there, leverages
or consistent with another API, etc.)
8. Ease of use for applications
9. Elegance/Beauty 

I'm sure I've missed some that were discussed, but it doesn't seem that
everything in the list above all are relevant to an API comparison, and
there could very well be things missing from the list.

I was going to look for some CS journal article which may provide
insight into metrics for performing such a comparison, but I haven't
found the time.


But I was thinking it reasonable that metrics, that get the most weight
in an evaluation, be in line with the purpose of an API: 

   Provide a well defined interface, that is consistent over time, which
   applications can call and whose source code can remain insulated from
   differences and changes in the underlying service, for some
   (unspecified) period of time into the future.

(I made that up.)  


That leads me to think that maybe the most important measures should be:

1. Projected invariance of the application facing side over time.

2. The amount of application code that would be forced to change given
forseeable changes or growth in the API due to change or growth in the
underlying service.

3. The transparency of differences in the underlying service (e.g.
capture devices from different manufacturers or using different
chipsets) to the applications calling the API.

4. The functionality provided to applications to deal with differences
that cannot be made transparent to the application.

5. The feasibility of maintaining the desirable properties of an API
while kernel software maintenance move forward.


Beauty, complexity, existing implementations (out of kernel), and ease
of use don't really rank, given my made up definition of an API.
(libX11 isn't an easy to use API, but it has stood the test of time.)

Given the back and forth on the list, I thought some discussion on how
one might perform a technical evaluation of an API may be productive.
The list conversations on certain point aspects of API proposals, would
benefit from rough concensus on how API "goodness" should be measured in
the first place, instead of arguing over perceptions/measurements that
may not be that important to a "good" API.


Regards,
Andy



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

Re: [linux-dvb] How to measure API "goodness"?

[Glenn McGrath]

On Wed, Sep 10, 2008 at 10:42 AM, Andy Walls <awalls@radix.net> wrote:
>
> This leads into something I've been thinking about the past few days
> that's probably worth discussion out loud:
>
> What are the attributes to measure for comparing APIs or API proposals?
> How can each attribute be measure objectively (if possible)?
> What are the units for each measurement attribute?
> What weight should be given to each attribute?
>
> I've seen several suggestions in the threads already for attributes that
> could be considered in a comparison:
>
> 1. Complexity (internal to the kernel)
> 2. Complexity (visible to the application)
> 3. Extensibility/Future adaptability
> 4. Implementation maturity (if one exists already)
> 5. Number of currently supported devices
> 6. Number of applications already using an implementation
> 7. Status of an implementation in the kernel (already there, leverages
> or consistent with another API, etc.)
> 8. Ease of use for applications
> 9. Elegance/Beauty
>
> I'm sure I've missed some that were discussed, but it doesn't seem that
> everything in the list above all are relevant to an API comparison, and
> there could very well be things missing from the list.
>
> I was going to look for some CS journal article which may provide
> insight into metrics for performing such a comparison, but I haven't
> found the time.
>
>
> But I was thinking it reasonable that metrics, that get the most weight
> in an evaluation, be in line with the purpose of an API:
>
>   Provide a well defined interface, that is consistent over time, which
>   applications can call and whose source code can remain insulated from
>   differences and changes in the underlying service, for some
>   (unspecified) period of time into the future.
>
> (I made that up.)
>
>
> That leads me to think that maybe the most important measures should be:
>
> 1. Projected invariance of the application facing side over time.
>
> 2. The amount of application code that would be forced to change given
> forseeable changes or growth in the API due to change or growth in the
> underlying service.
>
> 3. The transparency of differences in the underlying service (e.g.
> capture devices from different manufacturers or using different
> chipsets) to the applications calling the API.
>
> 4. The functionality provided to applications to deal with differences
> that cannot be made transparent to the application.
>
> 5. The feasibility of maintaining the desirable properties of an API
> while kernel software maintenance move forward.
>
>
> Beauty, complexity, existing implementations (out of kernel), and ease
> of use don't really rank, given my made up definition of an API.
> (libX11 isn't an easy to use API, but it has stood the test of time.)
>
> Given the back and forth on the list, I thought some discussion on how
> one might perform a technical evaluation of an API may be productive.
> The list conversations on certain point aspects of API proposals, would
> benefit from rough concensus on how API "goodness" should be measured in
> the first place, instead of arguing over perceptions/measurements that
> may not be that important to a "good" API.
>
>
> Regards,
> Andy

Well said, but can the goodness of an API even be measured ?

The more i learn about programming the more i think software
blueprints (to avoid saying design) are created rather than designed,
and that deep down this is a discussion of science vs art.

For example, to many the 5 measurable attributes you specify come
under the subjective value of beauty, people will quickly decide if
they personally like an API or not, and that is likely to determine
how useful it is.

If you do find any references on measuring an API (or a design) i
would love to read them.


Glenn

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

Re: [linux-dvb] How to measure API "goodness"?

[hermann pitton]

Am Mittwoch, den 10.09.2008, 13:40 +1000 schrieb Glenn McGrath:
> On Wed, Sep 10, 2008 at 10:42 AM, Andy Walls <awalls@radix.net> wrote:
> >
> > This leads into something I've been thinking about the past few days
> > that's probably worth discussion out loud:
> >
> > What are the attributes to measure for comparing APIs or API proposals?
> > How can each attribute be measure objectively (if possible)?
> > What are the units for each measurement attribute?
> > What weight should be given to each attribute?
> >
> > I've seen several suggestions in the threads already for attributes that
> > could be considered in a comparison:
> >
> > 1. Complexity (internal to the kernel)
> > 2. Complexity (visible to the application)
> > 3. Extensibility/Future adaptability
> > 4. Implementation maturity (if one exists already)
> > 5. Number of currently supported devices
> > 6. Number of applications already using an implementation
> > 7. Status of an implementation in the kernel (already there, leverages
> > or consistent with another API, etc.)
> > 8. Ease of use for applications
> > 9. Elegance/Beauty
> >
> > I'm sure I've missed some that were discussed, but it doesn't seem that
> > everything in the list above all are relevant to an API comparison, and
> > there could very well be things missing from the list.
> >
> > I was going to look for some CS journal article which may provide
> > insight into metrics for performing such a comparison, but I haven't
> > found the time.
> >
> >
> > But I was thinking it reasonable that metrics, that get the most weight
> > in an evaluation, be in line with the purpose of an API:
> >
> >   Provide a well defined interface, that is consistent over time, which
> >   applications can call and whose source code can remain insulated from
> >   differences and changes in the underlying service, for some
> >   (unspecified) period of time into the future.
> >
> > (I made that up.)
> >
> >
> > That leads me to think that maybe the most important measures should be:
> >
> > 1. Projected invariance of the application facing side over time.
> >
> > 2. The amount of application code that would be forced to change given
> > forseeable changes or growth in the API due to change or growth in the
> > underlying service.
> >
> > 3. The transparency of differences in the underlying service (e.g.
> > capture devices from different manufacturers or using different
> > chipsets) to the applications calling the API.
> >
> > 4. The functionality provided to applications to deal with differences
> > that cannot be made transparent to the application.
> >
> > 5. The feasibility of maintaining the desirable properties of an API
> > while kernel software maintenance move forward.
> >
> >
> > Beauty, complexity, existing implementations (out of kernel), and ease
> > of use don't really rank, given my made up definition of an API.
> > (libX11 isn't an easy to use API, but it has stood the test of time.)
> >
> > Given the back and forth on the list, I thought some discussion on how
> > one might perform a technical evaluation of an API may be productive.
> > The list conversations on certain point aspects of API proposals, would
> > benefit from rough concensus on how API "goodness" should be measured in
> > the first place, instead of arguing over perceptions/measurements that
> > may not be that important to a "good" API.
> >
> >
> > Regards,
> > Andy
> 
> Well said, but can the goodness of an API even be measured ?
> 
> The more i learn about programming the more i think software
> blueprints (to avoid saying design) are created rather than designed,
> and that deep down this is a discussion of science vs art.

That is totally right.

But we are still far away from to make that believe others.

So we hack on, and then show the art later.

> 
> For example, to many the 5 measurable attributes you specify come
> under the subjective value of beauty, people will quickly decide if
> they personally like an API or not, and that is likely to determine
> how useful it is.
> 
> If you do find any references on measuring an API (or a design) i
> would love to read them.
> 
> 
> Glenn
> 

I do agree again, there are still always _some other_ solutions, but if
3/4/5/6 or seven can agree here, they can make a big jump.

Cheers,
Hermann





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

Re: [linux-dvb] How to measure API "goodness"?

[Johannes Stezenbach]

On Wed, Sep 10, 2008 at 01:40:03PM +1000, Glenn McGrath wrote:
> On Wed, Sep 10, 2008 at 10:42 AM, Andy Walls <awalls@radix.net> wrote:
> >
> > What are the attributes to measure for comparing APIs or API proposals?
> 
> Well said, but can the goodness of an API even be measured ?

Yeah, it seems much easier to measure the badness ;-)
http://www.osnews.com/images/comics/wtfm.jpg

Johannes

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

Re: [linux-dvb] How to measure API "goodness"?

[Markus Rechberger]

On Fri, Sep 12, 2008 at 1:05 AM, Johannes Stezenbach <js@linuxtv.org> wrote:
> On Wed, Sep 10, 2008 at 01:40:03PM +1000, Glenn McGrath wrote:
>> On Wed, Sep 10, 2008 at 10:42 AM, Andy Walls <awalls@radix.net> wrote:
>> >
>> > What are the attributes to measure for comparing APIs or API proposals?
>>
>> Well said, but can the goodness of an API even be measured ?
>
> Yeah, it seems much easier to measure the badness ;-)
> http://www.osnews.com/images/comics/wtfm.jpg


asking linuxtv people about the goodness of code is as good as asking
the worst people who don't know about code how to write proper code.
The one who writes one driver, and rewrites that one hundred times
will probably be the best one to ask such a question.

Markus

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

Re: [linux-dvb] How to measure API "goodness"?

[Andy Walls]

On Wed, 2008-09-10 at 13:40 +1000, Glenn McGrath wrote:
> On Wed, Sep 10, 2008 at 10:42 AM, Andy Walls <awalls@radix.net> wrote:
> >
> > This leads into something I've been thinking about the past few days
> > that's probably worth discussion out loud:
> >
> > What are the attributes to measure for comparing APIs or API proposals?
> > How can each attribute be measure objectively (if possible)?
> > What are the units for each measurement attribute?
> > What weight should be given to each attribute?

> > Given the back and forth on the list, I thought some discussion on how
> > one might perform a technical evaluation of an API may be productive.
> > The list conversations on certain point aspects of API proposals, would
> > benefit from rough concensus on how API "goodness" should be measured in
> > the first place, instead of arguing over perceptions/measurements that
> > may not be that important to a "good" API.
> >
> >
> > Regards,
> > Andy
> 
> Well said,

Thank you.


>  but can the goodness of an API even be measured ?


IMO, sure.  Objective, consistent, and (reasonably) repeatable
assessment may be tricky.

Is it worth the work?  Maybe not.  I depends on the payoff.



> The more i learn about programming the more i think software
> blueprints (to avoid saying design) are created rather than designed,
> and that deep down this is a discussion of science vs art.

I suspect that had this API project started by going through a thorough
development waterfall:

   High Level Requirements capture
   High Level Design
   High Level Design Review
   Functional allocation/breakdown

      Detailed Requirements capture
      Detailed Design
      Test Development
      Detailed Design Review
      Code
      Compile
      Code Review
      Unit Test
   
   Integration Test
   System Test


then all these list discussions would have been moot and there would
only be the one, well reviewed API, *especially* with the proper parties
participating in the design reviews.

Although it may still have been 2 years to get something... ;)


On art vs. engineering:

Software development can be undertaken as a rigorous engineering
discipline, but doing so can take all the enjoyment out of it for the
developers.

Treating software development as an undisciplined art yields results and
schedules that are difficult to reliably predict, manage, and control;
so managing the project costs and software quality becomes a real
problem.



> For example, to many the 5 measurable attributes you specify come
> under the subjective value of beauty,

Actually I'd imagine the attributes would end up being assessed/scored
subjectively by individuals.  With enough people, with a minimum level
of experience, performing an assessment, averaging the subjective scores
for one attribute and computing a variance would come close to a good
objective assessment of an API against any particular attribute.

I'd also contend that beauty is a natural consequence of scoring high on
a majority of the attributes and not the other way around.  But I agree
with you that there is a correlation.



>  people will quickly decide if
> they personally like an API or not, and that is likely to determine
> how useful it is.

I'll agree.  There are subsets of people in any assessment with their
own agendas or interests.  In this case, I can hypothesize groups with
differing motivations that may wish to add weight to certain other
attributes for calling an API good:


1. users: usually want the API to support their particular hardware as
soon as possible with minimal effort on their part

2. kernel devs: may want an API that is easy to adopt and maintain,
especially on the "inward facing" side.  Also want to enhance the linux
kernel functionality in the long run.

3. people with some financial interest in supporting customers or
employers:  may want their customer's or employer's hardware and user
apps supported as soon as possible.

4. application writers: may often prefer an API with minimal complexity
to use that also doesn't force them to rework a lot of existing code.


The hypothesized groups above have desires to satisfy differing short to
mid terms goals.  An API ideally should be selected to guarantee gains
in the long term. IMO



> If you do find any references on measuring an API (or a design) i
> would love to read them.

I haven't had time to look yet.  Crazy week at work.  I doubt I'll find
anything anyway. :P


Regards,
Andy


> Glenn



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

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

[Manu Abraham]

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)

* 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


Regards,
Manu


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

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

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

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

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

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

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

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
> 



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

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

[barry bouwsma]

--- On Sun, 9/14/08, Markus Rechberger <mrechberger@gmail.com> wrote:

> >>> (Also to be noted is that, some BSD chaps also have shown interest in

Does BSD == NetBSD here?  Or are there other developments
as well that I'm not aware of?


> As for the em28xx driver I agreed with pushing all my code

Do you want to have patches for your repository, like the
following (just an example, based on the NetBSD SOC source)

--- em2880-dvb.c-LINUX  2008-09-03 06:47:08.000000000 +0200
+++ em2880-dvb.c        2008-09-14 12:35:49.000000000 +0200
@@ -18,6 +18,7 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#if defined(__linux__)
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/module.h>
@@ -29,6 +30,7 @@
 #include <linux/dvb/frontend.h>
 #include <linux/usb.h>
 #include <linux/version.h>
+#endif
 
 #include "em28xx.h"
 
@@ -60,9 +62,11 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr
 #define xc3028_offset_atsc 1750000;
 
 
+#if defined(__linux__)
 MODULE_DESCRIPTION("Empiatech em2880 DVB-T extension");
 MODULE_AUTHOR("Markus Rechberger <mrechberger@gmail.com>");
 MODULE_LICENSE("GPL");
+#endif
 
 
 DRX3973DData_t DRX3973DData_g = {
@@ -209,7 +213,11 @@ module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "em2880-dvb debug level (default off)");
 
 #define dprintk(lvl, fmt, args...) if (debug >= lvl) do {\
+#if defined(__linux__)
        printk(fmt, ##args); } while (0)
+#elif defined(__NetBSD__)
+       printf(fmt, ##args); } while (0)
+#endif
 
 
 static int em2880_set_alternate(struct em2880_dvb *dvb_dev);


I think I've found something to play with...  (waits patiently
for kernel panic, to have an excuse to reboot)


thanks,
barry bouwsma


      


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

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

[Markus Rechberger]

On Sun, Sep 14, 2008 at 12:51 PM, barry bouwsma
<free_beer_for_all@yahoo.com> wrote:
> --- On Sun, 9/14/08, Markus Rechberger <mrechberger@gmail.com> wrote:
>
>> >>> (Also to be noted is that, some BSD chaps also have shown interest in
>
> Does BSD == NetBSD here?  Or are there other developments
> as well that I'm not aware of?
>

for now it's netBSD, we're offering support to everyone who's interested.


>
>> As for the em28xx driver I agreed with pushing all my code
>
> Do you want to have patches for your repository, like the
> following (just an example, based on the NetBSD SOC source)
>

If you look at the chipdrivers, manufacturers often have independent
code there, as code can be kept independent in that area.
The bridge driver will contain operating system dependent code of course,
The drx driver which you mention mostly uses the Code which came from
Micronas, the module interface code which you looked at is linux
specific yes, but it's more or less just a wrapper against the
original source. It's the same with upcoming drivers.

Its just like Chipdriver - Linuxwrapper - linuxdriver; whereas it can
be the same with any operating system. This also keeps the incomplete
API (of any OS) separated from the available features of the
chipdriver logic. That way it's also rather easy to catch updates from
the manufacturers of the corresponding ICs.

Markus

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

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


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

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

[Steven Toth]

Markus Rechberger wrote:
> On Sun, Sep 14, 2008 at 12:51 PM, barry bouwsma
> <free_beer_for_all@yahoo.com> wrote:
>> --- On Sun, 9/14/08, Markus Rechberger <mrechberger@gmail.com> wrote:
>>
>>>>>> (Also to be noted is that, some BSD chaps also have shown interest in
>> Does BSD == NetBSD here?  Or are there other developments
>> as well that I'm not aware of?
>>
> 
> for now it's netBSD, we're offering support to everyone who's interested.
> 
> 
>>> As for the em28xx driver I agreed with pushing all my code
>> Do you want to have patches for your repository, like the
>> following (just an example, based on the NetBSD SOC source)
>>
> 
> If you look at the chipdrivers, manufacturers often have independent
> code there, as code can be kept independent in that area.
> The bridge driver will contain operating system dependent code of course,
> The drx driver which you mention mostly uses the Code which came from
> Micronas, the module interface code which you looked at is linux
> specific yes, but it's more or less just a wrapper against the
> original source. It's the same with upcoming drivers.

xc5000 and mxl5005 drivers are good examples of this. Basically 
reference code with a DVB wrapper and whitespace + context passing changes.

- Steve

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

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

[barry bouwsma]

--- On Sun, 9/14/08, Steven Toth <stoth@linuxtv.org> wrote:

> is that the BSD folks can't port the GPL license into BSD because it's 
> not compatible.

I don't want to see any religious war here (trimmed to dvb
list), but...

There is GPL code distributed as part of *BSD sources,
as you can see by reading the licensing in, for example,
$ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v


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

It all depends on the intended use -- whether for optional
kernel components as above.  In the distributions, though,
it's kept separated.

It's also possible to dual-licence source, and I see a good
number of such files in NetBSD under, as an example,
/lost+found/CVSUP/BSD/NetBSD.cvs/src/sys/dev/ic/


There will be plenty of misinformation and FUD about which
licensing is better, and I don't want to hear any more such.
Or debates.  Or evangelism.  Or anything.

The different BSDen will handle GPLed code differently.

(By the way, it is possible to completely build NetBSD from
within Linux, though the DVB code hasn't been merged as of
this morning my time, if someone with *BSD familiarity here
wants to think about considering maybe playing with it later
sometime, perhaps, maybe)


thanks,
barry bouwsma


      


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

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

[Markus Rechberger]

On Sun, Sep 14, 2008 at 5:14 PM, barry bouwsma
<free_beer_for_all@yahoo.com> wrote:
> --- On Sun, 9/14/08, Steven Toth <stoth@linuxtv.org> wrote:
>
>> is that the BSD folks can't port the GPL license into BSD because it's
>> not compatible.
>
> I don't want to see any religious war here (trimmed to dvb
> list), but...
>

I totally agree here, I won't reply anyone who's jumping onto
religious wars here, since this is
not the topic why it's getting supported.
Both use the same community applications which are available which is
good, so there's
some competition about getting things done in the end.

> There is GPL code distributed as part of *BSD sources,
> as you can see by reading the licensing in, for example,
> $ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
> Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
> csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v
>

also alsa-oss compat layer in Linux, though I don't want to get deeper
into it :-)

Markus

>
>> I owe it to myself to spend somehime reading the BSD licencing. Maybe
>> the GPL is compatible with BSD.
>
> It all depends on the intended use -- whether for optional
> kernel components as above.  In the distributions, though,
> it's kept separated.
>
> It's also possible to dual-licence source, and I see a good
> number of such files in NetBSD under, as an example,
> /lost+found/CVSUP/BSD/NetBSD.cvs/src/sys/dev/ic/
>
>
> There will be plenty of misinformation and FUD about which
> licensing is better, and I don't want to hear any more such.
> Or debates.  Or evangelism.  Or anything.
>
> The different BSDen will handle GPLed code differently.
>
> (By the way, it is possible to completely build NetBSD from
> within Linux, though the DVB code hasn't been merged as of
> this morning my time, if someone with *BSD familiarity here
> wants to think about considering maybe playing with it later
> sometime, perhaps, maybe)
>
>
> thanks,
> barry bouwsma
>
>
>
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>

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

Re: [linux-dvb] 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

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

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

[Steven Toth]

barry bouwsma wrote:
> --- On Sun, 9/14/08, Steven Toth <stoth@linuxtv.org> wrote:
> 
>> is that the BSD folks can't port the GPL license into BSD because it's 
>> not compatible.
> 
> I don't want to see any religious war here (trimmed to dvb
> list), but...
> 
> There is GPL code distributed as part of *BSD sources,
> as you can see by reading the licensing in, for example,
> $ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
> Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
> csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v

Interesting.

> 
> 
>> I owe it to myself to spend somehime reading the BSD licencing. Maybe 
>> the GPL is compatible with BSD.
> 
> It all depends on the intended use -- whether for optional
> kernel components as above.  In the distributions, though,
> it's kept separated.
> 
> It's also possible to dual-licence source, and I see a good
> number of such files in NetBSD under, as an example,
> /lost+found/CVSUP/BSD/NetBSD.cvs/src/sys/dev/ic/

I'm be quite happy to grant a second license on my work the the BSD 
guys, as the copyright owner I can do that. The legal stuff gets messy 
quickly and I don't claim to understand all of it.

I'm an opensource developer, I chose to work on Linux because it's the 
biggest movement. I have no objections to any other projects, in fact I 
welcome them.


> 
> 
> There will be plenty of misinformation and FUD about which
> licensing is better, and I don't want to hear any more such.
> Or debates.  Or evangelism.  Or anything.

Agreed.

> 
> The different BSDen will handle GPLed code differently.
> 
> (By the way, it is possible to completely build NetBSD from
> within Linux, though the DVB code hasn't been merged as of
> this morning my time, if someone with *BSD familiarity here
> wants to think about considering maybe playing with it later
> sometime, perhaps, maybe)

The issue would be your support community. If you're working on linux 
then people here will help, if our working on something else and asking 
for help here - then people will probably be trying to fix linux first, 
so responses to questions may not arrive, or be slow coming.

Still, better TV support in BSD is good news.

- Steve

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

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




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

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


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

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

[Simon Kenyon]

On Sun, 2008-09-14 at 02:46 +0400, Manu Abraham wrote:
> 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)

is there any issue with GPL code being merged into BSD?
just asking
--
simon


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

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

[Markus Rechberger]

On Sun, Sep 14, 2008 at 9:08 PM, Simon Kenyon <simon@koala.ie> wrote:
> On Sun, 2008-09-14 at 02:46 +0400, Manu Abraham wrote:
>> 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)
>
> is there any issue with GPL code being merged into BSD?
> just asking

Not with the code which comes from our side. They're at DVB-T right
now which already works.
That code is fully duallicensed.
The Bridge code itself needs to get slightly refactored for analog TV.
They are getting full technical and HW support.

Markus

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

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

[Markus Rechberger]

On Sun, Sep 14, 2008 at 6:54 PM, Steven Toth <stoth@linuxtv.org> wrote:
> barry bouwsma wrote:
>> --- On Sun, 9/14/08, Steven Toth <stoth@linuxtv.org> wrote:
>>
>>> is that the BSD folks can't port the GPL license into BSD because it's
>>> not compatible.
>>
>> I don't want to see any religious war here (trimmed to dvb
>> list), but...
>>
>> There is GPL code distributed as part of *BSD sources,
>> as you can see by reading the licensing in, for example,
>> $ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
>> Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
>> csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v
>
> Interesting.
>
>>
>>
>>> I owe it to myself to spend somehime reading the BSD licencing. Maybe
>>> the GPL is compatible with BSD.
>>
>> It all depends on the intended use -- whether for optional
>> kernel components as above.  In the distributions, though,
>> it's kept separated.
>>
>> It's also possible to dual-licence source, and I see a good
>> number of such files in NetBSD under, as an example,
>> /lost+found/CVSUP/BSD/NetBSD.cvs/src/sys/dev/ic/
>
> I'm be quite happy to grant a second license on my work the the BSD
> guys, as the copyright owner I can do that. The legal stuff gets messy
> quickly and I don't claim to understand all of it.
>

Great move Steven! Can we move the TDA10048 code over, maybe adding
a note that it's dual licensed would be nice?

thanks,
Markus

> I'm an opensource developer, I chose to work on Linux because it's the
> biggest movement. I have no objections to any other projects, in fact I
> welcome them.
>
>
>>
>>
>> There will be plenty of misinformation and FUD about which
>> licensing is better, and I don't want to hear any more such.
>> Or debates.  Or evangelism.  Or anything.
>
> Agreed.
>
>>
>> The different BSDen will handle GPLed code differently.
>>
>> (By the way, it is possible to completely build NetBSD from
>> within Linux, though the DVB code hasn't been merged as of
>> this morning my time, if someone with *BSD familiarity here
>> wants to think about considering maybe playing with it later
>> sometime, perhaps, maybe)
>
> The issue would be your support community. If you're working on linux
> then people here will help, if our working on something else and asking
> for help here - then people will probably be trying to fix linux first,
> so responses to questions may not arrive, or be slow coming.
>
> Still, better TV support in BSD is good news.
>
> - Steve
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>

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

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

[Christophe Thommeret]

Le Sunday 14 September 2008 20:51:05 Manu Abraham, vous avez écrit :
> 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.

Sounds like Sarah "pitbull" Palin's sentences :)


-- 
Christophe Thommeret


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

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


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

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

[Simon Kenyon]

On Sun, 2008-09-14 at 21:25 +0200, Markus Rechberger wrote:
> On Sun, Sep 14, 2008 at 9:08 PM, Simon Kenyon <simon@koala.ie> wrote:
> > On Sun, 2008-09-14 at 02:46 +0400, Manu Abraham wrote:
> >> 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)
> >
> > is there any issue with GPL code being merged into BSD?
> > just asking
> 
> Not with the code which comes from our side. They're at DVB-T right
> now which already works.
> That code is fully duallicensed.
> The Bridge code itself needs to get slightly refactored for analog TV.
> They are getting full technical and HW support.

not quite sure (in the context of your sentence) who "our side" is.
all the code on mcentral.de seems to be GPL 2 or greater with copyright
claimed by you and others. i've seen nothing on this mailing list about
dual licencing any linuxtv.org code.

i am in no way a gpl bigot. but legal niceties have to be dealt with.
--
simon


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

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

[Markus Rechberger]

On Sun, Sep 14, 2008 at 10:54 PM, Simon Kenyon <simon@koala.ie> wrote:
> On Sun, 2008-09-14 at 21:25 +0200, Markus Rechberger wrote:
>> On Sun, Sep 14, 2008 at 9:08 PM, Simon Kenyon <simon@koala.ie> wrote:
>> > On Sun, 2008-09-14 at 02:46 +0400, Manu Abraham wrote:
>> >> 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)
>> >
>> > is there any issue with GPL code being merged into BSD?
>> > just asking
>>
>> Not with the code which comes from our side. They're at DVB-T right
>> now which already works.
>> That code is fully duallicensed.
>> The Bridge code itself needs to get slightly refactored for analog TV.
>> They are getting full technical and HW support.
>
> not quite sure (in the context of your sentence) who "our side" is.
> all the code on mcentral.de seems to be GPL 2 or greater with copyright
> claimed by you and others. i've seen nothing on this mailing list about
> dual licencing any linuxtv.org code.
>
> i am in no way a gpl bigot. but legal niceties have to be dealt with.


It's on the website, especially the new drivers which came from Empia
are dual licensed
and intended to be reused with other systems. GPL is just the one
which is used with Linux.

Those parts which are in question in case of license violations will
be replaced and pointed out to people
who port the code. No big deal.

Markus

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

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


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

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


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

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

[Steven Toth]

Markus Rechberger wrote:
> On Sun, Sep 14, 2008 at 6:54 PM, Steven Toth <stoth@linuxtv.org> wrote:
>> barry bouwsma wrote:
>>> --- On Sun, 9/14/08, Steven Toth <stoth@linuxtv.org> wrote:
>>>
>>>> is that the BSD folks can't port the GPL license into BSD because it's
>>>> not compatible.
>>> I don't want to see any religious war here (trimmed to dvb
>>> list), but...
>>>
>>> There is GPL code distributed as part of *BSD sources,
>>> as you can see by reading the licensing in, for example,
>>> $ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
>>> Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
>>> csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v
>> Interesting.
>>
>>>
>>>> I owe it to myself to spend somehime reading the BSD licencing. Maybe
>>>> the GPL is compatible with BSD.
>>> It all depends on the intended use -- whether for optional
>>> kernel components as above.  In the distributions, though,
>>> it's kept separated.
>>>
>>> It's also possible to dual-licence source, and I see a good
>>> number of such files in NetBSD under, as an example,
>>> /lost+found/CVSUP/BSD/NetBSD.cvs/src/sys/dev/ic/
>> I'm be quite happy to grant a second license on my work the the BSD
>> guys, as the copyright owner I can do that. The legal stuff gets messy
>> quickly and I don't claim to understand all of it.
>>
> 
> Great move Steven! Can we move the TDA10048 code over, maybe adding
> a note that it's dual licensed would be nice?

In principle yes.

I'd like to see an example of dual license just to make sure it has no 
nasty side effects.

Can you point me at one of your dual-license drivers so I can review the 
wording?

Regards,

Steve


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

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

[Andreas Oberritter]

Steven Toth wrote:
> Markus Rechberger wrote:
>> Great move Steven! Can we move the TDA10048 code over, maybe adding
>> a note that it's dual licensed would be nice?
> 
> In principle yes.
> 
> I'd like to see an example of dual license just to make sure it has no 
> nasty side effects.
> 
> Can you point me at one of your dual-license drivers so I can review the 
> wording?

AFAIK the biggest problem with dual licensing is that you cannot merge
patches from Linus' tree, because they are not dual licensed (unless, of
course, you'll get the permission from the contributors).

Regards,
Andreas


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

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



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

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

[Steven Toth]

Andreas Oberritter wrote:
> Steven Toth wrote:
>> Markus Rechberger wrote:
>>> Great move Steven! Can we move the TDA10048 code over, maybe adding
>>> a note that it's dual licensed would be nice?
>> In principle yes.
>>
>> I'd like to see an example of dual license just to make sure it has no 
>> nasty side effects.
>>
>> Can you point me at one of your dual-license drivers so I can review the 
>> wording?
> 
> AFAIK the biggest problem with dual licensing is that you cannot merge
> patches from Linus' tree, because they are not dual licensed (unless, of
> course, you'll get the permission from the contributors).

That's also been my understanding in the past.

As the copyright owner I'm legally entitled to generate a separate 
license for the code I originally merged into Linus's tree, though - 
correct? (Perhaps not any updates that were subsequently made to that 
code by the community).

I guess this is would be seen legally as two pieces of code with two 
distinct licenses, not a dual license... or maybe I'm splitting hairs.

Regardless, it will be an interest exercise to review the proposed dual 
license, even if nothing good can come from it.

- Steve


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

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

[Markus Rechberger]

On Sun, Sep 14, 2008 at 11:57 PM, Steven Toth <stoth@linuxtv.org> wrote:
> Markus Rechberger wrote:
>>
>> On Sun, Sep 14, 2008 at 6:54 PM, Steven Toth <stoth@linuxtv.org> wrote:
>>>
>>> barry bouwsma wrote:
>>>>
>>>> --- On Sun, 9/14/08, Steven Toth <stoth@linuxtv.org> wrote:
>>>>
>>>>> is that the BSD folks can't port the GPL license into BSD because it's
>>>>> not compatible.
>>>>
>>>> I don't want to see any religious war here (trimmed to dvb
>>>> list), but...
>>>>
>>>> There is GPL code distributed as part of *BSD sources,
>>>> as you can see by reading the licensing in, for example,
>>>> $ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
>>>> Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
>>>> csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v
>>>
>>> Interesting.
>>>
>>>>
>>>>> I owe it to myself to spend somehime reading the BSD licencing. Maybe
>>>>> the GPL is compatible with BSD.
>>>>
>>>> It all depends on the intended use -- whether for optional
>>>> kernel components as above.  In the distributions, though,
>>>> it's kept separated.
>>>>
>>>> It's also possible to dual-licence source, and I see a good
>>>> number of such files in NetBSD under, as an example,
>>>> /lost+found/CVSUP/BSD/NetBSD.cvs/src/sys/dev/ic/
>>>
>>> I'm be quite happy to grant a second license on my work the the BSD
>>> guys, as the copyright owner I can do that. The legal stuff gets messy
>>> quickly and I don't claim to understand all of it.
>>>
>>
>> Great move Steven! Can we move the TDA10048 code over, maybe adding
>> a note that it's dual licensed would be nice?
>
> In principle yes.
>
> I'd like to see an example of dual license just to make sure it has no nasty
> side effects.
>
> Can you point me at one of your dual-license drivers so I can review the
> wording?
>

videodev2.h is also dual licensed.

Markus

> Regards,
>
> Steve
>
>

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

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


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

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

[hermann pitton]

Am Montag, den 15.09.2008, 00:33 +0200 schrieb Markus Rechberger:
> On Sun, Sep 14, 2008 at 11:57 PM, Steven Toth <stoth@linuxtv.org> wrote:
> > Markus Rechberger wrote:
> >>
> >> On Sun, Sep 14, 2008 at 6:54 PM, Steven Toth <stoth@linuxtv.org> wrote:
> >>>
> >>> barry bouwsma wrote:
> >>>>
> >>>> --- On Sun, 9/14/08, Steven Toth <stoth@linuxtv.org> wrote:
> >>>>
> >>>>> is that the BSD folks can't port the GPL license into BSD because it's
> >>>>> not compatible.
> >>>>
> >>>> I don't want to see any religious war here (trimmed to dvb
> >>>> list), but...
> >>>>
> >>>> There is GPL code distributed as part of *BSD sources,
> >>>> as you can see by reading the licensing in, for example,
> >>>> $ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
> >>>> Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
> >>>> csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v
> >>>
> >>> Interesting.
> >>>
> >>>>
> >>>>> I owe it to myself to spend somehime reading the BSD licencing. Maybe
> >>>>> the GPL is compatible with BSD.
> >>>>
> >>>> It all depends on the intended use -- whether for optional
> >>>> kernel components as above.  In the distributions, though,
> >>>> it's kept separated.
> >>>>
> >>>> It's also possible to dual-licence source, and I see a good
> >>>> number of such files in NetBSD under, as an example,
> >>>> /lost+found/CVSUP/BSD/NetBSD.cvs/src/sys/dev/ic/
> >>>
> >>> I'm be quite happy to grant a second license on my work the the BSD
> >>> guys, as the copyright owner I can do that. The legal stuff gets messy
> >>> quickly and I don't claim to understand all of it.
> >>>
> >>
> >> Great move Steven! Can we move the TDA10048 code over, maybe adding
> >> a note that it's dual licensed would be nice?
> >
> > In principle yes.
> >
> > I'd like to see an example of dual license just to make sure it has no nasty
> > side effects.
> >
> > Can you point me at one of your dual-license drivers so I can review the
> > wording?
> >
> 
> videodev2.h is also dual licensed.
> 

That was to what I tried to point to.

Cheers,
Hermann



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

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

[hermann pitton]

Am Sonntag, den 14.09.2008, 22:08 +0200 schrieb Christophe Thommeret:
> Le Sunday 14 September 2008 20:51:05 Manu Abraham, vous avez écrit :
> > 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.
> 
> Sounds like Sarah "pitbull" Palin's sentences :)

To make it short.

I would not ever go out with guys like Manu and Markus again and from me
they do not have a single line of code legally.

Hermann



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

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



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

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

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

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

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

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
> 


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

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
 







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

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

[Benny Amorsen]

barry bouwsma <free_beer_for_all@yahoo.com> writes:

> There is GPL code distributed as part of *BSD sources,
> as you can see by reading the licensing in, for example,
> $ ls /lost+found/CVSUP/BSD/FreeBSD.cvs/src/sys/gnu/dev/sound/pci/
> Attic       emu10k1-alsa.h,v  maestro3_reg.h,v  p17v-alsa.h,v
> csaimg.h,v  maestro3_dsp.h,v  p16v-alsa.h,v

Don't read too much into that. C header files are generally interface
descriptions, and those are generally not copyrightable. I write
"generally" because like everything else in law, there are exceptions.

I doubt that *BSD would allow GPL'd .c-files into their kernel trees.


/Benny

P.S. Interesting place you keep your sources...


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

[linux-dvb] OT: Dual/BSD Licensing (was: Re: Multiproto API/Driver Update)

[BOUWSMA Barry]

On Tue, 16 Sep 2008, Benny Amorsen wrote:

> I doubt that *BSD would allow GPL'd .c-files into their kernel trees.

Ha.  Found one.  Present (NetBSD) OS does not give me access
to my up-to-date source repositories, so I don't know if it's
obsolete now, and I can't grep through DragonFly-, Open-,
and other derivates along the BSD family tree.

There are, however, numerous dual GPL/BSD license files to
be found, some with different wordings.

/mnt/usr/local/src/netbsd-current-src/src/NetBSD.cvs/src/sys/dev/pci/if_lmc.c
is an example of a file has plenty of Linuxisms intact.

/mnt/usr/local/src/netbsd-current-src/src/NetBSD.cvs/src/sys/external/bsd/drm/dist/shared-core/via_drv.c
has a BSD license atop, and at the end, a Linux kernel module
GPL license...

/altroot/STABLE-4.4-FreeBSD/usr/local/system/src/sys/kern/kern_random.c
is quite old -- while I do have later source on this disk,
my present kernel limits me to the 16 partitions I've defined
from the 30-odd I can find with Linux (experimental code to
use BSD disklabels or GPT has not been as successful as I
would like); this isn't relevant, is it?  Anyway...  I'll
quote from this file:

 * $FreeBSD: src/sys/kern/kern_random.c,v 1.36.2.4 2002/09/17 17:11:57 sam Exp $
 * Version 0.95, last modified 18-Oct-95
 * Copyright Theodore Ts'o, 1994, 1995.  All rights reserved.
[...]
 * ALTERNATIVELY, this product may be distributed under the terms of
 * the GNU Public License, in which case the provisions of the GPL are
 * required INSTEAD OF the above restrictions.  (This clause is
 * necessary due to a potential bad interaction between the GPL and
 * the restrictions contained in a BSD-style copyright.)

Now we take a look at an interesting file:
 * $FreeBSD: src/sys/dev/dgb/dgm.c,v 1.31.2.3 2001/10/07 09:02:25 brian Exp $
[...]
 * There was a copyright confusion: I thought that having read the
 * GLPed drivers makes me mentally contaminated but in fact it does
 * not. Since the Linux driver by Troy De Jongh <troyd@digibd.com> or
 * <troyd@skypoint.com> was used only to learn the Digi's interface,
 * I've returned this driver to a BSD-style license. I tried to contact
 * all the contributors and those who replied agreed with license
 * change. If you did any contribution when the driver was GPLed and do
 * not agree with the BSD-style re-licensing please contact me.
 *  -SB


``Mentally contaminated''.  Hmmm.  Need to design a suitable
icon for that, and print up biohazard-like warning signs to
wear on my jacket.  Anyway, that's an example of the sort of
flame wars that you can find elsewhere.


Now, a bit futher along, again from my old source tree,

/altroot/STABLE-4.4-FreeBSD/usr/local/system/src/sys/gnu/i386/isa/dgb.c

 *  dgb.c $FreeBSD: src/sys/gnu/i386/isa/dgb.c,v 1.56.2.1 2001/02/26 04:23:09 jlemon Exp $
 *
 *  Digiboard driver.
 *
 *  Stage 1. "Better than nothing".
 *  Stage 2. "Gee, it works!".
 *
 *  Based on sio driver by Bruce Evans and on Linux driver by Troy
 *  De Jongh <troyd@digibd.com> or <troyd@skypoint.com>
 *  which is under GNU General Public License version 2 so this driver
 *  is forced to be under GPL 2 too.

But then, this is under FreeBSD's sys/gnu subdirectory,
where optional non-BSD-licensed files would be found.


Of course, the actual basics of the kernel (memory manglement
and what not) will not be exclusively GPL -- only those
optional components for convenience.


I hope these licenses help any authors who are
considering whether a dual-license for their code
is worthy.  This is all based on `grep', not on an
intimate knowledge of how these source files interface
with the kernel.



> P.S. Interesting place you keep your sources...

Not enough mountpoints, too many external drives with
too many partitions, never enough consistency to add a
fixed mountpoint for anything that I might occasionally
mount, so I just mount it on whatever looks available,
then it kinda gets hardcoded differently into different
scripts on different OSen, and anyway, I usually end up
rearranging or migrating stuff sooner rather than later.


med venlig hilsen,
barry bouwsma

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

Re: [linux-dvb] OT: Dual/BSD Licensing

[Benny Amorsen]

BOUWSMA Barry <freebeer.bouwsma@gmail.com> writes:

> There are, however, numerous dual GPL/BSD license files to
> be found, some with different wordings.

Dual licensed files don't count, you can just ignore the license you
don't like. I'm saying that only-GPL'd .c-files are a non-starter for
*BSD kernels.

However, when things are added to the official Linux kernel,
dual-BSD-GPL files often have their BSD license removed, and
compatibility ifdef's are almost always removed. That can be a
challenge if you try to keep a unified code base.


/Benny


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

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



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

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

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

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

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

[linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Steven Toth]

Hans Werner wrote:
> -------- Original-Nachricht --------
>> Datum: Sat, 11 Oct 2008 13:40:38 -0400
>> Von: Steven Toth <stoth@linuxtv.org>
>> An: Darron Broad <darron@kewl.org>
>> CC: Hans Werner <HWerner4@gmx.de>, fabbione@fabbione.net, scarfoglio@arpacoop.it
>> Betreff: Re: [PATCH] S2API: add multifrontend
> 
>> Darron Broad wrote:
>>> In message <48F0B6C5.5090505@linuxtv.org>, Steven Toth wrote:
>>>
>>> hello
>>>
>>> <snip>
>>>
>>>> I have an OOPS loading the cx23885 driver, I'm fixing now. Carry on
>> with 
>>>> your stuff and I'll add this fix to the entire patchset as a
>> supplemental.
>>>> Just FYI
>>> okay Steve.
>>>
>>> I have created two new repos:
>>>
>>> http://hg.kewl.org/s2-mfe-new/
>>> and
>>> http://hg.kewl.org/s2-mfe-new-dev/
>>>
>>> the former is as http://hg.kewl.org/s2-mfe/ without any FM radio
>>> support but some preliminary setup which has no great impact.
>>>
>>> the later is where i will fix the radio as best can be done
>>> by mid-week. hopefully the MEX will be understood by then
>>> and any bad code in tvaudio sorted out (it needs evaluation).
>>>
>>> currently s2-mfe-new-dev is exactly the same as s2-mfe on
>>> hg.kewl.org with the exception of one additional comment so
>>> I don't see any omissions.
>>>
>>> Hopefully i have commited the MFE patches in new in a correct
>>> fashion. You are free to do as you will with it and I will
>>> not change anything in this repo.
>>>
>>> I have to go now for some time, but will return later. I 
>>> hope all is going well.
>> OK, I've made some changes and cleanup patches for various things. This 
>> fixes the cx23885 tree for MFE, it's working now.
>>
>> Also a massive checkpatch compliance changes for various drivers, 
>> including the cx24116.
>>
>> (checkpatch is automatically run durin Mauro's import and highlights 
>> kernel coding violations).
>>
>> I need you all to pull this tree and re-run your tests. We need to 
>> re-verify that everything works as expected.... I doubt anything ot 
>> broken, but it has been a lot of cleanup).
>>
>> As always, http://linuxtv.org/hg/~stoth/s2-mfe
>>
>> Regards,
>>
>> Steve
> 
> Hi guys,
> 
> thank you Steve and Darron for your work on the repositories today!
> 
> I have pulled the latest s2-mfe and retested with the HVR4000 on DVB-T, 
> DVB-S, DVB-S2 and analogue TV. 
> 
> No problems so far.

I'm mutating the subject thread, and cc'ing the public mailing list into 
this conversion. Now is the time to announce the intension to merge 
multi-frontend patches, and show that we have tested and are satisfied 
with it's reliability across many trees.

(For those of you not familiar with the patch set, it adds 
'multiple-frontends to a single transport bus' support for the HVR3000 
and HVR4000, and potentially another 7134 based design (the 6 way medion 
board?).

For my part, I was asked to test the cx23885 changes and I responded to 
that with a series of patches to fix some OOPS initialisation errors. 
The MFE patches work correctly with the cx23885 tree now.

Over time I've heard constant suggestions that the patches are ready for 
merge, the cx88 and saa7134 trees are working correctly. Now is the time 
that I need you all to announce this. I need you each in turn to 
describe you testing, and state whether you think the patches are ready 
for merge.

Hans Werner <HWerner4@gmx.de>
darron@kewl.org
scarfoglio@arpacoop.it
fabbione@fabbione.net

If you're not normally members of this list then please say so, I'll 
ensure your response is cc'd back to the list.

Thanks,

Steve


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Darron Broad]

In message <48F36B32.5060006@linuxtv.org>, Steven Toth wrote:

hi.

<snip>
>> 
>> Hi guys,
>> 
>> thank you Steve and Darron for your work on the repositories today!
>> 
>> I have pulled the latest s2-mfe and retested with the HVR4000 on DVB-T, 
>> DVB-S, DVB-S2 and analogue TV. 
>> 
>> No problems so far.
>
>I'm mutating the subject thread, and cc'ing the public mailing list into 
>this conversion. Now is the time to announce the intension to merge 
>multi-frontend patches, and show that we have tested and are satisfied 
>with it's reliability across many trees.
>
>(For those of you not familiar with the patch set, it adds 
>'multiple-frontends to a single transport bus' support for the HVR3000 
>and HVR4000, and potentially another 7134 based design (the 6 way medion 
>board?).
>
>For my part, I was asked to test the cx23885 changes and I responded to 
>that with a series of patches to fix some OOPS initialisation errors. 
>The MFE patches work correctly with the cx23885 tree now.
>
>Over time I've heard constant suggestions that the patches are ready for 
>merge, the cx88 and saa7134 trees are working correctly. Now is the time 
>that I need you all to announce this. I need you each in turn to 
>describe you testing, and state whether you think the patches are ready 
>for merge.
>
>Hans Werner <HWerner4@gmx.de>
>darron@kewl.org

The test machine I have here utilises an HVR-4000 and AVERMEDIA
SUPER 007.

Multi-frontend works with both adapters with the HVR-4000 containing
analogue, DVB-S and DVB-T frontends, the AVERMEDIA solely DVB-T.

At this time with some further FM updates (see: http://hg.kewl.org/s2-mfe-fm/)
I can now reliably and consitently receive DVB-S/S2, DVB-T, analogue TV
and FM radio on the HVR-4000. DVB-T works on the AVERMEDIA as per
normal.

Applications which have been under test by include the command
line dvb-utils, dvbtraffic, dvbsnoop, GUI apps kaffeine and
mythtv. No obvious side effects have been witnessed of using
MFE and the applications themselves do not see any difference
except that they are unable to simultaneously open multiple
frontends due to the hardware limitation of such cards.

A couple of problems exist which may be present in all hybrid cards
is that you are able to concurrently open analogue and DVB-T where
these share the same tuner section. Another issue with shared
tuners is where both analogue and digital sections share a sleep
method which in some circumstances is incompatible.

At this time I am happy with the performance of this MFE card
(HVR-4000) and to be honest, I am looking at attending to other
activities. Bugs where present ought to be picked up by others,
I have done all that has been reasonable to test and determine
that MFE works.

>scarfoglio@arpacoop.it
>fabbione@fabbione.net
>
>If you're not normally members of this list then please say so, I'll 
>ensure your response is cc'd back to the list.

Thanks, cya!

--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Steven Toth]

Darron Broad wrote:
> In message <48F36B32.5060006@linuxtv.org>, Steven Toth wrote:
> 
> hi.
> 
> <snip>
>>> Hi guys,
>>>
>>> thank you Steve and Darron for your work on the repositories today!
>>>
>>> I have pulled the latest s2-mfe and retested with the HVR4000 on DVB-T, 
>>> DVB-S, DVB-S2 and analogue TV. 
>>>
>>> No problems so far.
>> I'm mutating the subject thread, and cc'ing the public mailing list into 
>> this conversion. Now is the time to announce the intension to merge 
>> multi-frontend patches, and show that we have tested and are satisfied 
>> with it's reliability across many trees.
>>
>> (For those of you not familiar with the patch set, it adds 
>> 'multiple-frontends to a single transport bus' support for the HVR3000 
>> and HVR4000, and potentially another 7134 based design (the 6 way medion 
>> board?).
>>
>> For my part, I was asked to test the cx23885 changes and I responded to 
>> that with a series of patches to fix some OOPS initialisation errors. 
>> The MFE patches work correctly with the cx23885 tree now.
>>
>> Over time I've heard constant suggestions that the patches are ready for 
>> merge, the cx88 and saa7134 trees are working correctly. Now is the time 
>> that I need you all to announce this. I need you each in turn to 
>> describe you testing, and state whether you think the patches are ready 
>> for merge.
>>
>> Hans Werner <HWerner4@gmx.de>
>> darron@kewl.org
> 
> The test machine I have here utilises an HVR-4000 and AVERMEDIA
> SUPER 007.
> 
> Multi-frontend works with both adapters with the HVR-4000 containing
> analogue, DVB-S and DVB-T frontends, the AVERMEDIA solely DVB-T.
> 
> At this time with some further FM updates (see: http://hg.kewl.org/s2-mfe-fm/)
> I can now reliably and consitently receive DVB-S/S2, DVB-T, analogue TV
> and FM radio on the HVR-4000. DVB-T works on the AVERMEDIA as per
> normal.
> 
> Applications which have been under test by include the command
> line dvb-utils, dvbtraffic, dvbsnoop, GUI apps kaffeine and
> mythtv. No obvious side effects have been witnessed of using
> MFE and the applications themselves do not see any difference
> except that they are unable to simultaneously open multiple
> frontends due to the hardware limitation of such cards.
> 
> A couple of problems exist which may be present in all hybrid cards
> is that you are able to concurrently open analogue and DVB-T where
> these share the same tuner section. Another issue with shared
> tuners is where both analogue and digital sections share a sleep
> method which in some circumstances is incompatible.

Some common hybrid issues we've seen across many cards, regardless of MFE.

> 
> At this time I am happy with the performance of this MFE card
> (HVR-4000) and to be honest, I am looking at attending to other
> activities. Bugs where present ought to be picked up by others,
> I have done all that has been reasonable to test and determine
> that MFE works.

Thanks Darron.

- Steve


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[hermann pitton]

Hi,

Am Montag, den 13.10.2008, 12:18 -0400 schrieb Steven Toth:
> Darron Broad wrote:
> > In message <48F36B32.5060006@linuxtv.org>, Steven Toth wrote:
> > 
> > hi.
> > 
> > <snip>
> >>> Hi guys,
> >>>
> >>> thank you Steve and Darron for your work on the repositories today!
> >>>
> >>> I have pulled the latest s2-mfe and retested with the HVR4000 on DVB-T, 
> >>> DVB-S, DVB-S2 and analogue TV. 
> >>>
> >>> No problems so far.
> >> I'm mutating the subject thread, and cc'ing the public mailing list into 
> >> this conversion. Now is the time to announce the intension to merge 
> >> multi-frontend patches, and show that we have tested and are satisfied 
> >> with it's reliability across many trees.
> >>
> >> (For those of you not familiar with the patch set, it adds 
> >> 'multiple-frontends to a single transport bus' support for the HVR3000 
> >> and HVR4000, and potentially another 7134 based design (the 6 way medion 
> >> board?).
> >>
> >> For my part, I was asked to test the cx23885 changes and I responded to 
> >> that with a series of patches to fix some OOPS initialisation errors. 
> >> The MFE patches work correctly with the cx23885 tree now.
> >>
> >> Over time I've heard constant suggestions that the patches are ready for 
> >> merge, the cx88 and saa7134 trees are working correctly. Now is the time 
> >> that I need you all to announce this. I need you each in turn to 
> >> describe you testing, and state whether you think the patches are ready 
> >> for merge.
> >>
> >> Hans Werner <HWerner4@gmx.de>
> >> darron@kewl.org
> > 
> > The test machine I have here utilises an HVR-4000 and AVERMEDIA
> > SUPER 007.
> > 
> > Multi-frontend works with both adapters with the HVR-4000 containing
> > analogue, DVB-S and DVB-T frontends, the AVERMEDIA solely DVB-T.
> > 
> > At this time with some further FM updates (see: http://hg.kewl.org/s2-mfe-fm/)
> > I can now reliably and consitently receive DVB-S/S2, DVB-T, analogue TV
> > and FM radio on the HVR-4000. DVB-T works on the AVERMEDIA as per
> > normal.
> > 
> > Applications which have been under test by include the command
> > line dvb-utils, dvbtraffic, dvbsnoop, GUI apps kaffeine and
> > mythtv. No obvious side effects have been witnessed of using
> > MFE and the applications themselves do not see any difference
> > except that they are unable to simultaneously open multiple
> > frontends due to the hardware limitation of such cards.
> > 
> > A couple of problems exist which may be present in all hybrid cards
> > is that you are able to concurrently open analogue and DVB-T where
> > these share the same tuner section. Another issue with shared
> > tuners is where both analogue and digital sections share a sleep
> > method which in some circumstances is incompatible.
> 
> Some common hybrid issues we've seen across many cards, regardless of MFE.
> 
> > 
> > At this time I am happy with the performance of this MFE card
> > (HVR-4000) and to be honest, I am looking at attending to other
> > activities. Bugs where present ought to be picked up by others,
> > I have done all that has been reasonable to test and determine
> > that MFE works.
> 
> Thanks Darron.
> 
> - Steve
> 

Steve, since you are going out for testers on the list now.

I'm not sure if you want feedback only from people where s2-mfe is
already implemented, or also from such where the basics are there now.

On the saa7134 all feels like it was prior, if you want that one too.

Cheers,
Hermann





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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Hans Werner]

Hi,

> Darron Broad wrote:
> > In message <48F36B32.5060006@linuxtv.org>, Steven Toth wrote:
> > 
> > hi.
> > 
> > <snip>
> >>> Hi guys,
> >>>
> >>> thank you Steve and Darron for your work on the repositories today!
> >>>
> >>> I have pulled the latest s2-mfe and retested with the HVR4000 on
> DVB-T, 
> >>> DVB-S, DVB-S2 and analogue TV. 
> >>>
> >>> No problems so far.
> >> I'm mutating the subject thread, and cc'ing the public mailing list
> into 
> >> this conversion. Now is the time to announce the intension to merge 
> >> multi-frontend patches, and show that we have tested and are satisfied 
> >> with it's reliability across many trees.
> >>
> >> (For those of you not familiar with the patch set, it adds 
> >> 'multiple-frontends to a single transport bus' support for the HVR3000 
> >> and HVR4000, and potentially another 7134 based design (the 6 way
> medion 
> >> board?).
> >>
> >> For my part, I was asked to test the cx23885 changes and I responded to
> >> that with a series of patches to fix some OOPS initialisation errors. 
> >> The MFE patches work correctly with the cx23885 tree now.
> >>
> >> Over time I've heard constant suggestions that the patches are ready
> for 
> >> merge, the cx88 and saa7134 trees are working correctly. Now is the
> time 
> >> that I need you all to announce this. I need you each in turn to 
> >> describe you testing, and state whether you think the patches are ready
> >> for merge.
> >>
> >> Hans Werner <HWerner4@gmx.de>
> >> darron@kewl.org
> > 
> > The test machine I have here utilises an HVR-4000 and AVERMEDIA
> > SUPER 007.
> > 
> > Multi-frontend works with both adapters with the HVR-4000 containing
> > analogue, DVB-S and DVB-T frontends, the AVERMEDIA solely DVB-T.
> > 
> > At this time with some further FM updates (see:
> http://hg.kewl.org/s2-mfe-fm/)
> > I can now reliably and consitently receive DVB-S/S2, DVB-T, analogue TV
> > and FM radio on the HVR-4000. DVB-T works on the AVERMEDIA as per
> > normal.
> > 

I have tested with the HVR4000 on many iterations of the MFE drivers and retested with
the latest s2-mfe tree yesterday. I found no problems for DVB-S, DVB-S2 (both QPSK
and PSK_8), DVB-T and analogue TV.

I will test the latest FM radio patch.

> > Applications which have been under test by include the command
> > line dvb-utils, dvbtraffic, dvbsnoop, GUI apps kaffeine and
> > mythtv. No obvious side effects have been witnessed of using
> > MFE and the applications themselves do not see any difference
> > except that they are unable to simultaneously open multiple
> > frontends due to the hardware limitation of such cards.

I tested with Kaffeine with a version of Christophe's S2API patch. It recognises both
S/S2 and T frontends on startup, and reliably scans S/S2 and T channels and tunes
between channels. I have at various times done some testing with MythTV, VDR,
Steve's tune.c and Igor's szap-s2. Apps see two normal frontends but should not hold both
open as Darron said. Closing and opening frontends as necessary seems to work cleanly
from the userspace point of view.

> > 
> > A couple of problems exist which may be present in all hybrid cards
> > is that you are able to concurrently open analogue and DVB-T where
> > these share the same tuner section. Another issue with shared
> > tuners is where both analogue and digital sections share a sleep
> > method which in some circumstances is incompatible.
> 
> Some common hybrid issues we've seen across many cards, regardless of MFE.

It seems relatively benign : if you run say kaffeine and tvtime together, either a DVB-T
or an analogue channel is shown (the other is blank) but neither app crashes and either
takes over on a tune action.

> 
> > 
> > At this time I am happy with the performance of this MFE card
> > (HVR-4000) and to be honest, I am looking at attending to other
> > activities. Bugs where present ought to be picked up by others,
> > I have done all that has been reasonable to test and determine
> > that MFE works.

I am also happy with the performance of the card with the MFE driver and would 
like to see it released. It is in daily use in my household without any trouble.

Hans

> 
> Thanks Darron.
> 
> - Steve

-- 
Release early, release often.

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

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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Andreas Oberritter]

Hello Steve,

Steven Toth wrote:
> I'm mutating the subject thread, and cc'ing the public mailing list into 
> this conversion. Now is the time to announce the intension to merge 
> multi-frontend patches, and show that we have tested and are satisfied 
> with it's reliability across many trees.
> 
> (For those of you not familiar with the patch set, it adds 
> 'multiple-frontends to a single transport bus' support for the HVR3000 
> and HVR4000, and potentially another 7134 based design (the 6 way medion 
> board?).

is this code still using more than one demux device per transport bus, or
has it already been changed to make use of the DMX_SET_SOURCE command?

Regards,
Andreas

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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Darron Broad]

In message <48F42D5C.7090908@linuxtv.org>, Andreas Oberritter wrote:

hi.

>Hello Steve,
>
>Steven Toth wrote:
>> I'm mutating the subject thread, and cc'ing the public mailing list into 
>> this conversion. Now is the time to announce the intension to merge 
>> multi-frontend patches, and show that we have tested and are satisfied 
>> with it's reliability across many trees.
>> 
>> (For those of you not familiar with the patch set, it adds 
>> 'multiple-frontends to a single transport bus' support for the HVR3000 
>> and HVR4000, and potentially another 7134 based design (the 6 way medion 
>> board?).
>
>is this code still using more than one demux device per transport bus, or
>has it already been changed to make use of the DMX_SET_SOURCE command?

At this time it duplicates all the device nodes along with
the frontends.

I have looked into this somewhat, and appreciate what you
are referring to. There would seem to be quite some 
significant reworking needed in videobuf-dvb to achieve
this requirement of one mux with multi-frontends in a
clean fashion.

If this is show-stopper, then so be it.

cya!

--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Steven Toth]

Andreas Oberritter wrote:
> Hello Steve,
> 
> Steven Toth wrote:
>> I'm mutating the subject thread, and cc'ing the public mailing list into 
>> this conversion. Now is the time to announce the intension to merge 
>> multi-frontend patches, and show that we have tested and are satisfied 
>> with it's reliability across many trees.
>>
>> (For those of you not familiar with the patch set, it adds 
>> 'multiple-frontends to a single transport bus' support for the HVR3000 
>> and HVR4000, and potentially another 7134 based design (the 6 way medion 
>> board?).
> 
> is this code still using more than one demux device per transport bus, or
> has it already been changed to make use of the DMX_SET_SOURCE command?

Yes.

I'm glad you mentioned this, I discussed this at LPC with a number of 
people.

The current code that's being tested in the mfe tree's implements 
multiple demux devices, that has not changed.

Speaking with two other devs at LPC we discussed changing this approach 
(and the current approach for many dual channel boards), to having a 
unified single adapter device, with either multiple demux devices or 
not. As a basic discussion topic the ideal had a lot of support.

A good example of this in the current kernel (without any MFE patches) 
is the current cx23885 driver, that registers adapter0 and adapter1 with 
two different ATSC frontends. I question (and argue) that it should 
really be /dev/dvb/adapter0/demux{0,1}

The same is also true for the for the multi-frontend patches, it should 
probably change (as part of an overall adapterX overhaul) to match the 
LinuxTV DVB API and register only one demux device.

That's a much larger project, and has not been addressed yet. Many users 
will probably also argue that it's unimportant work, when application 
are currently working.

My opinion is that we would review the adapter usage and determine 
whether we need or want to change that. If we do change it we should 
probably add some better application interfaces from the adapter inode - 
In a model similar to the S2API has done for frontends. Applications 
would then be able to query board specific details in a way that cannot 
be easily done now.

However, regardless of my opinions, it would be a mistake to hold back a 
merge of the current multi-frontend patches. Instead, we should merge 
the large number of MFE patches and start a larger adapter level 
discussion and slowly evolve with smaller patches. (We'll need someone 
to draft an RFC).

Are you volunteering to address this larger subject?

- Steve


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Steven Toth]

Darron Broad wrote:
> In message <48F42D5C.7090908@linuxtv.org>, Andreas Oberritter wrote:
> 
> hi.
> 
>> Hello Steve,
>>
>> Steven Toth wrote:
>>> I'm mutating the subject thread, and cc'ing the public mailing list into 
>>> this conversion. Now is the time to announce the intension to merge 
>>> multi-frontend patches, and show that we have tested and are satisfied 
>>> with it's reliability across many trees.
>>>
>>> (For those of you not familiar with the patch set, it adds 
>>> 'multiple-frontends to a single transport bus' support for the HVR3000 
>>> and HVR4000, and potentially another 7134 based design (the 6 way medion 
>>> board?).
>> is this code still using more than one demux device per transport bus, or
>> has it already been changed to make use of the DMX_SET_SOURCE command?
> 
> At this time it duplicates all the device nodes along with
> the frontends.
> 
> I have looked into this somewhat, and appreciate what you
> are referring to. There would seem to be quite some 
> significant reworking needed in videobuf-dvb to achieve
> this requirement of one mux with multi-frontends in a
> clean fashion.

I think we have four different people reporting success with all of the 
tree's, cx88, cx23885 and saa7134.

I'm going to issue the pull request for the MFE patches.

Thanks to everyone involved.

- Steve


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Christophe Thommeret]

Le Tuesday 14 October 2008 16:57:42 Steven Toth, vous avez écrit :
> Andreas Oberritter wrote:
> > Hello Steve,
> >
> > Steven Toth wrote:
> >> I'm mutating the subject thread, and cc'ing the public mailing list into
> >> this conversion. Now is the time to announce the intension to merge
> >> multi-frontend patches, and show that we have tested and are satisfied
> >> with it's reliability across many trees.
> >>
> >> (For those of you not familiar with the patch set, it adds
> >> 'multiple-frontends to a single transport bus' support for the HVR3000
> >> and HVR4000, and potentially another 7134 based design (the 6 way medion
> >> board?).
> >
> > is this code still using more than one demux device per transport bus, or
> > has it already been changed to make use of the DMX_SET_SOURCE command?
>
> Yes.
>
> I'm glad you mentioned this, I discussed this at LPC with a number of
> people.
>
> The current code that's being tested in the mfe tree's implements
> multiple demux devices, that has not changed.
>
> Speaking with two other devs at LPC we discussed changing this approach
> (and the current approach for many dual channel boards), to having a
> unified single adapter device, with either multiple demux devices or
> not. As a basic discussion topic the ideal had a lot of support.
>
> A good example of this in the current kernel (without any MFE patches)
> is the current cx23885 driver, that registers adapter0 and adapter1 with
> two different ATSC frontends. I question (and argue) that it should
> really be /dev/dvb/adapter0/demux{0,1}

Yes, sounded logical to me also. The fact that "frontend" and "demux" was 
suffixed with an integer suggested that, that's why kaffeine probes 
frontend/demux >0.
I think that the actual way of populating multiple adpaters is to make these 
devices working with current apps without any modifications.
On the other hand, since only dreambox drivers seem to use multiple frontends 
on single adapter, maybe this actual (and bad, i agree) way should be kept 
and multiple frontends on single adapter reserved for exclusive frontends  
until the api provide such properties query, so applications can assume these 
frontends to be exclusive.

> The same is also true for the for the multi-frontend patches, it should
> probably change (as part of an overall adapterX overhaul) to match the
> LinuxTV DVB API and register only one demux device.
>
> That's a much larger project, and has not been addressed yet. Many users
> will probably also argue that it's unimportant work, when application
> are currently working.
>
> My opinion is that we would review the adapter usage and determine
> whether we need or want to change that. If we do change it we should
> probably add some better application interfaces from the adapter inode -
> In a model similar to the S2API has done for frontends. Applications
> would then be able to query board specific details in a way that cannot
> be easily done now.
>
> However, regardless of my opinions, it would be a mistake to hold back a
> merge of the current multi-frontend patches. Instead, we should merge
> the large number of MFE patches and start a larger adapter level
> discussion and slowly evolve with smaller patches. (We'll need someone
> to draft an RFC).
>
> Are you volunteering to address this larger subject?
>
> - Steve




-- 
Christophe Thommeret


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Andreas Oberritter]

Steven Toth wrote:
> A good example of this in the current kernel (without any MFE patches)
> is the current cx23885 driver, that registers adapter0 and adapter1 with
> two different ATSC frontends. I question (and argue) that it should
> really be /dev/dvb/adapter0/demux{0,1}

Did you mean frontend{0,1} here?

> The same is also true for the for the multi-frontend patches, it should
> probably change (as part of an overall adapterX overhaul) to match the
> LinuxTV DVB API and register only one demux device.
> 
> That's a much larger project, and has not been addressed yet. Many users
> will probably also argue that it's unimportant work, when application
> are currently working.
> 
> My opinion is that we would review the adapter usage and determine
> whether we need or want to change that. If we do change it we should
> probably add some better application interfaces from the adapter inode -
> In a model similar to the S2API has done for frontends. Applications
> would then be able to query board specific details in a way that cannot
> be easily done now.

Yes, such an interface is definitely missing.

> However, regardless of my opinions, it would be a mistake to hold back a
> merge of the current multi-frontend patches. Instead, we should merge
> the large number of MFE patches and start a larger adapter level
> discussion and slowly evolve with smaller patches. (We'll need someone
> to draft an RFC).

There's no need to hold back the merge. Even if someone decides to change
the code to match the DVB API later, then it wouldn't be a change to the
API itself. (Or is there any change being done to the user interface now?)
Application developers can already add support for DMX_SET_SOURCE now.

> Are you volunteering to address this larger subject?

No.

Regards,
Andreas

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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Andreas Oberritter]

Christophe Thommeret wrote:
> I think that the actual way of populating multiple adpaters is to make these 
> devices working with current apps without any modifications.

For sure.

> On the other hand, since only dreambox drivers seem to use multiple frontends 
> on single adapter, maybe this actual (and bad, i agree) way should be kept 
> and multiple frontends on single adapter reserved for exclusive frontends  
> until the api provide such properties query, so applications can assume these 
> frontends to be exclusive.

Actually, the way it is implemented on the Dreambox is not that bad, because
there is at least one demux available for each frontend and you can choose
which frontend to connect to which demux(es), to use one demux for live tv,
and other ones for PIP or recording. But that doesn't really match PC
peripherials.

Regards,
Andreas

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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Steven Toth]

Andreas Oberritter wrote:
> Steven Toth wrote:
>> A good example of this in the current kernel (without any MFE patches)
>> is the current cx23885 driver, that registers adapter0 and adapter1 with
>> two different ATSC frontends. I question (and argue) that it should
>> really be /dev/dvb/adapter0/demux{0,1}
> 
> Did you mean frontend{0,1} here?

demux _and_ frontend, for different reasons.

> 
>> The same is also true for the for the multi-frontend patches, it should
>> probably change (as part of an overall adapterX overhaul) to match the
>> LinuxTV DVB API and register only one demux device.
>>
>> That's a much larger project, and has not been addressed yet. Many users
>> will probably also argue that it's unimportant work, when application
>> are currently working.
>>
>> My opinion is that we would review the adapter usage and determine
>> whether we need or want to change that. If we do change it we should
>> probably add some better application interfaces from the adapter inode -
>> In a model similar to the S2API has done for frontends. Applications
>> would then be able to query board specific details in a way that cannot
>> be easily done now.
> 
> Yes, such an interface is definitely missing.

Yeah, I've been thinking more and more about this. I need to finish some 
other projects before I try some ideas - but I think we need more bridge 
level support for applications.

> 
>> However, regardless of my opinions, it would be a mistake to hold back a
>> merge of the current multi-frontend patches. Instead, we should merge
>> the large number of MFE patches and start a larger adapter level
>> discussion and slowly evolve with smaller patches. (We'll need someone
>> to draft an RFC).
> 
> There's no need to hold back the merge. Even if someone decides to change
> the code to match the DVB API later, then it wouldn't be a change to the
> API itself. (Or is there any change being done to the user interface now?)
> Application developers can already add support for DMX_SET_SOURCE now.

OK.

> 
>> Are you volunteering to address this larger subject?
> 
> No.

OK. To be honest, I dbout anyone else will either.

Regards,

- Steve


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

Re: [linux-dvb] Multi-frontend patch merge (TESTERS FEEDBACK) was: Re: [PATCH] S2API: add multifrontend

[Hans Werner]

> > >> darron@kewl.org
> > > 
> > > The test machine I have here utilises an HVR-4000 and AVERMEDIA
> > > SUPER 007.
> > > 
> > > Multi-frontend works with both adapters with the HVR-4000 containing
> > > analogue, DVB-S and DVB-T frontends, the AVERMEDIA solely DVB-T.
> > > 
> > > At this time with some further FM updates (see:
> > http://hg.kewl.org/s2-mfe-fm/)
> > > I can now reliably and consitently receive DVB-S/S2, DVB-T, analogue
> TV
> > > and FM radio on the HVR-4000. DVB-T works on the AVERMEDIA as per
> > > normal.
> > > 
> 
> I have tested with the HVR4000 on many iterations of the MFE drivers and
> retested with
> the latest s2-mfe tree yesterday. I found no problems for DVB-S, DVB-S2
> (both QPSK
> and PSK_8), DVB-T and analogue TV.
> 
> I will test the latest FM radio patch.

Just an update on this: I have now tested Darron's latest FM radio patch from
with the HVR4000 and it is working well for me. I have the FMD1216MEX tuner
variant of this card.

I am tuning the radio with fm-tools and playing sound with ALSA arecord and aplay
(standard distro versions, no changes necessary). Tuning takes around 2 seconds.
Sound is heard in stereo.

Regards,
Hans


-- 
Release early, release often.

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

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