Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
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)
Posted Nov 26, 2008 18:30 UTC (Wed) by makomk (guest, #51493)
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.)
Posted Nov 27, 2008 15:39 UTC (Thu) by mrec (guest, #41847)
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.
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds