Kernel Maintainer Kills Philips USB Camera Support

outanowhere writes "The author of the Philips webcams kernel module has thrown in the towel and quit providing the pwc and pwcx kernel modules which make using Philips-based USB cameras such as those from Logitech and Philips possible with Linux. According to the author, the last straw was when a kernel maintainer changed his pwc module to make using the binary-only pwcx compression module impossible. It is a victory for obsessive kernel-purists but a major loss for all Linux users."

Comments

By the way

[gazbo]

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.

Re:By the way

[psavo]

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

[MS_is_the_best]

Despite the somewhat suggestive text from 'outanowhere' the truth is different I guess. Philips does not want to support linux, by providing a kernel driver for their device. That is their choice. This is and stays the main problem.

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

[GregChant]

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).

Do you have any evidence that this is the case, or is this just pure speculation?

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).

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.

However in the long run (and linux marketshare will help) manufacturers have to support linux.

Again, fallacious; again, a pipe-dream of the F/OSS community.

The more other manufacturers have open source drivers, the less trouble they have doing the same.

Do you have any evidence that this is the case?

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.

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

[MS_is_the_best]

Yep, I agree with you. However about 'the evidence' you want. I just know business, they (actually we), just weigh in the advantages against the disadvantages (usually involves calculation of money).

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

[nathanh]

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.

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

[squiggleslash]

If open source is about choice, I've just lost the choice to use both Phillips-based webcams and linux. Now my choice is one or the other.

Open source is about source code availability and the freedom to use that source code. It has nothing to do with "choice", it's just choice - the right to use something other than what a proprietary software vendor has told you to do - is one of the many, many, benefits.

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 so. Explain to me honestly that linux isn't about "choice", it's about forcing anyone who wants to play with linux to license everything under the GPL (or BSD, or release to the public domain).

Actually, no. If you want the camera driver to be part of the Linux kernel, then, yeah, you have to abide by the GPL both directly and in spirit. If you want to have a camera driver in userland, however, available as an option to the Philips driver writer and specifically rejected for, what I can only see as, ideological reasons, then you're free to do so.

Whatever the case, proprietary software is proprietary. You can't say "The great advantage of Linux is that it's open source!" in one breath and then say "Well, actually, you can't do anything with this camera driver" in the other.

Philips, not the various Linux contributors, has made the decision not to allow the free flow of information about how their devices work. It is Philips who are responsible for this, not the Linux contributors. They are the people who are restricting your freedoms. Address your complaints to them.

Re:By the way

[Teogue]

As a developer for a very small company, trying to get our Open Source driver into the 2.4 kernel was a nightmare.

For several reasons, user land was not a viable option. The elitist control freak running the show wouldn't let our code in. Consequently, we lost some good free advertising, and possibly some customers in order to feed the ego of some guy bent on denying anything he thought could go through user land instead.

We ended up just putting the source on our web site. Several customers already use it very successfully. But none the less, we were blocked from contributing while trying to uphold the spirit and ideals of OSS. I can only imagine how much the poor sap from Philips was being jerked around.

That being said, Linux was a stroll through a grassy meadow compared to trying to go through WHQL testing for M$.

"but a major loss for all Linux users."

[Fizzl]

Yes, all Linux users who care about that particular module.

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."

[megalomaniacs4u]

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.

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."

[ColaMan]

The thing is , if you *want* binary third-party carbage in your kernel, well now *you cannot do it at all*
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."

[squiggleslash]

...which it still could. It's a USB camera driver, it doesn't have to be a part of the kernel. Indeed, the guy says it himself:

I've considered the alternative, taking PWC/PWCX out of the kernel and supporting it solely as an add-on module, but rejected it. It would mean a demotion of PWC to a 2nd rank module, and probably quite a bit more work to maintain. Also, PWC would not work out-of-the-box anymore, while it does now. That would be acceptable if it's rarely used module, but that is not the case and it would probably confuse a lot of people.

I find this hilarious. He, and the submitter, have decided to attack the kernel maintainers for being ideological, when actually they're just trying to ensure the kernel remains legal for redistribution (it's licensed under the GPL, after all.) There's a route open to them that allows them to make a restricted product work under Linux, albeit in a slightly restricted way, but they're not taking it because it's horrid and PWC would be demoted to being second rank.

Well diddums! Complain to frickin' Philips then! They're the people being arseholes here by requiring people who want to make their bought, paid-for, hardware work under alternative operating systems sign NDAs. In the meantime, there are alternatives, the authors can still produce tools that will make their cameras "just work", it's going to be harder, but that's the downside of getting a proprietary device.

Re:"but a major loss for all Linux users."

[zenyu]

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.)

Annoying for a nice guy

[The Flying Guy]

