Kernel Maintainer Kills Philips USB Camera Support 206
outanowhere writes "The author of the Philips webcams kernel module has thrown in the towel and quit providing the pwc and pwcx kernel modules which make using Philips-based USB cameras such as those from Logitech and Philips possible with Linux.
According to the author, the last straw was when a kernel maintainer changed his pwc module to make using the binary-only pwcx compression module impossible.
It is a victory for obsessive kernel-purists but a major loss for all Linux users."
By the way (Score:4, Insightful)
Re:By the way (Score:5, Insightful)
For all of you who wonder what we mean when we say "zealots make it hard for businesses to take F/OSS seriously", this is what we mean.
Nope. This is eating own dogfood, having a stance and keeping it. Businesses can be sure that there's no fucking around rules of linux development. It's either playing by the rules or not playing at all.
Re:By the way (Score:3, Insightful)
Um, whose rules?
If open source is about choice, I've just lost the choice to use both Phillips-based webcams and linux. Now my choice is one or the other.
But if by "rules" you mean that the linux developers are making me -- and many others -- bear the costs of the developers' ideological fights, then say
Re:By the way (Score:5, Insightful)
It is about choice. You can choose to put the USB hook back and maintain the Philips webcam driver indefinitely in a separate kernel tree. The current kernel developers have the choice to drop that USB hook and tell the Philips webcam guy to find another way. The Philips webcam guy has the choice to reimplement the Philips webcam driver in userspace using libusb. Though as it is, he chose to have a hissy fit. His choice.
The mistake you've made is in thinking that "choice" is equivalent to "kernel developers give you all the options and you just choose a precanned solution from a checklist". That's not how it works. Get off your lazy butt and make things happen. Stop complaining that the kernel developers aren't doing things the way you want them to be done. That's their choice to make, not yours. Exercise your freedom of choice but don't expect others to do the work for you.
Re:By the way (Score:4, Insightful)
Ain't freedom grand? As with most things in life, freedom is only available to the elite few that possess enough understanding to be free in the first place. I understand that I'm free to fork the source, but if I lack the knowledge necessary to hack on the kernel what good is it to me to fork?
Re:By the way (Score:5, Interesting)
For several reasons, user land was not a viable option. The elitist control freak running the show wouldn't let our code in. Consequently, we lost some good free advertising, and possibly some customers in order to feed the ego of some guy bent on denying anything he thought could go through user land instead.
We ended up just putting the source on our web site. Several customers already use it very successfully. But none the less, we were blocked from contributing while trying to uphold the spirit and ideals of OSS. I can only imagine how much the poor sap from Philips was being jerked around.
That being said, Linux was a stroll through a grassy meadow compared to trying to go through WHQL testing for M$.
Re:By the way (Score:2)
Re:By the way (Score:3, Interesting)
I find it hard to swallow just one side of the story. (Score:4, Interesting)?!?! It is all to easy to just spout off with your opinion about an "elitist control freak" with out providing something to back up yor claims. Are there emails in LKML that you can back your assertions up with? What is your software driver package for, and do you have a URL for the download? Who is the control freak?
I'm much more willing to give your point
Re:By the way (Score:2, Interesting)
I'll not give you any information that could be traced back to me or my company, but take a moment to think on the way in which new drivers are scrutinized. They must have the Linux standard formatting, which at least I find quite odd. If the driver does not behave like other drivers in its class then you'll likely be rejected by default and have to claw your way in. Which is simil
Re:By the way (Score:3, Informative)
This is simply because your code needs to be
readable to everybody, and everybody is used to
the standard style.
Often, somebody will go through the Linux source
code making fixes to hundreds of drivers. Such a
person can work much faster if all the code uses
the same style.
Fix the style, then post to linux-kernel with
copies to Linus and Andrew Morton. Repeat as
needed, fixing up any objections you get.
Problems with open source kernels (Score:3, Interesting)
I *do* realize that this could cause major problems if there are internal reasons for using a particular style or -- God forbid
Comment removed (Score:5, Insightful)
Re:By the way (Score:2, Insightful)
I'll explain.
The GPL, under which the Linux kernel is released, is about using the idea of copyright to restrict one thing that copyright has traditionally been used for: controlling what others do with the work.
In a sense, the GPL and "Free Software" are about restrictions. The whole idea is to restrict the copyright-holders ability to control what others do with the work.
On a certain level,
Re:By the way (Score:5, Insightful)
Now, someone ported a binary driver to linux. Very nice from this guy, but in the long run this will hurt linux (AND linux users). Manufacturers are just weighing what's the penalty and the profit for bringing out a driver (binary or source), no driver or support somenone who writes a driver (binary or source). Now, if the use of binary drivers is discouraged, there will be more source drivers becoming available (but less drivers, some manufacturers are not willing to open their source). However in the long run (and linux marketshare will help) manufacturers have to support linux. The more other manufacturers have open source drivers, the less trouble they have doing the same.
Of course you can say all things about manufacturers 'not being able to open' (nvidia binary drivers cannot be opened, because of rules, etc.), but that is just not true. Nvidia has no advantage of opening their secrets (yes, their competitors will take advantage of this) and therefore they are not doing it (they lose perhaps a handfull of users). A perfect business decision in the light of most linux users using a binary driver. However if ATI IS providing (this is an example) the source, Nvidia has to look different to the situation, especially if, say 20% of the users uses ATI because of this and if ATI is also 'giving up' their secrets.
All this is just negotiation in the end and we should not give up already and accept binary drivers. That is just like a salesman selling televisions for 1 dollar, because that is bidded first.
No, i am not obsessed, just differently minded (and not native, sorry for my language).
Re:By the way (Score:4, Insightful)
Do you have any evidence that this is the case, or is this just pure speculation?
This is wholly fallacious. There is nothing to suggest that by blocking binary-only development, more source will become available. This is a pipe-dream of the F/OSS utopia.
Again, fallacious; again, a pipe-dream of the F/OSS community.
Do you have any evidence that this is the case?
You ought to have stopped after the first sentence. There is no monetary advantage to opening source or revealing trade secrets: the software industry isn't high school. If Janie (i.e. ATI) is smoking the marijuana (opens the source to its drivers), it doesn't mean it's okay for Bobby (nVidia) to do the same; it just means Janie (ATI) is foolish.
As several people have said, the consumer cares about what "just works". They don't care about software ideals, as evidenced by Microsoft's 95% market share. The software industry is inherently capitalistic, and will follow the money. If the consumer wants something that just works, and the F/OSS community isn't going to give it to them, they are going to pay money for it. This is where you will find the software industry: not out trying to "play by the F/OSS rules".
Re:By the way (Score:5, Insightful)
There is nothing to suggest that by blocking binary-only development, more source will become available. This is a pipe-dream of the F/OSS utopia.
No, it is just common sense. The push on, say Nvidia, to open their source is larger if binary drivers are not possible. Two things are important in this situation, marketshare and large customers. Large customers can perhaps (now under NDA) already get the source, lose of market share (if net loss of opening drivers is smaller than loss of profit by a smaller share in market they will just open of course).
However I tend to agree with you that when all binary drivers are forbidden and the manufacturers are offered a choice, leave the linux market or open their code, much much more will choose the first. That is because the business situation is like this at the moment. But some will not. (for example the NIC company specialized in linux clustering etc.).
If Janie (i.e. ATI) is smoking the marijuana (opens the source to its drivers), it doesn't mean it's okay for Bobby (nVidia) to do the same; it just means Janie (ATI) is foolish.
Companies are sometimes behaving more emotional than factual. For example if some major top 500 companies buy Linux licenses from SCO, a lot will follow. Their bosses will say, 'hey if BMW buys a license we have to do that also, because they have good lawyers'. Without even checking theirselves. This happens a lot (too much).
Re:By the way (Score:3, Insightful)
To reply to myself: I just thought of a better example to show this stuff DOES happen. Just look at the support list of the ALSA project (http://www.alsa-project.org/alsa-doc). They have a history of strongly discouraging binary drivers and it pays of. Yes, some manufacturers are unwilling to open, but a lot fall for the argument,
Re:By the way (Score:2)
since the heaviest pot smoker I ever met was a
driver developer for ATI. I never met Carl Sagan.
Re:By the way (Score:2)
Oop! I'm sorry, that was your credibility that just went down the drain. Here's a tip: if you want people to listen to what you have to say, don't insult your target audience.
It doesn't matter any more what points you're trying to make. You've just prejudiced your reader against you. This is great if you want an argument, but not so sensible if you actually want to get your point across...
Re:By the way (Score:2)
Re:By the way (Score:2)
Not so. Capitalism states anything you give away for free has no value. Far more enlightened people than me are STILL speculating on the nature of the software industry. It seems to me quite obvious the the success of Open Source software shows that software does not follow the rules of capitlism. I am tired of hearing what seem to be intelligent people on slashdot bolding predicting the future. I am reminded of the old chinese sa
Re:By the way (Score:3, Interesting)
You ought to have stopped after the first sentence. There is no monetary advantage to opening source or revealing trade secrets: the software industry isn't high school. If Janie (i.e. ATI) is smoking the marijuana (opens the source to its drivers), it doesn't mean it's okay for Bobby (nVidia) to do the same; it just means Janie (ATI) is foolish.
Actually, the opposite is quickly becoming true.
It all depends on what kind of systems you're using your hardware with. True, I can't see a Fortune 500 compa
Re:By the way (Score:4, Insightful)
There is no monetary advantage to opening source or revealing trade secrets.
Sure there is. I buy only hardware that is supported by open source drivers. Philips, Nvidia, and ATI are in the hardware business. If they want to sell hardware to people like me, they'll have to supply the docs. I'm not asking them to supply drivers, although that would be nice. I'm asking them to make the docs available, so that others can write drivers.
The Philips case is especially absurd. I'm prepared to believe that ATI and Nvidia have stuff in their drivers that gives them a competitive advantage. But some dinky little compressor? Give me a break. I bet it's only proprietary because it's some crappy little algortithm that it would embarass them to release.
Re:By the way (Score:2)
The last graphics card I purchased was a Radeon 9100. It will remain that was as long as there is is no Free Software driver for a more powerful graphics card.
Correction on your sig (Score:2)
A government big enough to give you everything you want is a government big enough to take from you everything you have.
It was made by Gerald Ford.
http://www.brainyquote.com/quotes/quotes/g/gera
Re:By the way (Score:2, Interesting)
Re:By the way (Score:2)
No, this example works. They cannot open the drivers they currently have, because there is IP from others in it. That is true. But if they have business incentive (more cards sold etc.) to open their drivers, they can rewrite the protected IP part with a different algorithm.
In the Nvidia case th
Re:By the way (Score:2)
Phillips has likely licenced the technology from another vendor who is unwilling to change the terms. The fact that they were willing to provide access to the code under NDA at little or no cost displays their good intentions.
If the Linux kernel team is going to fuck with binary code in the kernel, then alot of other devices are going to be broken.
Re:By the way (Score:2)
Now are you seriously going to tell me (and millions of other users) that because the purists want it this way that we can't install a version of Linux on a laptop without net access w/o first hacking together a custom kernel?!? wtf?!?
I read an article on
Re:By the way (Score:2)
I read an article on /. not too long ago that talked about the great lenghts Microsoft programmers went through to make sure that future versions of Windows were compatible with previous releases of software already in the wild - this is exactly why they have over 90 percent marketshare and 50 billion in the bank.
If backwards compatability was the main reason for MicroSofts success, then NetBSD would give them a run for their money. NetBSD is backwards compatible with previous releases all the way to 4.3
Re:By the way (Score:2)
When you are competing on price in a commodity market, you make your profit on the last 10% of the sales. The difference between a 90% target market and a 99% target is the difference between success and bankruptcy.
The only reasons any vendor of consumer-level mass sales hardware gets away with not documenting their interfaces are (1) lack of competition in an early-adoption market or (2) lack of c
"but a major loss for all Linux users." (Score:4, Insightful)
Itt's not like everyone in the world own a Philips USB camera.
Yes, yes. I know what's the point. Making it harder to include binary carbage in the kernel makes it harder to provide modules for proprietary hardware solutions.
But in the long run, do you want to have third party binary carbage in YOUR KERNEL?
No way to check out what's in there. Except perhaps reverse engineering, which isn't an option to everyone. Programming is hard. Reverse engineering is harder.
Re:"but a major loss for all Linux users." (Score:2, Insightful)
I think you are missing the point. Not every user cares what is in their kernel, much the same was as Windows users don't. They just want stuff to work.
Re:"but a major loss for all Linux users." (Score:4, Funny)
I think you are missing the point. Not every user cares what is in their kernel, much the same was as Windows users don't. They just want stuff to work.
And you're missing the 'provider' point. If Linux kernel maintainer isn't willing to provide binary module hooks into kernel, then it's his right to refuse having them.
This module could walk around this rule by having same system as nVidia kernel driver, but no, they come to slashdot, bitch and moan.
Re:"but a major loss for all Linux users." (Score:3, Insightful)
True, but this is short-sighted. The binary drivers WILL give problems in the long run for the users. (Microsoft knows this, windows is unstable with unstable drivers, therefore they emphasize a lot on signing of the drivers by Microsoft!)
It remembers me of the feauture bloat of win95-win200 path. The users wanted these feautures (being able to do all kind of things) and didn't care about the security impact. Microsoft
Re:"but a major loss for all Linux users." (Score:3, Interesting)
I almost threw my laptop out the window years ago when I installed Suse and couldn't figure out for the life of me why I couldn't get the damn WiFi interface to work.
When I discovered that it was because my laptop had an built-in wifi card that had a binary only driver (and I had to jump through hoops to install 3rd party support for it) I instantly just wiped Suse out an
Re:"but a major loss for all Linux users." (Score:2, Insightful)
You have to put your money where your mouth is. If you want a linux laptop, you GET a linux laptop. You don't bitch that your Windows-only laptop doesn't run linux.
This way there is a monetary incentive for these companies to support linux & the GPL.
Re:"but a major loss for all Linux users." (Score:2)
Do you only use WQHL drivers? Not many people I know do, particularly with video drivers. I have heard support techs tell people to upgrade to the latest drivers. I've heard them tell people to upgrade to the latest beta (!) drivers. I've never heard one tell a customer
Comment removed (Score:5, Insightful)
Re:"but a major loss for all Linux users." (Score:3, Insightful)
True. Not every users cares. However in Linux land it's the kernel developers who make all the decisions. So what the kernel developers care about is all that matters. The most influential kernel developers (eg, Linus, Alan) have been consistent in their stance that they will not go out of their way to support binary modules. If a binary module breaks
Re:"but a major loss for all Linux users." (Score:4, Insightful)
Forward to the past!
Yes, binary only modules are unacceptable in principle. Unfortunately unless you want to head back the days when most hardware wouldn't work under Linux they are a necessary evil.
Of course the zealots who want pure open-source will eventually have to face the fact that some companies will never open-source anything or live in eternal denial.
Re:"but a major loss for all Linux users." (Score:4, Insightful)
A binary driver means planned obsolescence for your hardware as soon as the manufacturer loses interest.
Oh, I'm sure you simply dump your machines yearly and get a new one, but those old clunkers are not defective in any way - or wouldn't be, if their driver came with source that we could update. There's your ecological argument for open source.
Re:"but a major loss for all Linux users." (Score:5, Insightful)
If you don't want third-party binary carbage in your kernel, well, you don't load the module that contains it.
People want their stuff to work. If they need to load a binary module to get their stuff to work, then they'll generally do that, zealots be damned.
Re:"but a major loss for all Linux users." (Score:2)
Yes. I use a Phillips based camera. Now I will no longer be able to do so from Linux, and you're trying like hell to tell me this is Good(TM) for me.
Re:"but a major loss for all Linux users." (Score:4, Interesting)
The kernel does support firmware. In fact, there has been significant effort recently to standardise the way that firmware is loaded to hardware by the kernel. The kernel developers don't seem to have a problem with firmware. Their beef is with binary drivers that run in the same address space as the rest of the kernel. I can see the kernel developer's point of view: they don't want to waste their time debugging around binary drivers.
Hopefuly the nvidia drivers. As much as I like the nvidia company - they have some of the best minds in the business, they are good contributors to the state of the art, they pump significant money into R&D, and they play (mostly) nicely with the standards bodies - their binary drivers are retarding the future of Linux. If the nvidia binary drivers stopped working tomorrow then we'd hear the howls from millions of Linux users, but after the howling stopped there would be some real progress on pushing DRM and Xorg DDX forwards.
Re:"but a major loss for all Linux users." (Score:4, Interesting)
Many (actually, all) of the Wireless LAN cards on Linux require a binary driver. There is a reason for this: A Wireless Lan Card is a radio transmitting device and falls under FCC rules.
The FCC has regulations about not allowing end users to change some of the parameters (which the chipset may allow) and therefore is pretty much ILLEGAL to have a source code driver for these cards because they are regulated devices.
For instance, some of the chips allow you to jack up the power beyond what the FCC allows. Which the binary driver does not, which is why the FCC allows the manufacturer to distribute the thing in the first place.
And the US is liberal in these matters. In Europe rules are usually stricter.
Re:"but a major loss for all Linux users." (Score:4, Insightful)
People should vote with their feet, and the fact is that free software drivers are better in the long run than proprietary drivers. Not withstanding the fact that they are commonly more modern in design and better written, they are also more likely to be portable across architectures. If Linux runs on PowerPC, but all the drivers are proprietary binary x86, well, it kind of makes it pointless.
Re:"but a major loss for all Linux users." (Score:5, Insightful)
For instance, some of the chips allow you to jack up the power beyond what the FCC allows. Which the binary driver does not, which is why the FCC allows the manufacturer to distribute the thing in the first place.
Simply not true. You can transmit 1 Watt with 802.11b in the US, but the most powerful cards can only be pumped up to about a 1/4 Watt. What you can do is tune to a different frequency on some of these cards, which is you can't do without a license of some sort from your government. But the thing is you can use channels 1 to 14 on these cards with the binary drivers which means you can break the rules in just about any Western country since each licenses only a subset of those channels. But, you can also install your own antenna which will take you outside the rules.
With WiMax it will be a bigger problem, since you will probably be required to implement a serious power back-off algorithm. But I highly doubt liability would attach to the manufacturer if someone hacked their drivers to go outside the rules, liablity does not seem to attach for semi-standard antenna ports. The real problem is that these companies are licensing not just their firmware but their driver software as well and don't want to put up the $$$ to get a GPL license on that. Kernel devs understand this and just ask for the specs for interacting with the firmware, the manufacturer could have gotten this included for free when they bought the firmware & driver software. But if they didn't they now have to pay more for it. Hopefully they learn their lesson for next time, being able to say you added 5-10% to sales by simply adding a free rider to a licensing agreement gets you kudos at any company (and easy to survey for too, linux&bsd users know which OS they are using.)
Re:"but a major loss for all Linux users." (Score:3, Informative)
I'm sure you know this, but part 15 actually limits you to 1W (30dB) EIRP (technically in some situation you can push 36dB but we will not get into that) which is not the same as your radio being able to output 1W or not. Antenna gain generally plays the biggest part in this. I would put good money that a lot of people out there running 200mW cards with a high gain directi
Annoying for a nice guy (Score:4, Interesting)
Re:Annoying for a nice guy (Score:2)
http://lkml.org/lkml/2004/8/24/278 [lkml.org]
He says there may still be legal issues, but is not sure. He's trying to maintain some trust between himself and the 'evil company'. It would be nice if they would formally allow him to open source though.
Last release ... (Score:4, Informative)
Anyway, the last release files can still be found online, backup fast (e.g. gentoo distfiles : pwcx-8.4.tar.gz [switch.ch], usb-pwcx-8.2.2.tar.gz [switch.ch]).
How about a real explanation? (Score:2)
The Linux kernel certainly does allow a "hook to load a binary module". How about "load module"? Or "exec" for that matter. There are dozens of binary closed modules that work "out of the box" (NVidea for instance? All those NT wireless cards? And I personally am employeed selling an evil closed-source application for Linux and the kernel maintainers have not removed exec() to stop me!
So my first reaction is that this guy is trying to raise flame
Re:How about a real explanation? (Score:2)
In addition another post apparently from some people who have studied the camera seems to indicate that the plugin was simply doing
Sheesh... (Score:5, Insightful)
Talk about flagrantly showing your bias. How about we rephrase that last sentence as...
This is only a loss to those silly people who think that their $50 web cam is so damn important that all of the kernel developers should support binary interfaces to cater for undocumented video hardware. The USB hook for binary modules was a real detriment to the USB subsystem. It was taken out for technical reasons.
As for this..
Talk about immature. He could leave it there until a new maintainer stepped forward but he'd rather have a dummy spit and stamp his feet.
What a wanker.
Re:Sheesh... (Score:4, Interesting)
I don't have much sympathy. API versioning isn't rocket science, and it does not doom you to "archaic" interfaces when managed correctly. Compatibility between the major releases (2.4 series, 2.6 series) etc alone would be a major improvement. It can be as simple as introducing a new function instead of changing the prototype of a new one, or introducing padding into the structures.
Unfortunately the kernel developers have this idea that somehow the kernel is exempt from the same rules that govern userspace: if you document and expose interfaces to external code, you keep the interfaces stable.
Quite a lot of armchair coders don't understand backwards compatibility. It does not (necessarily) lead to insecurity or unreliability. I would like to be given examples of occasions where it has, in fact. It does mean managing change, but then this is what maintainership is all about.
The idea that making binary development hard increases the likelyhood of source releases is a fantasy based on an incomplete understanding of the economics involved. The most likely outcome is in fact the discontinuing of the drivers altogether, as has happened here.
The USB hook for binary modules was a real detriment to the USB subsystem. It was taken out for technical reasons.
It was not. Re-read Greg KHs emails. It was taken out because he thought it was a GPL violation (which is a gray area).
Talk about immature. He could leave it there until a new maintainer stepped forward but he'd rather have a dummy spit and stamp his feet.
He has worked for years to produce a solid driver for the community, even signed NDAs to get the relevant specs, and has coded on in the face of ridiculous instability in kernel development. It isn't easy doing such job, yet he did it anyway.
When you have contributed for so long, in the face of such a difficult API to work with, then you may have some authority to say whether his behaviour is "childish" or not. In his position I'd be pretty pissed off as well.
Hell, even Linux userspace has severe problems with keeping stable interfaces. I would hate to be a kernel developer.
Re:Sheesh... (Score:4, Insightful)
- RustyTaco
Sympathy...and a future workaround (Score:4, Informative)
While the Philips binary seems to be stable, if an exception to it were made other binary modules could be argued for. In fact, that's what is happening now; more and more kernel patches are being made available with binary-only parts.
There are two solutions to this;
Converting USB kernel modules into user space tools happens regularly. Not as easily done as said, and it's less prestigious, though as a technical solution it does solve the kernel dispute.
Not having the source for these devices is silly, though. Do they intend to sell hardware or drivers? By releasing the source or the specs (at a minimum), Philips would gain much and loose little. Someone else can go on a rant to fill in the details...I'm done!
Re:Sympathy...and a future workaround (Score:2)
Re:Sympathy...and a future workaround (Score:2)
There's no conflict with that, the kernel changes, and...
Those fundamentalistic turds... (Score:3, Insightful)
Kernel maintainers see linux as a server platform... and that seems to be that... webcams don't really make headway in the Apache-server linux arena which is what Linux is really mainly being used for apart from embedded stuff.
Sure, perhaps they have a point? A kernel-hook here and a direct access there, and next thing you will have something like DirectX under linux! The Horror! A Security Nightmare!
But then there is also the practical approach... if they remove these things, then there *should* be alternatives!
Otherwise I will stop using Linux as my development platform as it's not consistent...
-sigh-
I've been using the pxc.o driver of Allesondro Rubini for some time now, and even that is a bit of a pain to install... One has to modify gub configs with kernel params etc...
Re:Those fundamentalistic turds... (Score:2)
There ARE alternatives. One is called libusb [sourceforge.net]. However, this guy decided that he'd rather not port his driver to libusb because it somehow makes it a second-rate driver, and therefore makes him a second rate developer or something... Tell that to the SANE developers, who are moving all USB scanner drivers over to use libusb.
This should really be done in userspace anyway (Score:5, Insightful)
That's all fine and dandy, you may think. Not so. Nowadays applications shouldn't use these kernel interfaces at all. They should use media frameworks like GStreamer [freedesktop.org]. If they did, the driver core could remain in the kernel, while the decompressor would be a special video-source plugin for GStreamer that talks to the kernel driver through some private interface.
The decompressor code could remain in userspace, where no one gives a flying fsck about its license. Applications would be more portable, and could use any video source instead of only v4l devices. Plus, it would be much easier to reverse engineer that damn decompressor, put it under the GPL, and be done with it.
This is the best line (Score:3, Funny)
I spittled my cereal all over my desk!! thanks a lot!
Misguided (Score:5, Informative)
I love the misguided comments in this story. In particular, I like the "most users don't care what is in their kernel, so we shouldn't care that we're taking away freedoms from all (including those who do care)".
Some comments from the guy who actually did this (http://www.uwsg.iu.edu/hypermail/linux/kernel/040 8.3/0270.html [iu.edu]):
So, just to summarise, a) removing the hook doesn't stop the driver working, b) there isn't really anything stopping him publishing the code as free software. Basically, he just wants to take his ball home because he thinks he should be allowed to put hooks for proprietary modules into the kernel.
Is it the first time he's threatened to do this? No (http://www.uwsg.iu.edu/hypermail/linux/kernel/010 5.3/0365.html [iu.edu]):
Linux doesn't need proprietary drivers, it doesn't need to compromise freedom, and it certainly doesn't need people to try to press the issue by holding code hostage. And, aside from all the facts that this guy is acting an arse, there are also questions over whether or not the hook is legal (Linus' point of view of derivative works of the Linux kernel is quite clear - they must be GPL'd), and the decision to remove the hook was partially a technical one anyway (only one driver is using it).
Yet, we are still going to get people holding this up as an example of the GPL preventing Linux from "going enterprise" or whatever. Guys; shove it - for Linux to be "accepted by business" doesn't mean that developers should bend over for whatever perversion proprietary companies want. Jeesh.
Re:Misguided (Score:2)
Linux doesn't need proprietary drivers
"Linux" may not, but "Linux users" certainly do, at least until the fundamental questions of economics and patents are resolved. Until then proprietary drivers will be on the increase, just like pro
Taking my toys and going home (Score:5, Insightful)
It's fine to lose interest due to political reasons and want to stop maintaining it. But this is pretty lame. Demanding that his code be removed from the kernel? (I expect the license will make it impossible to really "demand" that.) Getting rid of all the existing downloads, documentation and FAQs? It sounds more like a tantrum to me.
Tantrum (Score:2, Insightful)
He can't demand back what he has already GPL-licensed. He can request it to be evicted of the kernel, and his request will probably be granted... Then someone else will take pwc and maintain it as a kernel patch. The interesting thing is that it seems not to exist any license information for pwcx.
Re:Tantrum (Score:3, Interesting)
I imagine that he can't demand that anyone who has exercised the rights granted under his license to retroactively remove his work from their own.
But if he decides not to license his work under the GPL anymore, what right do you or I have to use his code in a new project? We have no license from him, so we'd be violating his copyright.
The situation, of course, gets muddier: if I had incorporated, for example, the entirety of his GPL'd code in some pr
Re:Tantrum (Score:3, Insightful)
Such rights were already excercised by a lot of Linux distributions, because his work was in the _pristine_, official Linus' kernel; besides, the copyright of his work is not only his: his code is a derivative work on lots of parts of the kernel, and, as such, the copyright holders of those parts are stake-holders in the copyrights of his work.
You used the expre
Re:Tantrum (Score:3, Insightful)
It doesn't work like that. He can choose not to license his *future* work on the codebase under the GPL *if* he is the sole copyright holder (or all copyright holders agree), but even if you are the sole copyright holder, you can never "remove the rights you granted under the GPL to existing code". It might be that
Re:Taking my toys and going home (Score:2)
It would be like painting a smile with teeth on the mona lisa because you did not like the smile that is there already.
If you have ever participated in discussions on the kernel mailing list, then you'd know that there is a lot of hate running through that list. People get into real heated discussions and it always comes down to GPL this and GPL that. The GPL is all good and fi
Re:Taking my toys and going home (Score:2)
I don't think it is his right. Once you've licensed something to someone else under the GPL, you've granted the right for that person to make copies (subject to the terms of the license) forever. Some social code might dictate that the kernel developers should comply with his demands, but there would be no legal basis that I know of.
The author made the same threat before... (Score:3, Interesting)
here's the message [sourceforge.net]
Reverse engineer it! (Score:4, Insightful)
Since the Philips webcams work so well (I have half a dozen myself in various applications, most with the 9.0 beta 2 driver), I'm surprised nobody has ever attempted to reverse-engineer the USB traffic and create a completely open, non-tainted-by-NDA decompression module.
It wouldn't be the first time Linux developers had ignored an uncooperative device manufacturer.
...laura
advice requested - a potential loss for LavaRnd (Score:5, Interesting)
One ironic twist is that LavaRnd used only the PWC (open source) module. We did NOT use the PWCX (binary-only) module. Our hotplug script did an rmmod of the pwcx module. We discovered that the PWCX module reduced the entropy that the webcams provided. The PWCX module, when loaded, made webcams a poorer entropy source.
LavaRnd used the entropy provided by the actual hardware. Our analysis showed that PWCX was in effect "faking" the larger image sizes by taking, say the true 160x120 pixel CCD output and expanding it to something like 640x480. The expansion was as if a 2D smoothing function (such as a 2D spline?) filled in the pixels in between. Each of the original 160x120 hardware pixels was turned into a 4x4 pixel grid where the edges of the grid were adjusted to fit better with neighboring 4x4 pixel grids. The PWCX appeared to support a higher frame rate because the PWCX module "decompressed" the true hardware pixels and filled in the pseudo-pixels on the other side of the USB wire.
We discovered the PWCX effect while taking entropy measurements of webcam frames. Using PWC alone in 160x120 mode, the webcam produced slightly more entropy than 640x480 PWCX mode. The PWCX module was not adding real image data to webcam frames, it was just smoothing and filling in data that looked good enough to a human. However, PWCX could not fool the math ... :-)
The PWC maintainer [demon.nl] says on his web site:
The PWC maintainer's position appears to be that if you cannot use PWCX, then PWC is worthless. From LavaRnd's point of view, PWCX (the binary only module) adds no value and in some ways reduces the Logitech QuickCam's value as an entropy source.
We (LavaRnd) do not want to take sides in this PWC/PWCX kernel dispute. If this posting appears that way, then we apologize. The PWC folks have been mostly patient with our unusual use of their webcam modules. The Linux kernel folks have provided us with a wonderful platform for LavaRnd. As for ourselves, we put a lot of time into helping end users use the PWC module in older kernels [isthe.com].
Here is our advice request:
The LavaRnd project would like to see the PWC (open source) module remain in the Linux Kernel. We would like the Linux kernel folk to not honor the maintainer's request to remove everything. We want the support of PWC without PWCX to continue in the Linux Kernel. What is the best was to make this position / request known to the key Kernel people in the hopes they will PWC as part of Linux?
And does every chunk of the Linux Kernel need an active maintainer? Could PWC remain in the Linux Kernel without the original maintainer's support or would someone such as ourselves need to step up and offer to maintain it?
Re:advice requested - a potential loss for LavaRnd (Score:2)
If I'm reading your post correctly you're saying that the 640x480 mode is just a software manipulation of the 160x120 video stream?
If ths is the case then quite probably this is why Phillips doesn't want the driver opened.
Can you explain the lower fram rate for 640x480 compared to 160x120?
I'll go an rip my Pro3000 and check the specs for the CCD.
Re:advice requested - a potential loss for LavaRnd (Score:3, Interesting)
Try this experiment: Take a 640x480 picture of a grid such as graph paper ... lines on a plain color background.
Enlarge the image until pixels are squares
that you an clearly see.
Notice the 4x4 pixel blocking.
Notice how each 4x4 pixel block looks like
a plane tilted in color space.
Now try the same for a 320x240 image. And notice the 2x2 pixel blo
Re:advice requested - a potential loss for LavaRnd (Score:2)
Have you tried this on a Windows machine?
The reason I'm sceptical is that my Pro3000 uses a SONY ICX098AK CCD. The overview [sony.net] and tech specs [sony.co.jp] would tend me to believe that the device can do VGA without software. Why would Phillips/Logitech fake it?
Re:advice requested - a potential loss for LavaRnd (Score:3, Interesting)
Our Logitech QuickCam 3000 Pro CCD only has a 160x120 pixel grid. While this closeup image of the chip [lavarnd.org] is a bit small to count by, under higher magnification you can see the individual sensors and count them. They do not have 640x480 pixel array on our chip. We counted 160x120 instead.
One can do the math. At 30 fps with 640x480 pixels, using the YUV 4:2:0 Planar palette, (encodes at 1.5 bytes per pixel) you have:
Re:advice requested - a potential loss for LavaRnd (Score:2)
I guess I'll have to put mine under a scope here at work and see what I see. I am astonished that Sony/Phillips/Logitech would be so underhand as to advertise a VGA webcam with only 160x120 CCD! I'm also wondering why nobody else has noticed this? The same CCD is being used in a number of differing cameras including some firewire models.
My understanding was that the webcam took the image at 640x480 but dropped the frames per sec due
Re:advice requested - a potential loss for LavaRnd (Score:2)
Re:advice requested - a potential loss for LavaRnd (Score:2)
Re:advice requested - a potential loss for LavaRnd (Score:2)
Re:advice requested - a potential loss for LavaRnd (Score:4, Informative)
Also helpful is #kernelnewbies on Freenode, where a bunch of kernel hackers hang out, but it sounds like this doesn't require low-latency interaction.
I would like to thank you for stepping up. All of us Linux users benefit (I, have been batting around the idea of playing around with some image recognition and processing ideas on Linux, and this would allow me to continue to do so).
I'd like to point out that there is userspace software (GPLed) to do superresolution processing that may be able to provide PWXC-like functionality, but still keep the kernel hackers happy.
I would like to see the PWC/PWXC guy reconsider abandoning ownership (and all the nice work he did) -- he probably did what he did in a fit of frusteration with the other kernel hackers, but if he becomes willing to allow PWC to just pass its data through some userspace software, this might not hurt end users (and if the userspace software is better, might even be a win).
Some want to share and modify programs. (Score:2)
I hope people don't frame this issue in terms of practical utility (because down that road lies giving up software freedom for whatever is convenient to proprietors) but instead, frame the issue in terms of our ability to do what made the systems we cherish -- pres
So which webcams -are- well supported by Linux? (Score:2)
And I was just about to buy one of these cameras :(
So, can anyone suggest some webcams which are well supported by Linux? I'd taken a look at several drivers, but the PWC/PWCX ones seemed to be the best.
With some of the others it seemed to be a lottery whether you'd be able to get a webcam with a compatible chipset (no matter what model number the manufacturer might use on the box).
Re:"Zealotry" (Score:5, Informative)
The module was fully GPL compliant but provided a hook where you could attach a binary-only part (this part wasn't necessary for the module to work, it just added more functionality).
So the module was completely GPL compliant but some people thought the hook to be "impure" or something... and removed it. After it has been three years in the kernel tree. The author is right: this is a little late to make a point !
That's zealotry in my book as the module did meet the legal requirements.
Re: (Score:3, Insightful)
Re:"Zealotry" (Score:2)
I don't think that he is referring to doing anything in userspace here. At least that is the implication that I believe you are giving this, as have several others. He is referring to simply making patches available to end-users that would have to apply them and build their own custom kernel.
This has all the same issues as being a "blessed" module in the first place. The only difference is whethe
Re:How about a compromise ? (Score:3, Informative)
See What does it mean for a module to be tainted? [tux.org]
So why the hell can't they all just agree to mark it as tainted and be done with the whole hoo-ha?
Re:How about a compromise ? (Score:3, Interesting)
Regarding point a), Linux has a hisotry of allowing binary modules, provided that there is reasonable evidence that they are not derived from the kernel code. This allows things like the andrew filesystem modules and various other binary modules to exist. The tainted flag is to mark them as non-debuggable. The primary module in this case is licensed as GPL, so that's not the issue. It debateab
Re:How about a compromise ? (Score:2)
Re:Alternatives? (Score:3, Interesting)
So, I just read a few of Mr. PWCX's additions to the maillists and I've come to think he's a being a real asshole. At the very first mention of removing his hook he goes balistic and threatens to remove all his work. He's probably only doing it now because he threatened he would in the first place.
And so, yet again, the person left with the most suckage is the average linux user. The kernel team is a hair bit restrictive, driver devs morph into uber-elitist pricks and y
Re:Alternatives? (Score:3, Interesting)
They let an outside guy write a _proprietry_ _binary_ driver under an NDA. Big deal.
Re:Alternatives? (Score:3, Insightful)
I can't think of any.
Realative to the situation, it is a big deal.
Re:Alternatives? (Score:2)
Just had a quick google, and found that webcam.sourceforge.org, which contains the quote:
"The CPiA, or Color Processor Interface ASIC, is made by the company STMicroelectronics (was the Sottish company VLSI Vision Ltd. This is the documentation I have received from VLSI Vision respectively from STM. "...
So actually yeah, other companies are giving docs.
Re:good - I am glad (Score:2)
Very Disappointed (Score:2)
Re:Seems nobody understood the problem ... (Score:2)
I haven't had my coffee this morning so I'm a little slow at these things :-).