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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

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]

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

[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

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

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

[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

[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] Multiproto API/Driver Update

[Otto Kekäläinen]

Hello,

I've read this thread and also the thread "Future of Multiproto" from
fall 2007 and I fealt I should say a few words about this..

I am not an expert in driver coding or APIs, so I can't say much about
who's technical approach is the most elegant or best in any way. I just
hope you could agree on some solution that would allow Mantis work to be
merged into v4l main so that the number of supported devices in v4l
would grow. For me, one of the beauties of FOSS is that once somebody
has coded a piece of good code, like a working driver, everybody in the
world can benefit of it almost immediately and without artificial
restrictions.

>From my point of view the state of v4l is far from optimal: I bought
myself a Terratec Cynergy C HD DVB -card (not a very new model). To get
it working I first tried the most recent v4l drivers, which I compiled
from source, but it didn't work. After some work I finally got it
working by using Mantis' version of v4l with a patch by Pauli Borodulin
and a IR remote code table made by myself. Now it works perfectly as
long as my distro releases a kernel update - after those I need to
recompile the driver manually.

This isn't very user friendly or technically elegant. Having to do this
mych work is OK while the driver is under development, but after about 6
months or so this hardware should work out-of-the-box.

Having all of our combined work in the main v4l, which is delivered by
Linux distros to users, would make everything work out-of-the-box for
everybody doing the same a few months after us - that would be nice and
I think that should be the ultimate goal, right?

Thanks to you all for you efforts! Hopefully all Linux drivers could go
upstream and ultimately benefit everybody in the future..


-- 
| Otto Kekäläinen
| http://www.sange.fi/


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

[linux-dvb] Multiproto API/Driver Update

[lucian orasanu]

>Feedback, bug reports, etc. are welcomed and encouraged!  Please feel
>free to
>contact me via email at:  abraham.manu at gmail.com
>
>If you have an unsupported device, please let me know!
>
>Best Regards,
>Manu

Can you solve stb08900 driver bugs?? that was reported in ML when you where away??



      

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

lucian orasanu wrote:
> 
> Can you solve stb08900 driver bugs?? that was reported in ML when you where away??

I need to read through the pile of emails in my mailbox, will go through
them one by one.

Regards,
Manu


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

[linux-dvb] Multiproto API/Driver Update

[Manu Abraham]

Greetings.

First I would like to thank everyone for their patience.  Multiproto
has been under development for some time and I know many of you have
been anxious for its arrival.  I would also like to thank all the
people who've helped code and test the new api.  Last but not least, a
thanks to the app developers who've supported multiproto, and whose
continued support is very much appreciated.

As you might already know, I've been out-of-town for the last few
months and haven't been able to progress multiproto further.  I've now
returned and am glad to announce I've been putting the finishing
touches on the multiproto api, along with many fixes/updates to
supported drivers.  Multiproto has reached a state where it is ready
to be adopted into the kernel and already has a pull request to do so.

Here are some important pieces of information for you to know:

current supported modulations with supported hardware:
DVB-S, DVB-S2, DVB-T, DVB-C, DVB-H

How big is multiproto?
It's not.  It doesn't exceed the size of the legacy api and is infact
smaller when used in non-legacy mode.

Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
Intentionally, no!  Experience with the old api development has proven
that making blind assumptions about delivery systems is a bad idea.
It's better to add in support for these when the hardware actually arrives
and can be properly tested. There is enough reserved space in the api to
support future modulations.

current supported chipsets/devices:
STB0899 based cards (AD SP400/VP-1041, TT S2 3200, KNC1 DVB-S2 etc.)

drivers currently in development:
STB0900/STB0903 based (eg. SAA716x based cards: AD SE-200/VP-1028, etc.)

To clear up some misinformation and misconceptions:

Is multiproto backwards compatible with previously built binaries?
YES!  You don't need to do anything to make it backward compatible.

Does multiproto have support for drivers found in v4l?
YES!  Multiproto includes the v4l tree as well.  However, the software
you use must support the multiproto api in order to use them.
Fortunately many already do but in the event support for the api must
be added, it can usually be done with minor changes.

Are new modulations possible?
YES!  Multiproto has been designed so that adding new future
modulations may be done with minimal effort.  This will help speed up
the driver development process and allow us to use this api for some
time to come.

If you would like to use any of these drivers now, you may pull the
tree from http://jusst.de/hg/multiproto.  Drivers may be configured
with 'make menuconfig' the same as you've done with v4l.

Feedback, bug reports, etc. are welcomed and encouraged!  Please feel
free to
contact me via email at:  abraham.manu@gmail.com

If you have an unsupported device, please let me know!

Best 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

[Goga777]

Hi, Manu

is it possible to patch scan2 for dvb-s2 support ?

Goga

> Greetings.
> 
> First I would like to thank everyone for their patience.  Multiproto
> has been under development for some time and I know many of you have
> been anxious for its arrival.  I would also like to thank all the
> people who've helped code and test the new api.  Last but not least, a
> thanks to the app developers who've supported multiproto, and whose
> continued support is very much appreciated.
> 
> As you might already know, I've been out-of-town for the last few
> months and haven't been able to progress multiproto further.  I've now
> returned and am glad to announce I've been putting the finishing
> touches on the multiproto api, along with many fixes/updates to
> supported drivers.  Multiproto has reached a state where it is ready
> to be adopted into the kernel and already has a pull request to do so.
> 
> Here are some important pieces of information for you to know:
> 
> current supported modulations with supported hardware:
> DVB-S, DVB-S2, DVB-T, DVB-C, DVB-H
> 
> How big is multiproto?
> It's not.  It doesn't exceed the size of the legacy api and is infact
> smaller when used in non-legacy mode.
> 
> Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
> Intentionally, no!  Experience with the old api development has proven
> that making blind assumptions about delivery systems is a bad idea.
> It's better to add in support for these when the hardware actually arrives
> and can be properly tested. There is enough reserved space in the api to
> support future modulations.
> 
> current supported chipsets/devices:
> STB0899 based cards (AD SP400/VP-1041, TT S2 3200, KNC1 DVB-S2 etc.)
> 
> drivers currently in development:
> STB0900/STB0903 based (eg. SAA716x based cards: AD SE-200/VP-1028, etc.)
> 
> To clear up some misinformation and misconceptions:
> 
> Is multiproto backwards compatible with previously built binaries?
> YES!  You don't need to do anything to make it backward compatible.
> 
> Does multiproto have support for drivers found in v4l?
> YES!  Multiproto includes the v4l tree as well.  However, the software
> you use must support the multiproto api in order to use them.
> Fortunately many already do but in the event support for the api must
> be added, it can usually be done with minor changes.
> 
> Are new modulations possible?
> YES!  Multiproto has been designed so that adding new future
> modulations may be done with minimal effort.  This will help speed up
> the driver development process and allow us to use this api for some
> time to come.
> 
> If you would like to use any of these drivers now, you may pull the
> tree from http://jusst.de/hg/multiproto.  Drivers may be configured
> with 'make menuconfig' the same as you've done with v4l.
> 
> Feedback, bug reports, etc. are welcomed and encouraged!  Please feel
> free to
> contact me via email at:  abraham.manu@gmail.com
> 
> If you have an unsupported device, please let me know!
> 
> Best 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]

Hi Goga,

Goga777 wrote:
> Hi, Manu
> 
> is it possible to patch scan2 for dvb-s2 support ?


Will do so.

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

[Johannes Stezenbach]

On Thu, Sep 04, 2008, Manu Abraham wrote:
> 
> Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
> Intentionally, no!  Experience with the old api development has proven
> that making blind assumptions about delivery systems is a bad idea.
> It's better to add in support for these when the hardware actually arrives
> and can be properly tested.

Full ACK on this one. Once an API is merged into the mailine
kernel we're stuck with it, no matter how ugly and broken it might be.
-> NEVER merge untested APIs

> If you would like to use any of these drivers now, you may pull the
> tree from http://jusst.de/hg/multiproto.  Drivers may be configured
> with 'make menuconfig' the same as you've done with v4l.
> 
> Feedback, bug reports, etc. are welcomed and encouraged!

I only want to add a bit of historical perspective so people
are aware of the reasons why Steve came up with his alternative
API proposal, and why a number of developers seem to support it.

First let's look at the timestamps:
http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.h

Then at some discussion from nearly one year ago:
http://article.gmane.org/gmane.linux.drivers.dvb/36643


Johannes
-- 
"Folks,
As vou can see for yourself.
The way this clock over here
is behaving,
TIME IS OF AFFLICTION!
Now this might be cause for alarm
Among a portion of you, as,
>From a certain experience,
I TEND TO PROCLAIM:
'THE EONS ARE CLOSING'!" -- Frank Zappa

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

Hi,

On Thu, Sep 4, 2008 at 10:47 PM, Johannes Stezenbach <js@linuxtv.org> wrote:
> On Thu, Sep 04, 2008, Manu Abraham wrote:
>>
>> Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
>> Intentionally, no!  Experience with the old api development has proven
>> that making blind assumptions about delivery systems is a bad idea.
>> It's better to add in support for these when the hardware actually arrives
>> and can be properly tested.
>

I have Empia ISDB-T and DMB-T/H hardware and the corresponding signal
generator for it here,
it's right on my roadmap and work can be started within a few days.

> Full ACK on this one. Once an API is merged into the mailine
> kernel we're stuck with it, no matter how ugly and broken it might be.
> -> NEVER merge untested APIs

should be the rule but there's always an exception for it too . o (
thinking about KVM )

>
>> If you would like to use any of these drivers now, you may pull the
>> tree from http://jusst.de/hg/multiproto.  Drivers may be configured
>> with 'make menuconfig' the same as you've done with v4l.
>>
>> Feedback, bug reports, etc. are welcomed and encouraged!
>
> I only want to add a bit of historical perspective so people
> are aware of the reasons why Steve came up with his alternative
> API proposal, and why a number of developers seem to support it.
>
> First let's look at the timestamps:
> http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
> http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.h
>
> Then at some discussion from nearly one year ago:
> http://article.gmane.org/gmane.linux.drivers.dvb/36643
>

by experience I'm sure most people won't read up the history here...

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:
> Hi,
> 
> On Thu, Sep 4, 2008 at 10:47 PM, Johannes Stezenbach <js@linuxtv.org> wrote:
>> On Thu, Sep 04, 2008, Manu Abraham wrote:
>>> Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
>>> Intentionally, no!  Experience with the old api development has proven
>>> that making blind assumptions about delivery systems is a bad idea.
>>> It's better to add in support for these when the hardware actually arrives
>>> and can be properly tested.

