| |||||||||||
|
| |||||||||||
Linux loses the Philips webcam driver
The latest set of USB patches includes an
unwelcome entry: the Philips webcam driver has been removed by its
author's request. The issue is whether this driver can contain a hook for
the insertion of a proprietary, binary-only module; when that hook was
removed (due to licensing concerns) the author (Nemosoft Unv) decided to
pull the whole thing. He has put up a web page describing his
position on the matter.
The driver, being licensed under the GPL, could be retained regardless of the author's wishes, but USB maintainer Greg Kroah-Hartman has not taken that approach. Linus supports this decision: "I'd love to let people just continue using it. But the fact is, at least from my standpoint, I'd really hope that anything I had written would be used in ways I asked people to - regardless of license. Now, I don't usually get into hissy fits, but the point stands, and the golden rule is: do unto others as you would have them do unto you." Update: Greg KH has posted a brief FAQ on why this driver was removed. (Log in to post comments)
Linux loses the Phillipswebcam driver Posted Aug 27, 2004 9:51 UTC (Fri) by Duncan (guest, #6647) [Link] Wow. I'm no friend of proprietaryware and certainly back the kernel folkson their stand. However, I can easily see someone else picking up the pieces (since it /is/ gpled), and it becoming yet another sourceforge project, possibly under a different name, so those that wish (and some of the various distributions) can continue to use it. Even if not, I can see it easily being maintained in the various distribution trees, with one or another likely becoming the authoritative source for it. As I said, I certainly back the kernel folks on this. Letting proprietaryware drivers attach themselves from their third party positions if they so desire is one thing, but putting a specific hook in the kernel for that specific purpose is quite another. Remove it, and good riddance! As well, there's the author's position in regard to the kernel which I'd respect. However, some third party can continue to offer it, and/or the distribs can pick it up, as desired, and I'd have no sympathy with the current author attempting to get them to cease distribution. It's unsettled whether he would, but he'd have little legal room to do so, even if he tried, given the license, which is as it should be, and part of the whole reason behind the GPL! Duncan
The GPL driver lacks features Posted Aug 27, 2004 11:52 UTC (Fri) by erich (subscriber, #7127) [Link] The GPL part of the driver lacks features. I have borrowed such a webcam for toying around with effectv. I can't run the full resolution without the closed-source part of the driver - the USB1 bandwith isn't sufficient apparently, so these resulutions require (proprietary) compression.
Of course would having a feature-limited driver still be better than not having a driver at all. But i'm unhappy with this development.
Linux loses the Phillips webcam driver Posted Aug 27, 2004 9:53 UTC (Fri) by vblum (subscriber, #1151) [Link] Fortunately i am not a user of this, but the development is a sad one. If I understand correctlu, the PWC approach was to hide all the binary stuff (closed) behind an open and maintained layer, so that the usual argument (closed drivers cannot be fixed externally if the mainline kernel development process breaks something by accident) would not appear to hold.
I personally believe that Phillips is paranoid by not making their specs openly accessible, but hey - the guy that has been punished in the process is not Phillips - the pressure was applied against some poor individual instead who tried to do the right thing.
Morale - why weren't the relevant people at Phillips put under pressure, rather than fighting a pointless battle with a maintainer? Just some thoughts, I had nothing to do with the story, and hence not much right to an opinion ...
Linux loses the Phillips webcam driver Posted Aug 27, 2004 9:59 UTC (Fri) by marduk (subscriber, #3831) [Link] I would agree with the author, that everyone loses on this one, but IMO free software wins. And when free software wins, everybody wins (indirectly):
* Me, because I'm stopping to support a popular driver in the Linux kernel. Something I was proud of, got me my 15 minutes of fame.
Hopefully he will find it worthy to work on another hardware driver for Linux that is not crippled by binary-only drivers and NDAs.
* You, because you will lose the ability to use your webcam.
Hopefully Linux hardware users will do the same when choosing hardware.
* Most of all, Linux itself; if you really want to make Linux a good user experience, it should be easy to install, and have good hardware support. The harder you make it to get your stuff working under Linux, the quicker people will turn away.
I'm sure there are many many types of hardware that could have made it into the kernel proper if binary-only drivers and NDAs were accepted. But this does not mean it is the "right" thing to do. It's unfortunate that this driver was ever allowed in the first place. It shouldn't even have gotten this far.
* And finally, Philips, since a great product of them will not be supported anymore; Linux support may not make them rich, but hey, they've given us a chance!
They've given Linux a chance and I agree that that's commendable. But, so have other hardware companies that provide binary-only drivers. Still that does not make it right to include those drivers in the stock kernel.
If we let this driver in, we have no reason to argue against other binary-only drivers' inclusion in the kernel. And what we stand to face in the future is a kernel in which most of the recent hardware drivers are closed and thus we are moving in the wrong direction as far as free software is concerned.
Let's not try to sweeten it Posted Aug 27, 2004 11:58 UTC (Fri) by ncm (subscriber, #165) [Link] This is a loss for Free Software. Period. We stuck to our guns, and now suffer for it. There's no point in pretending that it's always easy to stick with policy. Besides losing the driver, this is a PR failure: it will distract vendors from the many drivers integrated smoothly into the kernel source.However, we should not exaggerate the misfortune, or miss the real lesson. The real lesson of this whole fiasco is tread lightly. Given a bit of delicacy and time, everything could have been resolved. GK-H might have mailed the author privately (or phoned him!) and discussed alternatives informally, without backing him against the wall in public. With a few days to think about it, surely they would have hit on one of the many acceptable ways to put the proprietary stuff in user space. Next time.
Let's not try to sweeten it Posted Aug 27, 2004 12:49 UTC (Fri) by xav (subscriber, #18536) [Link] Well, could you explain how loosing a binary-only driver is a loss for Free Software ?
Let's not try to sweeten it Posted Aug 27, 2004 13:03 UTC (Fri) by ncm (subscriber, #165) [Link] You're not paying attention. We didn't just lose the binary driver, we lost the whole thing, and the maintainer besides. And all for nothing, really. This is something the FSF people understand better than the Linux kernel people do: confrontations usually produce heat, not light.
Let's not try to sweeten it Posted Aug 27, 2004 13:23 UTC (Fri) by marduk (subscriber, #3831) [Link] Yes, I understand that the "confrontation" was unfortunate and likely unnecessary. However I'm not so convinced that it was entirely the fault of the kernel maintainer. The driver author's own words seem to indicate that he (too?) was unwilling to bend. If he had/does submit the crippled, yet fully-open version of his driver, then I'm sure there would be little issue getting it merged into the kernel. Hopefully in the future he or some other knowledgeable person will do just that.
So in my original post (and this one as well) my aim was not to take either person's side but the side of free software itself. It's unfortunate that the free software got taken out of the kernel, yet just as unfortunate that one insists on only supporting driver with the binary-only parts included. I still conclude: both sides lose, but the net result is that free software wins (i.e. the kernel stays free).
Let's not try to sweeten it Posted Aug 31, 2004 1:58 UTC (Tue) by bignose (subscriber, #40) [Link] > We didn't just lose the binary driver, we lost the whole thing, and the> maintainer besides.
No, the GPL code is still available to all under the GPL. We lost only the current maintainer.
Let's not try to sweeten it Posted Aug 27, 2004 18:06 UTC (Fri) by emkey (guest, #144) [Link] Its a loss to Free Software because its one more bit of functionality lost over a largely pointless idiological point.
I care about features. I care about there being a real alternative to Microsoft Windows on the desktop. Within certain boundaries nothing else matters to me. Its pretty much that simple. And losing a significant bit of functionality in this way works against my interests and the interests of a lot of people who feel that idiology should be properly balanced against reality.
Let's not try to sweeten it Posted Aug 28, 2004 1:23 UTC (Sat) by xav (subscriber, #18536) [Link] Then, really, use something like MacOS X, it is exactely what you want.You didn't understand what Free Software is, it's not just an alternative to Windows. Respecting the GPL isn't a "largely pointless idiological point", it's what enables linux to progress and be independant of software vendors - it's more pragmatic than you think.
And then, bitching about your interests won't get you very far. The guys who will solve that current little problem will be the ones who decide to work on a new driver (or take over the old), not the ones whining on the forums.
Let's not try to sweeten it Posted Aug 31, 2004 14:12 UTC (Tue) by emkey (guest, #144) [Link] No, I understand perfectly well what free software is. The thing is as long as it is free to me I could care less where it comes from.
And no, I don't consider MacOS an alternative.
Let's not try to sweeten it Posted Aug 29, 2004 11:09 UTC (Sun) by ncm (subscriber, #165) [Link] It's lucky for you that somebody else is looking out for your interests, because you obviously don't understand them yourself. Free Software is about actually free software. Without that, it isn't about anything. Who would participate in something that isn't about anything? It would just fade away like so many other projects that are started and cannot sustain themselves.
Let's not try to sweeten it Posted Aug 31, 2004 14:13 UTC (Tue) by emkey (guest, #144) [Link] Gee, thanks for caring...
Personally I prefer to look out for my own interests. Something I'm 100% capable of doing by the way.
Let's not try to sweeten it Posted Aug 28, 2004 9:11 UTC (Sat) by _shadow (guest, #24330) [Link] How do we loose?
Easy to explain, Windows supports hardware much better than Linux today. We loose one camera support. It's not just a camera, it's one of the best cameras for Linux. I don't see many alternatives.
The second point is negative experience and negative image of that free software community. It shows clear that it does not want to coexist with proprietary software. Hey, if you want to beat Windows you need many applications, many people should work on them, and they would not work 8 hr a day for free. The result of free development is obvious if you compare say Gimp with Photoshop. Only few projects have external source of money. Apache is nice example of quality software. But wait, aren't they payed for this?
Let's not try to sweeten it Posted Aug 28, 2004 21:28 UTC (Sat) by tzafrir (subscriber, #11501) [Link] What did you expect Linus to do? Did you expect him to resond with: "Oh, please go on violating my license. Just because you contribute this very useful driver to us we'll look the other way. And no: no problem with the fact that you never told us about that extra license-violating functionality of the code you wrote".
Let's not try to sweeten it Posted Aug 28, 2004 0:28 UTC (Sat) by tincat2 (guest, #24322) [Link] i've got to agree with you-seems like something could have beenworked out here. i've been using this cam for three years now and have been grateful to the driver author for not only the driver, but for the info and advice he provides on his Philips webcam site. sometimes i feel he is a little arch in his comments to the user, but he's doing a lot of work for a non paying, often barely, if at all, grateful clientele. in any case, i don't believe i would have approached him brassily concerning this situation, were i the kernel maintainer. that's not to say that's what i think happened and keeping the kernel open makes sense in terms of stability and licensing issues. but it also seems to make sense to facilitate closed source functionality to the linux user as much as possible. linux is a very good thing and should be available to as many users as possible, including those who can and would just as soon pay someone for a ready made solid solution that plugs right in-linux needs to assimilate closed source as a path to a user base significant enough to prevent the coming attempts at a virtual lockout by hardware manufacturers in collusion with the dominant software producer.
Linux loses the Phillips webcam driver Posted Aug 27, 2004 10:30 UTC (Fri) by neoprene (guest, #8520) [Link] its Philips not Phillips. [pronounced feel-lips]
Typo fixed Posted Aug 27, 2004 10:34 UTC (Fri) by corbet (editor, #1) [Link] My error, fixed.A general request: when typos are mailed to lwn@lwn.net, they can be fixed more reliably, and without bothering the majority of readers who (we think!) don't come to LWN to read typo reports.
More conversation links Posted Aug 27, 2004 10:34 UTC (Fri) by rfunk (subscriber, #4054) [Link] I just went to the linux-usb-devel archives and found more of this conversation: before the removal and after the removal
More conversation links Posted Aug 27, 2004 10:37 UTC (Fri) by TimCunningham (guest, #10316) [Link] Thanks, I was looking for this.
More conversation links Posted Aug 27, 2004 13:46 UTC (Fri) by lucat (guest, #15102) [Link] The post of Nemsoft seems very childish to me. I can understand his point of view... but not when he demands that a piece of code that HE opensourced of his own will would be removed from the Kernel.I am sure that he is feeling hurt by the choice of the Kernel guys, after all he worked on this driver for 5 years... but his reaction is simply childish.
He might not have fully understood GPL, you just cannot withdraw it once you have GPLed your code. He has no right to demand the removal of the opensource part of the module. No one is going to change his copyright notice, but for sure he cannot ask them to remove it.
He says that his NDA expired one year ago, then he claims that he cannot GPL it anyways... at this point i must believe that HE does NOT want to opensource it... i don't know why... his fears of a legal battle with Philips simply don't stand. His NDA expired, he is FREE now to fully opensource the driver. Maybe he forgot what Linux is but for sure, from his requests, he forgot what GPL is.
Following his way to think then the Kernel guys could demand him to stop using Linux at all since it is their work... of course they will not, since they DO understand GPL.
Unfortunately i have one of the webcams that work with the PWC driver... until Philips will opensource the decompression algorithm i'll stop buying ANY Philips device. This will probably not solve anything, it will probably not make them change mind about opensourcing a dumb compression algorithm, but i for sure don't want to have to depend on them on my future hardware.
Bye,
More conversation links Posted Aug 27, 2004 14:01 UTC (Fri) by wcooley (subscriber, #1233) [Link] He did not demand the removal; he asked and it was removed as a matter of courtesy and because it has no maintainer. Because it is open source, users are still able to use the patch (if you can find it, which I'm sure you can). You are also free to continue maintaining and developing it. If you read the e-mail Greg linked to below, you'll see he would accept the patch back with a new maintainer.
More conversation links Posted Aug 27, 2004 14:12 UTC (Fri) by lucat (guest, #15102) [Link] > In case the answer is "No", then I will:> - demand that the PWC driver is removed from any further Linux kernel > releases; Open source or not, it"s still _my_ work.
It looks like a demand to me.
Bye,
More conversation links Posted Aug 27, 2004 14:19 UTC (Fri) by lucat (guest, #15102) [Link] I also want to add this... it seems to me that Nemosoft believes that the contract that he signed with Philips (the _expired_ NDA) is more important than the contract that he signed with everyone of us (the GPL).He can for sure think this... it is his right to do so... but this should also warn us that accepting closed-source code inside the Kernel will make our hardware dependent on the decisions of a particular company. When they will stop supporting new Kernel versions we will be forced to change our perfectly working hardware... this is unacceptable to me (when i buy something i want to be free to use it how i want and for how long i want) and this is why we should strongly oppose binary-only drivers in Linux. This is my opinion at least.
Bye,
More conversation links Posted Aug 29, 2004 21:58 UTC (Sun) by xoddam (subscriber, #2322) [Link] The GPL is not a contract, it's a license to copy.
Linux loses the Philips webcam driver Posted Aug 27, 2004 10:40 UTC (Fri) by gregkh (subscriber, #8) [Link] Please see http://thread.gmane.org/gmane.linux.kernel/230136 for myanswers on this issue.
greg k-h
Linux loses the Philips webcam driver Posted Aug 27, 2004 13:04 UTC (Fri) by kh (subscriber, #19413) [Link] Thank you for your efforts to keep the kernel Free.
Linux loses the Philips webcam driver Posted Aug 29, 2004 21:54 UTC (Sun) by penfold (guest, #21150) [Link] I am not a developer, nor have I studied the driver's code, so please forgive me if this is a stupid question.
But from the posts I read (both here and referenced in the links above), I think I see both sides of the argument. However, it appears to me that this hook was removed mainly because it's sole purpose was to support a closed source driver.
My stupid question: Could not something be written (open source of course) that would strip out the compressed video and simply generate a test pattern (Color bars perhaps?) with some text that mentions the feature(s) requires a closed source binary?
As I understand it, it would satisfy the closed source binary policy of the kernel (now an open source element requires the same hook), the NDA constraints that the developer may be operating under, while still providing support for a popular product.
Since I am not involved in this project, I do not know who is the best person to contact with this idea. If this is a good idea, I hope someone forwards it to those that do something with it. If it is not a good idea, I hope it helps spark a good one in someone else.
Linux loses the Philips webcam driver Posted Aug 30, 2004 1:09 UTC (Mon) by khim (subscriber, #9252) [Link] Huh. Typical "American answer". Rules are not laws! Linus is god as far is Linux is concerned. And he can just say: "yes, doing this is against the rules but it's good for linux kernel so we should do it this way". And it'll be end of story. No need to write some useless GPLed crap. Why here it did not go this way ? Simple: rules are invented to keep linux kernel in good shape and not something good in itself. Keeping this hook did not served purpose of supporting usefull free software so what's the point. There were similar discussions about hooks SELinux uses - they were to poorly developed that Linus said he'll consider total removal of hooks despite having quite usefull free software needing these hooks. So no, your proposal is not any good. And as far as you'll tring about a way to legalize binary module you'll get no support from kernel folks. You have two choices really: If you'll try to make letter of said rules satisfied but not spirit... well - it'll go nowhere. Rules by itself is not something work satisfying.
Linux loses the Philips webcam driver Posted Aug 27, 2004 10:44 UTC (Fri) by QuisUtDeus (guest, #14854) [Link] Maybe Phillips will do this or are doing this, but the common way for a company to provide closed-source binary drivers for their hardware is to - well - provide closed-source binary drivers for their hardware.
They should not (and may not) expect their closed-source driver to be included in the main kernel, but if they want to users of Linux to buy their hardware (this would seem a given for all hardware vendors), then they need to take the steps needed to support the more common target kernel versions. This is where a contractor or employee can be responsible for (and hopefully compensated for) making sure the driver still works with the desired kernel versions. NDAs would be no problem here, and the newest version to overcome incompatibilties with version X.Y.Z is available on their web-site within a week or less.
Sounds like a fun job if the hardware vendor wants to sell their hardware to people who might actually have money for their products since they save a fair amount on their software.
This part boggles my mind: the reluctance of hardware vendors to support Linux. If free software users are paying less for software, then they have that much more to buy hardware. Linux users could be any hardware vendor's best customers. We have few restrictions on installing the same OS on multiple machines, and if we want to have similar hardware support on them all, then we will buy mulitples of the same hardware, if only there is support for it.
Linux loses the Phillips webcam driver Posted Aug 27, 2004 10:56 UTC (Fri) by raymond (guest, #5200) [Link] Both the author and the kernel maintainers' standpoints are understandable. We all lose when the driver (this, or any other) support is dropped. But if binary drivers is encouraged, true open source driver may be discouraged.
I have long heard of the theory that binary driver should be discouraged. I feel frustrated very much when I deal with my binary ide-raid driver, for instance.
However, my humble opinion is that we should not discourage any thing that support Linux (or open source software).
In many cases, I can't recommend my friends to use Linux, just because many drivers aren't supported in Linux. And my friends are just ordinary users.
My theory is that we should encourage binary drivers, too. Then more people can enjoy Linux.
Yes! We (open source users) may be endangered if there are only closed source programs (and drivers). But if open source is really better (both from vendors' and users' points of view), then ultimately, open source code will prevail.
In all, I think we should not discourage anything (binary drivers, and others) to Linux. Just when more crowd use Linux (and other open source software), and vendors are attracted to Linux, with competition, smart vendors will win with open source code.
Extra *****
This is alway true nowadays.
Linux loses the Phillips webcam driver Posted Aug 27, 2004 13:55 UTC (Fri) by smoogen (subscriber, #97) [Link] Your analogy about foreigners only works if they share information with the court members.. which they would do to keep their jobs.. Closed source applications/modules have a long tendency of just taking information and not giving anything.
Linux loses the Phillips webcam driver Posted Aug 30, 2004 2:58 UTC (Mon) by tyhik (subscriber, #14747) [Link] "However, my humble opinion is that we should not discourage any thing that support Linux (or open source software)."
Which is producing worse user experience/publicity - preventing some
Linux loses the Phillips webcam driver Posted Aug 30, 2004 18:09 UTC (Mon) by raymond (guest, #5200) [Link] My theory is that open source will win because it is just better in native (for both user and vendor, and indeed, everyone). But before we reach the point that everyone realize this, we have to promote Linux (and open source) practically.
The approach should be "not prohibit anything", as soon as it doesn't violate open source.
I think the whole matter requires technical understanding to the kernel, which I frankly don't. My understanding is limited and may be wrong. I guess that the open source drivers are within the kernel tree. While the kernel maintainer is doing all-the-thing to uphold this. That's perfect and I agree very much.
But we should also encourage binary driver too. I guess we can put it in the user space (and some people are doing it already?), but somehow it will require separate maintanence. That's reasonable. What we should do to improve Linux's driver support is to make this work easier.
Binary driver is often making bad user experience. I think so.
But people know the difference (well, utimately) of non-open and open source code.
In all, we have to make binary driver interface with Linux well. And indeed, we have to make everything interface with Linux well. Then by natural selection, open source will win.
Again, question from a (not knowledgeable enough) programmer: can we make the binary driver compatible to main kernel tree in some way that minimum work is needed when the kernel tree progress changes?
Linux loses the Phillips webcam driver Posted Aug 31, 2004 1:36 UTC (Tue) by tyhik (subscriber, #14747) [Link] Open source can win only if it evolves. The problem withthe GPL-ed part of the webcam driver was that the author declared it will remain unmaintained. And unmaintained drivers tend to "rot", because kernel's requirements to drivers change over time.
Linus has explicitly declared that the in-kernel
You know how many mandrake users have blamed mandrake recently
Linux loses the Philips webcam driver Posted Aug 27, 2004 11:15 UTC (Fri) by iabervon (subscriber, #722) [Link] It seems to me like the generally accepted way to arrange this is to have the driver support a mode where it sends the data compressed in the weird way, and have a userspace binary-only program or library decompress it. It's not the problem of the open source driver or the kernel if the data that a device produces is in some weird proprietary format, if that's what the hardware actually does. For that matter, userspace might want to do something with the data still in that format; I could imagine streaming the data, still encoded, to a different machine (from your desktop machine to your web server?). If the compression is actually worthwhile, you might as well leave it compressed that way in transit.
Ironically, this position was recently expressed by Alan Cox in an unrelated thread about using floating point in the kernel.
Compressed? Fine. Posted Aug 27, 2004 11:40 UTC (Fri) by ncm (subscriber, #165) [Link] Yes. It seems as if this could have been resolved by asking the maintainer to move the proprietary scheiss to user-space, and have the device node deliver compressed material directly. Surely the commands to put the camera into the higher-resolution mode aren't considered secret?Maybe it's all water under the bridge now, but next time it could be different. It seems that the maintainer was confronted with this in public, and felt he was backed to the wall. It might have been handled much more delicately, and we all would have ended up winning. Not only would we still have support in the kernel, but orders of magnitude more people would be in a position to experiment with reverse-engineering the compression.
Compressed? Fine. Posted Aug 28, 2004 19:47 UTC (Sat) by lutchann (subscriber, #8872) [Link] The only binary-only code in the 9.x drivers was a .a file with the decompressor routines. This was linked against some glue code to make pwcx.ko for 2.6 kernels and pwcx.o for 2.4 kernels, but there was also the option to compile the .a file into user-space code and do the "proprietary" decompression in user space. Then you could get the high resolutions with no binary-only code in the kernel.
This is not a technical issue at all; it is a disagreement between Nemosoft and the rest of the community about the tolerance for binary-only modules in the kernel.
Compressed? Fine. Posted Aug 29, 2004 15:46 UTC (Sun) by jjs (guest, #10315) [Link] Check the below link to an e-mail to the lkml - Nemosoft plans on doing just that. Following the various threads on lkml, he wanted it pulled because without the driver, pwc was broken, and he didn't want to answer all the "why is my driver broken" questions when the correct solution was fix the problem.
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/2017...
Author's voice Posted Aug 30, 2004 7:21 UTC (Mon) by primorec (guest, #2740) [Link] http://www.smcc.demon.nl/webcam/
Still clueless Posted Aug 30, 2004 13:08 UTC (Mon) by ncm (subscriber, #165) [Link] It sounds like Nemosoft still hasn't figured out what happened, and is blaming the Linux kernel maintainers.What's odd is that I don't see any hint that he bothered to contact Philips and ask how they feel about abiding by the letter of the NDA, so he could release the source to the decompressor. Instead, he preferred to play chicken with the kernel maintainers because he doesn't agree with their policy. It looks like they recognized that was what he was really up to, and refused to play.
Linux loses the Philips webcam driver Posted Aug 27, 2004 11:15 UTC (Fri) by jwb (subscriber, #15467) [Link] This seems quite strange. You don't need the binary driver to get the basic functions of the camera working, but you do need it for the highest resolutions. So why not just toss the proprietary compression driver and keep the basic functions?
I'd much rather have a barely-working quickcam than a useless quickcam.
Linux loses the Philips webcam driver Posted Aug 27, 2004 12:02 UTC (Fri) by erich (subscriber, #7127) [Link] You do.The current maintainer (read: author) of the driver doesn't. So he told the kernel maintainers to remove this *unmaintained* driver from the kernel. I guess if you pick up the code - it's GPL - and resubmit it to the kernel developers promising you'll further maintain it, it will go back in.
Moving the proprietary decompression into a userspace application would of course be nice. But then someone needs to make a *secure* api for accessing it and for providing the decompressed video data back to userspace using a video4linux device (remember: you'll want to use the webcam the same way like all other webcams)
Linux loses the Philips webcam driver Posted Aug 27, 2004 13:06 UTC (Fri) by ncm (subscriber, #165) [Link] Jeopardy response: "What is a named pipe?"
Linux loses the Philips webcam driver Posted Aug 27, 2004 13:28 UTC (Fri) by Ross (subscriber, #4065) [Link] That doesn't agree with Linus' statement about respecting the wishes of theauthor. I some dissonance between all these statements.
It seems someone agrees Posted Aug 31, 2004 11:05 UTC (Tue) by Ross (subscriber, #4065) [Link] From KernelTrap:http://kerneltrap.org /node/view/3747?PHPSESSID= ec07d8bff92b1faf36bdc14451a40476
On Gwe, 2004-08-27 at 01:03, Linus Torvalds wrote: > Yes and no. From a legal standpoint you're right. However, we should also > be polite. If he's the sole author, and he asks for it, I think it's > reasonable to honor his wishes. He is not sole author. Large parts of the code are based on other authors work and simply copied from the standard framework. Please put back the version without the hooks. It is useful to all sorts of people in that form. When the author GPL'd it he gave up his rights to remove it. Expecting people to clean-room reverse engineer GPL source is a joke. Alan ----- On Gwe, 2004-08-27 at 20:29, Linus Torvalds wrote: > So stop whining about it. The driver got removed because the author asked > for it. Please put it back, minus the hooks so the rest of the world can use it. If not please remove every line of code I've even written because I don't like the new attitude .. so ner.. Point made ? We can't go around throwing out drivers because the author had a tantrum. Its also trivial to move the decompressor to user space where it should be anyway. Similarly the driver is useful without the binary stuff. Or do we need a -ac tree again where this time -ac is "added camera" ;) Alan
Linux loses the Philips webcam driver Posted Aug 27, 2004 11:49 UTC (Fri) by richo123 (guest, #24309) [Link] There seems to be a puzzling contradiction here which is potentially quite important: Nvidia currently provides a proprietary driver enabling their 3d graphics cards to work. ATI does the same thing. Why cannot Philips do the same thing? Further there obviously must be some interface in the kernel which allows these latter graphics drivers to work- why are the kernel maintainer not ripping this out to force Nvidia and ATI to provide non-closed drivers? Seems to me like both Philips and the kernel maintainers are not talking to each other properly which leaves the ordinary webcam user like myself high and dry! Come on guys get your act together!
Linux loses the Philips webcam driver Posted Aug 27, 2004 13:42 UTC (Fri) by marduk (subscriber, #3831) [Link] Nvidia and ATI's drivers are not in the kernel tree. They are seperate. The GPL enforces this. The PWC driver refuses to maintain it if it's not in the tree. Philips actually has little to to with this AFAIK, they just provided the info to the driver maintainer under an NDA.
So the issue really is that the driver maintainer doesn't want to conform to this standard. And also that the kernel folks probably should have never let this kind of code in the kernel in the first place.
Linux loses the Philips webcam driver Posted Aug 27, 2004 16:12 UTC (Fri) by richo123 (guest, #24309) [Link] OK thanks for the clarification. I still do not understand why the Nvidia model could not have been used by the driver maintainer. Is it really too much work? If it is we should petition Philips to do the right thing. It still sounds to me like there is too much petulance altogether on this matter...and my webcam will not work in the future... not a good situation for an OS with desktop aspirations
Linux loses the Philips webcam driver Posted Aug 28, 2004 22:02 UTC (Sat) by tzafrir (subscriber, #11501) [Link] let's say you suddenly have many oopses on your system. Since you are a decent GNU fellow your system has no propriatary code it. So you start debugging the problem knowing that you have the full source.
Your neighbour, likes the OS you called GNU/Linux not because it is free software, bla, bla bla. He likes Linux cause it's cool. And he knows that he can contact you with any problem. He bought himself a nice Philips webcam in addition to his on-board nvidia display adapter. One of the things he likes to do is displaying the camera's output on the screen in real time. He needs compression for that.
One day his system starts panicing. He calls you. Once you notice that the is not a trivial problem you want to start debugging. So you first need to reproduce the problem in a system without the propriatary drivers (you use the free nv driver, and don't use the webcam). This time it worked. You found the problem.
However it seems that your patch wasn't tested well enough. Your friend suddenly starts getting system hangs. Some signs point to some problems from the direction of the X server. You're called for help once again.
You follow your standard procedure. But this time the problems disappear when the propriatary are removed. Your feeling is that this is an interaction of your fix from yesterday and one of the propriatary drivers. Initial tests point to the NVidia driver.
NVidia is said to have great linux support. And indeed, one day after you send them the bug report they respond. They have tracked it down to a small bug in their code. They were even kind enough to provide you with a test version of the fixed driver.
You install the new driver and it seems that all's well. But suddenly whenever your friend tries to watch the the cammera, his system hangs for a while. A drivers clash again? This time it is between two propriatary drivers. Who can fix the problem? Nobody has the full source: not NVidia and not Philips.
Now suppose that you're not just a helpful geek, but a sysadmin in a network that needs to solve problems fast?
Linux loses the Philips webcam driver Posted Aug 28, 2004 22:42 UTC (Sat) by Ross (subscriber, #4065) [Link] After reading a little more about this, it appears that the driver didfollow the model at one time. But the maintainer found it too difficult to keep up with changes so he changed the driver so that it was partially open as an insulation layer against core kernel changes. NVidia does this too, but the open part of their driver isn't shipped as part of the kernel proper. I don't see an inconsistancy here. I still wonder about the "respecting the author's wishes" part.
Linux loses the Philips webcam driver Posted Aug 27, 2004 13:51 UTC (Fri) by smoogen (subscriber, #97) [Link] I think it is probably because there is a bigger money incentive for Nvidia and ATI to do it than Philips. Every sale matters to Nvidia/ATI and making sure that big government contracts for various visualization tools go through because you have Linux support means a lot to the 2 companies.
For Philips.. they could lose ALL their webcam sales and it would be a drop in the bucket of their bottom line. So there is zero incentive to do anything..
So What Posted Aug 27, 2004 12:51 UTC (Fri) by clugstj (subscriber, #4020) [Link] I'm in a ranting mood...
It's just a video camera driver! Has anyone ever found a worthwhile use for those things anyway?
And another thing:
I feel better now.
So What Posted Aug 27, 2004 13:15 UTC (Fri) by horen (subscriber, #2514) [Link] I'm the owner of a Philips PCVC740K webcam, and I'm sorry that the pwcx portion (and perhaps the pwc part, as well) is going away. I've enjoyed using it during the past few years, but I'll just "bite the bullet" and purchase a newer, less-expensive, better, and better-supported make/model.
It's really not such a big thing: we end-up doing this frequently with a wide variety of items, where models change and/or are discontinued. Yes, it sucks, but Windows XP SP2 sucks much worse. Do the math.
Nomination (was: So What) Posted Aug 27, 2004 15:37 UTC (Fri) by maney (subscriber, #12630) [Link] Yes, it sucks, but Windows XP SP2 sucks much worse. Do the math.+1: best capsule summary of the affair.
Linux driver model Posted Aug 27, 2004 13:55 UTC (Fri) by subhasroy (guest, #325) [Link]
Isn't it possible to make the Linux's driver interface more plugin-friendly?
I think the peripheral device vendors have rights to keep their drivers proprietary and binary. I think the Linux users should be able to enjoy products from such vendors.
If the Linux kernel is designed such that:
I see the device drivers as part of the device rather than part of the kernel. The kernel should avoid including in itself device drivers for every product that the kernel intends to permit the users to use.
Linux driver model Posted Aug 27, 2004 14:09 UTC (Fri) by piman (subscriber, #8957) [Link] Such "generic hooks" can be provided by free kernel space drivers as device files, and then userspace tools can manage those devices.
The problem is not that someone wants to make a binary driver for Linux (this is unfortunately common, and has a slew of other issues, but it's not the problem here). The problem is that someone wants to make a binary driver for Linux, and keep it in the kernel tree, which claims to be free.
Or do you think that Linus shouldn't have the right to say what goes in the tarballs he releases?
Linux driver model Posted Aug 27, 2004 18:05 UTC (Fri) by subhasroy (guest, #325) [Link]
Of course I also believe Linus has right to keep "binary crap" out of his kernel.
I just hope for a good technical solution and I don't know why it should be impossible to come to come up with such a solution.
The vendor-supplied proprietary stuff should make use of the user-space as much as possible. Loading third party binaries to kernel makes it vulnerable to instability.
Linux driver model Posted Aug 28, 2004 11:28 UTC (Sat) by piman (subscriber, #8957) [Link] Well, the one fellow with the technical know-how and specs from Philips has refused to develop the driver anymore. If someone else wanted to pick up the userspace decoding project, they'd have to convince Philips, and also sign another NDA. The first part is often difficult, and few people would agree to the latter.
A good solution would be for owners of the camera to write Philips and ask them to make the specs freely available.
Reverse engineering is an alternative to signing an NDA Posted Aug 29, 2004 12:05 UTC (Sun) by hamjudo (guest, #363) [Link] The existing not quite free drivers discouraged work on a truly free driver. Now that they're out of the way, we can start working on a free driver.It's been done before. In November 5th, 1995 Russell Nelson set up a website and mailing list for reverse engineering another camera that lacked free documentation. Here is the announcement. I remember testing camera code with a baby in my lap. Reverse engineering just the decompressor is a smaller task than reverse engineering the whole camera. I haven't read all the referenced postings yet. Has anyone started on such a project? I can help test, but I'm no project manager.
Linux driver model Posted Aug 28, 2004 3:14 UTC (Sat) by qubes (subscriber, #2562) [Link] Hardware manufatures can fsck them selves if it _requires_ a binary blobto make it work. If that's all the manufature provides I don't buy their hardware. I've got a Nvidia chipset, but only because there is a free GPL'ed version in X; if there wasn't I would have spent my _cash_ on other hardware. At the time, ATI didn't have even 2d support for thier cards; hopefully, even marketing will be able to understand that. Now, I just wish a well read author would write about the dangers using un-peer reviewed source code; much like using junk science (even if junk science is so much quicker to produce.) Thomas
Linux driver model Posted Aug 30, 2004 9:36 UTC (Mon) by raymond (guest, #5200) [Link] I think the kernel should be pure open source. This is essential for it to be high quality and stable.
Still I think we should find a way to promote binary driver. Is it possible to make the kernel a layered structure that we can keep the core open source while at same time make binary driver "compatible" across minor version?
I wish I am more knowledgable before I comment. I always think that only people who know details are suitable to comment. But I really wish that the driver support of Linux could be improved.
Linux driver model Posted Aug 27, 2004 14:54 UTC (Fri) by Los__D (subscriber, #15263) [Link] Hmmmm... I'm not completely sure, but I think that the firmware loading part of hotplug is a little like what you are looking for... Of course it's not completely free of a GPL part (AFAIK, at least Intel's Centrino wireless drivers still has a real kernel module), but it does seperate the binary version from the kernel module...
Dennis
Linux driver model Posted Aug 29, 2004 5:36 UTC (Sun) by mbp (guest, #2737) [Link] > Isn't it possible to make the Linux's driver interface more> plugin-friendly?
It might be technically possible, although it would come at a performance and technical cost: you can no longer update anything that's depended on by binary drivers, even in a source-compatible way. It would also be practically impossible to support a kernel with random binary drivers installed. But it's not primarily a technical decision.
> I think the peripheral device vendors have rights to keep their
That's your opinion. Most of the core kernel developers have the opposite opinion: binary drivers are not something they wish to encourage. See akpm's OLS keynote http://www.groklaw.net/article.php?story=20040802115731932 for example. So, until you do your own kernel, it's not likely to happen.
> The kernel should avoid including in itself device drivers for every
This is also the opposite of the stated policy. It's fine that you think that would be better, but it's not likely to happen.
Linux loses the Philips webcam driver Posted Aug 27, 2004 16:56 UTC (Fri) by pheldens (guest, #19366) [Link] Hmm I've been using this cam now and then over the past years. Too bad the author also wants to pull out the free part of the driver now. The free driver only allowed certain lower resolutions, resolutions sufficient for use with applications like gnome-meeting etc. But if he wants to..The driver also supported cams of other brands.
User space drivers Posted Aug 27, 2004 17:18 UTC (Fri) by simlo (subscriber, #10866) [Link] are needed!Legally you can do whatever you want in user space, no need to be open source there. So if just the kernel will make a nice interface for making drivers (and filesystems, protocols etc.) run in user space we would have a nice compromise: Companies can make closed source drivers for Linux but they will not run as effecient as the open source ones running in the kernel. And not at least: Linux would probably be a lot more stable since drivers have an harder time crashing the whole system.
User space drivers Posted Aug 28, 2004 3:04 UTC (Sat) by rakoch (guest, #4666) [Link] What you are basically saying is that Linux is obsolete ;)-Rudiger
User space drivers Posted Aug 30, 2004 9:03 UTC (Mon) by simlo (subscriber, #10866) [Link] No, I am not. I find the microkernel idea facinating but as far as I see it it has failed completely. Which systems are truely microkernel these days? I have heard that even QNX have pulled some stuff into the kernel space to make it fast enough!I have heard people pressing for the microkernel idea without memory protection, too. There the idea is that each subsystem although they all run within the same memory space has it's own thread. The only way they can communicate is with messages. The reason for this is to enforce a strict decoubling and avoid locks between multiple threads. But it is still not very effective... But I say: We need the "microkernel" ideas for stability and also to get some properitary extensions. What I argue for is that the whole API for making drivers is made available in both kernel and userspace. Then you can start by making drivers in user space where it is easier to debug and reload and once it has proven stable it can be moved to within the kernel. Companies who don't want to GPL their code have to let it stay in user space where it is slow.
Public relations disaster Posted Aug 28, 2004 17:26 UTC (Sat) by simosx (guest, #24338) [Link]
Reading all the mail archives on the issue of the PWC driver, it looks to me as
Instead of defusing the situation, more oil was being spilt on it,
For a person who has been working mostly on his own for four years to get the PWC driver working on Linux looks as a crusade, and I would be able to understand if he feels emotional (even irrational) on aspects of his work.
This URL is very descriptive of the downhill direction:
The author of the PWC driver, in the first e-mail above, makes the "threat" to "withdraw his support" from the PWC driver. However, in the e-mail he makes two points:
I feel the author of the PWC driver has been "forced" to drop the work on his driver.
So, what is going to happen now? Are you going to be able to bring back the original author of the PWC driver after this? This notion that if you write for open-source software makes you expendable is quite discouraging.
DISCLAIMER: I do not know the author of the PWC driver personally so the above is speculation. I only contacted him about 4 years ago to get a borrowed PWC camera to work. He answered promptly to my e-mails and I managed to get the camera working on the development version of Linux at that time. Thanks again.
Public relations disaster Posted Aug 29, 2004 4:02 UTC (Sun) by dvrabel (subscriber, #9500) [Link] You missed the bit where Nemosoft mentions the NDA expired a year ago. He could have open sourced the decompressor.
Public relations disaster Posted Aug 29, 2004 18:21 UTC (Sun) by simosx (guest, #24338) [Link]
Thanks for reminder.
The author of the driver states that there are personal reasons for this decision, which suggests that more information can come out of it. That did not have the chance to come out now.
I hope someone takes the initiative to put the pieces together.
Personal issues? Posted Aug 31, 2004 3:08 UTC (Tue) by nchip (guest, #13292) [Link] It appear, atleast from distance, that Nemosoft had a for long time gottired against the way life of binary-only stuff was constantly made harder. And it didn't help that Greg seems hostile against the driver, marking the driver broken for what Nemosoft felt was a non-issue. Removing the hook was just the last straw. As a Logitech sphere owner, I thank Nemosoft for creating the driver and talking philips to release the documentation to him. You have done your contribution to the open source community, which much more than many of most vocal zealots have done. If maintaining the pwc driver is no longer fun for you, perhaps it is time to do something else for a change. (And eventually return like a hero with philips's permission to open source pwcx ;-) ) But I have to agree with the kernel maintainers standpoint that hooks to support binary-only drivers do not belong to _the_ vanilla kernel. If we make it easy to include binary-only drivers, there will be lot more of them. Maintaining a valid technical reason ( "If we open source it, it will be easier to support, and it will be eventually be supported by all distributions" ) to release Linux drivers as open source is very important. Out of kernel driver modules may be second class citizens, but they work and get included in distributions, unlike the pwc9 approach. It involved patching the kernel and copying a .a to kernel tree and recompiling the whole thing.
Linux loses the Philips webcam driver Posted Aug 31, 2004 6:14 UTC (Tue) by Hurra_asbest (guest, #24400) [Link] A couple of points :1. There appears to be a bit of confusion here as to why the hook for external modules (the binary-only pcwx in practice) was removed. Unlike what people here have claimed the hook in the pwc-modules is NOT a GPL-violation. The GPL doesn't prevent you from writing GPLed software that you can run closed-source binaries on. The hook was removed because it violates a Linux Kernel policy of not including any hook which is solely used for loading non-GPLed modules. Had there been a reverse-engineered GPLed version of the pcwx-module to load it would have been allowed, even though it could still be used to load the binary-only module. The maintainer of pwc has not violated the GPL, only a policy meant to discourage writing closed-source drivers for Linux.
2. As for the people saying that the (binary only) pwcx module is unnecessary for the camera to work, and that this is blown out of proportion; Fact is that these webcams need the provided decompression in order to support images of higher resolutions than 160x120. This resolution is clearly not useful for anything.
As much as I am a follower of free software I can only see this as a situation where everybody loses, not least the users. I was myself looking for a well-supported webcam, and had decided on a Logitech-cam based on the great support given by this driver (with the proprietary part). I'm glad I had not bought it before I saw this. There are very few webcams which are as well supported as this family of affordable cams in Linux, and from the information out there, these would be the obvious choice for most users until a few days ago.
In this case for instance it could be argued that a non-proprietary (maybe reverse-engineered) version of pcwx might be coming at some point or another, and as long as the code in the kernel is fully GPL that the module loading hook could stay in for the sake of the users.
The maintainer of the pcw module on his part could consider changing his module to work the way the proprietary nVIDIA and ATI drivers do. I understand this creates some 'support' issues for him, but at least he would be playing by the kernel-maintainers' rules.
Incidents like this one makes me wonder sometimes if dedication to Free Software will be enough for me to keep using Linux. Personally I don't code, but I try to give my contribution now and again by sending in bug reports or suggesting improvements to software that I use, testing the latest CVS of some of the less critical software I use etc.
Linux loses the Philips webcam driver Posted Sep 19, 2008 10:29 UTC (Fri) by shadowen (guest, #54028) [Link]
This shows a huge flaw in the Linux kernel, that I have noted, and been annoyed with (though I have not been able to find a suitable discussion forum for it), the architecture for drivers is very fluid and dynamic, which is a benefit (for kernel developers) in you can alter the design, but has a huge problem in that there is a lot of work, just maintaining a working driver (not bug fixing the driver but to keep it working with the kernel). I see this problem almost every time a kernel update is released, which for deployment purposes makes it very expensive to do a update on existing systems.
Most drivers for windows are written, bug fixed (to a degree), and then left alone, compare this to linux, I've seen a lot of changes (I use proprietary NVidia drivers, and virtualbox), that when the kernel version changes, it breaks existing drivers.
Not all vendors can release their driver into open source, either because they are licensing parts from other companies, or it contains trade secrets (not that I agree that trade secrets and/or patents are a good idea), but legally these companies cannot create open source drivers.
Looking at it from a company, looking to cut costs, and not allowed to gpl the driver, they look at the market 90% windows, 10% Linux, but resources for maintaining drivers is 1unit for windows, and 9units (over time) for maintaining Linux, because the driver interface is not stable, that is it's not the driver being improved, but just keeping the interfaces working.
So we combine the fact that the driver interface in the kernel continually breaks compiled drivers, and that it is legally impossible for some companies to release full gpl/open source drivers, and you have a hardware support problem, that will not go away, and those producing high volume, low cost items, will avoid doing Linux, due to the cost. Even those wishing to support Linux have problems again due to costs, and legal issues.
The result, all anti-Linux debatteers are right in that the hardware support for Linux is lacking, a lot of things don't work (fortunately a lot of things do work - kudos to those doing the drivers). It is always a non-trivial matter of installing 3rd party linux drivers.
All in All Linux and Open Source looses in this issue, though ideologically I understand the point of keeping everything clean, however pragmatically this is a HUGE stumbling block for the wide spread adoption of for instance, Linux.
If I could find a forum for the discussion, then I would like to bring a discussion about creating a stable 3rd part driver environment. This environment should be flexible, and yet stable, preferably isolated from the kernel, so that instabilities in the 3rd part, doesn't bring the system down.
A good example of such a system is the ndiswrapper project, where quite a few off the shelf windows drivers can be used to run wireless network cards, many of which do not have open source drivers. The funny thing with the ndiswrapper is that with every new kernel version it needs to be recompiled or updated, but the drivers it contains remain functioning and stable.
I'm a very keen supporter of open source and Linux, and it really bugs me to see the community shooting themselves in the foot, and feeding the opposition free points by not considering that 3rd party stuff is necessary. In an ideal world yes pure open source is the way forward, however for now, and the foreseeable future, the world isn't ideal, and such an ideological stance will hurt open source systems more than help it.
However having said that I concur.
In FSF operating system's case the Kernel should only contain pure open source, under whatever license (clean as the kernel developers desire).
However, there should be a well defined, very highly stable 3rd part driver interface available as a part of the kernel, or as a user space driver environment. This would encourage the development of drivers for linux, as the costs involved are NOT ongoing, though they may be proprietory, it would still give the hardware support that is currently lacking.
As to how to force the hardware developers to release their information to a gpl driver, that is another matter, currently No FSF operating system has the momentum to force the issue.
Linux loses the Philips webcam driver Posted Sep 19, 2008 10:58 UTC (Fri) by kragil (guest, #34373) [Link]
Wow .. I haven't read the stuff you wrote and I guess nobody will read it because it is a comment on the bottom of 4 years old article.
But I am interested why did you write it?
Linux loses the Philips webcam driver Posted Sep 19, 2008 13:50 UTC (Fri) by shadowen (guest, #54028) [Link]
Because I'm looking forum for it.. figured this might be one.
Linux loses the Philips webcam driver Posted Sep 19, 2008 13:52 UTC (Fri) by shadowen (guest, #54028) [Link]
and someone did notice it :-)
Linux loses the Philips webcam driver Posted Sep 19, 2008 15:51 UTC (Fri) by nix (subscriber, #2304) [Link] However, there should be a well defined, very highly stable 3rd part driver interface available as a part of the kernelI can say with 100% certainty that there is no chance of this ever happening. The problem is that the invariants that drivers must maintain change over time, and many of those invariants *cannot* be ignored. e.g. the recent BKL-elimination changes have required modifications to a whole pile of drivers, first pushing the BKL down into e.g. their ioctl functions and then purging them from there and replacing them with better locking if necessary. If the invariant `ioctl() takes the BKL' was wired into some 'very highly stable interface', then a) we wouldn't be able to push the BKL down into the individual ioctl() functions and b) we wouldn't be able to eliminate it from there. Another example of a pervasive change is suspend/resume support. If a driver is to be useful with suspend/resume, it needs changes: but if your interface is frozen then it can't change. Your requirement pretty much means that evolution of the kernel would have to stop. No thanks.
|
|||||||||||