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.

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

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.

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.