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

[PainKilleR-CE]

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.

Actually, the more manufacturers see that drivers are routinely broken with little care by the Linux kernel maintainers, the less likely they are to develop drivers, source or binary. In the long run, this can be detrimental to Linux' market penetration, as users trying to switch find that their hardware does not work.

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.

I'm afraid you chose the wrong example here, because nVidia is dealing with licensing agreements forced upon them by law. They tried to use someone else's IP, and they got caught, and were forced to license that IP. In the end, they either retool their line, break compatability, and release drivers and cards that don't utilize that IP, or they release binary-only drivers. Unless there's something wrong with the licensed IP or they can convince the original owners of that IP to license it for open source distribution, it's out of their hands.

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.

But, again, nVidia doesn't own the secrets in this case. Additionally, ATI provides most of the information needed to create a driver for their cards, but doesn't provide the driver itself. Some people seem to prefer this method, but, in the end, it still means you have no support from ATI.

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

[MS_is_the_best]

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.
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, everybody gives us information, we have already creative drivers etc.). Just look at the mailing-lists.

Re:By the way

[orthogonal]

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.

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

This is little different that the "anti-spam" campaigners who -- admittedly with virtuous goals -- blacklist email from domains which can't avoid sharing an upstream provider with a spammer. The blacklisters know full well that many of the blacklisted domains have nothing to do with spammers -- and in fact they count on that -- because they hope that by injuring innocent third parties, those third parties will demand that their ISPs stop hosting the spammers (or more often, that their ISPs upstream's upstream will stop hosting a client which sub-leases to another company which hosts a spammer).

The kernel developers apparently hope that we will all now boycott Phillips and companies like Logitech which use the Phillips chip-set, and this in turn will forceforcing Phillips and inconveniencing thousands (millions?) of end-users?

If the GPL such a terrible idea that it can only work when people are forced to use it, maybe it's time to re-think the GPL.

Or maybe the kernel developers cold figure out a more direct avenue of action, that doesn't inconvenience third parties: imagine a GPL that read, "everybody can use linux (and apache, and gcc, and PHP) except Phillips. End-users wouldn't be inconvenienced, but Phillips -- well, I'm guessing they probably use quite a few linux machines for development, and gcc on them, and probably an apache webserver or three.

Now, of course, that's not going to happen, not least because the developers get a real thrill from listing all the companies that use linux, and threatening to take it away from one company would cause a whole lot of companies to reconsider their use of Open Source tools.

But a similar bludgeon is being wielded on the common home and hobbyist end-user here. And that's fine: the kernel developers have every right to write the kernel the way they want, and to use it for political purposes if they so choose. But then don't come to me and tell me linux is about "choice". Be honest, and tell me linux is about pushing an ideological agenda.

Re:By the way

[reclusivemonkey]

The software industry is inherently capitalistic, and will follow the money.

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 saying "May you live in exciting times". We do, as long you keep an open mind. The first decade of every century heralds great change. How that can be anything else but open source software for this century is beyond me.

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

[Anonymous Coward]

It's not about choice. That's the problem. Sure, "Open Source" may be about choice, but "Free Software" isn't.

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, that provides greater choice and freedom the the users of the GPL'd work. But it doesn't provide greater choice and freedom for the holder of the copyright, and it restricts your ability to just do whatever the hell you want with the work.

You can't modify it, add to it, distribute it or sell it if you don't allow others to do the same. If there is any piece of code attached to it, then in must be licensed similarly.

The guy's having a snit. The kernel maintainers don't have a responsibility to make Linux big or wonderful or a consumer-oriented system. They have a responsibility to the GPL, and that's it.

By the way, the kernel *is* "about forcing anyone who wants to play with linux to license everything under the GPL"

That's the point of the GPL. You can't get around it. If you want to play in the Kernel, you gotta open your source.

This isn't about convenience, it's about the law. How's this: if they relax their stance on this, then it provides legal fodder for the SCO's of the world to say "See! The GPL can't be enforced! They're trying to get around it!"

The worst thing, THE ABSOLUTE WORST THING, that can happen to Linux or F/OSS right now is to have the GPL legally invalidated by those who use it not being "true" to it.

