[linux-dvb] removal em28xx from linuxtv.org
mrechberger at gmail.com
Mon Jul 2 15:45:36 CEST 2007
On 7/2/07, Sascha Sommer <saschasommer at freenet.de> wrote:
> On Thursday 28 June 2007 23:20, Markus Rechberger wrote:
> > On 6/28/07, Sascha Sommer <saschasommer at freenet.de> wrote:
> > > Hi,
> > >
> > > On Thursday 14 June 2007 23:05, Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > > since I officially take care about the latest Empia em28xx code I want
> > > > to get that project removed from linuxtv.org.
> > > > Mauro already broke some parts in the incomplete inkernel linux
> > > > Since the few developers here who cannot just shut their mouth and
> > > > accept others work I don't see another way out.
> > > > I will rebase the code a last time and add a binary module interface
> > > > to the em28xx driver to allow the usage of proprietary dvb-t demod and
> > > > tuner code from userspace. Mauro is probably aware of wasting my time,
> > > > and the 3-4 other people who are against 1 1/2 years of work which has
> > > > been done are probably aware either of it.
> > > >
> > > > I will stop any further cooperation with that project since I simply
> > > > don't have the time for all these useless flamewars with people who
> > > > don't know it better.
> > > >
> > > > If opensource isn't entirely possible because of a flawed community
> > > > it's better to go binary.
> > >
> > > Can someone please summarize these flamewars and especially the
> > > problems?
> > > Why can you people spend hours reverseegineering all kinds of obfuscated
> > > hardware while not being able to work out a plan to resolve this issue?
> > > This is really a shame.
> > > No, it wasn't very nice to see the em28xx driver (that is based on the
> > > Cinergy
> > > 200 USB driver that I started in 2004) in video4linux cvs without
> > > for
> > > the cards that were originally supported by the Cinergy driver. However
> > > instead of whining I sent a patch to readd these devices.
> > > I don't see how a em28xx driver that is seperated from video4linux is an
> > > improvement in any way.
> > It's definitelly an improvement to stay out of all these stupid
> > flamewars and any further discussions about improving that framework.
> > > It should have never gotten into this state.
> > > Markus, what will happen with your code?
> > It's intended to go into 2.6.23.
> > > Do you intend to merge it into the
> > > kernel someday later? Won't there be more conflicts?
> > > Why do we suddenly need a binary module interface?
> > there are several advantages:
> > *) easy use of floating point operations
> > *) moving code from kernelspace to userspace, so development of newer
> > drivers can be more relaxed without having to fear to hit kernel null
> > pointers or other similar bugs.
> > *) it will also allow binary userspace modules (eg. for tuners), it's
> > better to provide a proper driver instead of having nothing sometimes.
> > *) some devices require a firmware, so there's no advantage over a
> > kernelspace driver which requires a firmware to work which is not
> > compiled into the driver.
> > *) portability the drivers can be reused with BSD, OSX, etc.
> I only know about the analog tuners and not much about them either so my
> on your advantages list may be flawed. Floating point, Null pointers,
> firmware loading these are all things that could of course be done more
> easily in the userspace but I doubt that they are so hard to do in the
> to justify yet another demon running in userspace.
> Are these tuners really so complicated that there need to be binary only
> modules for them?
If you look at tuner sources like the qt1010 or mt2060 they "work" but
they aren't compareable with the quality you experience in Windows.
The mt2060 causes a significant signal drop in Linux for several
devices (it got reported but I couldn't reproduce it since the signal
around was too strong)
> What is so secret about a tuner driver that it can't be
> released as opensource? I'm sceptical about the binary drivers from
As I wrote earlier already, I do not really intend to publish the
current modules which are in question as binary modules.
The question arises with newer devices, however companies can already
publish binary drivers using usbfs (in case of USB) or accessing MMIO
(in case of PCI) from userspace (PCI dma must still be handled in
kernelspace), it's just a matter if they'll do so.
Avermedia violated the GPL by providing binary only drivers, but on
the other side someone has to think how much time did they spend to
work/(waste) with the "DVB community"? They didn't spend any time with
it and saved alot time and money because they avoided useless
discussions. This is also a valid point where I'm stuck with that 3-5
people community for 1 1/2 years and I changed the design of the
em28xx to not cross anyone's way anymore.
> Users may be happy with them. However it is not always the best idea to
> blindly follow the users wishes. If Linux sucks because all important
> in the system are driven by broken binary only drivers they will simply move
> on to another os. We are the ones who spent our free time to improve this
> free system. It is our repsonsibility to keep linux free and useable.
> Markus, whatever you do make sure to keep an eye on the various licenses
> Your advantage list should maybe also include a
> "Allows the creation of tuner drivers without interacting with the linuxtv
> project" entry.
this also works without all that. It's entirely possible to push
dvb-usb devices to userspace.
The i2c-dev interface provides an interface for i2c busses to userspace.
Vmware and Virtualbox also use usbfs for usb clients within their
> I still hope that we can sort this out some day later. For
> now it is probably the best to let everyone go its way.
Talk is cheap doing something requires certain skills, I hope more
people will join the userspace development in future since it really
introduces some interesting advantages.
More information about the linux-dvb