[linux-dvb] why opensource will fail

[linux-dvb] why opensource will fail

[Paul Chubb]

Hi,
     now that I have your attention:-{)=

I believe that this community has a real problem. There appears to be 
little willingness to help and mentor newcomers. This will limit the 
effectiveness of the community because it will hinder expansion of 
people who are both willing and able to work on the code. Eventually 
this issue  will lead to the community dying simply because you have 
people leaving but few joining.

The card I was working on has been around for  a while now. There have 
been three attempts so far to get it working with Linux. Two in this 
community and one against the mcentral.de tree. Both attempts in this 
community have failed not because of a lack of willingness of the people 
involved to do the hard yards but because of the inability of the 
community to mentor and help newcomers.

The third attempt by a Czech programmer succeeded, however it is 
dependent on the mcentral.de tree and the author appears to have made no 
attempt to get the patch into the tree. The original instructions to 
produce a driver set are in Czech. However instructions in english for 
2.6.22 are available - ubuntu gutsy. I will soon be putting up 
instructions for 2.6.24 - hardy. They may even work  for later revisions 
since the big issue was incompatible versioning.

I understand from recent posts to this list that many in the community 
are disturbed by the existence of mcentral.de. Well every person from 
now on who wants to run the Leadtek Winfast DTV1800H will be using that 
tree. Since the card is excellent value for what it is, there should be 
lots of them. Not helping newcomers who are trying to add cards has led 
and will lead to increased fragmentation.

And before you say or think that we are all volunteers here, I am a 
volunteer also. I have spent close to 3 weeks on this code and it is 
very close to working. The biggest difference between working code in 
the mcentral.de tree and the patch I was working on is the firmware that 
is used.

Finally you might consider that if few developers are prepared to work 
on the v4l-dvb tree, then much of the fun will disappear because those 
few will have to do everything.

Cheers Paul

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

[linux-dvb] Why my binary-only Win95 closed-source drivers trump your puny free-as-in-beer etc. [was: Re: why (etc.)]

[barry bouwsma]

Bow down before the might of my hardware that I can't use on
anything later than an LSI-11-based machine!  Replies there ------>
plz thx okbye

--- On Sat, 9/13/08, Paul Chubb <paulc@singlespoon.org.au> wrote:

> The third attempt by a Czech programmer succeeded, however it is 
> dependent on the mcentral.de tree and the author appears to

I have a serious question.  Really.  I mean it.

I want factual answers.  No flames.  If your native language
is not english, feel free to reply in personal mail in your
native language, and I will try to make sense of it -- sometimes
I feel that non-english speakers here would be far more effective
in their native language, as anyone who has heard or read me
fumbling through their native languange (english included) will
agree.

I periodically build the drivers from recent em28xx-new against
a recent kernel, and pass the needed patches upstream.  While
I have an EM288x device, it's not yet supported, so I can't
actually test my hacks.

I've just now downloaded the mcentral v4l-dvb source, in an
attempt to compile (notice I said nothing about functionality)
it against a recent kernel.  My observation so far is that it
has heaps of backwards-compatibility, and lacks a few recent
changes that I'm hoping to merge in.  (`Hope' the operative
word)

Otherwise I really don't pay attention to the details of the
drivers and their use, probably the reason for my question.

You can bet that as soon as Markus has time to write support
for the demodulators and such, that I'm going to try my hardest
to get it to work with a stock linux kernel.


Can you, or someone, explain the technical details of what needs
to be done to a random, or a particular driver on mcentral, to
get it into em28xx on linuxtv?  Or why it can't be done as is,
as I see a slow addition of drivers to linuxtv over time?

Or better yet, give me an example of code that won't fit into
linuxtv from mcentral.  That might keep me quiet for a while.

In spite of the fact that I may have the datasheet for one of
the chips in my unsupported device, there is no way I'll be
able to turn that into a driver, no matter how much mentoring
or handholding I get, whereas I might be able to stumble my
way through incompatibility issues with plenty of review.
Maybe in ten years or so, in the event I'm still alive, I'd
be able to whip together a driver free of the enforced DRM
(not the broadcast norm DRM, hmmm, does that deserve a place
in the digital-broadcasting API?)



> I understand from recent posts to this list that many in the community 
> are disturbed by the existence of mcentral.de. Well every person from 
> now on who wants to run the Leadtek Winfast DTV1800H will be using that 
> tree. Since the card is excellent value for what it is,