The bludgeon is being used by the person who refuses to play--"if the kernel maintainers won't do it my way, then I'm leaving, boo-hoo!"

Re:By the way

[Enrico Pulatzo]

So you have a choice, be practical and don't use the camera with Linux, or be shackled with the responsibility of maintaining a module across any kernel version you may ever come across.

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

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

Re:By the way

[i0wnzj005uck4]

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 company hiring programmers to fix bugs in webcam or wireless keyboard drivers, but studios like Pixar, Disney, and Dreamworks, who run a lot of their software on Linux machines, might lean towards hardware accelerated cards for modeling which offer the drivers because it would mean less turnaround time from bug finding to bug squashing, as the debugging could be done in-house. You're probably thinking, "Yeah, but that's only for the software, and not the render farms -- a few errors during preview don't matter." However, as we move from software raytracing to hardware accelerated raytracing (which is the next obvious step after what we have now in the current generation of cards), render farms will be able to use 3D cards to to render photo-quality images at high resolution in a fraction of the time.

Now, what if a company like Dreamworks, which has hundreds of identical machines in its render farm, find that there's a driver-level bug which generates errors on some of its frames? They could switch back to software rendering (which would take longer), or they could fix the driver bug with their in-house programmers using the open source drivers and release a patch (which, incidentally, benefits everyone).

This is a highly theorhetical example (and absurd for now, but not 5 or 10 years from now), but I think it illustrates that open source drivers could, in fact, be a deciding factor for product purchases in companies using Linux.

Re:By the way

[V. Mole]

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

[warpSpeed]

The elitist control freak running the show wouldn't let our code in.

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 of view some credit if you back it up with something.

Re:By the way

[Teogue]

I am admittedly and quite obviously biased. I assumed that this would go without saying in my original post, but it did not.

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 similar to our case sans the ability to claw.

consequently Microsoft says our device is unclassified, and therefore no one but them can test it. THAT is a true pain in the ass (and wallet).

If you've followed kernel development, which your post deftly implies, then you know that drivers get rejected quite often. Open source... Free.. Rejected. My point is that if the maintainers can overcome the desire to support all OSS to reject a driver that shares their ideals and goals, then closed source binaries don't stand a chance.