We have ISDB-T running under linux in the lab, we have a pretty good 
idea about what we need to generalize for an API, but you can't make a 
standard out of one demod.

All API's developers should be cautious here.


> 
> I have Empia ISDB-T and DMB-T/H hardware and the corresponding signal
> generator for it here,
> it's right on my roadmap and work can be started within a few days.

A big difference between can and will, the em28xx fiasco tells us this.

I hope this next question isn't seen as a flame, because I ask this as a 
genuine question. Are you committing to adding ISDB-T and DMB-T/H 
support to master at linuxtv.org? Or would this be something you'd plan 
to keep at you own site, like your other code?


> 
>> Full ACK on this one. Once an API is merged into the mailine
>> kernel we're stuck with it, no matter how ugly and broken it might be.
>> -> NEVER merge untested APIs

Indeed.

> 
> should be the rule but there's always an exception for it too . o (
> thinking about KVM )
> 
>>> If you would like to use any of these drivers now, you may pull the
>>> tree from http://jusst.de/hg/multiproto.  Drivers may be configured
>>> with 'make menuconfig' the same as you've done with v4l.
>>>
>>> Feedback, bug reports, etc. are welcomed and encouraged!
>> I only want to add a bit of historical perspective so people
>> are aware of the reasons why Steve came up with his alternative
>> API proposal, and why a number of developers seem to support it.

/me nods

>>
>> First let's look at the timestamps:
>> http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
>> http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.h
>>
>> Then at some discussion from nearly one year ago:
>> http://article.gmane.org/gmane.linux.drivers.dvb/36643

This is worth reading.

>>
> 
> by experience I'm sure most people won't read up the history here...

Also agreed, a lot of people have lost sight of the history - which is 
the entire reason that the S2API alternative exists.

Manu,

The S2API tree is available on linuxtv.org with HVR4000 support, 
spanning 3 or 4 patches.

I have a TT-3200, do you have a complete tree with all of your pull 
req'd patches available on linuxtv.org for testing, including your 
demodulation and tuning drivers? Do you have a complete solution that I 
can evaluate for pro's and cons?

Thanks,

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

[Simon Kenyon]

Steven Toth wrote:
> A big difference between can and will, the em28xx fiasco tells us this.
>   
just wondering if your tree will go any way towards resolving that 
little problem?
--
simo

_______________________________________________
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 7, 2008 at 9:15 PM, Simon Kenyon <simon@koala.ie> wrote:
> Steven Toth wrote:
>> A big difference between can and will, the em28xx fiasco tells us this.
>>
> just wondering if your tree will go any way towards resolving that
> little problem?

I don't see any fiasco nor problem here, it's more comfortable to have
the em28xx in an extra
tree and do ongoing development with it. People who followed the
development  during the last
few years know that newer things got added and newer chips are
supported by it, it will continue
to evolve anyway.

The driverwork is currently around 30% of it, patching applications
and providing full support from
the driver till the endapplications is what everything's focussing on
mcentral.de not just driver only
development.

We do dedicated application support for several customers too (analog
tv, radio, dvb integration in their
business applications).
There are many new products coming up, adding support for them is on
the roadmap.

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]

Markus Rechberger wrote:
> On Sun, Sep 7, 2008 at 9:15 PM, Simon Kenyon <simon@koala.ie> wrote:
>   
>> Steven Toth wrote:
>>     
>>> A big difference between can and will, the em28xx fiasco tells us this.
>>>
>>>       
>> just wondering if your tree will go any way towards resolving that
>> little problem?
>>     
>
> I don't see any fiasco nor problem here, it's more comfortable to have
> the em28xx in an extra
> tree and do ongoing development with it. People who followed the
> development  during the last
> few years know that newer things got added and newer chips are
> supported by it, it will continue
> to evolve anyway.
>
> The driverwork is currently around 30% of it, patching applications
> and providing full support from
> the driver till the endapplications is what everything's focussing on
> mcentral.de not just driver only
> development.
>
> We do dedicated application support for several customers too (analog
> tv, radio, dvb integration in their
> business applications).
> There are many new products coming up, adding support for them is on
> the roadmap.
>
> Markus
>
>   
i have had the device for a while now
i originally got it because the wiki showed that support was being worked on
then that all changed and you moved your stuff elsewhere

i really don't understand your rationale. i really don't.
i'm not trying to start a flame war, but your arguments for having your 
own tree and doing stuff user side makes no sense

let my try to explain:

you say:

 > it is more comfortable to have the em28xx in an extra tree

it may very well be comfortable for you. but it is impossible for me
i have lots of different devices. i can choose between using your tree 
and having support for one of them.
or i change choose the linuxtv.org tree and have supoort for all the 
other. how is that "more comfortable"?
i really don't understand that argument

you then say:

 > newer things get added and newer chips are supported by it

how does that help me? it doesn't, as far as i can see

next you say:

 > the driverwork is currently around 30% of it, patching applications 
and providing full support from the driver till the...

apart from the little speedbump that is multiproto vs. s2api most apps 
don't need "supporting". they are already supported by their respective 
communities.

 > we do dedicated application support for several customers...

now i think we get to the heart of the matter.
you have built up a nice little business providing support for the 
various devices. you have customers who (in my humble opinion 
misguidedly) think that by having support in your tree that they can 
proudly boast "linux supported". all i can say is well done. 
congratulations on building a sucessful business.

but please do not mistake that for providing linux support for the 
em28xx devices in linux. what you are providing and "linux support of 
the em28xx class of devices" are not one and the same thing. for better 
or worse, linux support means that at some point (and it may well be one 
year from now) it will be in the kernel.
have you not seen all the software that has come and gone because linus 
will not put it in the tree. right now the only route to doing that is 
to get it in the linuxtv.org tree. from there it stands some chance of 
making it into the kernel. i seriously doubt that any other approach has 
any chance of success.

this may not be of concern or interest to you. well so be it. but it is 
important to me.

regards and best of luck
--
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 Mon, Sep 8, 2008 at 1:14 PM, Simon Kenyon <simon@koala.ie> wrote:
> Markus Rechberger wrote:
>>
>> On Sun, Sep 7, 2008 at 9:15 PM, Simon Kenyon <simon@koala.ie> wrote:
>>
>>>
>>> Steven Toth wrote:
>>>
>>>>
>>>> A big difference between can and will, the em28xx fiasco tells us this.
>>>>
>>>>
>>>
>>> just wondering if your tree will go any way towards resolving that
>>> little problem?
>>>
>>
>> I don't see any fiasco nor problem here, it's more comfortable to have
>> the em28xx in an extra
>> tree and do ongoing development with it. People who followed the
>> development  during the last
>> few years know that newer things got added and newer chips are
>> supported by it, it will continue
>> to evolve anyway.
>>
>> The driverwork is currently around 30% of it, patching applications
>> and providing full support from
>> the driver till the endapplications is what everything's focussing on
>> mcentral.de not just driver only
>> development.
>>
>> We do dedicated application support for several customers too (analog
>> tv, radio, dvb integration in their
>> business applications).
>> There are many new products coming up, adding support for them is on
>> the roadmap.
>>
>> Markus
>>
>>
>
> i have had the device for a while now
> i originally got it because the wiki showed that support was being worked on
> then that all changed and you moved your stuff elsewhere
>
> i really don't understand your rationale. i really don't.
> i'm not trying to start a flame war, but your arguments for having your own
> tree and doing stuff user side makes no sense
>
> let my try to explain:
>
> you say:
>
>> it is more comfortable to have the em28xx in an extra tree
>
> it may very well be comfortable for you. but it is impossible for me
> i have lots of different devices. i can choose between using your tree and
> having support for one of them.
> or i change choose the linuxtv.org tree and have supoort for all the other.
> how is that "more comfortable"?
> i really don't understand that argument
>
> you then say:
>
>> newer things get added and newer chips are supported by it
>
> how does that help me? it doesn't, as far as i can see
>
> next you say:
>
>> the driverwork is currently around 30% of it, patching applications and
>> providing full support from the driver till the...
>
> apart from the little speedbump that is multiproto vs. s2api most apps don't
> need "supporting". they are already supported by their respective
> communities.
>
>> we do dedicated application support for several customers...
>
> now i think we get to the heart of the matter.
> you have built up a nice little business providing support for the various
> devices. you have customers who (in my humble opinion misguidedly) think
> that by having support in your tree that they can proudly boast "linux
> supported". all i can say is well done. congratulations on building a
> sucessful business.
>
> but please do not mistake that for providing linux support for the em28xx
> devices in linux. what you are providing and "linux support of the em28xx
> class of devices" are not one and the same thing. for better or worse, linux
> support means that at some point (and it may well be one year from now) it
> will be in the kernel.
> have you not seen all the software that has come and gone because linus will
> not put it in the tree. right now the only route to doing that is to get it
> in the linuxtv.org tree. from there it stands some chance of making it into
> the kernel. i seriously doubt that any other approach has any chance of
> success.
>
> this may not be of concern or interest to you. well so be it. but it is
> important to me.
>

the code on mcentral.de didn't write itself, it was mostly written
from our side.
If you're going to pay my monthly insurance for working together with
linuxtv.org (something has to
compensate the slowdown of the development due those endless wanted
discussions) I'll be glad to
go that way.

Application development and driver development is right now at an
acceptable speed, noone bothers
about fixed drivers there which improve the signal strength etc.

The code is already used with BSD [1] now and will be used by our OSX
driver in near future.

Markus

[1] http://netbsd-soc.sourceforge.net/projects/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

[Halim Sahin]

Hi,
On Mo, Sep 08, 2008 at 02:21:21 +0200, Markus Rechberger wrote:
> If you're going to pay my monthly insurance for working together with
> linuxtv.org (something has to
> compensate the slowdown of the development due those endless wanted
> discussions) I'll be glad to
> go that way.

Your choosen way doesn't compensate the non-ending diskusions too.
Maybe you should start to show other developers how things can go on
without slowing down development and
building drivers out of official kernel tree?

I read most of the mails on this list and
the current situation is really annoying.

1. We have multiproto
2. We have s2-API
3. We have your drivers at mcentral.de

Please go on alltogether and stop working against each other.
Have a nice Day