This is the second time I've read about incompatibility (an
either/or choice) between the trees.  That obviously isn't
acceptable to me.  Can you or someone give a *technical only*
overview of why this should be, so I can motivate myself to
do what I can to make it should not be so?

Again, no flames, minimal opinions, please.  Facts will be
`rewarded' by an `effort' on my part to try to `benefit'
everyone out there who wants additional `functionality', but
no promises.

Disclaimer:  if I don't make much sense, it's due to chronic
sleep deprivation, in part.


thanks,
barry bouwsma


      


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

Re: [linux-dvb] Why my binary-only Win95 closed-source drivers trump your puny free-as-in-beer etc. [was: Re: why (etc.)]

[Paul Chubb]

Barry,
delightful post. I am not sure I am able to answer all your questions 
because my experience is strictly limited to what I have done in the 
last three weeks. My experience is two surmountable incompatibilities. 
Being a newbie I may have misunderstood what I am seeing but:

1) My take is that the mcentral.de tree was originally based somewhere 
around 2.6.22. At some stage the functionality in videobuf_core.c was 
replaced by video-buf-dvb.c. This meant that when you compile against 
the 2.6.22 headers it works fine but still loads the videobuf_core 
module from the previous module set. Once you get to 2.6.24 it still 
loads videobuf_core, however now you get a lot of symbol issues when it 
loads and ultimately the driver for the card didn't work. This was 
simply fixed by removing all the old drivers in the drivers/media/video 
directory.

2) The v4l-dvb tree has complex firmware loading logic in tuner-xc2028.c 
that is tied to a single file that has lots of firmware modules in it. 
the mcentral.de tree has that code replaced by a new xc3028-tuner module 
that is designed to load individual fw files. Mr Rechberger managed to 
get original firmware from Xcieve.

So either could be fixed, and I fixed the first. I could have fixed the 
second by investing more time. But I don't think that is why people talk 
about incompatibility between the two.

Cheers Paul
barry bouwsma wrote:
> Bow down before the might of my hardware that I can't use on
> anything later than an LSI-11-based machine!  Replies there ------>
> plz thx okbye
>
> --- On Sat, 9/13/08, Paul Chubb <paulc@singlespoon.org.au> wrote:
>
>   
>> The third attempt by a Czech programmer succeeded, however it is 
>> dependent on the mcentral.de tree and the author appears to
>>     
>
> I have a serious question.  Really.  I mean it.
>
> I want factual answers.  No flames.  If your native language
> is not english, feel free to reply in personal mail in your
> native language, and I will try to make sense of it -- sometimes
> I feel that non-english speakers here would be far more effective
> in their native language, as anyone who has heard or read me
> fumbling through their native languange (english included) will
> agree.
>
> I periodically build the drivers from recent em28xx-new against
> a recent kernel, and pass the needed patches upstream.  While
> I have an EM288x device, it's not yet supported, so I can't
> actually test my hacks.
>
> I've just now downloaded the mcentral v4l-dvb source, in an
> attempt to compile (notice I said nothing about functionality)
> it against a recent kernel.  My observation so far is that it
> has heaps of backwards-compatibility, and lacks a few recent
> changes that I'm hoping to merge in.  (`Hope' the operative
> word)
>
> Otherwise I really don't pay attention to the details of the
> drivers and their use, probably the reason for my question.
>
> You can bet that as soon as Markus has time to write support
> for the demodulators and such, that I'm going to try my hardest
> to get it to work with a stock linux kernel.
>
>
> Can you, or someone, explain the technical details of what needs
> to be done to a random, or a particular driver on mcentral, to
> get it into em28xx on linuxtv?  Or why it can't be done as is,
> as I see a slow addition of drivers to linuxtv over time?
>
> Or better yet, give me an example of code that won't fit into
> linuxtv from mcentral.  That might keep me quiet for a while.
>
> In spite of the fact that I may have the datasheet for one of
> the chips in my unsupported device, there is no way I'll be
> able to turn that into a driver, no matter how much mentoring
> or handholding I get, whereas I might be able to stumble my
> way through incompatibility issues with plenty of review.
> Maybe in ten years or so, in the event I'm still alive, I'd
> be able to whip together a driver free of the enforced DRM
> (not the broadcast norm DRM, hmmm, does that deserve a place
> in the digital-broadcasting API?)
>
>
>
>   
>> I understand from recent posts to this list that many in the community 
>> are disturbed by the existence of mcentral.de. Well every person from 
>> now on who wants to run the Leadtek Winfast DTV1800H will be using that 
>> tree. Since the card is excellent value for what it is,
>>     
>
> This is the second time I've read about incompatibility (an
> either/or choice) between the trees.  That obviously isn't
> acceptable to me.  Can you or someone give a *technical only*
> overview of why this should be, so I can motivate myself to
> do what I can to make it should not be so?
>
> Again, no flames, minimal opinions, please.  Facts will be
> `rewarded' by an `effort' on my part to try to `benefit'
> everyone out there who wants additional `functionality', but
> no promises.
>
> Disclaimer:  if I don't make much sense, it's due to chronic
> sleep deprivation, in part.
>
>
> thanks,
> barry bouwsma
>
>
>       
>
>
>   


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

Re: [linux-dvb] Why I need to choose better Subject: headers [was: Re: Why (etc.)]

[barry bouwsma]

--- On Sat, 9/13/08, Paul Chubb <paulc@singlespoon.org.au> wrote:

> around 2.6.22. At some stage the functionality in videobuf_core.c was 
> replaced by video-buf-dvb.c. This meant that when you compile against 
> the 2.6.22 headers it works fine but still loads the videobuf_core 
> module from the previous module set. Once you get to 2.6.24 it still 
> loads videobuf_core, however now you get a lot of symbol issues when it 
> loads and ultimately the driver for the card didn't work. This was 

Ah, thanks.  I've seen this (in the list) often and ignored it
as a newbie error.  (I ignore most things anyway)

Now I'm trying to hack* around something comparable in a diff
which has strangely disappeared from my screen, but may be
videodev.c --> v4l2-dev.c  which probably will/has cause(d)
issues.

* `hack' should be translated as, looking at the diffs, wishing
I had had more sleep, even if it had meant missing all the doku on
Chairman Humph (for those in the know) that I should have instead
recorded for later viewing, and wondering if a `make-it-compile'
hack is enough...  Am I making sense?  Should I sleep?


> 2) The v4l-dvb tree has complex firmware loading logic in tuner-xc2028.c 
> 
> So either could be fixed, and I fixed the first. I could have fixed the 
> second by investing more time.

Just to be clear -- did you fix the firmware issue, or the issue
with migration of, and changes to, source files, which in my
hum^Wignorant opinion, would be the more difficult one in general?


>  But I don't think that is why people talk 
> about incompatibility between the two.

It's helpful to me, nonetheless.  I am sympathetic to the fork,
as my `production' (were I to produce anything; in reality, I
mean that it's been several years operating with only power
failures requiring attention, otherwise generally running with
full CPU load) machine is 2.6.14 and has loads of hacks which
I need to apply to a more recent kernel, should I find a stable
one (perhaps the hardware of my development machine is suspect
here, as I now have nearly a week uptime on the same kernel
which would typically freeze/panic within a few hours -- watch
it wedge solid before I can send this, again), and much of the
code which I've hacked (UFS large fragment size filesystem,
ISA ethernet and others) has or may have suffered substantial
rewriting since I got it working...  That second sentence was long...


