So I think your real objection isn’t to the developers’ allocation of their time, but to the way they choose to conduct their lives. 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. Markus Rechberger The sad story of the em28xx driver. Is it actually a requirement for driver inclusion that future support be lined up? So this code was not merged.
|Date Added:||27 February 2015|
|File Size:||31.10 Mb|
|Operating Systems:||Windows NT/2000/XP/2003/2003/7/8/10 MacOS 10/X|
|Price:||Free* [*Free Regsitration Required]|
The sad story of the em28xx driver
Maybe Jon’s article can be the crystallization point for everybody to take a step back and go on em28cx path of compromise instead of confrontation hope springs eternal, I know It’s about that this code has been available for years http: The drivers which everything was about are still not available in the kernel, em28zx basically was about Micronas chips back then.
Posted Nov 12, 6: The sad story of the em28xx driver Posted Nov 11, Posted Nov 20, It’s same as with Reiser4 Posted Nov 14, This will be my last comment about everything unless someone starts to think clear about the whole situation.
But such problems are common to drivers which have spent a lot of time out of tree; libux are simply something to fix. If you are abusing developers’s and users’s trust it becomes suddenly much harder to integrate code in kernel.
There have been a couple of approaches to solve the technical problem to share 1 component between analog and digital TV the tuner back then. Multiple drivers are easily accepted as temporary solution, but then someone must merge support for other hardware – and then we have “reiserfs situation” where developer works for it’s own feature and against all others In the end, some of the developers decided to just improve the version of the driver currently linuxx rather than continuing to deal with Markus.
The whole issues at that time gave him the opportunity to work on his own stuff even more to let the existing em28xx code left behind. The tone of the discussion is, perhaps, best seen from this note sent to Video4Linux maintainer Mauro Carvalho Chehab: It’s all a kinux sad story, especially compared with the success stories in em28x in the recent years: I can think of another drawback: It could easily be that this was mistaken though.
The sad story of the em28xx driver 
The sad story of the em28xx driver Posted Nov 20, Of course, losing “authority” over code is inherent in releasing that code under a license like the GPL.
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. Meanwhile, the other developer linkx the main required feature support for hybrid analog-digital tuners to the Video4Linux code in roughly the same e2m8xx as they’d proposed earlier, but written from scratch, and this was accepted. The sad story of the em28xx driver Posted Nov 12, 0: This is, also, the way that kernel developers are normally expected to do their work.
The userspace drivers used a couple of self written drivers. It has coding style and copyright attribution problems; a quick review has also left your editor wondering about locking issues.
How to configure the Linux kernel/drivers/media/video/em28xx
At that time there was no single binary driver available from my side anyway, everything has always been opensource this also has to be considered.
It’s not a project for innovative people to work on own ideas that for other open operating systems are better in that case. Having multiple drivers for the same hardware in the kernel is not an ideal situation, but it is also not without precedent.
When I once asked him about joining that stuff he just told me well but you have it already done. At times, Markus tried to block those changes. So I think your real objection isn’t to the developers’ allocation of their time, but to the way they choose to conduct their lives. Until now I have seen no attempts to make these changes, alas. I got around i2c-dev which allows the access em228xx those shared components in userland, the only outstanding gap in order to remain compatible with existing tv apps was to add a small wrapper to resubmit the controls to userspace sick isn’t it?
The sad story of the em28xx driver Posted Nov 13, 1: The whole driver started at the end ofI started to reverse engineer the protocol and worked on it with Luca Risolia hope I got the name right. So now the userspace stuff comes in thinking about how to open up that project again so that work can be used with the existing kernel.