I have to call that elitism. I can only point to the demeanor of the fellow we talked with about getting our product in, (which you'll see no proof of, but you know the types that are running this show) to tell you that he was in deed a control freak.

Do you still find that over the top?

Re:By the way

[r00t]

You do need to follow the Linux standard formatting.
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.

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

[AmiMoJo]

"But in the long run, do you want to have third party binary carbage in YOUR KERNEL?"

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

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

[psavo]

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

[MS_is_the_best]

Not every user cares what is in their kernel, much the same was as Windows users don't.

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 listened to this and now they are paying for their short-term strategy. About half of the home PC's are infected with spyware, zombies, viri, spam bots etc. and this is something the users DO not want.

It is a bit naive to blame the users 100% for this, Microsoft has told them everything would be easy and this is the result. (They are fixing the problems fast I think).

*n[iu]x developers cared more about security (were the zealots back then) and kept their OS secure. Know this pays off. Hopefully we will again be the zealots and take the path that works best in the long run.

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

[nathanh]

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.

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 then tough luck.

If the kernel developers are wrong then the market will sort things out. One of the distros will produce a distribution with the USB hook patched back in. But I wouldn't hold my breath.

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

[nathanh]

YOu mean like the firmware required to run the Hauppauge PVR250/350 cards? Or perhaps some of the SCSI drivers which require binary firmware to be downloaded? Hell I even think there are a few network cards which require it, too.

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.

And unless I'm misunderstanding the basic premise behind what's going on here this is likely only the start because, as I've mentioned, there are plenty of cards already supported by the kernel which require non-OSS parts to be part of the driver. What's next?

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

[tigersha]

Another example here: Wireless LAN cards.

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

[sumbry]

Sorry, but if it comes down to me having problems with a driver versus not having a piece of hardware work at all, I'll take the former.

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 and put Windows back on. A laptop is COMPLETELY USELESS to me without a functioning wireless interface.. and I don't want to have to jump through hoops to get the damn thing to work either - it's just frustrating.

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

[albalbo]

Then people shouldn't buy cards which require proprietary drivers for bizarre reasons; there are plenty which do not.

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

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

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

[Frantactical Fruke]

The binary driver for the Aureal Vortex soundcard stopped working when distributions started using GCC 3 for kernel compiles. What can we do? Nothing. Aureal went bankrupt in 2000.
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."

[Anonymous Coward]

So buy an IBM laptop if you want to run Linux. That laptop was completely useless to you because it was designed for Windows.

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

[GoRK]

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.

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 directional antenna are actually operating illegally. Higher power radios with low-gain omni's are often great for indoor spaces, but by the time you stick a big 24dB antenna up on a pole, you don't need that much power from the radio.

As an aside (and more or a reply to the grandparent post) there are a lot of good reasons for needing to get around the FCC restrictions in the driver -- using the radio in countries outside the US is the main need, but there are other situations where it's good to allow it such as when ham radio guys (legally) use frequencies outside the ISM band...

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

Last release ...

[dago]

Sad, really sad. It's a lose-lose situation, and the biggest losers are linux users [who have pwc-based webcams].

Anyway, the last release files can still be found online, backup fast (e.g. gentoo distfiles : pwcx-8.4.tar.gz, usb-pwcx-8.2.2.tar.gz).

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.

Re:How about a compromise ?

[ColaMan]

There's already a "tainted" identifier for modules - it's purpose is to tell you when your kernel's been tainted from an Impure Source(tm) - lsmod will tell you if your kernel's been corrupted by a non-GPL type module. Oops's from a tainted kernel a simply not accepted by the kernel maintainers as they can't bugtrace with them.

See What does it mean for a module to be tainted?

So why the hell can't they all just agree to mark it as tainted and be done with the whole hoo-ha?

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.

Re:Sheesh...

[IamTheRealMike]

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

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

[RustyTaco]

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.

There's the part you're not understanding. Aside from the syscalls which havn't really changed in ages (You can boot the same userland on a 2.2, 2.4, or 2.6 kernel) Linux does not have any "Documented and exposed" interfaces. It's monolithic by design, so anything in kernel space is part of the kernel and uses volitile internal interfaces. It's not what they teach you in CS 101, but that's how it works.

- RustyTaco

Sympathy...and a future workaround

[Spoing]

There are debates like this on the Linux Kernel Mailing List frequently. Should binary modules be supported? If so, within what limits? The concensus seems to be;

• Loading firmware to a target device is OK.
• Loading a binary kernel module taints the kernel;
  • Idealistically: It's not open source!
  • Practically: Defects in that binary module can be debugged but the original source can't be fixed since it's not available -- so it's a waste of time.
  • A big annoyance: One bad module can cause non-obvious problems, so if the kernel is tainted it is entirely suspect.
• Code clean up and improvement will impact the kernel interfaces; changes constantly happen in other kernel structures as well as user space tools.
• The push over time is to place as much under the control of user space tools as possible and as little in kernel modules (within limits).

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;

• Move the driver to user space and out of the kernel.
• Open the source for the binary part.

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!

Those fundamentalistic turds...

[Domini]

-grin-

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

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.

Re:How about a compromise ?

[drnlm]

You need to consider a) the GPL statements about derived code and b) the FSF statements about linking and the GPL.

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 debateable (as we don't have the source), whether the bianry module qualifies as being derived from the kernel or not. If a strong case can be made that it is derived, distributing under a non-GPL license is illegal. Non-one seems to have made this claim, so it is probable that this is not an issue.

b) on the other hand, is very much an issue. The GPL code provides a specialised hook for the binary-only module. It would be pretty difficult to argue that this does not consitute linking under the FSF's definition, and as such, the combined work must be distributable under the GPL. Since this is not the case, there is a licensing problem.

Now, if the binary only module communicated with the GPL'd code via standard interfaces (run as a userspace program, or whatever), the linking issue would not apply. This is not the case.