Halim


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

Halim Sahin wrote:
> Hi,
> On Mo, Sep 08, 2008 at 02:21:21 +0200, Markus Rechberger wrote:
>> If you're going to pay my monthly insurance for working together with
>> linuxtv.org (something has to
>> compensate the slowdown of the development due those endless wanted
>> discussions) I'll be glad to
>> go that way.
> 
> Your choosen way doesn't compensate the non-ending diskusions too.
> Maybe you should start to show other developers how things can go on
> without slowing down development and
> building drivers out of official kernel tree?
> 
> I read most of the mails on this list and
> the current situation is really annoying.
> 
> 1. We have multiproto
> 2. We have s2-API
> 3. We have your drivers at mcentral.de
> 
> Please go on alltogether and stop working against each other.
> Have a nice Day

S2API is available on linuxtv.org, along with all of my other trees. I 
don't get paid by Hauppauge to work on Linux.... I chose to work from 
linuxtv.org because I love Linux and I believe that's where the heart of 
the community belongs.

Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that 
those developers don't want to contribute to the community at linuxtv.org.

S2API is actively maintained at linuxtv.org, where the community owns 
the code.

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

> Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that 
> those developers don't want to contribute to the community at linuxtv.org.

Since it is another round of spreading lies and false accusations, i
will respond.

http://thread.gmane.org/gmane.linux.kernel/729892

http://thread.gmane.org/gmane.linux.kernel/729969

also at

http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/

Normally anyone sane would think that the linux-kernel @kernel.org is
just a superset of any smaller Linux-* communities.

Maybe you just need to find a newer topic to spread Fear, Uncertainty
and Doubt (FUD).

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

[Hans Werner]

-------- Original-Nachricht --------
> Datum: Mon, 08 Sep 2008 21:54:46 +0400
> Von: Manu Abraham <abraham.manu@gmail.com>
> An: linux-dvb@linuxtv.org
> Betreff: Re: [linux-dvb] Multiproto API/Driver Update

> Steven Toth wrote:
> 
> > Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that 
> > those developers don't want to contribute to the community at
> linuxtv.org.
> 
> Since it is another round of spreading lies and false accusations, i
> will respond.
> 
> http://thread.gmane.org/gmane.linux.kernel/729892
> 
> http://thread.gmane.org/gmane.linux.kernel/729969
> 
> also at
> 
> http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/
> 
> Normally anyone sane would think that the linux-kernel @kernel.org is
> just a superset of any smaller Linux-* communities.
> 
> Maybe you just need to find a newer topic to spread Fear, Uncertainty
> and Doubt (FUD).
> 
> Regards,
> Manu

Where's the beef? The drivers are missing.
http://linuxtv.org/pipermail/linux-dvb/2008-September/028445.html


-- 
Release early, release often.

Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03

_______________________________________________
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 Mon, Sep 8, 2008 at 8:19 PM, Hans Werner <HWerner4@gmx.de> wrote:
>
> -------- Original-Nachricht --------
>> Datum: Mon, 08 Sep 2008 21:54:46 +0400
>> Von: Manu Abraham <abraham.manu@gmail.com>
>> An: linux-dvb@linuxtv.org
>> Betreff: Re: [linux-dvb] Multiproto API/Driver Update
>
>> Steven Toth wrote:
>>
>> > Fragmenting tree's to mcentral.de or Manu's repo (just.de?) shows that
>> > those developers don't want to contribute to the community at
>> linuxtv.org.
>>
>> Since it is another round of spreading lies and false accusations, i
>> will respond.
>>
>> http://thread.gmane.org/gmane.linux.kernel/729892
>>
>> http://thread.gmane.org/gmane.linux.kernel/729969
>>
>> also at
>>
>> http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/
>>
>> Normally anyone sane would think that the linux-kernel @kernel.org is
>> just a superset of any smaller Linux-* communities.
>>
>> Maybe you just need to find a newer topic to spread Fear, Uncertainty
>> and Doubt (FUD).
>>
>> Regards,
>> Manu
>
> Where's the beef? The drivers are missing.
> http://linuxtv.org/pipermail/linux-dvb/2008-September/028445.html
>

The drivers will come afterwards, first the split out framework
afterwards the rest.
(just as far as I understood).

I fully agree with Manu though.

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]

Hans Werner wrote:

> Where's the beef? The drivers are missing.
> http://linuxtv.org/pipermail/linux-dvb/2008-September/028445.html
> 

If you have read the post or the links what i sent or what i wrote maybe
you would have understood.

Also, i don't know whether you are the same Hans Werner as in here:

http://article.gmane.org/gmane.linux.drivers.dvb/44017

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

Simon Kenyon wrote:
> Markus Rechberger wrote:
>> On Sun, Sep 7, 2008 at 9:15 PM, Simon Kenyon <simon@koala.ie> wrote:
>>   
>>> Steven Toth wrote:
>>>     
>>>> A big difference between can and will, the em28xx fiasco tells us this.
>>>>
>>>>       
>>> just wondering if your tree will go any way towards resolving that
>>> little problem?
>>>     
>> I don't see any fiasco nor problem here, it's more comfortable to have
>> the em28xx in an extra
>> tree and do ongoing development with it. People who followed the
>> development  during the last
>> few years know that newer things got added and newer chips are
>> supported by it, it will continue
>> to evolve anyway.
>>
>> The driverwork is currently around 30% of it, patching applications
>> and providing full support from
>> the driver till the endapplications is what everything's focussing on
>> mcentral.de not just driver only
>> development.
>>
>> We do dedicated application support for several customers too (analog
>> tv, radio, dvb integration in their
>> business applications).
>> There are many new products coming up, adding support for them is on
>> the roadmap.
>>
>> Markus
>>
>>   
> i have had the device for a while now
> i originally got it because the wiki showed that support was being worked on
> then that all changed and you moved your stuff elsewhere
> 
> i really don't understand your rationale. i really don't.
> i'm not trying to start a flame war, but your arguments for having your 
> own tree and doing stuff user side makes no sense
> 
> let my try to explain:
> 
> you say:
> 
>  > it is more comfortable to have the em28xx in an extra tree
> 
> it may very well be comfortable for you. but it is impossible for me
> i have lots of different devices. i can choose between using your tree 
> and having support for one of them.
> or i change choose the linuxtv.org tree and have supoort for all the 
> other. how is that "more comfortable"?
> i really don't understand that argument
> 
> you then say:
> 
>  > newer things get added and newer chips are supported by it
> 
> how does that help me? it doesn't, as far as i can see
> 
> next you say:
> 
>  > the driverwork is currently around 30% of it, patching applications 
> and providing full support from the driver till the...
> 
> apart from the little speedbump that is multiproto vs. s2api most apps 
> don't need "supporting". they are already supported by their respective 
> communities.
> 
>  > we do dedicated application support for several customers...
> 
> now i think we get to the heart of the matter.
> you have built up a nice little business providing support for the 
> various devices. you have customers who (in my humble opinion 
> misguidedly) think that by having support in your tree that they can 
> proudly boast "linux supported". all i can say is well done. 
> congratulations on building a sucessful business.
> 
> but please do not mistake that for providing linux support for the 
> em28xx devices in linux. what you are providing and "linux support of 
> the em28xx class of devices" are not one and the same thing. for better 
> or worse, linux support means that at some point (and it may well be one 
> year from now) it will be in the kernel.
> have you not seen all the software that has come and gone because linus 
> will not put it in the tree. right now the only route to doing that is 
> to get it in the linuxtv.org tree. from there it stands some chance of 
> making it into the kernel. i seriously doubt that any other approach has 
> any chance of success.
> 
> this may not be of concern or interest to you. well so be it. but it is 
> important to me.

Good comments Simon, and I largely agree with you.

I've tried to help mediate on issues like this in the past, trying to 
get the em28xx tree back to linuxtv.org and in the master repo. But, 
people are people and the major players fundamentally disagree about 
major issues. We can't find a way to resolve this - and I don't think it 
will ever be resolved.

Pity, because Hauppauge sold a lot of em28xx based products, as did many 
other companies.

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

Simon Kenyon wrote:
> Steven Toth wrote:
>> A big difference between can and will, the em28xx fiasco tells us this.
>>   
> just wondering if your tree will go any way towards resolving that 
> little problem?

I have enough in the API now to tune some experimental ISDB-T products 
we have in the lab. That code is already in the the tune.c for anyone to 
view.

Like everything, it will evolve over time but the code is available now 
for you to view in tune.c

- 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:
> Hi,
> 
> On Thu, Sep 4, 2008 at 10:47 PM, Johannes Stezenbach <js@linuxtv.org> wrote:
>> On Thu, Sep 04, 2008, Manu Abraham wrote:
>>> Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
>>> Intentionally, no!  Experience with the old api development has proven
>>> that making blind assumptions about delivery systems is a bad idea.
>>> It's better to add in support for these when the hardware actually arrives
>>> and can be properly tested.
> 
> I have Empia ISDB-T and DMB-T/H hardware and the corresponding signal
> generator for it here,
> it's right on my roadmap and work can be started within a few days.

With all due respect, their is a big difference between can and will.

Are you committing to adding ISDB-T and DMB-T/H support, and having that 
code live at linuxtv.org?

Or, are these patches something that you'd want to keep in your 
out-of-kernel trees at mcentral.de, like your other works? (This isn't 
am opportunity to flame, it's a genuine question - I'm interested in 
your future direction plans).


> 
>> Full ACK on this one. Once an API is merged into the mailine
>> kernel we're stuck with it, no matter how ugly and broken it might be.
>> -> NEVER merge untested APIs
> 
> should be the rule but there's always an exception for it too . o (
> thinking about KVM )


We don't add API's that can't be tested, that's just a basic rule.


> 
>>> If you would like to use any of these drivers now, you may pull the
>>> tree from http://jusst.de/hg/multiproto.  Drivers may be configured
>>> with 'make menuconfig' the same as you've done with v4l.
>>>
>>> Feedback, bug reports, etc. are welcomed and encouraged!
>> I only want to add a bit of historical perspective so people
>> are aware of the reasons why Steve came up with his alternative
>> API proposal, and why a number of developers seem to support it.


Yes.


>>
>> First let's look at the timestamps:
>> http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
>> http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.h
>>
>> Then at some discussion from nearly one year ago:
>> http://article.gmane.org/gmane.linux.drivers.dvb/36643

This is a great one page email, worth reading everyone.

