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).
Now, someone ported a binary driver to linux. Very nice from this guy, but in the long run this will hurt linux (AND linux users). Manufacturers are just weighing what's the penalty and the profit for bringing out a driver (binary or source), no driver or support somenone who writes a driver (binary or source). Now, if the use of binary drivers is discouraged, there will be more source drivers becoming available (but less drivers, some manufacturers are not willing to open their source). However in the long run (and linux marketshare will help) manufacturers have to support linux. The more other manufacturers have open source drivers, the less trouble they have doing the same.
Actually, the more manufacturers see that drivers are routinely broken with little care by the Linux kernel maintainers, the less likely they are to develop drivers, source or binary. In the long run, this can be detrimental to Linux' market penetration, as users trying to switch find that their hardware does not work.
Of course you can say all things about manufacturers 'not being able to open' (nvidia binary drivers cannot be opened, because of rules, etc.), but that is just not true.
I'm afraid you chose the wrong example here, because nVidia is dealing with licensing agreements forced upon them by law. They tried to use someone else's IP, and they got caught, and were forced to license that IP. In the end, they either retool their line, break compatability, and release drivers and cards that don't utilize that IP, or they release binary-only drivers. Unless there's something wrong with the licensed IP or they can convince the original owners of that IP to license it for open source distribution, it's out of their hands.
Nvidia has no advantage of opening their secrets (yes, their competitors will take advantage of this) and therefore they are not doing it (they lose perhaps a handfull of users). A perfect business decision in the light of most linux users using a binary driver. However if ATI IS providing (this is an example) the source, Nvidia has to look different to the situation, especially if, say 20% of the users uses ATI because of this and if ATI is also 'giving up' their secrets.
But, again, nVidia doesn't own the secrets in this case. Additionally, ATI provides most of the information needed to create a driver for their cards, but doesn't provide the driver itself. Some people seem to prefer this method, but, in the end, it still means you have no support from ATI.
-PainKilleR-[CE]
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.
Sorry, but if it comes down to me having problems with a driver versus not having a piece of hardware work at all, I'll take the former.
I almost threw my laptop out the window years ago when I installed Suse and couldn't figure out for the life of me why I couldn't get the damn WiFi interface to work.
When I discovered that it was because my laptop had an built-in wifi card that had a binary only driver (and I had to jump through hoops to install 3rd party support for it) I instantly just wiped Suse out and put Windows back on. A laptop is COMPLETELY USELESS to me without a functioning wireless interface.. and I don't want to have to jump through hoops to get the damn thing to work either - it's just frustrating.
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.
Repling to my own post, yeah, yeah..
So, I just read a few of Mr. PWCX's additions to the maillists and I've come to think he's a being a real asshole. At the very first mention of removing his hook he goes balistic and threatens to remove all his work. He's probably only doing it now because he threatened he would in the first place.
And so, yet again, the person left with the most suckage is the average linux user. The kernel team is a hair bit restrictive, driver devs morph into uber-elitist pricks and yank their code, and people are left with less or poor hardware support.
Fuckin' crazy.
I'm against picketing, but I don't know how to show it.
Yes, poor poor philips. They put so much time and money into this... oh wait no they didn't. They didn't put any money in. They didn't even put any developers in.
They let an outside guy write a _proprietry_ _binary_ driver under an NDA. Big deal.
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
He can't demand back what he has already GPL-licensed.
I imagine that he can't demand that anyone who has exercised the rights granted under his license to retroactively remove his work from their own.
But if he decides not to license his work under the GPL anymore, what right do you or I have to use his code in a new project? We have no license from him, so we'd be violating his copyright.
The situation, of course, gets muddier: if I had incorporated, for example, the entirety of his GPL'd code in some project of mine, and had released my project under the GPL, presumably you could use the GPL license I grant for my project, and use my project that incorporates his code in your new project. (Although I'd question the morality of my continuing to provide his code, and the morality of your using it if you knew he'd rescinded his license.)
On the other hand, if I had merely incorporated his work by reference in my code (as say, by relying on a header file he provided, and by linking to a binary library compiled from his code) I'd say it can be argued that while you could compile my (still GPL'd) code, you couldn't compile his library -- but probably could use an existing binary copy of his library.
So on a new OS for which his library had never been compiled, I'd say that compiling it -- even to get my still GPL'd code to work -- would be a violation of his copyright.
It's conundrums like this that have always made me leery of open sourcing code -- it's not that the GPL is so onerous, it's that once you stick a finger into that tar-baby you can never again extract yourself. And clearly it was worries like this that led to the Lesser GPL ("LGPL") license.
I have a bit of code I'm thinking of open-sourcing -- I've kept it closed simply because it's essentially a web-spider, and I incorporated pauses in it, to spare other people's servers, that I don't want selfish users to remove. I wish there were an established license that would allow me to open source it with conditions, like "don't remove the pauses". And I really wouldn't want anyone to, for instance, re-brand and sell my code -- as they can with the GPL, so long as they offer the source code.
I know that a license that could be rescinded would be less attractive to businesses -- businesses wouldn't want to base long term strategy on the variable whims on a licensor -- but I doubt any business would be using my code anyway. And I'm not big on giving away freebie code to businesses -- I'm interested in helping out fellow hobbyists, not MBAs with a bonus for every job they outsource. (Just as I'm tired of writing articles for Wikipedia only to see dozens of ad-supported commercial sites rip off my work without even crediting me.)
So what's the license for me to use? It's not the BSD license, and it's not the GPL license. Does the Open Source movement have an answer for people like me, who want to maintain "moral" control of their code?
Opinions on the Twiddler2 hand-held keyboard?
3 years ago, when he was asked to take its image format conversion out of the kernel:
here's the message
You ought to have stopped after the first sentence. There is no monetary advantage to opening source or revealing trade secrets: the software industry isn't high school. If Janie (i.e. ATI) is smoking the marijuana (opens the source to its drivers), it doesn't mean it's okay for Bobby (nVidia) to do the same; it just means Janie (ATI) is foolish.
Actually, the opposite is quickly becoming true.
It all depends on what kind of systems you're using your hardware with. True, I can't see a Fortune 500 company hiring programmers to fix bugs in webcam or wireless keyboard drivers, but studios like Pixar, Disney, and Dreamworks, who run a lot of their software on Linux machines, might lean towards hardware accelerated cards for modeling which offer the drivers because it would mean less turnaround time from bug finding to bug squashing, as the debugging could be done in-house. You're probably thinking, "Yeah, but that's only for the software, and not the render farms -- a few errors during preview don't matter." However, as we move from software raytracing to hardware accelerated raytracing (which is the next obvious step after what we have now in the current generation of cards), render farms will be able to use 3D cards to to render photo-quality images at high resolution in a fraction of the time.
Now, what if a company like Dreamworks, which has hundreds of identical machines in its render farm, find that there's a driver-level bug which generates errors on some of its frames? They could switch back to software rendering (which would take longer), or they could fix the driver bug with their in-house programmers using the open source drivers and release a patch (which, incidentally, benefits everyone).
This is a highly theorhetical example (and absurd for now, but not 5 or 10 years from now), but I think it illustrates that open source drivers could, in fact, be a deciding factor for product purchases in companies using Linux.
- Cloud
If open source is about choice, I've just lost the choice to use both Phillips-based webcams and linux. Now my choice is one or the other.
Open Source is not about *that* choice though. In general Open Source is obviously not about your choice to use any hardware you want, otherwise you might have noticed that you still don't have the choice to run hardware for which no F/OSS drivers exist.
I find it hard to swallow just one side of the story. (Score:4, Interesting)?!?! It is all to easy to just spout off with your opinion about an "elitist control freak" with out providing something to back up yor claims. Are there emails in LKML that you can back your assertions up with? What is your software driver package for, and do you have a URL for the download? Who is the control freak?
I'm much more willing to give your point of view some credit if you back it up with something.
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)
I am admittedly and quite obviously biased. I assumed that this would go without saying in my original post, but it did not.
I'll not give you any information that could be traced back to me or my company, but take a moment to think on the way in which new drivers are scrutinized. They must have the Linux standard formatting, which at least I find quite odd. If the driver does not behave like other drivers in its class then you'll likely be rejected by default and have to claw your way in. Which is similar to our case sans the ability to claw.
consequently Microsoft says our device is unclassified, and therefore no one but them can test it. THAT is a true pain in the ass (and wallet).
If you've followed kernel development, which your post deftly implies, then you know that drivers get rejected quite often. Open source... Free.. Rejected. My point is that if the maintainers can overcome the desire to support all OSS to reject a driver that shares their ideals and goals, then closed source binaries don't stand a chance.
I have to call that elitism. I can only point to the demeanor of the fellow we talked with about getting our product in, (which you'll see no proof of, but you know the types that are running this show) to tell you that he was in deed a control freak.
Do you still find that over the top?
Quando Omni Flunkus Moritati
I have to agree with the other respondant. I understand how irritating it is for you -- after all, there are no code style constraints on Windows drivers -- but the only software that makes it into the mainstream Linux kernel (or bundled with the Windows distribution) is the very good stuff, and unlike on Windows, on Linux the code, not just the binary, is a factor in the quality.
I *do* realize that this could cause major problems if there are internal reasons for using a particular style or -- God forbid -- if you are trying to get a driver into both Linux and BSD or something similar. I'm not sure that there is a good solution, for trying to get open source drivers included in a kernel. That's an interesting point, though.
May we never see th