thanks for your feedback!
barry bouwsma


      


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

Re: [linux-dvb] Why I need to choose better Subject: headers [was: Re: Why (etc.)]

[Paul Chubb]

Barry,
I drew the line at porting the xc3028 tuner module from mcentral.de into 
v4l-dvb, so no didn't solve the firmware issues. If you know what you 
are doing it should be trivial work - just linking in yet another tuner 
module and then calling it like all the others. For me because I don't 
know the code well it would take a week or two.

The other issue is that with the state of relationship between Markus 
Rechberger and the community I don't want to be in the middle of that.

Cheers Paul

barry bouwsma wrote:
> --- On Sat, 9/13/08, Paul Chubb <paulc@singlespoon.org.au> wrote:
>
>   
>> around 2.6.22. At some stage the functionality in videobuf_core.c was 
>> replaced by video-buf-dvb.c. This meant that when you compile against 
>> the 2.6.22 headers it works fine but still loads the videobuf_core 
>> module from the previous module set. Once you get to 2.6.24 it still 
>> loads videobuf_core, however now you get a lot of symbol issues when it 
>> loads and ultimately the driver for the card didn't work. This was 
>>     
>
> Ah, thanks.  I've seen this (in the list) often and ignored it
> as a newbie error.  (I ignore most things anyway)
>
> Now I'm trying to hack* around something comparable in a diff
> which has strangely disappeared from my screen, but may be
> videodev.c --> v4l2-dev.c  which probably will/has cause(d)
> issues.
>
> * `hack' should be translated as, looking at the diffs, wishing
> I had had more sleep, even if it had meant missing all the doku on
> Chairman Humph (for those in the know) that I should have instead
> recorded for later viewing, and wondering if a `make-it-compile'
> hack is enough...  Am I making sense?  Should I sleep?
>
>
>   
>> 2) The v4l-dvb tree has complex firmware loading logic in tuner-xc2028.c 
>>
>> So either could be fixed, and I fixed the first. I could have fixed the 
>> second by investing more time.
>>     
>
> Just to be clear -- did you fix the firmware issue, or the issue
> with migration of, and changes to, source files, which in my
> hum^Wignorant opinion, would be the more difficult one in general?
>
>
>   
>>  But I don't think that is why people talk 
>> about incompatibility between the two.
>>     
>
> It's helpful to me, nonetheless.  I am sympathetic to the fork,
> as my `production' (were I to produce anything; in reality, I
> mean that it's been several years operating with only power
> failures requiring attention, otherwise generally running with
> full CPU load) machine is 2.6.14 and has loads of hacks which
> I need to apply to a more recent kernel, should I find a stable
> one (perhaps the hardware of my development machine is suspect
> here, as I now have nearly a week uptime on the same kernel
> which would typically freeze/panic within a few hours -- watch
> it wedge solid before I can send this, again), and much of the
> code which I've hacked (UFS large fragment size filesystem,
> ISA ethernet and others) has or may have suffered substantial
> rewriting since I got it working...  That second sentence was long...
>
>
> thanks for your feedback!
> barry bouwsma
>
>
>       
>
>
>   


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

Re: [linux-dvb] Why I need to choose better Subject: headers [was: Re: Why (etc.)]

[Steven Toth]

Paul Chubb wrote:
> Barry,
> I drew the line at porting the xc3028 tuner module from mcentral.de into 
> v4l-dvb, so no didn't solve the firmware issues. If you know what you 
> are doing it should be trivial work - just linking in yet another tuner 
> module and then calling it like all the others. For me because I don't 
> know the code well it would take a week or two.

No porting required.

xc3028 tuner is already in the kernel, it should just be a case of 
configuring the attach/config structs correctly.

- Steve

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

Re: [linux-dvb] Why I need to choose better Subject: headers [was: Re: Why (etc.)]

[Paul Chubb]

Steven Toth wrote:
> Paul Chubb wrote:
>> Barry,
>> I drew the line at porting the xc3028 tuner module from mcentral.de 
>> into v4l-dvb, so no didn't solve the firmware issues. If you know 
>> what you are doing it should be trivial work - just linking in yet 
>> another tuner module and then calling it like all the others. For me 
>> because I don't know the code well it would take a week or two.
>
> No porting required.
>
> xc3028 tuner is already in the kernel, it should just be a case of 
> configuring the attach/config structs correctly.
>
> - Steve
>
Steve,
           I think we are talking about two different things. Yes the 
xc3028 tuner is supported via tuner-xc2028 and works for many xc3028 
based cards. This support uses the xc3028-v27.fw file that contains say 
80 firmware modules. This firmware was extracted from a Haupage windows 
driver.

I believe that the 1800H has some incompatibility with this firmware. 
The mcentral.de tree has a different firmware loading and tuner support 
module for xc3028 that loads individual firmware modules - you literally 
put twenty or thirty files into /lib/firmware. This firmware is the 
standard firmware from xceive before the card manufacturers get to it. 
Comparing the dmesg listing from a working mcentral.de setup and the 
non-working v4l tree the only thing that leaps out is the different 
firmware. If I was continuing the next step would be to port that tuner 
module into the v4l code and set it up in the normal way.

Cheers Paul

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

[linux-dvb] xc3028 config issue. Re: Why I need to choose better Subject: headers [was: Re: Why (etc.)]

[Steven Toth]

Mauro, see question below.

Paul Chubb wrote:
> Steven Toth wrote:
>> Paul Chubb wrote:
>>> Barry,
>>> I drew the line at porting the xc3028 tuner module from mcentral.de 
>>> into v4l-dvb, so no didn't solve the firmware issues. If you know 
>>> what you are doing it should be trivial work - just linking in yet 
>>> another tuner module and then calling it like all the others. For me 
>>> because I don't know the code well it would take a week or two.
>>
>> No porting required.
>>
>> xc3028 tuner is already in the kernel, it should just be a case of 
>> configuring the attach/config structs correctly.
>>
>> - Steve
>>
> Steve,
>           I think we are talking about two different things. Yes the 
> xc3028 tuner is supported via tuner-xc2028 and works for many xc3028 
> based cards. This support uses the xc3028-v27.fw file that contains say 
> 80 firmware modules. This firmware was extracted from a Haupage windows 
> driver.

Correct.

(I changed the subject by the way)

> 
> I believe that the 1800H has some incompatibility with this firmware. 
> The mcentral.de tree has a different firmware loading and tuner support 
> module for xc3028 that loads individual firmware modules - you literally 
> put twenty or thirty files into /lib/firmware. This firmware is the 
> standard firmware from xceive before the card manufacturers get to it. 
> Comparing the dmesg listing from a working mcentral.de setup and the 
> non-working v4l tree the only thing that leaps out is the different 
> firmware. If I was continuing the next step would be to port that tuner 
> module into the v4l code and set it up in the normal way.

the v27.fw file does contain the correct firmware, so the fact that the 
inkernel tuner driver isn't select the correct version (or that it needs 
a hint in the config struct) is probably a very small fix.

Mauro (cc'd) generally maintains that driver and he should be able to 
help. My suggestion is that you cut/paste the attach/config struct from 
your leadtek code into this email thread. From you email address I guess 
you're trying to get DVB-T 7MHz working in Australia. Mauro can review it.

Ideally, we'd point you at a different card struct for the same tuner 
that we know works in Australia, so you build the leadtek config struct 
based on something that we know works.

Mauro, what should the attach/config struct look like for a xc2028/3028 
tune in Australia? Can you point to a working example or suggest a change?

Regards,

- Steve




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

Re: [linux-dvb] xc3028 config issue. Re: Why I need to choose better Subject: headers [was: Re: Why (etc.)]

[Christophe Thommeret]

Le Monday 15 September 2008 17:00:35 Glenn McGrath, vous avez écrit :
> On Tue, Sep 16, 2008 at 12:30 AM, Mauro Carvalho Chehab
>
> <mchehab@infradead.org> wrote:
> > You should also notice that, on Australia, you'll need an extra offset of
> > 500 KHz for the frequency.
>
> What is the reason behind this... it took me a week to make an
> initial-tuning-data file for my tv card.
>
> I read that Australian broadcasters are allowed to broadcast +/-
> 125kHz from the center frequency, is it anything to do with that,
> where does the 500 come from ?

Allowed shiftings are n*125 (or n*167 on 8mhz)

> I started an app called utuner (gna.org/utuner if anyone whats to take
> a look, afaik nobody else has looked at it yet, so expect it to be
> rough) still very early, i just want to make something more flexible
> than w_scan that can generate an initial-tuning-data file, dont care
> if i have to leave the channel scan going all night and scan the whole
> spectrum, it will still be quicker than the week it took me to
> generate my initial-tuning-data file.

:)

-- 
Christophe Thommeret


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

Re: [linux-dvb] Why my binary-only Win95 closed-source drivers trump your puny free-as-in-beer etc. [was: Re: why (etc.)]

[Markus Rechberger]

On Sat, Sep 13, 2008 at 12:35 PM, Paul Chubb <paulc@singlespoon.org.au> wrote:
> Barry,
> delightful post. I am not sure I am able to answer all your questions
> because my experience is strictly limited to what I have done in the
> last three weeks. My experience is two surmountable incompatibilities.
> Being a newbie I may have misunderstood what I am seeing but:
>
> 1) My take is that the mcentral.de tree was originally based somewhere
> around 2.6.22. At some stage the functionality in videobuf_core.c was
> replaced by video-buf-dvb.c. This meant that when you compile against
> the 2.6.22 headers it works fine but still loads the videobuf_core
> module from the previous module set. Once you get to 2.6.24 it still
> loads videobuf_core, however now you get a lot of symbol issues when it
> loads and ultimately the driver for the card didn't work. This was
> simply fixed by removing all the old drivers in the drivers/media/video
> directory.
>

slightly wrong assumption it's separated since 2.6.12 and earlier
probably already
it was a staging tree for linuxtv initially, the changes grew and are
out of scope of
a staging tree for linuxtv now. It's a full development tree on its
own regulary adding
support for newer devices. eg. currently there are full hybrid
analogTV/DVB-T/DVB-C/radio
devices, ISDB-T and DMB-TH on the list to get in there.

Also when looking at the other repositories on mcentral.de, there are
applications like
tvtime, vlc, gqradio which are modified in order to support those
devices. It's not only about
the driver there.

As for the Acer One Aspire it's nearly impossible to get audio work at
all the default way,
there has been some development at that side too in order to just get
it work without
having to modify the whole system. (eg em28xx-aad, which is work in
progress too).


> 2) The v4l-dvb tree has complex firmware loading logic in tuner-xc2028.c
> that is tied to a single file that has lots of firmware modules in it.
> the mcentral.de tree has that code replaced by a new xc3028-tuner module
> that is designed to load individual fw files. Mr Rechberger managed to
> get original firmware from Xcieve.
>

Yes we have full Xceive manufacturer support, I mainly leave those
modules for Xceive
since they still use to update those drivers and we sometimes have to
adjust some settings
too in order to increase the signal quality. The Xceive tuners will
remain a topic for us.

tuner-xc2028 is Mauro's work which was cobbled together from a leaked
outdated xc3028
source which has been sent around last year, the code is quite
asynchronous with what
xceive actually delivers not taking care about their changes and bugs.
Personally I'm no fan
of that firmware parsing stuff, we have devices which require 4
firmwares already in order
to get those components work. The usual user way is to search it with
google (even though when
it's documented on linuxtv.org).

We also have commercial customers which build further products with
our devices they keep
watching particular parts of the driver quite intensive, and we also
use to provide custom
v4l2/dvb/atsc patches for their applications. As for them it's also
comfortable just to receive
rpm, debian or other packages not touching anything of their existing
system but still adding
full support for the product which they use. Many of them already have
the UVC driver built against
their running system and wouldn't like to upgrade the core.

There will always be people not liking this situation but alot people
also prefer it to have it like that.
Upstream pushes of the existing code can be discussed on the em28xx
mailinglist I'm open for such a
discussion (we have the necessary kernel changes but still some open
points which came in again recently).

There are more or less more contributors there as can be seen in the
commit logs which
show up the constant development.
http://mcentral.de/hg/~mrec/em28xx-new/shortlog

-Markus

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

Re: [linux-dvb] why opensource will fail

[Igor M. Liplianin]

В сообщении от 13 September 2008 09:28:10 Paul Chubb написал(а):
> Hi,
>      now that I have your attention:-{)=
>
> I believe that this community has a real problem. There appears to be
> little willingness to help and mentor newcomers. This will limit the
> effectiveness of the community because it will hinder expansion of
> people who are both willing and able to work on the code. Eventually
> this issue  will lead to the community dying simply because you have
> people leaving but few joining.
>
> The card I was working on has been around for  a while now. There have
> been three attempts so far to get it working with Linux. Two in this
> community and one against the mcentral.de tree. Both attempts in this
> community have failed not because of a lack of willingness of the people
> involved to do the hard yards but because of the inability of the
> community to mentor and help newcomers.
>
> The third attempt by a Czech programmer succeeded, however it is
> dependent on the mcentral.de tree and the author appears to have made no
> attempt to get the patch into the tree. The original instructions to
> produce a driver set are in Czech. However instructions in english for
> 2.6.22 are available - ubuntu gutsy. I will soon be putting up
> instructions for 2.6.24 - hardy. They may even work  for later revisions
> since the big issue was incompatible versioning.
>
> I understand from recent posts to this list that many in the community
> are disturbed by the existence of mcentral.de. Well every person from
> now on who wants to run the Leadtek Winfast DTV1800H will be using that
> tree. Since the card is excellent value for what it is, there should be
> lots of them. Not helping newcomers who are trying to add cards has led
> and will lead to increased fragmentation.
>
> And before you say or think that we are all volunteers here, I am a
> volunteer also. I have spent close to 3 weeks on this code and it is
> very close to working. The biggest difference between working code in
> the mcentral.de tree and the patch I was working on is the firmware that
> is used.
>
> Finally you might consider that if few developers are prepared to work
> on the v4l-dvb tree, then much of the fun will disappear because those
> few will have to do everything.
>
> Cheers Paul

There is a question of time and patience.
Don't give up.

-- 
Igor M. Liplianin

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

Re: [linux-dvb] why opensource will fail

[Steven Toth]

Paul Chubb wrote:
> Hi,
>      now that I have your attention:-{)=

.... You've also had my attention in the past, if I recall I have you 
tips about not using cx_write, instead using cx_set/cx_clear.

Your latest patch still doesn't have those changes btw. ;)


> 
> I believe that this community has a real problem. There appears to be 
> little willingness to help and mentor newcomers. This will limit the 
> effectiveness of the community because it will hinder expansion of 
> people who are both willing and able to work on the code. Eventually 
> this issue  will lead to the community dying simply because you have 
> people leaving but few joining.

I disagree with everything you've just said, but that's just my opinion.


> 
> The card I was working on has been around for  a while now. There have 
> been three attempts so far to get it working with Linux. Two in this 
> community and one against the mcentral.de tree. Both attempts in this 
> community have failed not because of a lack of willingness of the people 
> involved to do the hard yards but because of the inability of the 
> community to mentor and help newcomers.


Did I not try to help you? The one piece of initial feedback I gave you, 
you ignored. (see my opening statement).

I'm always willing to help people, but they also have to demonstrate 
that they are applying themselves, doing basic research, asking specific 
questions ... rather than, here's my patch - and What's Wrong with it.


> 
> The third attempt by a Czech programmer succeeded, however it is 
> dependent on the mcentral.de tree and the author appears to have made no 
> attempt to get the patch into the tree. The original instructions to 
> produce a driver set are in Czech. However instructions in english for 
> 2.6.22 are available - ubuntu gutsy. I will soon be putting up 
> instructions for 2.6.24 - hardy. They may even work  for later revisions 
> since the big issue was incompatible versioning.
> 
> I understand from recent posts to this list that many in the community 
> are disturbed by the existence of mcentral.de. Well every person from 
> now on who wants to run the Leadtek Winfast DTV1800H will be using that 
> tree. Since the card is excellent value for what it is, there should be 
> lots of them. Not helping newcomers who are trying to add cards has led 
> and will lead to increased fragmentation.

So port the mcentral.de details into the kernel, I doubt they'll be 
significantly different.... we're talking about adding support for an 
existing card, it's not a lot of engineering work.


> 
> And before you say or think that we are all volunteers here, I am a 
> volunteer also. I have spent close to 3 weeks on this code and it is 
> very close to working. The biggest difference between working code in 
> the mcentral.de tree and the patch I was working on is the firmware that 
> is used.

... and your efforts are valuable.

Markus (mcentral.de) is paid to work on Linux, just to be clear.

Your last message on that thread said: "xc2028 2-0061: xc2028/3028 
firmware name not set!"

You could of asked a second time before taking the opportunity to vent, 
and taking the community to task.

Showing patience and perseverance is what most other newcomers demonstrate.


> 
> Finally you might consider that if few developers are prepared to work 
> on the v4l-dvb tree, then much of the fun will disappear because those 
> few will have to do everything.

Whether we have 3 people or 30, it's never enough.

In my experience, people who join the list then vent all over it are 
rarely around long enough to make a difference. They often think they 
know more about the community than the community itself.

On the other hand, the people who join and ask well thought out 
questions, describe their failures and working assumptions, then 
demonstrate a willingness to learn attract a mentor very quickly.

... just my opinion of course :)

If you want to make progress with the leadtek card then another look at 
the feedback I gave you, then approach the group again with a more 
insightful email.

Maybe someone will help you then.

- Steve



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

Re: [linux-dvb] why opensource will fail

[Paul Chubb]

Hi Steven
Steven Toth wrote:
> Paul Chubb wrote:
>> Hi,
>>      now that I have your attention:-{)=
>
> .... You've also had my attention in the past, if I recall I have you 
> tips about not using cx_write, instead using cx_set/cx_clear.
>
> Your latest patch still doesn't have those changes btw. ;)
Yes I have had your attention. Your two emails were the exception to the 
rule. On the cx_write issue, I took that advice on board. If you look at 
the latest patch you will see that the code was changed and then 
commented out. Remember I was porting a working patch. Since the changes 
did not fix any of the problems I was having and since the patch was 
working I commented them out. Once the patch was working I would have 
returned and put them back. The issue with the advice was the question 
of whether the patch writer intended to set the other GPIO bits in that 
code.
>
>
>>
>> I believe that this community has a real problem. There appears to be 
>> little willingness to help and mentor newcomers. This will limit the 
>> effectiveness of the community because it will hinder expansion of 
>> people who are both willing and able to work on the code. Eventually 
>> this issue  will lead to the community dying simply because you have 
>> people leaving but few joining.
>
> I disagree with everything you've just said, but that's just my opinion.
>
>
>>
>> The card I was working on has been around for  a while now. There 
>> have been three attempts so far to get it working with Linux. Two in 
>> this community and one against the mcentral.de tree. Both attempts in 
>> this community have failed not because of a lack of willingness of 
>> the people involved to do the hard yards but because of the inability 
>> of the community to mentor and help newcomers.
>
>
> Did I not try to help you? The one piece of initial feedback I gave 
> you, you ignored. (see my opening statement).
>
> I'm always willing to help people, but they also have to demonstrate 
> that they are applying themselves, doing basic research, asking 
> specific questions ... rather than, here's my patch - and What's Wrong 
> with it.
Let me see, 3 weeks work. Reading the communities documentation. Reading 
the code. Looking up the specific chips. Bottom line is that if you 
don't know what is normal behavior and what is not it is difficult to 
ask the right questions. I had never even seen a dmesg of one of these 
cards starting up and there is very little documentation of the code 
that is detailed enough to get you over those kind of learning humps.
>>
>> The third attempt by a Czech programmer succeeded, however it is 
>> dependent on the mcentral.de tree and the author appears to have made 
>> no attempt to get the patch into the tree. The original instructions 
>> to produce a driver set are in Czech. However instructions in english 
>> for 2.6.22 are available - ubuntu gutsy. I will soon be putting up 
>> instructions for 2.6.24 - hardy. They may even work  for later 
>> revisions since the big issue was incompatible versioning.
>>
>> I understand from recent posts to this list that many in the 
>> community are disturbed by the existence of mcentral.de. Well every 
>> person from now on who wants to run the Leadtek Winfast DTV1800H will 
>> be using that tree. Since the card is excellent value for what it is, 
>> there should be lots of them. Not helping newcomers who are trying to 
>> add cards has led and will lead to increased fragmentation.
>
> So port the mcentral.de details into the kernel, I doubt they'll be 
> significantly different.... we're talking about adding support for an 
> existing card, it's not a lot of engineering work.
>
As I said elsewhere. Trivial for someone who knows the code but a couple 
of weeks effort for someone like me who doesn't
>>
>> And before you say or think that we are all volunteers here, I am a 
>> volunteer also. I have spent close to 3 weeks on this code and it is 
>> very close to working. The biggest difference between working code in 
>> the mcentral.de tree and the patch I was working on is the firmware 
>> that is used.
>
> ... and your efforts are valuable.
>
> Markus (mcentral.de) is paid to work on Linux, just to be clear.
So are many people, Linus included. They generally break down into 
people who get it and those that don't.
>
> Your last message on that thread said: "xc2028 2-0061: xc2028/3028 
> firmware name not set!"
>
> You could of asked a second time before taking the opportunity to 
> vent, and taking the community to task.
>
> Showing patience and perseverance is what most other newcomers 
> demonstrate.
I don't believe I have either vented or taken the community to task. I 
have pointed out, as an outsider, that there is a problem and have done 
so in a way  that has attempted to be polite but also to paint why it is 
important. If you found it impolite, please accept my apology.

"patience and perseverance" demonstrates the meat of my comment. The 
higher the bar to contribute the less people will try.
>
>
>>
>> Finally you might consider that if few developers are prepared to 
>> work on the v4l-dvb tree, then much of the fun will disappear because 
>> those few will have to do everything.
>
> Whether we have 3 people or 30, it's never enough.
>
> In my experience, people who join the list then vent all over it are 
> rarely around long enough to make a difference. They often think they 
> know more about the community than the community itself.
While I don't agree that I have vented, there is a certain self 
fulfillment in your observation. And I bet there are also lots of people 
who try and just disappear off the list.
>
> On the other hand, the people who join and ask well thought out 
> questions, describe their failures and working assumptions, then 
> demonstrate a willingness to learn attract a mentor very quickly.
>
> ... just my opinion of course :)
>
> If you want to make progress with the leadtek card then another look 
> at the feedback I gave you, then approach the group again with a more 
> insightful email.
Back when I was young I wanted to do OS development specifically 
hardware/software interfaces. Since Australia in those days did 
practically none of this work, I did systems development in C on a NOS 
called Banyan VINES.

I wanted to have a mythtv setup. The easiest solution was to simply get 
the Czech patch working. However I believed it to be a better solution 
to get it into the standard tree. As you pointed out it is not supposed 
to be a hard job.

At this point I have a working card outside of the standard v4l-dvb 
tree. Continuing would require love and enthusiasm.
>
> Maybe someone will help you then.
>
> - Steve
>

>
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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