>>
> 
> by experience I'm sure most people won't read up the history here...

Maybe.

Manu,

The S2API tree is available on linuxtv.org for people to download and 
experiment with. It has HVR4000 DVB-S2 support, QAM, ATSC, DVB-S and 
DVB-T. These are known to work with the exercising tool. We are testing 
ISDB-T over the next few days.... It's preliminary.

I need to do some comparison for plumbers.

Why aren't you issuing a pull request that includes the 3200 drivers?

- 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

[hermann pitton]

Am Donnerstag, den 04.09.2008, 22:47 +0200 schrieb Johannes Stezenbach:
> On Thu, Sep 04, 2008, Manu Abraham wrote:
> > 
> > Does it support ISDB-T, ATSC-MH, CMMB, DBM-T/H?
> > Intentionally, no!  Experience with the old api development has proven
> > that making blind assumptions about delivery systems is a bad idea.
> > It's better to add in support for these when the hardware actually arrives
> > and can be properly tested.
> 
> Full ACK on this one. Once an API is merged into the mailine
> kernel we're stuck with it, no matter how ugly and broken it might be.
> -> NEVER merge untested APIs
> 
> > If you would like to use any of these drivers now, you may pull the
> > tree from http://jusst.de/hg/multiproto.  Drivers may be configured
> > with 'make menuconfig' the same as you've done with v4l.
> > 
> > Feedback, bug reports, etc. are welcomed and encouraged!
> 
> I only want to add a bit of historical perspective so people
> are aware of the reasons why Steve came up with his alternative
> API proposal, and why a number of developers seem to support it.
> 
> First let's look at the timestamps:
> http://jusst.de/hg/multiproto/log/2a911b8f9910/linux/include/linux/dvb/frontend.h
> http://jusst.de/hg/multiproto_api_merge/log/4c62efb08ea6/linux/include/linux/dvb/frontend.h
> 
> Then at some discussion from nearly one year ago:
> http://article.gmane.org/gmane.linux.drivers.dvb/36643
> 
> 
> Johannes

-- 
"Folks,
As vou can see for yourself.
The way this clock over here
is behaving,
TIME IS OF AFFLICTION!
Now this might be cause for alarm
Among a portion of you, as,
>From a certain experience,
I TEND TO PROCLAIM:
'THE EONS ARE CLOSING'!" -- Frank Zappa

OK, maybe more quoting does help a little.

"Im Falschen kann es nichts Richtiges geben."

Theodor W. Adorno

"Da steh ich nun ich armer Tor und bin so klug als je zuvor."

Johann Wolfgang von Goethe

"Wo viel Licht ist, ist auch viel Schatten."

As said previously, the "best" interpreter ever was Ronald Reagan on his
Berlin speech ...

Again the same author.

In general I prefer Zappa too, it's more like driving beans to Utah or
that one with the fried chickens :)

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

[Francesco Schiavarelli]

Seeing how hot API discussion got lately I think it's time to write on 
the subject.

Some time ago a discussion went on multiple TS support in DVB-S2, see:

http://article.gmane.org/gmane.linux.drivers.dvb/37299

I know that is a typical broadcaster application that a "normal" user 
won't benefit so much, but I'd love to see it implemented as I think 
v4l-dvb will gain some professional adoption.

 From a purely technical point of view how hard will be to extend 
multiproto to support such feature? And is S2API ready for the same?

I'd like also to see support for non-tuning devices like ASI input 
cards, is it planned?

thanks
Francesco

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

Francesco Schiavarelli wrote:
> Seeing how hot API discussion got lately I think it's time to write on
> the subject.
> 
> Some time ago a discussion went on multiple TS support in DVB-S2, see:
> 
> http://article.gmane.org/gmane.linux.drivers.dvb/37299


Yes, i do remember.

> I know that is a typical broadcaster application that a "normal" user
> won't benefit so much, but I'd love to see it implemented as I think
> v4l-dvb will gain some professional adoption.
> 
> From a purely technical point of view how hard will be to extend
> multiproto to support such feature?


The data structure is quite simple with regards to S2. We've had some
lab tests only on this feature and not wide spread tests and results. If
someone can provide access to such streams in practical life it would be
quite easy to add it.


> And is S2API ready for the same?
> 

No idea. i guess not.

> I'd like also to see support for non-tuning devices like ASI input
> cards, is it planned?

We've had a discussion on ASI input. Also i do have an ASI patch on my
machine somewhere here. It can be added in to multiproto quite easily.

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

[barry bouwsma]

Ciao,

--- On Fri, 9/5/08, Francesco Schiavarelli <kaboom@tiscalinet.it> wrote:

> Seeing how hot API discussion got lately I think it's time to write on 
> the subject.

I'm going to avoid giving an opinion, because I don't have one
to give as an outsider, other than whatever works, is good...


What I wonder, is two things.

