Linux loses the Philips webcam driver
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.
Posted Aug 27, 2004 15:51 UTC (Fri)
by Duncan (guest, #6647)
[Link] (1 responses)
Posted Aug 27, 2004 17:52 UTC (Fri)
by erich (guest, #7127)
[Link]
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.
Posted Aug 27, 2004 15:53 UTC (Fri)
by vblum (guest, #1151)
[Link]
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 ...
Posted Aug 27, 2004 15:59 UTC (Fri)
by marduk (subscriber, #3831)
[Link] (14 responses)
* 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.
Posted Aug 27, 2004 17:58 UTC (Fri)
by ncm (guest, #165)
[Link] (13 responses)
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.
Posted Aug 27, 2004 18:49 UTC (Fri)
by xav (guest, #18536)
[Link] (11 responses)
Posted Aug 27, 2004 19:03 UTC (Fri)
by ncm (guest, #165)
[Link] (2 responses)
Posted Aug 27, 2004 19:23 UTC (Fri)
by marduk (subscriber, #3831)
[Link]
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).
Posted Aug 31, 2004 7:58 UTC (Tue)
by bignose (subscriber, #40)
[Link]
No, the GPL code is still available to all under the GPL. We lost only the current maintainer.
Posted Aug 28, 2004 0:06 UTC (Sat)
by emkey (guest, #144)
[Link] (5 responses)
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.
Posted Aug 28, 2004 7:23 UTC (Sat)
by xav (guest, #18536)
[Link] (2 responses)
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.
Posted Aug 31, 2004 20:12 UTC (Tue)
by emkey (guest, #144)
[Link] (1 responses)
And no, I don't consider MacOS an alternative. Posted Aug 29, 2004 17:09 UTC (Sun)
by ncm (guest, #165)
[Link] (1 responses)
Posted Aug 31, 2004 20:13 UTC (Tue)
by emkey (guest, #144)
[Link]
Personally I prefer to look out for my own interests. Something I'm 100% capable of doing by the way.
Posted Aug 28, 2004 15:11 UTC (Sat)
by _shadow (guest, #24330)
[Link] (1 responses)
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?
Posted Aug 29, 2004 3:28 UTC (Sun)
by tzafrir (subscriber, #11501)
[Link]
Posted Aug 28, 2004 6:28 UTC (Sat)
by tincat2 (guest, #24322)
[Link]
Posted Aug 27, 2004 16:30 UTC (Fri)
by neoprene (guest, #8520)
[Link] (1 responses)
Posted Aug 27, 2004 16:34 UTC (Fri)
by corbet (editor, #1)
[Link]
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.
Posted Aug 27, 2004 16:34 UTC (Fri)
by rfunk (subscriber, #4054)
[Link] (6 responses)
Posted Aug 27, 2004 16:37 UTC (Fri)
by TimCunningham (guest, #10316)
[Link]
Posted Aug 27, 2004 19:46 UTC (Fri)
by lucat (guest, #15102)
[Link] (4 responses)
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,
Posted Aug 27, 2004 20:01 UTC (Fri)
by wcooley (guest, #1233)
[Link] (3 responses)
Posted Aug 27, 2004 20:12 UTC (Fri)
by lucat (guest, #15102)
[Link] (2 responses)
It looks like a demand to me.
Bye,
Posted Aug 27, 2004 20:19 UTC (Fri)
by lucat (guest, #15102)
[Link] (1 responses)
Bye,
Posted Aug 30, 2004 3:58 UTC (Mon)
by xoddam (subscriber, #2322)
[Link]
Posted Aug 27, 2004 16:40 UTC (Fri)
by gregkh (subscriber, #8)
[Link] (3 responses)
greg k-h
Posted Aug 27, 2004 19:04 UTC (Fri)
by kh (guest, #19413)
[Link]
Posted Aug 30, 2004 3:54 UTC (Mon)
by penfold (guest, #21150)
[Link] (1 responses)
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.
Posted Aug 30, 2004 7: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.
Posted Aug 27, 2004 16:44 UTC (Fri)
by QuisUtDeus (guest, #14854)
[Link] (1 responses)
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.
Posted Aug 27, 2004 16:56 UTC (Fri)
by raymond (guest, #5200)
[Link] (4 responses)
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.
Posted Aug 27, 2004 19:55 UTC (Fri)
by smoogen (subscriber, #97)
[Link]
Posted Aug 30, 2004 8:58 UTC (Mon)
by tyhik (guest, #14747)
[Link] (2 responses)
Which is producing worse user experience/publicity - preventing some
Posted Aug 31, 2004 0:09 UTC (Tue)
by raymond (guest, #5200)
[Link] (1 responses)
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?
Posted Aug 31, 2004 7:36 UTC (Tue)
by tyhik (guest, #14747)
[Link]
Linus has explicitly declared that the in-kernel
You know how many mandrake users have blamed mandrake recently
Posted Aug 27, 2004 17:15 UTC (Fri)
by iabervon (subscriber, #722)
[Link] (5 responses)
Ironically, this position was recently expressed by Alan Cox in an unrelated thread about using floating point in the kernel.
Posted Aug 27, 2004 17:40 UTC (Fri)
by ncm (guest, #165)
[Link] (4 responses)
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.
Posted Aug 29, 2004 1:47 UTC (Sun)
by lutchann (subscriber, #8872)
[Link]
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.
Posted Aug 29, 2004 21:46 UTC (Sun)
by jjs (guest, #10315)
[Link] (2 responses)
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/2017...
Posted Aug 30, 2004 13:21 UTC (Mon)
by primorec (guest, #2740)
[Link]
Posted Aug 30, 2004 19:08 UTC (Mon)
by ncm (guest, #165)
[Link]
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.
Posted Aug 27, 2004 17:15 UTC (Fri)
by jwb (guest, #15467)
[Link] (4 responses)
I'd much rather have a barely-working quickcam than a useless quickcam.
Posted Aug 27, 2004 18:02 UTC (Fri)
by erich (guest, #7127)
[Link] (3 responses)
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)
Posted Aug 27, 2004 19:06 UTC (Fri)
by ncm (guest, #165)
[Link]
Posted Aug 27, 2004 19:28 UTC (Fri)
by Ross (guest, #4065)
[Link] (1 responses)
Posted Aug 31, 2004 17:05 UTC (Tue)
by Ross (guest, #4065)
[Link]
http://kerneltrap.org /node/view/3747?PHPSESSID= ec07d8bff92b1faf36bdc14451a40476
Posted Aug 27, 2004 17:49 UTC (Fri)
by richo123 (guest, #24309)
[Link] (5 responses)
Posted Aug 27, 2004 19:42 UTC (Fri)
by marduk (subscriber, #3831)
[Link] (3 responses)
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.
Posted Aug 27, 2004 22:12 UTC (Fri)
by richo123 (guest, #24309)
[Link] (2 responses)
Posted Aug 29, 2004 4:02 UTC (Sun)
by tzafrir (subscriber, #11501)
[Link]
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?
Posted Aug 29, 2004 4:42 UTC (Sun)
by Ross (guest, #4065)
[Link]
Posted Aug 27, 2004 19:51 UTC (Fri)
by smoogen (subscriber, #97)
[Link]
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..
Posted Aug 27, 2004 18:51 UTC (Fri)
by clugstj (subscriber, #4020)
[Link] (2 responses)
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.
Posted Aug 27, 2004 19:15 UTC (Fri)
by horen (guest, #2514)
[Link] (1 responses)
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.
Posted Aug 27, 2004 21:37 UTC (Fri)
by maney (subscriber, #12630)
[Link]
+1: best capsule summary of the affair.
Posted Aug 27, 2004 19:55 UTC (Fri)
by subhasroy (guest, #325)
[Link] (8 responses)
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.
Posted Aug 27, 2004 20:09 UTC (Fri)
by piman (guest, #8957)
[Link] (5 responses)
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?
Posted Aug 28, 2004 0:05 UTC (Sat)
by subhasroy (guest, #325)
[Link] (2 responses)
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.
Posted Aug 28, 2004 17:28 UTC (Sat)
by piman (guest, #8957)
[Link] (1 responses)
A good solution would be for owners of the camera to write Philips and ask them to make the specs freely available.
Posted Aug 29, 2004 18:05 UTC (Sun)
by hamjudo (guest, #363)
[Link]
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.
Posted Aug 28, 2004 9:14 UTC (Sat)
by qubes (guest, #2562)
[Link]
Posted Aug 30, 2004 15:36 UTC (Mon)
by raymond (guest, #5200)
[Link]
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.
Posted Aug 27, 2004 20:54 UTC (Fri)
by Los__D (guest, #15263)
[Link]
Dennis
Posted Aug 29, 2004 11:36 UTC (Sun)
by mbp (subscriber, #2737)
[Link]
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://web.archive.org/web/20190809094732/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.
Posted Aug 27, 2004 22:56 UTC (Fri)
by pheldens (guest, #19366)
[Link]
Posted Aug 27, 2004 23:18 UTC (Fri)
by simlo (guest, #10866)
[Link] (3 responses)
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.
Posted Aug 28, 2004 9:04 UTC (Sat)
by rakoch (guest, #4666)
[Link] (1 responses)
Posted Aug 30, 2004 15:03 UTC (Mon)
by simlo (guest, #10866)
[Link]
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.
Posted Aug 28, 2004 23:26 UTC (Sat)
by simosx (guest, #24338)
[Link] (2 responses)
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.
Posted Aug 29, 2004 10:02 UTC (Sun)
by dvrabel (subscriber, #9500)
[Link] (1 responses)
Posted Aug 30, 2004 0:21 UTC (Mon)
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.
Posted Aug 31, 2004 9:08 UTC (Tue)
by nchip (guest, #13292)
[Link]
Posted Aug 31, 2004 12:14 UTC (Tue)
by Hurra_asbest (guest, #24400)
[Link]
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.
Posted Sep 19, 2008 16:29 UTC (Fri)
by shadowen (guest, #54028)
[Link] (4 responses)
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.
Posted Sep 19, 2008 16:58 UTC (Fri)
by kragil (guest, #34373)
[Link] (2 responses)
But I am interested why did you write it?
Posted Sep 19, 2008 19:50 UTC (Fri)
by shadowen (guest, #54028)
[Link]
Posted Sep 19, 2008 19:52 UTC (Fri)
by shadowen (guest, #54028)
[Link]
Posted Sep 19, 2008 21:51 UTC (Fri)
by nix (subscriber, #2304)
[Link]
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.
Wow. I'm no friend of proprietaryware and certainly back the kernel folks Linux loses the Phillipswebcam driver
on 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 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.The GPL driver lacks features
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.Linux loses the Phillips webcam driver
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):Linux loses the Phillips webcam driver
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.
Let's not try to sweeten it
Well, could you explain how loosing a binary-only driver is a loss for Free Software ?Let's not try to sweeten it
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
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.Let's not try to sweeten it
> We didn't just lose the binary driver, we lost the whole thing, and theLet's not try to sweeten it
> maintainer besides.
Its a loss to Free Software because its one more bit of functionality lost over a largely pointless idiological point.Let's not try to sweeten it
Then, really, use something like MacOS X, it is exactely what you want.Let's not try to sweeten it
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.
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.Let's not try to sweeten it
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
Gee, thanks for caring... Let's not try to sweeten it
How do we loose? Let's not try to sweeten it
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
i've got to agree with you-seems like something could have been Let's not try to sweeten it
worked 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.
its Philips not Phillips. [pronounced feel-lips]Linux loses the Phillips webcam driver
My error, fixed.
Typo fixed
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
Thanks, I was looking for this.More conversation links
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.More conversation links
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.
Luca
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
> In case the answer is "No", then I will:More conversation links
> - demand that the PWC driver is removed from any further Linux kernel
> releases; Open source or not, it"s still _my_ work.
Greg did the right thing removing it, but this doesn't change the fact that the author of the driver CANNOT demand it to be removed. He can _ASK_ for it to be removed, but that's all he can do.
Luca
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).More conversation links
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.
Luca
The GPL is not a contract, it's a license to copy. More conversation links
Please see http://thread.gmane.org/gmane.linux.kernel/230136 for myLinux loses the Philips webcam driver
answers on this issue.
Thank you for your efforts to keep the kernel Free.Linux loses the Philips webcam driver
I am not a developer, nor have I studied the driver's code, so please forgive me if this is a stupid question.Linux loses the Philips webcam driver
Linux loses the Philips webcam driver
1. Create working open-sorce decompressor (reverse-engeener it or something).
2. Push decompressor into userspace.
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.Linux loses the Philips webcam driver
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.Linux loses the Phillips webcam driver
In ancient China, there is a wisdom that a country should employ smart foreigners in the government. Some locals are afriad that foreigners would pretend to be loyal yet do some harmful things. But as you may have guessed, the history tell us that those countries which employ elites from all over the world, gain prosperity.
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
"However, my humble opinion is that we should not discourage any thing that support Linux (or open source software)."Linux loses the Phillips webcam driver
people migrating to linux because some hardware is not
supported or forsing somebody to move off from linux, because
the maintainer stops supporting or removes his binary-only
support? You remember what triggered this thread here and elsewhere?
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.Linux loses the Phillips webcam driver
Open source can win only if it evolves. The problem withLinux loses the Phillips webcam driver
the 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.
interfaces won't be immutable. In the long
run this is a very right decision. Companies come and go,
their attitude to open source may change and then change again,
but the kernel must move on.
because they were not able to get their nvidia kickass 3d cards
working without recompiling the kernel. The real problem was
that while mandrake enabled
4kB stacks option in the kernel as thousands of inkernel drivers could
happily work with 4k stacks, nvidia was not able to
port their driver to comply with 4k stack requirement for about 5
months. Kernel evolves
and drivers must follow. Unmaintained open source drivers are bad, but
simple changes to them can be made even by people, who are not
overly familiar with the code. Unmaintained (or poorly maintained)
binary drivers are far worse,
as they can generate lot of bad linux experience, while
being fixable only by the author.
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.Linux loses the Philips webcam driver
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?
Compressed? Fine.
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.Compressed? Fine.
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.Compressed? Fine.
http://www.smcc.demon.nl/webcam/Author's voice
It sounds like Nemosoft still hasn't figured out what happened, and is blaming the Linux kernel maintainers.
Still clueless
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?Linux loses the Philips webcam driver
You do.Linux loses the Philips webcam driver
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.
Jeopardy response: "What is a named pipe?"Linux loses the Philips webcam driver
That doesn't agree with Linus' statement about respecting the wishes of theLinux loses the Philips webcam driver
author. I some dissonance between all these statements.
From KernelTrap:It seems someone agrees
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
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
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.Linux loses the Philips webcam driver
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 aspirationsLinux loses the Philips webcam driver
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.Linux loses the Philips webcam driver
After reading a little more about this, it appears that the driver didLinux loses the Philips webcam driver
follow 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.
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.Linux loses the Philips webcam driver
I'm in a ranting mood...So What
Who's the brain-drain who first called these things "webcam"'s? What's the "Web" got to do with it? It's a video camera attached to a computer - nothing more.
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. So What
Yes, it sucks, but Windows XP SP2 sucks much worse. Do the math.
Nomination (was: So What)
Linux driver model
- no per-product hook is required
- highly generic but rich hooks (API) are provided
- binaries containing proprietary device drivers can make use
of the hooks and make effective functioning of the devices possible.
Such "generic hooks" can be provided by free kernel space drivers as device files, and then userspace tools can manage those devices.Linux driver model
Linux driver model
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.Linux driver model
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.
Reverse engineering is an alternative to signing an NDA
Hardware manufatures can fsck them selves if it _requires_ a binary blob Linux driver model
to 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
I think the kernel should be pure open source. This is essential for it to be high quality and stable.Linux driver model
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...Linux driver model
> Isn't it possible to make the Linux's driver interface more Linux driver model
> plugin-friendly?
> drivers proprietary and binary.
> product that the kernel intends to permit the users to use.
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..Linux loses the Philips webcam driver
The driver also supported cams of other brands.
are needed! User space drivers
What you are basically saying is that Linux is obsolete ;)
User space drivers
-Rudiger
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!User space drivers
Public relations disaster
another public relations disaster has just been unfolded.
any bridges have been burnt down.
http://sourceforge.net/mailarchive/message.php?msg_id=932...
- His driver will not be able to work anymore and he cannot see another way it will work without the hook. He feels this puts his work and efforts of four years in peril.
- He feels he does not get the appropriate recognition for his work.
For both points, he says "But if you (kernel peeps) show contempt for all the work that I have done, then I'm not going to help you anymore, with Linux."
You missed the bit where Nemosoft mentions the NDA expired a year ago. He could have open sourced the decompressor.Public relations disaster
Public relations disaster
It appear, atleast from distance, that Nemosoft had a for long time got Personal issues?
tired 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.
A couple of points :Linux loses the Philips webcam driver
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.
It shows how crippled the driver is without the proprietary part. I can understand that the maintainer could see it as completely destroying his work. Still, withdrawing the GPLed part of the driver from the kernel completely seems a bit like an overreaction.
There is a definite gap between the coders responsible for kernel developement and end-users. One should push for open-source hardware drivers for the many good reasons mentioned in this thread. Still, this case makes me wonder if the kernel maintainers shouldn't losen their policies just a little bit in some cases.
Mostly I use my computer to do a hundred more or less normal things that I expect are the same things that most users do. I feel fortunate that I can actually do those things in Linux, and I am smart enough to know where and how to check for compatibility before I purchase new hardware.
But as I said, there are a hundred things I use my PC for, and some of these are very important to me. If I was an owner of one of these webcams now I would probably be quite disappointed with Linux right now.
This doesn't just hurt the users, it hurts Linux as well.
Linux loses the Philips webcam driver
Linux loses the Philips webcam driver
Nobody will ever see it.
Linux loses the Philips webcam driver
Linux loses the Philips webcam driver
Linux loses the Philips webcam driver
However, there should be a well defined, very highly stable 3rd part
driver interface available as a part of the kernel
I 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.