This is not zealotry. The Linux kernel is GPL. With that, come certain limitations. Especially with accusations (SCO) flying about, being very careful the kernel follows the legal requirements of the GPL is important.

This is the best line

[phunhippy]

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

I spittled my cereal all over my desk!! thanks a lot!

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.

Re:"Zealotry"

[squiggleslash]

Believe it or not I did RTFA, I just made the mistake of doing so at 7.30 in the morning and posting a kneejerk response to all the "They're all zealots" posts.

Still, I disagree anyone, except outanowhere and Nemosoft Unv, are being "zealots" in this case. There are perfectly good reasons for avoiding having proprietary, closed, code run at a kernel level with kernel privileges, and by Unv's own admission, there are other ways of achieving the same thing. He just doesn't want to do them:

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.

This really is a matter of deciding whether he's maintaining proprietary code to operate a proprietary device, in which case, unfortunately, he's going to have to seperate his work from everyone else's, or whether he's not in which case he's going to have to press Philips harder to get out of the NDA. Ultimately, one way or another, he has many, many, options available to him that will ensure his camera will work under Linux. He's chosen to reject all routes except one that makes a lot of other people very uncomfortable. I'd say he's far more guilty of "zealotry" than the kernel maintainers he flames.

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.

Re:Alternatives?

[omega9]

Repling to my own post, yeah, yeah..

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 yank their code, and people are left with less or poor hardware support.

Fuckin' crazy.

Re:Alternatives?

[JohnFluxx]

Yes, poor poor philips. They put so much time and money into this... oh wait no they didn't. They didn't put any money in. They didn't even put any developers in.

They let an outside guy write a _proprietry_ _binary_ driver under an NDA. Big deal.

Re:Alternatives?

[omega9]

How many other webcam companies let another guy write a prorietary driver under an NDA?

I can't think of any.

Realative to the situation, it is a big deal.

Tantrum

[hummassa]

It *is* a tantrum.

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

[orthogonal]

He can't demand back what he has already GPL-licensed.

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 project of mine, and had released my project under the GPL, presumably you could use the GPL license I grant for my project, and use my project that incorporates his code in your new project. (Although I'd question the morality of my continuing to provide his code, and the morality of your using it if you knew he'd rescinded his license.)

On the other hand, if I had merely incorporated his work by reference in my code (as say, by relying on a header file he provided, and by linking to a binary library compiled from his code) I'd say it can be argued that while you could compile my (still GPL'd) code, you couldn't compile his library -- but probably could use an existing binary copy of his library.

So on a new OS for which his library had never been compiled, I'd say that compiling it -- even to get my still GPL'd code to work -- would be a violation of his copyright.

It's conundrums like this that have always made me leery of open sourcing code -- it's not that the GPL is so onerous, it's that once you stick a finger into that tar-baby you can never again extract yourself. And clearly it was worries like this that led to the Lesser GPL ("LGPL") license.

I have a bit of code I'm thinking of open-sourcing -- I've kept it closed simply because it's essentially a web-spider, and I incorporated pauses in it, to spare other people's servers, that I don't want selfish users to remove. I wish there were an established license that would allow me to open source it with conditions, like "don't remove the pauses". And I really wouldn't want anyone to, for instance, re-brand and sell my code -- as they can with the GPL, so long as they offer the source code.

I know that a license that could be rescinded would be less attractive to businesses -- businesses wouldn't want to base long term strategy on the variable whims on a licensor -- but I doubt any business would be using my code anyway. And I'm not big on giving away freebie code to businesses -- I'm interested in helping out fellow hobbyists, not MBAs with a bonus for every job they outsource. (Just as I'm tired of writing articles for Wikipedia only to see dozens of ad-supported commercial sites rip off my work without even crediting me.)

So what's the license for me to use? It's not the BSD license, and it's not the GPL license. Does the Open Source movement have an answer for people like me, who want to maintain "moral" control of their code?

Re:Tantrum