Does DiSEqC 1.1 fit into the existing API, and is it more of
a question of hardware support (generally I've noticed 1.0 and
1.2 listed), and applications being able to handle the additional
switching (I've found an app limit of 4 positions)?

I don't know enough about the internals of DiSEqC to have any idea
what I'm talking about; I've got a 1.1 switch on order, and I have
a 1.1-able 8/1+16/1 receiver, where those appear to be incompatible
with my existing 4/1 switch.


Second, how do non-DVB-like technologies like DAB (Eureka-147) fit
into the scope of either multiproto or S2API -- or must they
remain outside of v4l-dvb?

The Wiki sez, ``some developers already have hardware using
standards unsupported by multiproto, such as ISDB-T and DMB-T/H.''
And some of us non-developers have such hardware and want to try
it with non-Windows for readily-receiveable DAB.

Or is DAB/T-DMB too different from DVB and related technologies,
that a separate development path needs to be taken outside
linux-dvb, but probably within V4L?


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

[Manu Abraham]

barry bouwsma wrote:
> Ciao,
> 

[..]

> 
> What I wonder, is two things.
> 
> Does DiSEqC 1.1 fit into the existing API, and is it more of
> a question of hardware support (generally I've noticed 1.0 and
> 1.2 listed), and applications being able to handle the additional
> switching (I've found an app limit of 4 positions)?

Cascading is not supported by the dvb-apps, i must say. It's more of a
support from the application side.

As far as multiproto goes, the driver used alongwith it supports DiSEqC 2.0


> I don't know enough about the internals of DiSEqC to have any idea
> what I'm talking about; I've got a 1.1 switch on order, and I have
> a 1.1-able 8/1+16/1 receiver, where those appear to be incompatible
> with my existing 4/1 switch.
> 
> 
> Second, how do non-DVB-like technologies like DAB (Eureka-147) fit
> into the scope of either multiproto or S2API -- or must they
> remain outside of v4l-dvb?


There is already a kernel module called dabusb for ages.


> The Wiki sez, ``some developers already have hardware using
> standards unsupported by multiproto, such as ISDB-T and DMB-T/H.''
> And some of us non-developers have such hardware and want to try
> it with non-Windows for readily-receiveable DAB.

With some simple definitions ? What applications are used ? With regards
to ISDB-T, there was an idea to integrate the ARIB extension used in the
DVB V4 API, but then it was proven that there wasn't much use for the
same due to:

* lack of available hardware (only some mobile devices using 1 seg or
likewise were available) Of course, there was the demodulator from
Toshiba TCxxxx, the DVB V4 API which it was based on.

* most of the stuff's completely scrambled and the scrambling schemes
are not open like DVB stuff.

But still, if there's need to add support for the same into the
multiproto tree, it is quite trivial.

> Or is DAB/T-DMB too different from DVB and related technologies,
> that a separate development path needs to be taken outside
> linux-dvb, but probably within V4L?

DMB resembles quite a bit of DAB. Well, the tables for DMB-T/H is quite
different from standard DVB tables, but still you can use multiproto to
handle DMB-T/H, it's quite trivial.

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

[Jelle De Loecker]

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

Is there any change in the cultiproto disecq code?

For example
MythTV won't tune to channels on disecq port 2 or higher. (Disecq port 1 
always works)

However, Kaffeine works. I'm able to watch every BBC channel on Astra 
28,2 (which is on my second port)

This made me think it's MythTV.
But a friend of mine now said an older, regular DVB-S card DOES work 
with disecq.

I must point out that I'm not using the latest multiproto drivers, the 
one with the old_api support (so that I don't have to patch mythtv)

/Met vriendelijke groeten,/

*Jelle De Loecker*
Kipdola Studios - Tomberg


Manu Abraham schreef:
> barry bouwsma wrote:
>   
>> Ciao,
>>
>>     
>
> [..]
>
>   
>> What I wonder, is two things.
>>
>> Does DiSEqC 1.1 fit into the existing API, and is it more of
>> a question of hardware support (generally I've noticed 1.0 and
>> 1.2 listed), and applications being able to handle the additional
>> switching (I've found an app limit of 4 positions)?
>>     
>
> Cascading is not supported by the dvb-apps, i must say. It's more of a
> support from the application side.
>
> As far as multiproto goes, the driver used alongwith it supports DiSEqC 2.0
>
>
>   
>> I don't know enough about the internals of DiSEqC to have any idea
>> what I'm talking about; I've got a 1.1 switch on order, and I have
>> a 1.1-able 8/1+16/1 receiver, where those appear to be incompatible
>> with my existing 4/1 switch.
>>
>>
>> Second, how do non-DVB-like technologies like DAB (Eureka-147) fit
>> into the scope of either multiproto or S2API -- or must they
>> remain outside of v4l-dvb?
>>     
>
>
> There is already a kernel module called dabusb for ages.
>
>
>   
>> The Wiki sez, ``some developers already have hardware using
>> standards unsupported by multiproto, such as ISDB-T and DMB-T/H.''
>> And some of us non-developers have such hardware and want to try
>> it with non-Windows for readily-receiveable DAB.
>>     
>
> With some simple definitions ? What applications are used ? With regards
> to ISDB-T, there was an idea to integrate the ARIB extension used in the
> DVB V4 API, but then it was proven that there wasn't much use for the
> same due to:
>
> * lack of available hardware (only some mobile devices using 1 seg or
> likewise were available) Of course, there was the demodulator from
> Toshiba TCxxxx, the DVB V4 API which it was based on.
>
> * most of the stuff's completely scrambled and the scrambling schemes
> are not open like DVB stuff.
>
> But still, if there's need to add support for the same into the
> multiproto tree, it is quite trivial.
>
>   
>> Or is DAB/T-DMB too different from DVB and related technologies,
>> that a separate development path needs to be taken outside
>> linux-dvb, but probably within V4L?
>>     
>
> DMB resembles quite a bit of DAB. Well, the tables for DMB-T/H is quite
> different from standard DVB tables, but still you can use multiproto to
> handle DMB-T/H, it's quite trivial.
>
> Regards,
> Manu
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>   

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

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

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

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

[Manu Abraham]

Jelle De Loecker wrote:
> Is there any change in the cultiproto disecq code?
> 

No newer changes on the diseqc part.

> For example
> MythTV won't tune to channels on disecq port 2 or higher. (Disecq port 1
> always works)
> 
> However, Kaffeine works. I'm able to watch every BBC channel on Astra
> 28,2 (which is on my second port)
> 
> This made me think it's MythTV.

There was a post on the VDR ML a while back on the same. It was the
DiSEqC Command sequence being used. There was a discussion on that very
same topic. You can do a quick lookup on the archives for the same.


Regards,
Manu

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

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

[Markus Rechberger]

On Mon, Sep 8, 2008 at 10:54 PM, Manu Abraham <abraham.manu@gmail.com> wrote:
> Jelle De Loecker wrote:
>> Is there any change in the cultiproto disecq code?
>>
>
> No newer changes on the diseqc part.
>
>> For example
>> MythTV won't tune to channels on disecq port 2 or higher. (Disecq port 1
>> always works)
>>
>> However, Kaffeine works. I'm able to watch every BBC channel on Astra
>> 28,2 (which is on my second port)
>>
>> This made me think it's MythTV.
>
> There was a post on the VDR ML a while back on the same. It was the
> DiSEqC Command sequence being used. There was a discussion on that very
> same topic. You can do a quick lookup on the archives for the same.
>

We can work together if you want on ISDB-T and DMB-TH if you want!
Just to clear out those considerations too.

Best regards,
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:

> 
> We can work together if you want on ISDB-T and DMB-TH if you want!
> Just to clear out those considerations too.


I don't have any inhibitions in working with anyone. Whatever work i
have done is quite open, where quite a lot of people have collaborated
on the same, some way or the other.

But, consider this as an advice, whatever work you put your effort in
to, if it goes to the mainline kernel eventually, it can benefit a whole
community at large.


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

[Uri Shkolnik]

Manu and all,


First I would like to present myself (I'm new to this forum)
My name is Uri Shkolnik, and I work as Software Architecture at Siano Mobile Silicon (www.siano-ms.com).

As some people reading this mailing list know, but some don't.... Siano manufactures chipsets that support various of MDTV standards (DVB-H, DVB-T, ISDB-T, CMMB, T-DMB, DAB-IP,... and many more). Many products you see actually uses Siano's chipsets.

As far as I understand from this thread, and from other threads, the LinuxTV/DVB sub-system will not support non-DVB standards in the near future.

This is quite understandable since those standards are quite complicate, and the newer are even more complicated than DVB-C/S/T. It took about 5 years for the DVB sub-system to become mature, so, trying to add all of those standards at once will lead to nowhere good.

I don't know what should be done next, which API (and sub-system) should be added first, second, ... (or not at all?). I have my own views (CMMB getting much more audience than DVB-H and ISDB-T more than the DAB family). 

But, I can offer technical assistant. Siano is senior member at most of the MDTV consortiumes (CMMB, DVB and more) and I have access to lot of technical documentation (specifications, guildlines, etc.) which are otherwise quite hard (if not impossible) to be obtained.
True that some (not all) of those papers are under classification that does not permit me to share them directly, but always a specific question can be answered.

One point regarding Siano non-DVB offering - With Michael Krufky's help, I'm trying to find a way to add Siano's non-DVB(-T) offering into the kernel's code base (till now we supply a proprietary sources directly to our customers). Of course it will be somewhat specific code by the fact that it'll match Siano's chipset instead of be more generic.


So, I'm done with the introduction..... :-)


Regards,

Uri




      

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

Uri Shkolnik wrote:
> Manu and all,
> 
> 
> First I would like to present myself (I'm new to this forum)
> My name is Uri Shkolnik, and I work as Software Architecture at Siano Mobile Silicon (www.siano-ms.com).
> 
> As some people reading this mailing list know, but some don't.... Siano manufactures chipsets that support various of MDTV standards (DVB-H, DVB-T, ISDB-T, CMMB, T-DMB, DAB-IP,... and many more). Many products you see actually uses Siano's chipsets.
> 
> As far as I understand from this thread, and from other threads, the LinuxTV/DVB sub-system will not support non-DVB standards in the near future.
> 

Well, this is not true. What the idea we put forward was thus:

* have an API that is capable of supporting things which are needed in
the future as well, not just for now.

* At the point of working on the same, we mostly worked on DSS, DVB-S2,
DVB-H, also for some DOCSIS cable modems. Since these were somewhat
suppoted on many hardware we had.

* The Linux DVB V4 API supports ISDB-T and is running on some STB's
http://linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel-v4/

This is something which has been proven with regards to the ARIB
extensions as well, so we can use the interface of the delivery system
in the new API. But having no open drivers which were really supported,
really was a let down and the scrambling being employed -- was not
something that was open, slowed down things quite a lot, as it was yet
to be seen whether such supported hardware drivers would really exist
under Linux.

* With regards to DMB-T/H or the Chinese T-DMB, there is quite some
people interested on the same, This can be added in to the API at any
point of time, without sacrificing backward binary compatibility.

* There was even DVB-T2 in the works at that time, but it was argued and
proven right that we shouldn't just blindly keep adding things till we
really have support on the same.

You can see my post over here:
http://thread.gmane.org/gmane.linux.kernel/729969

> This is quite understandable since those standards are quite complicate, and the newer are even more complicated than DVB-C/S/T. It took about 5 years for the DVB sub-system to become mature, so, trying to add all of those standards at once will lead to nowhere good.
> 

True, one must look first what hardware will the general home user would
like to get going under Linux. There are some features professional
users also would like to get going.

But adding all the definitions into an API will be just a mess:
for example ATSC over satellite was a standard that was put forward at
some point of time and later on the whole standard itself was scrapped
in favour of DVB over satellite.

> I don't know what should be done next, which API (and sub-system) should be added first, second, ... (or not at all?). I have my own views (CMMB getting much more audience than DVB-H and ISDB-T more than the DAB family). 
> 
> But, I can offer technical assistant. Siano is senior member at most of the MDTV consortiumes (CMMB, DVB and more) and I have access to lot of technical documentation (specifications, guildlines, etc.) which are otherwise quite hard (if not impossible) to be obtained.
> True that some (not all) of those papers are under classification that does not permit me to share them directly, but always a specific question can be answered.

That would be nice. Well, there are quite some vendors who are willing
to help as well. Some of us have access to some of the consortiums,
AFAICS. If there's supported hardware out there, we can add in support
in the API too, for the relevant delivery systems.

The easiest way to do so, will be to start a discussion, on a newer
thread as to what you will need in terms of API support in a newer
delivery system.

> One point regarding Siano non-DVB offering - With Michael Krufky's help, I'm trying to find a way to add Siano's non-DVB(-T) offering into the kernel's code base (till now we supply a proprietary sources directly to our customers). Of course it will be somewhat specific code by the fact that it'll match Siano's chipset instead of be more generic.
> 


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

[barry bouwsma]

--- On Mon, 9/8/08, Uri Shkolnik <urishk@yahoo.com> wrote:

> First I would like to present myself (I'm new to this forum)

A hearty Welcome from my side, and I hope you have a pleasant
stay.  Please help yourself to the refreshments from the bar,
and have a kipper.  ;-)


> I don't know what should be done next, which API (and
> sub-system) should be added first, second, ... (or not at
> all?). I have my own views (CMMB getting much more audience
> than DVB-H and ISDB-T more than the DAB family). 

Of course, this will depend on your location -- in some parts
of Europe, DVB-H is available as an (subscription) option and
DAB is widespread from the provider-point-of-view.

It is from my perspective in Europe that I write, where ISDB-T
is not used, but DAB hardware is relatively difficult to find.
Still, DAB services have been widely available for a longer
time than DVB-T has been operating.


> One point regarding Siano non-DVB offering - With Michael
> Krufky's help, I'm trying to find a way to add
> Siano's non-DVB(-T) offering into the kernel's code
> base (till now we supply a proprietary sources directly to
> our customers).

When you say `customers', do you mean business customers,
for example, TerraTec, which has incorporated your device
into the Cinergy Piranha, which I have, and for which the
TerraTec-supplied 'Doze media player can sort-of successfully
play the available DAB stations?  Or do you mean, `end-users'
(fnarr) such as myself, who want to use this device under
Linux, for more than DVB-T?


Here is my biggest question, which probably could be answered
if I used a Real Web Browser.

My Internet access is mostly through a SSH connection to a text-
only web-browser on a trusted host, usually on a borrowed
connection.  So I don't have access to Javascript links, or
other non-text offerings -- and often I have no access at all,
so I've sort of adopted a UUCP-like way of `working', for some
values of `work'.


In Mr. Krufky's work, I've seen reference to Siano-provided
drivers as an alternative to those which he's painstakingly
adapted and included in the mainstream.  Unfortunately for me,
the link is to the main webpage, and from there, normal links
lead nowhere interesting.  There are plenty of Javascript links
that I can't follow.  So, I haven't found anything which might
help me to answer my further questions myself, and for that,
I must apologise.


>  Of course it will be somewhat specific code
> by the fact that it'll match Siano's chipset instead
> of be more generic.

I don't see this as a real problem, because I don't know
how to weave a generic API from the DAB/DAB+ specs that
I've read.


I was hoping to find a diagram of the demodulation process
for DAB streams, from the OFDM RF carrier (handled by the
hardware) to the mp2/AAC+ audio decoding (in Linux, handled
by a userspace software player).  Unfortunately, I could not
find anything...

Had I found something, I would ask you, if it is not obvious
from freely-available code to customers, just where in the
chain of decoding, your hardware outputs a stream.  I mean,
if I supply a channel number such as 12C (VHF), would I be
seeing the entire multiplex from which I could extract one
particular service, or can I expect something more specific?


I suspect that I would likely find that with different
devices (of the few that are available), I'd be tapping
into the demodulation-demultiplexing chain at different
points, therefore needing to be able to tweak the devices
differently appropriate to where I tap into the chain.


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

[Uri Shkolnik]

--- On Thu, 9/11/08, barry bouwsma <free_beer_for_all@yahoo.com> wrote:

> From: barry bouwsma <free_beer_for_all@yahoo.com>
> Subject: Re: [linux-dvb] Multiproto API/Driver Update
> To: "linux-dvb" <linux-dvb@linuxtv.org>, urishk@yahoo.com
> Date: Thursday, September 11, 2008, 11:51 PM
> --- On Mon, 9/8/08, Uri Shkolnik <urishk@yahoo.com>
> wrote:
> 
> > First I would like to present myself (I'm new to
> this forum)
> 
> A hearty Welcome from my side, and I hope you have a
> pleasant
> stay.  Please help yourself to the refreshments from the
> bar,
> and have a kipper.  ;-)
> 

Thanks :-)

> 
> > I don't know what should be done next, which API
> (and
> > sub-system) should be added first, second, ... (or not
> at
> > all?). I have my own views (CMMB getting much more
> audience
> > than DVB-H and ISDB-T more than the DAB family). 
> 
> Of course, this will depend on your location -- in some
> parts
> of Europe, DVB-H is available as an (subscription) option
> and
> DAB is widespread from the provider-point-of-view.
> 
> It is from my perspective in Europe that I write, where
> ISDB-T
> is not used, but DAB hardware is relatively difficult to
> find.
> Still, DAB services have been widely available for a longer
> time than DVB-T has been operating.
> 
I'm not so sure. As I see it, if it depends on number of users DVB-H comes last after CMMB and ISDB-T.

> 
> > One point regarding Siano non-DVB offering - With
> Michael
> > Krufky's help, I'm trying to find a way to add
> > Siano's non-DVB(-T) offering into the kernel's
> code
> > base (till now we supply a proprietary sources
> directly to
> > our customers).
> 
> When you say `customers', do you mean business
> customers,
> for example, TerraTec, which has incorporated your device
> into the Cinergy Piranha, which I have, and for which the
> TerraTec-supplied 'Doze media player can sort-of
> successfully
> play the available DAB stations?  Or do you mean,
> `end-users'
> (fnarr) such as myself, who want to use this device under
> Linux, for more than DVB-T?
> 

Siano does not manufacture devices. So 'business customers' will fit. 

I know the TerraTec device you refer to, and theoretically it can be used as DAB radio receiver. The current LinuxTV lacks the code to support it.
  
> 
> Here is my biggest question, which probably could be
> answered
> if I used a Real Web Browser.
> 
> My Internet access is mostly through a SSH connection to a
> text-
> only web-browser on a trusted host, usually on a borrowed
> connection.  So I don't have access to Javascript
> links, or
> other non-text offerings -- and often I have no access at
> all,
> so I've sort of adopted a UUCP-like way of
> `working', for some
> values of `work'.
> 
> 
> In Mr. Krufky's work, I've seen reference to
> Siano-provided
> drivers as an alternative to those which he's
> painstakingly
> adapted and included in the mainstream.  Unfortunately for
> me,
> the link is to the main webpage, and from there, normal
> links
> lead nowhere interesting.  There are plenty of Javascript
> links
> that I can't follow.  So, I haven't found anything
> which might
> help me to answer my further questions myself, and for
> that,
> I must apologise.

You can ask any question you like to, I'll gladly help you with anything I can. 

> 
> 
> >  Of course it will be somewhat specific code
> > by the fact that it'll match Siano's chipset
> instead
> > of be more generic.
> 
> I don't see this as a real problem, because I don't
> know
> how to weave a generic API from the DAB/DAB+ specs that
> I've read.
> 

It's quite simple actually. 
There is a open source module from Siano that enable DAB @ Linux. The problem is that this module is not a part of DVB and does not communicates with DVB in any way, but it uses its own character devices in order to communicate with user space applications. It may be converted of course to something that uses DVB, and also be more generic.

> 
> I was hoping to find a diagram of the demodulation process
> for DAB streams, from the OFDM RF carrier (handled by the
> hardware) to the mp2/AAC+ audio decoding (in Linux, handled
> by a userspace software player).  Unfortunately, I could
> not
> find anything...

I'm not sure I understand you, so -
1) You always get the digital output from the device (in case of DAB it a framed stream). I don't know any hardware that pipe out the raw modem output.
2) If you refer to the frontend parameters (for DAB family), I can supply you with those.
3) FIB parsing (this is part of the control scheme that is used by DAB) - you get a stream of data frames contain it. Siano offers binary library (user space) that parses it and gives simple API to know what are the available services.


> 
> Had I found something, I would ask you, if it is not
> obvious
> from freely-available code to customers, just where in the
> chain of decoding, your hardware outputs a stream.  I mean,
> if I supply a channel number such as 12C (VHF), would I be
> seeing the entire multiplex from which I could extract one
> particular service, or can I expect something more
> specific?
> 
DAB is not a multiplex... 
> 
> I suspect that I would likely find that with different
> devices (of the few that are available), I'd be tapping
> into the demodulation-demultiplexing chain at different
> points, therefore needing to be able to tweak the devices
> differently appropriate to where I tap into the chain.
> 



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

[Christophe Thommeret]

Le Friday 12 September 2008 00:23:35 Uri Shkolnik, vous avez écrit :
> DAB is not a multiplex...

???

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

[Uri Shkolnik]

--- On Fri, 9/12/08, Christophe Thommeret <hftom@free.fr> wrote:

> From: Christophe Thommeret <hftom@free.fr>
> Subject: Re: [linux-dvb] Multiproto API/Driver Update
> To: linux-dvb@linuxtv.org, urishk@yahoo.com
> Date: Friday, September 12, 2008, 2:16 AM
> Le Friday 12 September 2008 00:23:35 Uri Shkolnik, vous avez
> écrit :
> > DAB is not a multiplex...
> 
> ???
> 
> -- 
> Christophe Thommeret


[ Sorry for the late response ]

My mistake... of course it is a multiplex. 
My company's inner terminology (since we deal with multiple DTV standards) always refers to DAB multiplex as "ensemble" (in order to differ it from other multiplex types), and I applied it in this ML.... sorry. 

Uri



      

_______________________________________________
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 Thu, 9/11/08, Uri Shkolnik <urishk@yahoo.com> wrote:

> > It is from my perspective in Europe that I write,
> > 
> I'm not so sure. As I see it, if it depends on number
> of users DVB-H comes last after CMMB and ISDB-T.

Then let them add their support ;-P   I just discovered that
I should be within reception range of a (subscription) DVB-H
mux, though sticking a directional antenna out the window did
not show any signal (but also not on other previously-received
frequencies) -- but climbing a nearby hill should net me a
useful signal, maybe two.

For DAB, a simple paperclip antenna will get me one ensemble,
a second should be receivable as well, and perhaps with a good
antenna, some others may appear.

So, I can test real-world broadcasts and get the actual hands-
on experience I need to understand and be able to help --
which is more than I can for the other missing standards, as
I'm not so good with the theoretical...



> I know the TerraTec device you refer to, and theoretically
> it can be used as DAB radio receiver. The current LinuxTV
> lacks the code to support it.
[...]
> There is a open source module from Siano that enable DAB @
> Linux.

Is this something I would be able to download?  (Feel free to
mail me privately if you don't want it available to other
developers, though they could certainly fit it into a suitable
API much better than I could)

I've searched with g00gle but haven't found any source to
download.  (And if drivers under Linux for the other modes
(T-DMB, DVB-H) are available, they may help me to better
understand those modes as well)


>   The problem is that this module is not a part of DVB
> and does not communicates with DVB in any way, but it uses
> its own character devices in order to communicate with user
> space applications. It may be converted of course to
> something that uses DVB, and also be more generic.

There is another USB DAB device out there (apparently no
longer available, and if so, at an `early-adopter' price)
with kernel support.
Perhaps there's some shared functionality that can be
combined, somehow, and make easier possibly adding support
for some of the small handful of other DAB-able devices.


Anyway, if I'm able to start to play with my device and DAB
under linux, that should keep me busy and quiet for some time

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

[Uri Shkolnik]

--- On Fri, 9/12/08, barry bouwsma <free_beer_for_all@yahoo.com> wrote:

> From: barry bouwsma <free_beer_for_all@yahoo.com>
> Subject: Re: [linux-dvb] Multiproto API/Driver Update
> To: "linux-dvb" <linux-dvb@linuxtv.org>, urishk@yahoo.com
> Date: Friday, September 12, 2008, 12:17 PM
> --- On Thu, 9/11/08, Uri Shkolnik <urishk@yahoo.com>
> wrote:
> 
> > > It is from my perspective in Europe that I write,
> > > 
> > I'm not so sure. As I see it, if it depends on
> number
> > of users DVB-H comes last after CMMB and ISDB-T.
> 
> Then let them add their support ;-P   I just discovered
> that
> I should be within reception range of a (subscription)
> DVB-H
> mux, though sticking a directional antenna out the window
> did
> not show any signal (but also not on other
> previously-received
> frequencies) -- but climbing a nearby hill should net me a
> useful signal, maybe two.
> 
> For DAB, a simple paperclip antenna will get me one
> ensemble,
> a second should be receivable as well, and perhaps with a
> good
> antenna, some others may appear.
> 
> So, I can test real-world broadcasts and get the actual
> hands-
> on experience I need to understand and be able to help --
> which is more than I can for the other missing standards,
> as
> I'm not so good with the theoretical...
> 
> 
> 
> > I know the TerraTec device you refer to, and
> theoretically
> > it can be used as DAB radio receiver. The current
> LinuxTV
> > lacks the code to support it.
> [...]
> > There is a open source module from Siano that enable
> DAB @
> > Linux.
> 
> Is this something I would be able to download?  (Feel free
> to
> mail me privately if you don't want it available to
> other
> developers, though they could certainly fit it into a
> suitable
> API much better than I could)
> 
> I've searched with g00gle but haven't found any
> source to
> download.  (And if drivers under Linux for the other modes
> (T-DMB, DVB-H) are available, they may help me to better
> understand those modes as well)
> 
> 
> >   The problem is that this module is not a part of DVB
> > and does not communicates with DVB in any way, but it
> uses
> > its own character devices in order to communicate with
> user
> > space applications. It may be converted of course to
> > something that uses DVB, and also be more generic.
> 
> There is another USB DAB device out there (apparently no
> longer available, and if so, at an `early-adopter'
> price)
> with kernel support.
> Perhaps there's some shared functionality that can be
> combined, somehow, and make easier possibly adding support
> for some of the small handful of other DAB-able devices.
> 
> 
> Anyway, if I'm able to start to play with my device and
> DAB
> under linux, that should keep me busy and quiet for some
> time
> 
> thanks,
> barry bouwsma

[ Sorry for the late response ]

Regarding DAB support -

In order to add full support for DAB ( / DAB+ / T-DMB / DAB-IP / any other ensemble based transmission) you need to have an ensemble parser. This is quite a problem since I'm not familiar with any such decent open source parser.  

Anyone?

Uri


      

_______________________________________________
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 Thursday 18 September 2008 21:11:02 Uri Shkolnik, vous avez écrit :
> --- On Fri, 9/12/08, barry bouwsma <free_beer_for_all@yahoo.com> wrote:
> > From: barry bouwsma <free_beer_for_all@yahoo.com>
> > Subject: Re: [linux-dvb] Multiproto API/Driver Update
> > To: "linux-dvb" <linux-dvb@linuxtv.org>, urishk@yahoo.com
> > Date: Friday, September 12, 2008, 12:17 PM
> > --- On Thu, 9/11/08, Uri Shkolnik <urishk@yahoo.com>
> >
> > wrote:
> > > > It is from my perspective in Europe that I write,
> > >
> > > I'm not so sure. As I see it, if it depends on
> >
> > number
> >
> > > of users DVB-H comes last after CMMB and ISDB-T.
> >
> > Then let them add their support ;-P   I just discovered
> > that
> > I should be within reception range of a (subscription)
> > DVB-H
> > mux, though sticking a directional antenna out the window
> > did
> > not show any signal (but also not on other
> > previously-received
> > frequencies) -- but climbing a nearby hill should net me a
> > useful signal, maybe two.
> >
> > For DAB, a simple paperclip antenna will get me one
> > ensemble,
> > a second should be receivable as well, and perhaps with a
> > good
> > antenna, some others may appear.
> >
> > So, I can test real-world broadcasts and get the actual
> > hands-
> > on experience I need to understand and be able to help --
> > which is more than I can for the other missing standards,
> > as
> > I'm not so good with the theoretical...
> >
> > > I know the TerraTec device you refer to, and
> >
> > theoretically
> >
> > > it can be used as DAB radio receiver. The current
> >
> > LinuxTV
> >
> > > lacks the code to support it.
> >
> > [...]
> >
> > > There is a open source module from Siano that enable
> >
> > DAB @
> >
> > > Linux.
> >
> > Is this something I would be able to download?  (Feel free
> > to
> > mail me privately if you don't want it available to
> > other
> > developers, though they could certainly fit it into a
> > suitable
> > API much better than I could)
> >
> > I've searched with g00gle but haven't found any
> > source to
> > download.  (And if drivers under Linux for the other modes
> > (T-DMB, DVB-H) are available, they may help me to better
> > understand those modes as well)
> >
> > >   The problem is that this module is not a part of DVB
> > > and does not communicates with DVB in any way, but it
> >
> > uses
> >
> > > its own character devices in order to communicate with
> >
> > user
> >
> > > space applications. It may be converted of course to
> > > something that uses DVB, and also be more generic.
> >
> > There is another USB DAB device out there (apparently no
> > longer available, and if so, at an `early-adopter'
> > price)
> > with kernel support.
> > Perhaps there's some shared functionality that can be
> > combined, somehow, and make easier possibly adding support
> > for some of the small handful of other DAB-able devices.
> >
> >
> > Anyway, if I'm able to start to play with my device and
> > DAB
> > under linux, that should keep me busy and quiet for some
> > time
> >
> > thanks,
> > barry bouwsma
>
> [ Sorry for the late response ]
>
> Regarding DAB support -
>
> In order to add full support for DAB ( / DAB+ / T-DMB / DAB-IP / any other
> ensemble based transmission) you need to have an ensemble parser. This is
> quite a problem since I'm not familiar with any such decent open source
> parser.
>
> Anyone?

It's always possible to write one :)

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

[barry bouwsma]

--- On Mon, 9/8/08, Manu Abraham <abraham.manu@gmail.com> wrote:

> > Second, how do non-DVB-like technologies like DAB (Eureka-147) fit
> > into the scope of either multiproto or S2API -- or must they
> > remain outside of v4l-dvb?
> 
> There is already a kernel module called dabusb for ages.

I just looked at it again, now that I know a bit more about
how DAB works, and to confirm the impression I got earlier
when I was thinking about seeing if I could make it work
with my (then) new DAB-able device.

This seems to be written specifically for one particular
product, which I don't have, and I've forgotten what I've
read about it.  It seems to be mostly loading firmware to
the device, and pulling data from it via USB.  I don't
see any way to tune to a particular frequency, or select
a particular service, so that's presumably done elsewhere,
perhaps physically on the receiver itself.

The device I have is partly supported by the v4l-dvb `siano'
directory, with hints such as
#define MSG_SMS_DAB_CHANNEL        607

I have what looks to be a personal reply from Herr Acher
that has helped me understand a bit more about the dabusb
code/device, and I need to welcome the honourable Uri Shkolnik
and ask questions to learn about the Siano's support of DAB.



> > And some of us non-developers have such hardware and want to try
> > it with non-Windows for readily-receiveable DAB.
> 
> With some simple definitions ? What applications are used ?

I imagine I will have to hack something out of gaffer tape
and chewing gum if I want to actually do anything...



Now a completely different question -- I was pleased to see
that my not-too-old kernel compiled well with your mp_plus
source, and I read on the Wiki that certain basic tools
still needed to be ported to multiproto.

Something hands-on like this is probably the only way I'm
ever going to get a clue about the APIs.  And it might even
result in something useful in addition.  But I don't have
any hardware which requires multiproto, if I'd need that
for testing or anything.

Would it be worth it for me to attempt such a port, given
that, or will I find it unlikely to get anywhere?  I'm no
developer and no programmer, and barely a hacker...


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

[Uri Shkolnik]

Barry,

My name is Uri Shkolnik and I'm Siano's software architect.

If you would like to add a generic support for DAB, T-DMB, DAB2, DAB-IP, etc. to LinuxTV, it'll be great!

I can assist you with generic information, plus chipset specific information.

If you have a DAB related RF feed, I even can, on certain conditions, to supply you with a hardware (USB or SDIO based), I already did so before with different open source / Linux projects.

I'm not sure that DVB sub-system is the perfect location for DAB related devices, and what about multi-DTV devices? (Siano based chipsets devices support many DTV standards, DVB-x and DAB-y among them), maybe somewhere up the chain (under media/common ? elsewhere? I'm not pretending to be a Linux kernel nor LinuxTV expert).

Anyway, keep in touch, just letting you know that I'm here... (except my vacation between Sep 19th and Oct 20th :-)


Uri

--- On Wed, 9/10/08, barry bouwsma <free_beer_for_all@yahoo.com> wrote:

> From: barry bouwsma <free_beer_for_all@yahoo.com>
> Subject: Re: [linux-dvb] Multiproto API/Driver Update
> To: "Manu Abraham" <abraham.manu@gmail.com>
> Cc: linux-dvb@linuxtv.org
> Date: Wednesday, September 10, 2008, 3:52 AM
> --- On Mon, 9/8/08, Manu Abraham
> <abraham.manu@gmail.com> wrote:
> 
> > > Second, how do non-DVB-like technologies like DAB
> (Eureka-147) fit
> > > into the scope of either multiproto or S2API --
> or must they
> > > remain outside of v4l-dvb?
> > 
> > There is already a kernel module called dabusb for
> ages.
> 
> I just looked at it again, now that I know a bit more about
> how DAB works, and to confirm the impression I got earlier
> when I was thinking about seeing if I could make it work
> with my (then) new DAB-able device.
> 
> This seems to be written specifically for one particular
> product, which I don't have, and I've forgotten
> what I've
> read about it.  It seems to be mostly loading firmware to
> the device, and pulling data from it via USB.  I don't
> see any way to tune to a particular frequency, or select
> a particular service, so that's presumably done
> elsewhere,
> perhaps physically on the receiver itself.
> 
> The device I have is partly supported by the v4l-dvb
> `siano'
> directory, with hints such as
> #define MSG_SMS_DAB_CHANNEL        607
> 
> I have what looks to be a personal reply from Herr Acher
> that has helped me understand a bit more about the dabusb
> code/device, and I need to welcome the honourable Uri
> Shkolnik
> and ask questions to learn about the Siano's support of
> DAB.
> 
> 
> 
> > > And some of us non-developers have such hardware
> and want to try
> > > it with non-Windows for readily-receiveable DAB.
> > 
> > With some simple definitions ? What applications are
> used ?
> 
> I imagine I will have to hack something out of gaffer tape
> and chewing gum if I want to actually do anything...
> 
> 
> 
> Now a completely different question -- I was pleased to see
> that my not-too-old kernel compiled well with your mp_plus
> source, and I read on the Wiki that certain basic tools
> still needed to be ported to multiproto.
> 
> Something hands-on like this is probably the only way
> I'm
> ever going to get a clue about the APIs.  And it might even
> result in something useful in addition.  But I don't
> have
> any hardware which requires multiproto, if I'd need
> that
> for testing or anything.
> 
> Would it be worth it for me to attempt such a port, given
> that, or will I find it unlikely to get anywhere?  I'm
> no
> developer and no programmer, and barely a hacker...
> 
> 
> 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

[Michael Krufky]

On Wed, Sep 10, 2008 at 5:16 AM, Uri Shkolnik <urishk@yahoo.com> wrote:
> Barry,
>
> My name is Uri Shkolnik and I'm Siano's software architect.
>
> If you would like to add a generic support for DAB, T-DMB, DAB2, DAB-IP, etc. to LinuxTV, it'll be great!
>
> I can assist you with generic information, plus chipset specific information.
>
> If you have a DAB related RF feed, I even can, on certain conditions, to supply you with a hardware (USB or SDIO based), I already did so before with different open source / Linux projects.
>
> I'm not sure that DVB sub-system is the perfect location for DAB related devices, and what about multi-DTV devices? (Siano based chipsets devices support many DTV standards, DVB-x and DAB-y among them), maybe somewhere up the chain (under media/common ? elsewhere? I'm not pretending to be a Linux kernel nor LinuxTV expert).
>
> Anyway, keep in touch, just letting you know that I'm here... (except my vacation between Sep 19th and Oct 20th :-)

Uri,

The policy on this mailing list is not to top-post.  Email replies
should appear below the quoted text -- please keep this in mind for
the future.

As far as your previous comments, please get over the DVB
nomenclature.  LinuxDVB is the _name_ of the Linux kernel subsystem
that deals with digital media, as a whole, *not* limited to DVB-T,
DVB-S, DVB-C, DVB-T2, DVB-S2, DVB-C2, ATSC, ISDB-T, DVB-H, DMB-TH,
DAB,  etc etc etc

Your comment stating that, "the LinuxTV/DVB sub-system will not
support non-DVB standards in the near future" is entirely invalid.
There is no reason why the LinuxDVB API cannot be extended to support,
as you call them, "non-DVB" standards.

Now that you, Uri, have joined our community and are offering help
with documentation, specifications, etc, this is a great opportunity
to help in adding support for these new standards to the Linux Kernel.

Just so that everybody is on the same page here, there are two API
proposals on the table.  These proposals deal with ways to extend the
LinuxDVB API for future expansion.   The issue being discussed is
*not*  how to deal with adding support for additional standards -- we
already have that covered.  Regardless of whether Manu's proposal or
Steve's proposal is accepted, support for the same additional
standards will be added, while still leaving room for future
expansion.

Once the decision is officially made, as per who's API extension
proposal is accepted, then I welcome you to start discussing how we
can add support for the additional standards into the kernel.

Please don't reply to this message -- we're better off dealing with
this topic in a _new_ thread, after the API discussions have
completed.  To continue on with this here will only distract from the
threads original topic.

Thank you for your input.

Regards,

Mike 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

[Manu Abraham]

barry bouwsma wrote:

>>> And some of us non-developers have such hardware and want to try
>>> it with non-Windows for readily-receiveable DAB.
>> With some simple definitions ? What applications are used ?
> 
> I imagine I will have to hack something out of gaffer tape
> and chewing gum if I want to actually do anything...


Use any of the existing applications, "as it is".

> 
> Now a completely different question -- I was pleased to see
> that my not-too-old kernel compiled well with your mp_plus
> source, and I read on the Wiki that certain basic tools
> still needed to be ported to multiproto.


Please use the multiproto tree rather than the multiproto_plus tree.


> Something hands-on like this is probably the only way I'm
> ever going to get a clue about the APIs.  And it might even
> result in something useful in addition.  But I don't have
> any hardware which requires multiproto, if I'd need that
> for testing or anything.
> 
> Would it be worth it for me to attempt such a port, given
> that, or will I find it unlikely to get anywhere?  I'm no
> developer and no programmer, and barely a hacker...


You don't need to make any ports, neither for the drivers nor for the
applications ...


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 Samstag, den 13.09.2008, 01:43 +0400 schrieb Manu Abraham:
> barry bouwsma wrote:
> 
> >>> And some of us non-developers have such hardware and want to try
> >>> it with non-Windows for readily-receiveable DAB.
> >> With some simple definitions ? What applications are used ?
> > 
> > I imagine I will have to hack something out of gaffer tape
> > and chewing gum if I want to actually do anything...
> 
> 
> Use any of the existing applications, "as it is".
> 
> > 
> > Now a completely different question -- I was pleased to see
> > that my not-too-old kernel compiled well with your mp_plus
> > source, and I read on the Wiki that certain basic tools
> > still needed to be ported to multiproto.
> 
> 
> Please use the multiproto tree rather than the multiproto_plus tree.
> 
> 
> > Something hands-on like this is probably the only way I'm
> > ever going to get a clue about the APIs.  And it might even
> > result in something useful in addition.  But I don't have
> > any hardware which requires multiproto, if I'd need that
> > for testing or anything.
> > 
> > Would it be worth it for me to attempt such a port, given
> > that, or will I find it unlikely to get anywhere?  I'm no
> > developer and no programmer, and barely a hacker...
> 
> 
> You don't need to make any ports, neither for the drivers nor for the
> applications ...

Linus and Greg don't get their jobs done or do it too well.

Either stay more away from subsystems or come closer.

To let it hang around over years for cheap, is a pity.

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

[Klaus Schmidinger]

On 09/12/08 23:43, Manu Abraham wrote:
> barry bouwsma wrote:
> ...
>> Now a completely different question -- I was pleased to see
>> that my not-too-old kernel compiled well with your mp_plus
>> source, and I read on the Wiki that certain basic tools
>> still needed to be ported to multiproto.
> 
> 
> Please use the multiproto tree rather than the multiproto_plus tree.

I tried the multiproto version 855d0c878944, but it didn't work on
my system. My VDR doesn't recognize my DVB-T card and hangs upon startup.
When I try to unload the driver modules, the 'rmmod budget_core' appears
to hang. If I kill that, a subsequent 'lsmod' also hangs, so I need to do
a reboot - which also hangs, so a hard reset is the last resort.

Then I tried the latest multiproto_plus version adf34f76ab7c, with which
VDR's startup sequence results in

Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter0/frontend0
Sep 14 13:06:59 video vdr: [3313] CI adapter on device 0 thread started (pid=3309, tid=3313)
Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
Sep 14 13:06:59 video vdr: [3314] section handler thread started (pid=3309, tid=3314)
Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter1/frontend0
Sep 14 13:06:59 video vdr: [3316] CI adapter on device 1 thread started (pid=3309, tid=3316)
Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
Sep 14 13:06:59 video vdr: [3317] section handler thread started (pid=3309, tid=3317)
Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter2/frontend0
Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
Sep 14 13:06:59 video vdr: [3319] section handler thread started (pid=3309, tid=3319)
Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter3/frontend0
Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
Sep 14 13:06:59 video vdr: [3321] section handler thread started (pid=3309, tid=3321)

This is the DVBFE_GET_DELSYS call that apparently fails.

Using the multiproto_plus version 88821ce4ed8d (2008-04-13) works fine.
So I'm still using that one for now.

Have there been any API changes since multiproto_plus version 88821ce4ed8d
that I would need to take into account in VDR?

Klaus

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

Klaus Schmidinger wrote:
> On 09/12/08 23:43, Manu Abraham wrote:
>> barry bouwsma wrote:
>> ...
>>> Now a completely different question -- I was pleased to see
>>> that my not-too-old kernel compiled well with your mp_plus
>>> source, and I read on the Wiki that certain basic tools
>>> still needed to be ported to multiproto.
>>
>> Please use the multiproto tree rather than the multiproto_plus tree.
> 
> I tried the multiproto version 855d0c878944, but it didn't work on
> my system. My VDR doesn't recognize my DVB-T card and hangs upon startup.
> When I try to unload the driver modules, the 'rmmod budget_core' appears
> to hang. If I kill that, a subsequent 'lsmod' also hangs, so I need to do
> a reboot - which also hangs, so a hard reset is the last resort.
> 
> Then I tried the latest multiproto_plus version adf34f76ab7c, with which
> VDR's startup sequence results in
> 
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter0/frontend0
> Sep 14 13:06:59 video vdr: [3313] CI adapter on device 0 thread started (pid=3309, tid=3313)
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3314] section handler thread started (pid=3309, tid=3314)
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter1/frontend0
> Sep 14 13:06:59 video vdr: [3316] CI adapter on device 1 thread started (pid=3309, tid=3316)
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3317] section handler thread started (pid=3309, tid=3317)
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter2/frontend0
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3319] section handler thread started (pid=3309, tid=3319)
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter3/frontend0
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3321] section handler thread started (pid=3309, tid=3321)
> 
> This is the DVBFE_GET_DELSYS call that apparently fails.
> 
> Using the multiproto_plus version 88821ce4ed8d (2008-04-13) works fine.
> So I'm still using that one for now.
> 
> Have there been any API changes since multiproto_plus version 88821ce4ed8d
> that I would need to take into account in VDR?

