The sad story of the em28xx driver

Posted Nov 13, 2008 18:35 UTC (Thu) by mrec (guest, #41847)
In reply to: The sad story of the em28xx driver by mjcoder
Parent article: The sad story of the em28xx driver

that's over since Mauro took over some people didn't agree either, one maintainer stopped to support his project too because of that, the competitive S2 API got merged already.

http://www.mail-archive.com/vdr@linuxtv.org/msg07539.html

although guess what one argument for not taking my code was we should first get multiproto in before taking my first patches. It's all connected, including multiple flamewars. Now one group (the v4l group) has taken over without taking other dvb people who managed the project before as a small group before... although this group wasn't defined either.

It's all about friendship there, A likes B instead of C even if C has better stuff and supporters, so A will wait till B completes his stuff, and C will be pushed away as long as possible without clean reviews or something else, this is just the way how it works out. Basically there are too many good people involved already. The project is moreover looking for lower skilled people who can be taught what to do (do it as A or B says otherwise they'll run against C). It's not a project for innovative people to work on own ideas that for other open operating systems are better in that case.

The sad story of the em28xx driver

Posted Nov 16, 2008 10:17 UTC (Sun) by Ze (guest, #54182) [Link] (3 responses)

When friendship rules over code quality then that's a sad state of affairs but not an uncommon one.

Cliques are a hard problem to beat and generally impossible , we can see so many examples of this screwing projects over.

In this case it's bloody disgusting that code was put on the backburner in favour of waiting for somebody else to complete their alternative solution just because A liked B better than C.

The sad story of the em28xx driver

Posted Nov 17, 2008 20:35 UTC (Mon) by cde (guest, #46554) [Link]

This story reminds me of the Con Kolivas scheduler melodrama. Here we have again one guy against a supposed "clique" of kernel developers. Reality is probably a bit more complex though.

The sad story of the em28xx driver

Posted Nov 26, 2008 18:30 UTC (Wed) by makomk (guest, #51493) [Link] (1 responses)

As I recall, it was more complicated than that (though this was a while
ago). There was some prolonged feuding relating to changes to the core
code. They ended with Markus submitting some code which made non-backwards
compatible changes to that code (something some of the other developers
didn't like); one of them proposed a simple change that would add better
backwards compatibility, but Markus basically said "take it as it is or
leave it".

What happened next was that Marcus developed his own (partially user-space)
replacement for a large chunk of the Video4Linux/DVB framework, including
forking a driver or two that hadn't been written by him, had been in-kernel
for a while, and was used by other cards. Meanwhile, the other developer
added the main required feature (support for hybrid analog-digital tuners)
to the Video4Linux code in roughly the same way as they'd proposed earlier,
but written from scratch, and this was accepted. (It also eventually lead
to some nice code cleanups.)

Well, Marcus' userspace stuff was rejected, due to (a) duplicating existing
code in a way that'd make life difficult for developers and (b) the only
real "benefit" being the ability to have closed-source blobs in drivers.
(Messages to me from Markus threatening to take his code closed-source if
he didn't get his way didn't exactly encourage me to support it either.)
There were code quality issues too, of course, but I'm not sure anyone got
as far as looking at those.

In the end, some of the developers decided to just improve the version of
the driver currently in-kernel rather than continuing to deal with Markus.
Only after this effort was well underway did Markus begin developing yet
another in-kernel driver. (This one also seemed to fail to meet kernel code
quality standards last time I checked, mainly due to incorporating large
chunks of third-party code.)

The sad story of the em28xx driver

Posted Nov 27, 2008 15:39 UTC (Thu) by mrec (guest, #41847) [Link]

(b) the only real "benefit" being the ability to have closed-source blobs in drivers.

This was one possibility yes, but I also pointed out that the already available i2c-dev infrastructure could directly be used with the driver for setting up chips.

http://mcentral.de/mrec/analogscan.png

This player parses the sysfs tree and opens the corresponding i2c device directly without any additional module. It can do some setup steps which the API currently cannot handle.

So in order to avoid that someone has to disallow the usbfs and i2c-dev interface. Back then Greg Kroah pointed out that binary drivers could use that interface, it was accepted because he basically didn't clash with another developer. So binary drivers here or there is basically the same.
This was basically my try to make development liberal and not driven by one single person.

The userspace drivers used a couple of self written drivers. The drivers which everything was about are still not available in the kernel, it basically was about Micronas chips back then.
The approach aimed to have some compatibility level to the available BSD tuning modules.

Building a virtual front between developers who actually supported linux for a long time isn't healthy. But well that way I don't see any chance in officially supporting and telling people to use video on linux unless they want to depend on the video4linux Maintainer. This will be my last comment about everything unless someone starts to think clear about the whole situation.

I never dropped off anyone contributing to that project, rather helped them to get further into it and the code authors as well as the support mailinglist are a proof of that.