[hummassa]

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

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 expression "rescinded the license", but this is something he coud not do, event if he was the sole copyright owner: the GPL itself prevents it. When you license something under the GPL, you are granting a non-rescindable license (except in the case of section #4).

I have a bit of code I'm thinking of open-sourcing -- I've kept it closed simply because it's essentially a web-spider, and I incorporated pauses in it, to spare other people's servers, that I don't want selfish users to remove. I wish there were an established license that would allow me to open source it with conditions, like "don't remove the pauses". And I really wouldn't want anyone to, for instance, re-brand and sell my code -- as they can with the GPL, so long as they offer the source code

Please, please: read the DFSG AND the OSI Open Source Definition. What you want is _not_ open source, and _not_ Free software. You are better off, for now, not opening the code for your spider.

Re:Tantrum

[0x0d0a]

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.

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 v2.3.1 or whatever is the final GPL version, but that version will stay GPL.

He can request that the code be removed from the mainline kernel -- a kernel guy doing so would do so as a courtesy to him, not because of any legal requirement.

Anyone could pick up the last GPLed version and start maintaining it.

The whole thing kind of sucks. The kernel people are understandably cranky because they're trying to work in a world where NDAs aren't that feasible, the GPL is important, and binary modules play hell with their ability to troubleshoot, platform compatibility and the like. The guy is understandably cranky because the kernel people are basically throwing out work that he went to the trouble of coding up for free under NDA (which seems to work pretty well). End users are understandably cranky because they paid $100 for their webcam that suddenly (at best) drops in resolution or stops working. Philips *could* become justifiably cranky because of the way they've given out some technical data and gotten kinda screwed, with Linux support for their products being dropped with no warning.

I have a bit of code I'm thinking of open-sourcing -- I've kept it closed simply because it's essentially a web-spider, and I incorporated pauses in it, to spare other people's servers, that I don't want selfish users to remove.

As a completely unrelated aside, I'm not sure that this is a good idea. Web servers can always limit rates to heavy users. However, a user can always get an "abusable" tool from somewhere. And honestly, wget in recursive mode doesn't cause problems (if wget allowed parallel operation, *then* there might be fireworks). I've never modified open-source software to remove delays, but I *have* binary-hacked a closed source piece of software to remove an imposed delay on web site downloading.

The author made the same threat before...

[Bazzargh]

3 years ago, when he was asked to take its image format conversion out of the kernel:
here's the message

Reverse engineer it!

[spaceyhackerlady]

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

[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?

Re:advice requested - a potential loss for LavaRnd

[chongo]

We know that the 640x480 bits are not real bits from the hardware. Perhaps the 640x480 rate is due to the CPU time needed to fill in the in between pixels?

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

Now try the same for a 160x120 image.

Re:advice requested - a potential loss for LavaRnd

[chongo]

Sorry, we do not have a system that runs windows. Also PWC/PWCX only runs under Linux. :-)

Our Logitech QuickCam 3000 Pro CCD only has a 160x120 pixel grid. While this closeup image of the chip 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:

640*480*1.5 octets*30/sec = 13824000 octets/sec

You cannot shove data down a USB1.1 pipe at that rate. Something has to fill in the extra data (between the 160x120 pixel grid and the frame buffer of an application) as it cannot be sent over a USB 1.1 wire and keep up.

If you examine under high magnifaction (where pixels are a few mm in size), you can see the 4x4 chunking that PWCX performs.

Maybe windows has the Philips decompressor builtin by default?

Re:advice requested - a potential loss for LavaRnd

[0x0d0a]

Post to LKML. This is probably the "official way", and even if not, they'll definitely tell you the right thing to do.

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

Problems with open source kernels

[0x0d0a]

I have to agree with the other respondant. I understand how irritating it is for you -- after all, there are no code style constraints on Windows drivers -- but the only software that makes it into the mainstream Linux kernel (or bundled with the Windows distribution) is the very good stuff, and unlike on Windows, on Linux the code, not just the binary, is a factor in the quality.

I *do* realize that this could cause major problems if there are internal reasons for using a particular style or -- God forbid -- if you are trying to get a driver into both Linux and BSD or something similar. I'm not sure that there is a good solution, for trying to get open source drivers included in a kernel. That's an interesting point, though.

Re:Problems with open source kernels

[Teogue]

Thank you all for the responses. Maybe we'll try again going through the whole community instead of one guy.