There hasn't been any further API changes after that changeset.

The only other change (to dvb-core) is a backward compatibility add on
from Anssi Hannula, but that change i haven't ported yet to the
multiproto_plus tree.

Maybe something came up, while merging the two trees .. ?

Let me see what i can dig through.

Thanks for looking it up.

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]

Klaus Schmidinger wrote:
> On 09/12/08 23:43, Manu Abraham wrote:
>> barry bouwsma wrote:
>> ...
>>> Now a completely different question -- I was pleased to see
>>> that my not-too-old kernel compiled well with your mp_plus
>>> source, and I read on the Wiki that certain basic tools
>>> still needed to be ported to multiproto.
>>
>> Please use the multiproto tree rather than the multiproto_plus tree.
> 
> I tried the multiproto version 855d0c878944, but it didn't work on
> my system. My VDR doesn't recognize my DVB-T card and hangs upon startup.
> When I try to unload the driver modules, the 'rmmod budget_core' appears
> to hang. If I kill that, a subsequent 'lsmod' also hangs, so I need to do
> a reboot - which also hangs, so a hard reset is the last resort.


Digging more into this...


> Then I tried the latest multiproto_plus version adf34f76ab7c, with which
> VDR's startup sequence results in
> 
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter0/frontend0
> Sep 14 13:06:59 video vdr: [3313] CI adapter on device 0 thread started (pid=3309, tid=3313)
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3314] section handler thread started (pid=3309, tid=3314)
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter1/frontend0
> Sep 14 13:06:59 video vdr: [3316] CI adapter on device 1 thread started (pid=3309, tid=3316)
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3317] section handler thread started (pid=3309, tid=3317)
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter2/frontend0
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3319] section handler thread started (pid=3309, tid=3319)
> Sep 14 13:06:59 video vdr: [3309] probing /dev/dvb/adapter3/frontend0
> Sep 14 13:06:59 video vdr: [3309] ERROR (dvbdevice.c,471): Operation not supported
> Sep 14 13:06:59 video vdr: [3321] section handler thread started (pid=3309, tid=3321)
> 
> This is the DVBFE_GET_DELSYS call that apparently fails.

Does this look like a mix up of the headers ? Also i do see a bad merge
with the multiproto_plus tree with the v4l-dvb head :-/

So eventually since the IOCTL doesn't exist in the merged
multiproto_plus tree, i guess that's why it is failing.

Regards,
Manu

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