Slashdot Mirror
Kernel Maintainer Kills Philips USB Camera Support
outanowhere writes "The author of the Philips webcams kernel module has thrown in the towel and quit providing the pwc and pwcx kernel modules which make using Philips-based USB cameras such as those from Logitech and Philips possible with Linux.
According to the author, the last straw was when a kernel maintainer changed his pwc module to make using the binary-only pwcx compression module impossible.
It is a victory for obsessive kernel-purists but a major loss for all Linux users."
I met the maintainer once (although he lives relativly close), nice guy, but I kinda think this is just a useless move to annoy him, there are many fully binary only modules out there and he makes the effort to make opensource what he can (NDA) but provides a binary only module (on his own website) to add some more functionality (larger image/higher fps).
The kernel does support firmware. In fact, there has been significant effort recently to standardise the way that firmware is loaded to hardware by the kernel. The kernel developers don't seem to have a problem with firmware. Their beef is with binary drivers that run in the same address space as the rest of the kernel. I can see the kernel developer's point of view: they don't want to waste their time debugging around binary drivers.
Hopefuly the nvidia drivers. As much as I like the nvidia company - they have some of the best minds in the business, they are good contributors to the state of the art, they pump significant money into R&D, and they play (mostly) nicely with the standards bodies - their binary drivers are retarding the future of Linux. If the nvidia binary drivers stopped working tomorrow then we'd hear the howls from millions of Linux users, but after the howling stopped there would be some real progress on pushing DRM and Xorg DDX forwards.
Another example here: Wireless LAN cards.
Many (actually, all) of the Wireless LAN cards on Linux require a binary driver. There is a reason for this: A Wireless Lan Card is a radio transmitting device and falls under FCC rules.
The FCC has regulations about not allowing end users to change some of the parameters (which the chipset may allow) and therefore is pretty much ILLEGAL to have a source code driver for these cards because they are regulated devices.
For instance, some of the chips allow you to jack up the power beyond what the FCC allows. Which the binary driver does not, which is why the FCC allows the manufacturer to distribute the thing in the first place.
And the US is liberal in these matters. In Europe rules are usually stricter.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Regarding point a), Linux has a hisotry of allowing binary modules, provided that there is reasonable evidence that they are not derived from the kernel code. This allows things like the andrew filesystem modules and various other binary modules to exist. The tainted flag is to mark them as non-debuggable. The primary module in this case is licensed as GPL, so that's not the issue. It debateable (as we don't have the source), whether the bianry module qualifies as being derived from the kernel or not. If a strong case can be made that it is derived, distributing under a non-GPL license is illegal. Non-one seems to have made this claim, so it is probable that this is not an issue.
b) on the other hand, is very much an issue. The GPL code provides a specialised hook for the binary-only module. It would be pretty difficult to argue that this does not consitute linking under the FSF's definition, and as such, the combined work must be distributable under the GPL. Since this is not the case, there is a licensing problem.
Now, if the binary only module communicated with the GPL'd code via standard interfaces (run as a userspace program, or whatever), the linking issue would not apply. This is not the case.
This is not zealotry. The Linux kernel is GPL. With that, come certain limitations. Especially with accusations (SCO) flying about, being very careful the kernel follows the legal requirements of the GPL is important.
I don't have much sympathy. API versioning isn't rocket science, and it does not doom you to "archaic" interfaces when managed correctly. Compatibility between the major releases (2.4 series, 2.6 series) etc alone would be a major improvement. It can be as simple as introducing a new function instead of changing the prototype of a new one, or introducing padding into the structures.
Unfortunately the kernel developers have this idea that somehow the kernel is exempt from the same rules that govern userspace: if you document and expose interfaces to external code, you keep the interfaces stable.
Quite a lot of armchair coders don't understand backwards compatibility. It does not (necessarily) lead to insecurity or unreliability. I would like to be given examples of occasions where it has, in fact. It does mean managing change, but then this is what maintainership is all about.
The idea that making binary development hard increases the likelyhood of source releases is a fantasy based on an incomplete understanding of the economics involved. The most likely outcome is in fact the discontinuing of the drivers altogether, as has happened here.
The USB hook for binary modules was a real detriment to the USB subsystem. It was taken out for technical reasons.
It was not. Re-read Greg KHs emails. It was taken out because he thought it was a GPL violation (which is a gray area).
Talk about immature. He could leave it there until a new maintainer stepped forward but he'd rather have a dummy spit and stamp his feet.
He has worked for years to produce a solid driver for the community, even signed NDAs to get the relevant specs, and has coded on in the face of ridiculous instability in kernel development. It isn't easy doing such job, yet he did it anyway.
When you have contributed for so long, in the face of such a difficult API to work with, then you may have some authority to say whether his behaviour is "childish" or not. In his position I'd be pretty pissed off as well.
Hell, even Linux userspace has severe problems with keeping stable interfaces. I would hate to be a kernel developer.
As a developer for a very small company, trying to get our Open Source driver into the 2.4 kernel was a nightmare.
For several reasons, user land was not a viable option. The elitist control freak running the show wouldn't let our code in. Consequently, we lost some good free advertising, and possibly some customers in order to feed the ego of some guy bent on denying anything he thought could go through user land instead.
We ended up just putting the source on our web site. Several customers already use it very successfully. But none the less, we were blocked from contributing while trying to uphold the spirit and ideals of OSS. I can only imagine how much the poor sap from Philips was being jerked around.
That being said, Linux was a stroll through a grassy meadow compared to trying to go through WHQL testing for M$.
Quando Omni Flunkus Moritati
One ironic twist is that LavaRnd used only the PWC (open source) module. We did NOT use the PWCX (binary-only) module. Our hotplug script did an rmmod of the pwcx module. We discovered that the PWCX module reduced the entropy that the webcams provided. The PWCX module, when loaded, made webcams a poorer entropy source.
LavaRnd used the entropy provided by the actual hardware. Our analysis showed that PWCX was in effect "faking" the larger image sizes by taking, say the true 160x120 pixel CCD output and expanding it to something like 640x480. The expansion was as if a 2D smoothing function (such as a 2D spline?) filled in the pixels in between. Each of the original 160x120 hardware pixels was turned into a 4x4 pixel grid where the edges of the grid were adjusted to fit better with neighboring 4x4 pixel grids. The PWCX appeared to support a higher frame rate because the PWCX module "decompressed" the true hardware pixels and filled in the pseudo-pixels on the other side of the USB wire.
We discovered the PWCX effect while taking entropy measurements of webcam frames. Using PWC alone in 160x120 mode, the webcam produced slightly more entropy than 640x480 PWCX mode. The PWCX module was not adding real image data to webcam frames, it was just smoothing and filling in data that looked good enough to a human. However, PWCX could not fool the math ... :-)
The PWC maintainer says on his web site:
The PWC maintainer's position appears to be that if you cannot use PWCX, then PWC is worthless. From LavaRnd's point of view, PWCX (the binary only module) adds no value and in some ways reduces the Logitech QuickCam's value as an entropy source.
We (LavaRnd) do not want to take sides in this PWC/PWCX kernel dispute. If this posting appears that way, then we apologize. The PWC folks have been mostly patient with our unusual use of their webcam modules. The Linux kernel folks have provided us with a wonderful platform for LavaRnd. As for ourselves, we put a lot of time into helping end users use the PWC module in older kernels.
Here is our advice request:
The LavaRnd project would like to see the PWC (open source) module remain in the Linux Kernel. We would like the Linux kernel folk to not honor the maintainer's request to remove everything. We want the support of PWC without PWCX to continue in the Linux Kernel. What is the best was to make this position / request known to the key Kernel people in the hopes they will PWC as part of Linux?
And does every chunk of the Linux Kernel need an active maintainer? Could PWC remain in the Linux Kernel without the original maintainer's support or would someone such as ourselves need to step up and offer to maintain it?
chongo (was here)