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."
Sad, really sad. It's a lose-lose situation, and the biggest losers are linux users [who have pwc-based webcams].
Anyway, the last release files can still be found online, backup fast (e.g. gentoo distfiles : pwcx-8.4.tar.gz, usb-pwcx-8.2.2.tar.gz).
#include "coucou.h"
The module was fully GPL compliant but provided a hook where you could attach a binary-only part (this part wasn't necessary for the module to work, it just added more functionality).
So the module was completely GPL compliant but some people thought the hook to be "impure" or something... and removed it. After it has been three years in the kernel tree. The author is right: this is a little late to make a point !
That's zealotry in my book as the module did meet the legal requirements.
There's already a "tainted" identifier for modules - it's purpose is to tell you when your kernel's been tainted from an Impure Source(tm) - lsmod will tell you if your kernel's been corrupted by a non-GPL type module. Oops's from a tainted kernel a simply not accepted by the kernel maintainers as they can't bugtrace with them.
See What does it mean for a module to be tainted?
So why the hell can't they all just agree to mark it as tainted and be done with the whole hoo-ha?
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
While the Philips binary seems to be stable, if an exception to it were made other binary modules could be argued for. In fact, that's what is happening now; more and more kernel patches are being made available with binary-only parts.
There are two solutions to this;
Converting USB kernel modules into user space tools happens regularly. Not as easily done as said, and it's less prestigious, though as a technical solution it does solve the kernel dispute.
Not having the source for these devices is silly, though. Do they intend to sell hardware or drivers? By releasing the source or the specs (at a minimum), Philips would gain much and loose little. Someone else can go on a rant to fill in the details...I'm done!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
I love the misguided comments in this story. In particular, I like the "most users don't care what is in their kernel, so we shouldn't care that we're taking away freedoms from all (including those who do care)".
Some comments from the guy who actually did this (http://www.uwsg.iu.edu/hypermail/linux/kernel/040 8.3/0270.html):
So, just to summarise, a) removing the hook doesn't stop the driver working, b) there isn't really anything stopping him publishing the code as free software. Basically, he just wants to take his ball home because he thinks he should be allowed to put hooks for proprietary modules into the kernel.
Is it the first time he's threatened to do this? No (http://www.uwsg.iu.edu/hypermail/linux/kernel/010 5.3/0365.html):
Linux doesn't need proprietary drivers, it doesn't need to compromise freedom, and it certainly doesn't need people to try to press the issue by holding code hostage. And, aside from all the facts that this guy is acting an arse, there are also questions over whether or not the hook is legal (Linus' point of view of derivative works of the Linux kernel is quite clear - they must be GPL'd), and the decision to remove the hook was partially a technical one anyway (only one driver is using it).
Yet, we are still going to get people holding this up as an example of the GPL preventing Linux from "going enterprise" or whatever. Guys; shove it - for Linux to be "accepted by business" doesn't mean that developers should bend over for whatever perversion proprietary companies want. Jeesh.
"Elmo knows where you live!" - The Simpsons
Simply not true. You can transmit 1 Watt with 802.11b in the US, but the most powerful cards can only be pumped up to about a 1/4 Watt.
I'm sure you know this, but part 15 actually limits you to 1W (30dB) EIRP (technically in some situation you can push 36dB but we will not get into that) which is not the same as your radio being able to output 1W or not. Antenna gain generally plays the biggest part in this. I would put good money that a lot of people out there running 200mW cards with a high gain directional antenna are actually operating illegally. Higher power radios with low-gain omni's are often great for indoor spaces, but by the time you stick a big 24dB antenna up on a pole, you don't need that much power from the radio.
As an aside (and more or a reply to the grandparent post) there are a lot of good reasons for needing to get around the FCC restrictions in the driver -- using the radio in countries outside the US is the main need, but there are other situations where it's good to allow it such as when ham radio guys (legally) use frequencies outside the ISM band...
You do need to follow the Linux standard formatting.
This is simply because your code needs to be
readable to everybody, and everybody is used to
the standard style.
Often, somebody will go through the Linux source
code making fixes to hundreds of drivers. Such a
person can work much faster if all the code uses
the same style.
Fix the style, then post to linux-kernel with
copies to Linus and Andrew Morton. Repeat as
needed, fixing up any objections you get.
Post to LKML. This is probably the "official way", and even if not, they'll definitely tell you the right thing to do.
Also helpful is #kernelnewbies on Freenode, where a bunch of kernel hackers hang out, but it sounds like this doesn't require low-latency interaction.
I would like to thank you for stepping up. All of us Linux users benefit (I, have been batting around the idea of playing around with some image recognition and processing ideas on Linux, and this would allow me to continue to do so).
I'd like to point out that there is userspace software (GPLed) to do superresolution processing that may be able to provide PWXC-like functionality, but still keep the kernel hackers happy.
I would like to see the PWC/PWXC guy reconsider abandoning ownership (and all the nice work he did) -- he probably did what he did in a fit of frusteration with the other kernel hackers, but if he becomes willing to allow PWC to just pass its data through some userspace software, this might not hurt end users (and if the userspace software is better, might even be a win).
May we never see th