I met the maintainer once (although he lives relativly close), nice guy, but I kinda think this is just a useless move to annoy him, there are many fully binary only modules out there and he makes the effort to make opensource what he can (NDA) but provides a binary only module (on his own website) to add some more functionality (larger image/higher fps).

Re:"Zealotry"

[DarkDust]

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.

Sheesh...

[nathanh]

It is a victory for obsessive kernel-purists but a major loss for all Linux users.

Talk about flagrantly showing your bias. How about we rephrase that last sentence as...

It is a victory for kernel developers who do not have to waste their time with crash dumps from kernels linked to binary modules, for users who benefit from a more stable kernel, and for the advancement of Linux because it is not held back by archaic binary interfaces.

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..

So what's going to happen next? Well, I'm pulling the plug completely. I'm cleaning up this website, removing the downloads, documentation, FAQs, etc.

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.

So what can you do about it? Not much, unless the kernel maintainers ease up a little, and stop being such fundamentalistic turds.

What a wanker.

This should really be done in userspace anyway

[Nagus]

The decompression part of this driver is in the kernel. This allows applications to get at the uncompressed (or "decoded") videostream through the v4l (video4linux) programming interface.

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. 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.

Misguided

[albalbo]

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):

"Without this hook, PWC will work, but with limitations, just as it always has."
"Actually, I've got a little surprise for you. The NDA I signed with Philips has already expired a year ago. Yet, I didn't just throw the decompressor code on the Internet."

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):

"Anyway, I am not going to debate this any further at this point. Johannes, please remove my webcam driver from the USB source tree" (May 25, 2001)

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.

Taking my toys and going home

[Tom7]

So what's going to happen next? Well, I'm pulling the plug completely. I'm cleaning up this website, removing the downloads, documentation, FAQs, etc. I'm discontinuing the webcam@ mailbox, and I'm going to request (well, demand) that PWC will be removed from the kernel tree. I do not want a crippled driver in the kernel with my name attached to it. Last, I'm going to remove the entries in the bugtracker.

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.

advice requested - a potential loss for LavaRnd

[chongo]

The result of this PWC mess is a loss for the LavaRnd project. We used the Logitech QuickCam 3000 Pro - pwc730 webcam and the Logitech QuickCam 3000 Pro - pwc740 webcam as two of our reference entropy sources because the cameras, when tuned with our code, are an excellent entropy source for generating random numbers.

One ironic twist is that LavaRnd used only the PWC (open source) module. We did NOT use the PWCX (binary-only) module. Our hotplug script did an rmmod of the pwcx module. We discovered that the PWCX module reduced the entropy that the webcams provided. The PWCX module, when loaded, made webcams a poorer entropy source.

LavaRnd used the entropy provided by the actual hardware. Our analysis showed that PWCX was in effect "faking" the larger image sizes by taking, say the true 160x120 pixel CCD output and expanding it to something like 640x480. The expansion was as if a 2D smoothing function (such as a 2D spline?) filled in the pixels in between. Each of the original 160x120 hardware pixels was turned into a 4x4 pixel grid where the edges of the grid were adjusted to fit better with neighboring 4x4 pixel grids. The PWCX appeared to support a higher frame rate because the PWCX module "decompressed" the true hardware pixels and filled in the pseudo-pixels on the other side of the USB wire.

We discovered the PWCX effect while taking entropy measurements of webcam frames. Using PWC alone in 160x120 mode, the webcam produced slightly more entropy than 640x480 PWCX mode. The PWCX module was not adding real image data to webcam frames, it was just smoothing and filling in data that looked good enough to a human. However, PWCX could not fool the math ... :-)

The PWC maintainer says on his web site:

" and I'm going to request (well, demand) that PWC will be removed from the kernel tree.''

The PWC maintainer's position appears to be that if you cannot use PWCX, then PWC is worthless. From LavaRnd's point of view, PWCX (the binary only module) adds no value and in some ways reduces the Logitech QuickCam's value as an entropy source.

We (LavaRnd) do not want to take sides in this PWC/PWCX kernel dispute. If this posting appears that way, then we apologize. The PWC folks have been mostly patient with our unusual use of their webcam modules. The Linux kernel folks have provided us with a wonderful platform for LavaRnd. As for ourselves, we put a lot of time into helping end users use the PWC module in older kernels.

Here is our advice request:

The LavaRnd project would like to see the PWC (open source) module remain in the Linux Kernel. We would like the Linux kernel folk to not honor the maintainer's request to remove everything. We want the support of PWC without PWCX to continue in the Linux Kernel. What is the best was to make this position / request known to the key Kernel people in the hopes they will PWC as part of Linux?

And does every chunk of the Linux Kernel need an active maintainer? Could PWC remain in the Linux Kernel without the original maintainer's support or would someone such as ourselves need to step up and offer to maintain it?