[linux-dvb] Why my binary-only Win95 closed-source drivers trump your puny free-as-in-beer etc. [was: Re: why (etc.)]
mrechberger at gmail.com
Sun Sep 21 17:07:47 CEST 2008
On Sat, Sep 13, 2008 at 12:35 PM, Paul Chubb <paulc at singlespoon.org.au> wrote:
> 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
slightly wrong assumption it's separated since 2.6.12 and earlier
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
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
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
> 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
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.
More information about the linux-dvb