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

[david.given]

This is a pipe-dream of the F/OSS utopia.

Oop! I'm sorry, that was your credibility that just went down the drain. Here's a tip: if you want people to listen to what you have to say, don't insult your target audience.

It doesn't matter any more what points you're trying to make. You've just prejudiced your reader against you. This is great if you want an argument, but not so sensible if you actually want to get your point across...

Re:By the way

[MS_is_the_best]

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
No, this example works. They cannot open the drivers they currently have, because there is IP from others in it. That is true. But if they have business incentive (more cards sold etc.) to open their drivers, they can rewrite the protected IP part with a different algorithm.

In the Nvidia case this is all not very realistic. They have invested too much in the way they work now, so it will never be usefull enough for them to open their drivers.

It is possible (I think this will happen, only not in near future) that a new competitor comes from open source world (or other) doing exactly this (provide open drivers). If the market is ready for this, that can become a hit and common business practice. But for this to happen, we have to encourage open drivers now.
(Someone remembers the Voodoo cards, and their problem with their too closed and problematic Glide API and their resistance against DirectX?
Where are they now?).

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

[duffbeer703]

I thought the point of the Linux "community" was that you could dissassemble your toaster and write Linux drivers for it to replace the manual controls?

Phillips has likely licenced the technology from another vendor who is unwilling to change the terms. The fact that they were willing to provide access to the code under NDA at little or no cost displays their good intentions.

If the Linux kernel team is going to fuck with binary code in the kernel, then alot of other devices are going to be broken.

Re:By the way

[Anonymous Coward]

You should take your own advice. You had a target audience of one, and insulted him in the first sentence.

Re:By the way

[sumbry]

This is exactly why I don't run Linux on my laptop. Most laptops (especially Intel Centrino-based) are shipping with binary-only drivers. This same problem is going to affect them - this is not just a USB camera issue...

Now are you seriously going to tell me (and millions of other users) that because the purists want it this way that we can't install a version of Linux on a laptop without net access w/o first hacking together a custom kernel?!? wtf?!?

I read an article on /. not too long ago that talked about the great lenghts Microsoft programmers went through to make sure that future versions of Windows were compatible with previous releases of software already in the wild - this is exactly why they have over 90 percent marketshare and 50 billion in the bank.

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

[Anonymous Coward]

>Very nice from this guy, but in the long run this will hurt linux (AND linux users).
Why will it hurt users ? I just want my damn gadget working, I don't care if it uses a properitary driver,properitary cable,interface,user application or whatnot. I want it working.

This might be a user problem under linux though, as drivers are often not even minor version level compatible.. Thats a whole other issue though, and is just as much a problem for binary modules as not-in-the-tree OSS modules.

Re:By the way

[Anonymous Coward]

Linux is not a business, dumbass. It does not exist to serve users.

Re:By the way

[Anonymous Coward]

How that can be anything else but open source software for this century is beyond me.

I hope you're right, but it could certainly be, say, the USA starting a world war on terrorism that leads to the destruction of all life.

Re:By the way

[PainKilleR-CE]

In the Nvidia case this is all not very realistic. They have invested too much in the way they work now, so it will never be usefull enough for them to open their drivers.

This is exactly why I said it's not a good example, though the rest of your statements (a 3rd party developing open drivers) bring up a good point. Unfortunately, 3rd-party drivers are very unlikely to take full advantage of the hardware without open specifications (the reason so many people prefer ATI's methods).

(Someone remembers the Voodoo cards, and their problem with their too closed and problematic Glide API and their resistance against DirectX?
Where are they now?).

Voodoo didn't resist DirectX very long, it was OpenGL that gave them problems, precisely because their cards weren't developed with it in mind. id Software forced their hand in this by announcing that Quake 3 would not support their "miniGL" drivers, requiring them to release OpenGL drivers for the cards. These drivers, when finally released, showed very poor performance (in part because of the fact that they were new drivers). This, combined with severe delays on the release of new cards, and a constant resistance to new features (32bit colour, for one), while introducing new features with questionable benefit, and rumors of requiring a secondary power source (now common on many cards, at the time unheard of), and finally buying STB so they could become the sole producer of 3dfx cards, all undid the company. In the end, most of their IP is now at nVidia, a company which took the market by ramping up the frequency at which new chips were released to market (every 6 months, something 3dfx never managed), fixing OpenGL problems with their chips within 3 generations (~2 years, all before their cards were even remotely popular for 3D graphics), working with Microsoft on DirectX support, introducing 32bit colour when no one thought it was necessary, and producing reference 2d/3d boards that surpassed the capabilities of 3dfx' add-on 3D-only boards before 3dfx could build any kind of reputation for building solid 2d/3d boards.

In the end, nVidia played a tough hand against 3dfx, and 3dfx kept stumbling. By the time this mess was all over, ATI stepped up to the plate, and though they stumbled at first, they have since managed to keep up with (or get ahead of) nVidia at nearly every turn.

Re:By the way

[Anonymous Coward]

I appreciate your willingness to call bullshit when you see a claim that's not backed up. But you are claiming a lot of stuff without evidence, too. Why do you have a lower standard of proof for your own quotes?

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

[Paradise Pete]

Holy shit do you ever come off sounding like an utter cocksucker.

In what way? Do you mean it's hard to understand what he's saying?

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

[addaon]

Why couldn't it go in user space? The fact that people suggested it implies it might have been workable... and keeping stuff out of the kernel is worth some extra effort.

Re:By the way

[Teogue]

Mostly because of the general flakyness of USB in linux. At least, that is my rather biased opinion.

After pretty much a complete rewrite for 2.6, the user land code was, well useable, but still not the same.

In short, it was workable, but not comercial quality.

Re:By the way

[aminorex]

It's funny that you should use the marijuana story,
since the heaviest pot smoker I ever met was a
driver developer for ATI. I never met Carl Sagan.

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

[LizardKing]

I read an article on /. not too long ago that talked about the great lenghts Microsoft programmers went through to make sure that future versions of Windows were compatible with previous releases of software already in the wild - this is exactly why they have over 90 percent marketshare and 50 billion in the bank.

If backwards compatability was the main reason for MicroSofts success, then NetBSD would give them a run for their money. NetBSD is backwards compatible with previous releases all the way to 4.3BSD. Can you still run DOS program from the same era as 4.3BSD on you WinXP box? Unlikely. The true reason for MicroSofts dominance is somewhere else.

Re:By the way

[aminorex]

That's why I like IBM Thinkpads. They have reliably run Debian or RedHat for me since the 600X back in '97.

When you are competing on price in a commodity market, you make your profit on the last 10% of the sales. The difference between a 90% target market and a 99% target is the difference between success and bankruptcy.

The only reasons any vendor of consumer-level mass sales hardware gets away with not documenting their interfaces are (1) lack of competition in an early-adoption market or (2) lack of competition due to collusion. ATI/NVIDIA is a perfect example of the latter. If one of them opened their interface specifications, the other would soon do likewise, or be roadkill.

Re:By the way

[Anonymous Coward]

You can tell this post doesn't deserve an answer (even ignoring the glaring logic errors) when he starts comparing "making open source drivers" with "smoking marijuana".

WTF !?

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

[Dh2000]

No matter how long it takes, eventually, binary drivers will be broken and the developer who wrote it will probably not want to rewrite it.

Why not have it opensource? Any programmer that has the know-how can do the chore, then.

Look at the Win9X drivers that don't work with NT, 2000, and XP. You may say "it's a different kernel" but that's exactly the same problem with Linux. Only difference is that Linux kernel development is much, much faster than MS's. Sure, it'd be nice if a driver compiled for version x.x.1 worked with x.x.4, but it's even easier to just recompile it.
(One could always try force-loading the module so as to ignore version info.)

And, if you don't care about the license of software, why not use windows? Your hardware will probably work on it.

Re:By the way

[lynx_user_abroad]

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?

Your argument undercuts itself. Freedom is not only available to "the elite few that possess enough understanding to be free in the first place" but also to the ones they bring with them. If you lack the knowledge necessary to hack the kernel in order to support the binary module, then clearly you lack the knowledge to be able to create your own kernel from scratch. Yet you use such a free kernel, or you wouldn't be complaining about having to learn to hack it.

Do you owe anything to the core kernel developers for the kernels they've made available to you? If yes, then you at least owe them the respect that comes with allowing them to choose what they will or will not support. If you don't owe them anything, then take the existing kernel and leave.

This world may not always offer you just exactly what you want when you want it. Unless you are hopelessly spoiled, you'll accept that.

If the failure of the core kernel developers to provide 'convenient' access to this hardware creates a community of developers of large enough size to support a forked kernel, then it will happen. And you'll get your driver through them. If not, then there wasn't enough call in the community for that.

But there is one thing you seem to have completely missed: If you choose to develop the knowledge necessary to hack on the kernel and support a fork, no one (except perhaps the hoplessly spoiled) is going to try to stop you. I suspect you'd even get help, of a sorts, from the core kernel development team.

Can you expect the same support from Philips?

Re:By the way

[Unknown Lamer]

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.

The last graphics card I purchased was a Radeon 9100. It will remain that was as long as there is is no Free Software driver for a more powerful graphics card.

Some of use use Free Software for the Freedom part of it...

Re:By the way

[sydb]

In what way is "Oop!" an insult?

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

[ashoooo]

This argument is going nowhere.

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.

Re:By the way

[0x0d0a]

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.

Video cards are a special case. They are high-innovation, both ATI and Nvidia retain a large number of very highly-paid and well-known computer scientists on staff, and they hide a lot of their magic in the driver. It is a hyper-competitive arena where a 10% performance difference can make or break a product cycle. There are almost no other devices with drivers that operate like this -- certainly not webcams.

Re:By the way

[0x0d0a]

Same here, but with a 9200. The card before that was a Matrox G450, and the card before that a G200. In each case, it was because the card was the best-supported-by-open-source-drivers-on-Linux product of its time.

Of course, I am only one person.

It would be to everyone's benefit for someone to maintain a website ranking products based on open-source support for Linux, so that I can just choose the highest-ranked product that fits my needs.

Re:By the way

[Anonymous Coward]

And your statement rebutts or adds to the argument... how?

Re:By the way

[Anonymous Coward]

If they want to sell hardware to people like me

You are not commercially important. The class of consumer you represent is commercially insignificant in comparison with the class of consumer that buys the thing, plugs it in, and uses Windows with it forever. This is the same reason we don't have left-handed everything on the shelf next to the right-handed versions.

If FOSS wants to influence the behaviour of commercial entities, it needs to understand its relationships with commercial entities in terms of money in addition to ideology. At this, FOSS is failing.

Re:By the way

[Anonymous Coward]

Can you still run DOS program from the same era as 4.3BSD on you WinXP box?

GEM3 starts fine under WinXP, thanks.

Re:By the way

[Ogerman]

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.

Uh.. no, that's just market economics. If Linux becomes the big game in town, everybody will be forced to follow the rules. The question becomes: At what point it makes sense to set down these strict rules? Is Linux popular enough yet that disallowing binary firmwares / driver stubs will actually cost hardware companies in lost sales? Probably not in this particular case. While there are millions of machines running Linux, very few have webcams and even fewer use these budget USB webcams that rely on software image processing routines to work.

On the other hand, I'm pretty certain that Promise was convinced to fully open source their SATA / RAID controller drivers because of pressure from one large customer who wanted to use Linux but didn't want the risk of their binary drivers. It can happen.

Time will tell what the outcome of this will be. No doubt it will get back to Philips and they'll be forced to reconsider their decision one way or another.

There is no monetary advantage to opening source or revealing trade secrets

There is possible monetary advantage of opening source due to increased customers (even if small). But here's the more important thing: there is no monetary disadvantage of opening source. Ever hear of disassemblers? Yeah, the competition uses them. Ever hear of memory probes and signal analyzers? Par for the course. Ever hear of white room reverse-engineering? Yeah, that's pretty popular too. You simply can't hide trade secrets in software. Now *that* is a pipe dream.

Re:By the way

[Kalzus]

Make a point to remember in the future that we're scratching our own itches, and not everyone is interesting in Saving The World through Linux.

Re:By the way

[Thing 1]

Shouldn't be hard to whip up a Perl script to convert from one style to another.

Then you could use CVS triggers, so that when you checked the code in it was converted to the Linux style, and when you checked code out, it came to you in the style you prefer.

For the overly paranoid, it would compile yours and the converted version (both checking out and in), making sure that the result was identical, to ensure that the conversion was effective. If not it would leave it as-is, and send an email letting the developers know what two files failed so they can fix the conversion algorithm.

Re:By the way

[nicolas.e]

Look at the Win9X drivers that don't work with NT, 2000, and XP. You may say "it's a different kernel" but that's exactly the same problem with Linux.

Not at all. Different versions of linux are different versions of the *same* kernel.
win95 vs wnt have *different kernels*.
nt vs 2000 vs xp have different versions of the *same* kernel, and here, a binary driver made for windows 2000 often works on xp. Would a binary driver made for 2.4 work for 2.6 ?

Re:By the way

[nicolas.e]

GEM3 starts fine under WinXP, thanks.

Your argument is ridiculous. If you think this way, netbsd runs any pc program thanks to bochs. The above poster meant natively, like win9x ran dos programs.

Re:By the way

[jbolden]

And lets not forget the many thousands of low end embedded systems being sold today in which well supported drivers most certainly is a major factor in which hardware gets picked. Since they are choosing from a 1/2 dozen + vendors they can choose on the basis of level of linux support.

Re:By the way

[ACPosterChild]

I'm not arguing against you, but without any proof your story is no more than an anecdote that is, itself, begging the question.

As a fellow software developer, I could see how lots of people might want to get things put in the kernel that have crappy code, or code formatting the reviewers aren't familiar with and have to spend extra time on, or modules that don't behave in standard ways. Sure, it might be more of a pain in the ass for individual developers, but it's good for the project as a whole. So, in order for your story to have much credence, you would really need to provide concrete examples of how these good ideas were mis-applied to you, i.e., why the problem was really with the reviewer and not you.

But yeah, if you actually were getting shafted by an ego-maniacal asshole, that really sucks.

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

[Anonymous Coward]

Flamebait?!? What for?

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

[Anonymous Coward]

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

You mean... like NVidia video drivers? I don't see why the kernel maintainers aren't fixing the kernel so NVidia can't do that trick anymore, yet they have time for this.

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

[tzanger]

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

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.

When you have a nontrivial piece of hardware, chances are that the thing contains an FPGA or perhaps even a decent processor of its own. In an attempt to save money and secondarily make it easier on the end-user, the device creators opted to have the firmware downloaded to the card after bootup and initialization instead of putting it in nonvolatile storage. Great idea except when the people who make the decision decide that it's not so cool anymore.

I'll reserve judgement on Mr. Kroah, as I haven't seen his side of it but I tend to agree with the driver writer; it's far too late to be pulling this shit. 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?

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

[Anonymous Coward]

That linux land you speak of is dead and will never come back. With they money that ibm et all have funded into the devolpment, they say how the kernel will turn out. anything else is foolish

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

[eXtro]

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

I actually don't care. All I care is that I have a solution that works. I happen to be somebody who makes use of the Philips USB camera driver, I purchased my particular device because at the time it was the best camera in terms of features that had some form of linux support.

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.

Your statement is meaningless. You shouldn't trust binary code because reverse engineering is hard. Granted, it is and as you say it's beyond the abilities of most people. Kernel programming is hard as well and so while I have access to the kernel source realistically it doesn't provide me any more insight into the reliability, stability or security of the kernel. I admit it, I both can't be bothered to do an audit of the kernel and I don't have the necessary skills.

I do know that the kernel developers purposely destroyed functionality in the kernel which I and others made use of to make some sort of point. So yeah, I have source code but I don't have a warm and fuzzy feeling about the amount of faith I can put into the kernel developers.

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

[Anonymous Coward]

mod this up...

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

[Atzanteol]

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

Yes. I use a Phillips based camera. Now I will no longer be able to do so from Linux, and you're trying like hell to tell me this is Good(TM) for me.

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

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

[llefler]

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

Do you only use WQHL drivers? Not many people I know do, particularly with video drivers. I have heard support techs tell people to upgrade to the latest drivers. I've heard them tell people to upgrade to the latest beta (!) drivers. I've never heard one tell a customer to upgrade to the latest WQHL drivers.

I think source to drivers is nice to have and should be encouraged. But I don't think it is as important as having a working device. Honestly, I'd prefer hardware vendors simply opened the specifications to their hardware. If they provide an OS driver, great.

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

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

[Anonymous Coward]

The thing is , if you *want* binary third-party carbage in your kernel, well now *you cannot do it at all*

This is wrong. You can still get the driver from an older kernel and compile it seperately. Or just use an older kernel :). This driver just won't be a part of the latest mainline kernel.

Although this is not a great solution in the long run, if there's any real demand, someone is bound to create a fork of the code (binary and all) from the last kernel version in which it was included. There's no reason why a kernel module will go unmaintained if anyone is willing to be the maintainer.

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

[silicon not in the v]

So what? This guy was doing a favor for Phillips by making their binary driver integrate via this "hook" into the kernel. No reason why that has to be the case. They can do an all-binary driver like Nvidia does, and it works just as well. Then, the kernel guys are happy because it's not touching their precioussss GPL stuff.

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

[Paul Jakma]

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.

I'm sure it is.

Whose fault is it though? The kernel guys' fault for not being able to write drivers for hardware they can not get specs for? SuSe's fault for not including the binary-only version driver, the licence for which almost certainly prohibits redistribution?

Why dont you blame these hardware manufacturers for not releasing programming specifications (openly or under NDA to kernel hackers) and/or not writing a GPL driver? They're the only ones who can change the situation. They're the ones to pin the blame on for making your Linux experience frustrating.

Complaining on /. about SuSe, who can not do anything about it is senseless.

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

[RzUpAnmsCwrds]

"A binary driver means planned obsolescence for your hardware as soon as the manufacturer loses interest."

No, it doesn't. I have a Rio 500. Rio went out of business some time ago (and, no, the new "Rio" isn't the same as the old Rio).

Yet my device still works? Why? Because the old Windows 2000 driver still works in Windows XP SP2.

Planned obsolescence is only an issue if new software isn't binary compatible with old software.

Repeat after me:

We shouldn't have to recompile modules for new kernels. Windows and Mac OS X users don't have to, so why should Linux users have to.

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

[Frantactical Fruke]

So, you are quite sure that this driver will also work in whatever Windows you will use five years from now?
Plenty of old hardware around that only has a win98 driver and does not work on win2k and such. Or so my mother tells me. Win95 was my last contact with MS.
Even MS doesn't put up with that much old crud in its kernel, apparently. Having the sources is the only way to keep old hardware alive.
There will be a move to 64 bit hardware soon and yet another shove for old drivers, no?

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

[wireloose]

While this may sound like serious issues to some, I feel compelled to point out that in reality, the omni-directional antennas buried inside wireless laptops or mobile devices do not have the gain characteristics necessary to get significant past the 30db limitation with the power available from the card itself. The vast majority of wireless device users would probably use power controls to eek out a few extra minutes of battery time, and a subset would be interested in maximum gain. Yes, there would be some that would strive to increase power. But to get 24db gain, you have to have a fairly stable antenna, highly directional, and that's not practical for laptops in typical use. There are other ways to bump up power, but they just don't always make sense. Sure, you can add an inline amp in your transmitter, but unless there's a similarly amped system at the other end of your transmission, it doesn't gain you a lot. If law enforcement was a valid reason for disallowing a technical capability, we could easily start discussing governors for cars to prevent them from exceeding the speed limit. I certainly would never have mine retrofitted :) I'd prefer to have open source choice. If a driver has to be kept proprietary for business reasons, no matter what they are, let them support their hardware with non-kernel modules. It's their business choice. I won't necessarily agree with it, but mine is one of many opinions. An ideal wireless NIC driver would be open source. It would dynamically adjust gain levels up and down to balance power consumption (battery life) without compromising data integrity. And if someone wants to tweak the open source for max power, power to them!

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

[Anonymous Coward]

The drivers for my old parallel-port scanner don't work in NT-based Windows. For a while I was plugging it into my Win98 box and using it there, but sadly the Win98 box was destroyed to make something new so I now have a useless scanner. This is just one of many examples of hardware which hasn't been upgraded to use the fancy new Windows Driver Model.

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

[Daniel]

It doesn't matter whose fault it is; what matters is that the hardware doesn't work.

Daniel

the funny thing is...

[hatrisc]

turning on my computer this morning, i was looking at my webcam (which is phillips based) thinking of the interesting stuff i might do with it.

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:Annoying for a nice guy

[ycv]

I kinda think this is just a useless move to annoy him

As stated above, his driver can live in user-space, which seems more natural, and enables to make a fully free kernel.

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

Please read his post
http://lkml.org/lkml/2004/8/24/278, he says that the NDA has expired one year ago. Everything could have been released under the GPL.

Re:Annoying for a nice guy

[Atzanteol]

Please read *all* of this post:
http://lkml.org/lkml/2004/8/24/278

He says there may still be legal issues, but is not sure. He's trying to maintain some trust between himself and the 'evil company'. It would be nice if they would formally allow him to open source though.

Re:Annoying for a nice guy

[0x0d0a]

Yeah -- he might be able to do something legally, but companies can do a lot of nasty things legally, like using bogus patents.

The point is that he's trying not to burn Phillips for letting him have the data. It would be *infinitely* better if Phillips would just let the code be GPLed, but they might not want that to happen, if they think that it's a major competitive advantage (and that their competitors are willing to go GPL or are just interested in taking ideas, not code, from their GPL code).

No more Philips USB Camera Support for lnx?

[u-238]

Well, that's about enough for me. I've had a good run. Someone tell my parents I'll miss them, and that they can get a replacement for the rat poison missing with the money in my wallet.

How about a compromise ?

[moro_666]

I totally understand kernel developers, the closed source third party module may as well be a huge security risk through some leaks or badly handled events which may cause instability and insecurity of the whole kernel. When a hacker should find it out, he could easilly attack the systems which have the webcam attached to it and do whatever they want.

But how about this, give the kernel a configuration flag that describes itself as a possible security/stability leak (advises not to activate it :S ), but when enabled, it includes the possible binary data into the kernel. By default it should be disabled.

So usual people who don't need the special binary submodule can use their cams and go on without worries about security, and serious cam fanatics (i still don't get why would anyone attach a cam to their machines) can enable the binary module. the binary module itself should be downloadble separatly from the kernel, just to avoid any unwanted enabling without any external tasks.

so , any comments ?

Re:How about a compromise ?

[frickenhell]

They already have this. The kernel can tell if it has been tainted when a particular module is loaded.

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?

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.

Re:How about a compromise ?

[tchuladdiass]

Um, the driver that the binary-only module is also written by this guy. Are you trying to pull a SCO and say that once your own code touches something GPL that you can't also use your own code in a non-GPL manner? Sounds a lot like what the FSF used to pull with the KDE team, that they were violating their own license. I'm sorry, but copyright law doesn't work work like that. You can license something one way, and turn around and use the same code (assuming you didn't transfer the copyright) in any other way you want.
The only way around that would be if the GPL itself came with it's own license on restrictions when applying it.

Re:How about a compromise ?

[0x0d0a]

No. It's fine to write code and put it in both GPLed and non-GPL-compatible software if you hold all copyrights. I have plenty of utility code that I've written that has been in both.

The problem is that you can't write code and then run it in a manner where it is simultaneously linked with both GPLed and GPL-incompatible software, which is what the webcam module guy is doing.

Re:How about a compromise ?

[tchuladdiass]

I thought the GPL only covered distribution, not usage. If I take a GPL program, and link in a GPL-incompatible module and only keep it on my system, then that is not a violation.

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

"Zealotry"

[squiggleslash]

I wonder if any of the people who are currently flaming the Linux developers as out-of-touch zealots are aware that the kernel is licensed under this thing called the GPL, a license that requires anyone redistributing the kernel to release full source code, by law?

I wasn't aware that "zealotry" and "obsessive" meant "trying to meet the minimum requires to remain legal", but obviously I'm in a minority here...

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:"Zealotry"

[gazbo]

You've not read what went on.

The problem isn't with the binary driver being removed - that can be distributed separately. The problem is with the exported function in the GPL module being removed. The only reason it was exported was to allow the binary driver to integrate with the module, and that was also the only reason it was removed.

There were no legal ramifications either way.

Re:"Zealotry"

[doctormetal]

I wonder if any of the people who are currently flaming the Linux developers as out-of-touch zealots are aware that the kernel is licensed under this thing called the GPL, a license that requires anyone redistributing the kernel to release full source code, by law?

Did you read the article? It states:

As most of you probably know, the driver consists of two parts, PWC which is available as source and part of the kernel, and PWCX, the binary-only decompressor part. PWC itself works, but with limitations in framerate and resolution; to get the full benfits of the cam, you must use PWCX.

Which means that only the oss part is distributed with the kernel and not the binary part.

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.

Re:"Zealotry"

[gi-tux]

by Unv's own admission, there are other ways of achieving the same thing. He just doesn't want to do them

I don't think that he is referring to doing anything in userspace here. At least that is the implication that I believe you are giving this, as have several others. He is referring to simply making patches available to end-users that would have to apply them and build their own custom kernel.

This has all the same issues as being a "blessed" module in the first place. The only difference is whether or not Linus and the other maintainers have "blessed" the code and take any level of responsibility for it. And by being outside the main kernel tree, it is more difficult to keep the modules up-to-date.

The NDA doesn't matter, he stated that it had expired. He obviously could open-source the code as far as the NDA is concerned. However, there could be other issues than an NDA, there could potientially be copyright issues, etc that would play into this as well. There are other reasons for not open-sourcing the code. It is an act of good-will between him and Philips. Philips trusted him with their knowledge, knowing that he was an open-source developer. Obviously Philips wasn't planning on these cameras still being on the market when they picked that date to end the NDA, but by him not releasing code for a product they still have on the market, he has a better chance of getting a similar agreement on their next line of products.

Now, it is possble that there are still other ways to get these cameras to work properly. However, it would probably involve a large amount of time on the part of Nemosoft and he just might not have that time available right now. These drivers have been working at some level for a number of years and Nemosoft has ported them to new releases of the kernel, etc when necessary.

I am not sure that anyone is in the right on this issue. I believe that everyone involved has some blame for this. I am just glad that I didn't buy that Philips camera last month that I started to buy. I would have been highly upset at spending over $100.00 for a camera that was not going to be useful in a short period of time.

How about a real explanation?

[spitzak]

Can anybody with real knowledge explain this in more detail?

The Linux kernel certainly does allow a "hook to load a binary module". How about "load module"? Or "exec" for that matter. There are dozens of binary closed modules that work "out of the box" (NVidea for instance? All those NT wireless cards? And I personally am employeed selling an evil closed-source application for Linux and the kernel maintainers have not removed exec() to stop me!

So my first reaction is that this guy is trying to raise flames by blaming a technical decision he dislikes on GPL zealotry.

Conversely, it is quite possible that it is physically impossible to make the webcam work using the available kernel interfaces, in which case the kernel maintainers are in the wrong by removing this and not at least coming up with an alternative.

So will somebody in the know, without flaming for either side, explain the exact technical details, so we can really judge who is wrong here?

Re:How about a real explanation?

[tzanger]

Conversely, it is quite possible that it is physically impossible to make the webcam work using the available kernel interfaces, in which case the kernel maintainers are in the wrong by removing this and not at least coming up with an alternative.

I find it very hard to believe but not impossible that that may be the case. I wonder why the binary-only can't be handled in userspace though... there are plenty of kernel modules that do similar things.

Re:How about a real explanation?

[Anonymous Coward]

exec doesn't run binaries in kernel mode.

Re:How about a real explanation?

[spitzak]

Yes from further comments it sounds like it was possible to make this be a user-space program, and this is the solution being used for many other closed USB devices such as scanners and some other cameras. So I'm beginning to think the author is the one at fault, I cannot blame the kernel maintainers for wanting to limit the binary-loading interfaces to a small controlled area.

In addition another post apparently from some people who have studied the camera seems to indicate that the plugin was simply doing image processing of the same image, not reading extra data from the camera. No wonder Phillips want's it closed source! (if this is true, of course. But tricks like this are another danger of closed source that nobody here has mentioned).

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

[Anonymous Coward]

There have never been reports of crashes caused by this driver. Your religious fanaticism is funny, though. Have fun with that, while the rest of us use the best tool for the job.

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

[avida]

you are the wanker!

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

Re:Sheesh...

[NateTech]

Ahh.. let's see here... who's bias is showing?

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.

Let's rephrase your statement as:

This is only a loss for people who'd like to buy an inexpensive webcam and actually get something done with it like monitor their property or communicate with family members, and who would also like to use a Free OS to do it.

Fair 'nuff?

Everyone's biased. What you're saying is you don't like his bias, but you're allowed to show yours? Pot. Kettle. Black.

Re:Sheesh...

[Anonymous Coward]

"Hell, even Linux userspace has severe problems with keeping stable interfaces."

Huh? My debian unstable system running Linux 2.6.6, gcc 3.3.4 and glibc 2.3.2 can still run binaries I compiled on my slackware system from 1994 or 1995 (somewhere in there).

I just had to install the libc5 package, which is hardly surprising given that they link against it.

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!

Re:Sympathy...and a future workaround

[IamTheRealMike]

The relevant binary code involved video codecs. These are often patented and licensed from 3rd parties. Even if Phillips had invented and created the technology, that doesn't mean it's in their economic advantage to do so.

Re:Sympathy...and a future workaround

[Spoing]

1. The relevant binary code involved video codecs. These are often patented and licensed from 3rd parties. Even if Phillips had invented and created the technology, that doesn't mean it's in their economic advantage to do so.

There's no conflict with that, the kernel changes, and...

• Move the driver to user space and out of the kernel.

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

Re:Those fundamentalistic turds...

[Anonymous Coward]

What about the critical fishcam market?

Re:Those fundamentalistic turds...

[dozer]

if they remove these things, then there *should* be alternatives!

There ARE alternatives. One is called libusb. However, this guy decided that he'd rather not port his driver to libusb because it somehow makes it a second-rate driver, and therefore makes him a second rate developer or something... Tell that to the SANE developers, who are moving all USB scanner drivers over to use libusb.

This should really be done in userspace anyway

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

Bye general computing, hello do what we tell you

[pocopoco]

This reminds me of when I downloaded a Mozilla version that refused to let me open certain files like .exe files after downloading (you could just tell it to open most files after they dl, but not the exe ones). I looked around for a way to turn this off, couldn't find it, and immediately changed browsers. OK, it's more secure, but what the f*ck? It's my machine, I want to make the decision about running an exe. Most of the time I was getting the file off a trusted site, so zero need to check for viruses and what not, and just had to go freaking start the file from the OS.

Apparently once any software gets big enough the maintainers start feeling like arrogant assholes. Same with this, there's no legal problem with including a hook to load the binary part here. Some asshat just thinks the concept it's impure and may cause bugs...wth? It's my decision. You don't want, then don't run it and says it's not recommended! Hopefully someone with a little respect for the whole concept of computers being general purpose tools will step in and fix this. It's tougher to switch OSes than it is to switch browsers, but if they keep crippling the thing "for my own good" like Mozilla started to do I certainly will.

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

[IamTheRealMike]

He already explained why he hasn't published the information. Whether you agree with his reasoning or not is besides the point, he's explained it and it's not that he just gets a kick out of it. Given that the binary code has broken in the past I tend to agree with him.

Linux doesn't need proprietary drivers

"Linux" may not, but "Linux users" certainly do, at least until the fundamental questions of economics and patents are resolved. Until then proprietary drivers will be on the increase, just like proprietary software in userland will. If Linus doesn't recognise this reality I suspect it may eventually fork.

Re:Misguided

[GreyWolf3000]

Why does everyone assume that the vanilla kernel hosted at kernel.org is the end all, be all of linuxes?

It's open source...to me that means that all of the code in question can still be maintained as a patchset against Linus' latest kernel.

Most distributions use heavily patched kernels anyways.

This is why I consider this guy to be unfair--he's whining that the 'fundamentalists' who develop the main kernel want to keep their distribution of Linux* free from binary code.

Distributions that aim to make the average Joe's Linux experience better could include this patchset by default. Everyone wins.

* By this I mean the kernel, not the OS; on a side not, this is a great example of why GNU/Linux could make practical sense.

Re:Misguided

[jbolden]

If Linus doesn't recognise this reality I suspect it may eventually fork.

With whom on the other side? IBM, SGI... love the gpl and are big advocates. Its not like there is some large group dedicated to low end hardware support features in the kernel. There isn't anyone to fork. Basically you have large companies interested in server techologies on one side and the original Linux people on the other. There isn't a third "desktop" side which has those kinds of resources.

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:Taking my toys and going home

[josepha48]

Actually it is his right to do so. He wrote and maintained all the pwc code, so he has the right to request that it be removed.

It would be like painting a smile with teeth on the mona lisa because you did not like the smile that is there already.

If you have ever participated in discussions on the kernel mailing list, then you'd know that there is a lot of hate running through that list. People get into real heated discussions and it always comes down to GPL this and GPL that. The GPL is all good and fine, but what is the problem with a binary only module attached to the kernel. It was not shipped with the kernel it was external to the kernel. nVidia did this for a while.

Rather than everyone attacking the maintainer of this, we should be thinking that this guy went out of his way to provide us with support for many webcams that we would probably not have gotton support for.

I just want to thak the Linux kernel developers and all the people who attack this guy, because when his code goes out the kernel, all the people who use those cams are going to be sitting at their desks with a useless peice of hardware on top that does not work with. Consider it a waste of about 50-100 USD. Thanks guys! I only bought the cam because I found his site and saw it was supported.

Re:Taking my toys and going home

[Tom7]

Actually it is his right to do so. He wrote and maintained all the pwc code, so he has the right to request that it be removed.

I don't think it is his right. Once you've licensed something to someone else under the GPL, you've granted the right for that person to make copies (subject to the terms of the license) forever. Some social code might dictate that the kernel developers should comply with his demands, but there would be no legal basis that I know of.

good - I am glad

[suezz]

this happened - in todays wonderful world of lawsuits and patents I don't think I want the kernel to load a module that was provided by a person who signed an nda. thanks kernel developers. second my logitech webcam pro 4000 works just fine. I always had problems getting the pwcx to work and when I did I didn't notice a big difference - but that just may be me. I hope they don't remove the pwc module because of this person's request. It's GPL - so they don't have to - can't they put in this guys rant from the website in the source code and say the maintainer is now someone else. that would explain to everyone what is going on with support for the module and would clear his name like he is worried about. I think this will be good for the kernel overall - the less proprietary crap and nda's the better.

Re:good - I am glad

[suezz]

yes - I am replying to my own post - I have just read some of the emails threads from the guy on the kernel list and I think he is being a bit of a zealot and I say so long - linux does not need individuals who think they are bigger than the whole. why can't the kernel maintainers do something similiar to what the distros did with X11. just cut your losses now and keep what you have in the kernel and try to get support for the compression some other way. you can keep what you have in the kernel like as of today's date or something and just take his name out of source or like above just put the explanation in the source. he is just being an ass about it wanting everything out of the kernel that is currently there under the gpl. I wouldn't feel like this is stealing - I don't agree with the emails who said that - it is just a disagreement for future development. This is one individual trying to force his way on the kernel - that is just not right - even Linus doesn't do that -

Re:good - I am glad

[Atzanteol]

You didn't notice a difference with pwcx? On my Logitech camera it was the difference between something like a 320x200 resolution vs. 640x480 resolution. I'd say that's significant.

Re:Bye general computing, hello do what we tell yo

[Anonymous Coward]

It's tougher to switch OSes [...], but [...] I certainly will.

This doesn't seem like much of a threat against linux since you seem to be using Windows. ... refused to let me open certain files like .exe files ...

Alternatives?

[omega9]

After reading the rant^H^H^H^Hexplaination, it seems like the current two-part design is a product of Phillips still wanting to protect it's IP. There's enough open source code to get the cams working, but if you realy want all the wiz-bang you'll need their proprietary binary module.

If I were Phillips, I'd be pretty pissed. They have a product whos inner workings they, understandably, don't want to fully release just yet. There's enough code out there to drive the cams with pure open-source, but they've also been kind enough to provide a binary only interface to take advantage of more features.

It's kinda like:

Phillips: "We want to provide you with functionality, but we also have obligations to our internals and share holders, so we'll do what we can and meet you half way."

Kernel team: "Yeah, all that time we talk about wanting better hardware support? We were just fucking with you. Go home and die."

I understand the reason the hook was taken out of the kernel, and I can fully appreciate the intentions of doing so, but regardless of the technicalities, what kind of message does this send to Phillips, and, more importantly, other companies like it now and in the future?

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.

Re:Alternatives?

[JohnFluxx]

The situation sucks all round. I'm just saying that philips didn't exactly bend over backwards.

Just had a quick google, and found that webcam.sourceforge.org, which contains the quote:

"The CPiA, or Color Processor Interface ASIC, is made by the company STMicroelectronics (was the Sottish company VLSI Vision Ltd. This is the documentation I have received from VLSI Vision respectively from STM. "...

So actually yeah, other companies are giving docs.

Re:Alternatives?

[jejones]

Apart from the question of "purity," there's also a question of security. How am I to know that there's not a back door of some sort planted in a binary-only driver?

("Nobody's going to take the time to look at the source," you say? I'm sure someone will... and if people are sufficiently worried about security, then it may be profitable for someone to do the Linux equivalent of Underwriters Laboratories, and certify software.)

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.

Re:Tantrum

[jbolden]

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

There is a GPLed work which incorperates his code: The kernel itself.

Correction on your sig

[b-baggins]

The actual quote is:

A government big enough to give you everything you want is a government big enough to take from you everything you have.

It was made by Gerald Ford.

http://www.brainyquote.com/quotes/quotes/g/geral dr fo113300.html

Re:Correction on your sig

[Paradise Pete]

It was made by Gerald Ford

I think maybe ol' Jerry was "inspired" by the original.

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

Very Disappointed

[SirPrize]

I have to say that I'm very disappointed with what has happened. I think it's reasonable to have a lower-version open-source version, and then a binary-only higher-quality version. Because of the stance of the kernel developers in removing the hook to allow the higher-quality version, they've forced the author to pull the plug on the lower-quality driver as well. I was very impressed by the quality (640x480 with very high framerate) provided by my webcam (Logitech Zoom) under Linux using the PWCX module. `

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

not that choice

[Anonymous Coward]

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 not about *that* choice though. In general Open Source is obviously not about your choice to use any hardware you want, otherwise you might have noticed that you still don't have the choice to run hardware for which no F/OSS drivers exist.

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

[Usquebaugh]

I have one of the very nice Logitech Orbit cameras as well as a PRO3000. I was thinking of going getting a second Orbit to do Stero vision, I probably won't.

If I'm reading your post correctly you're saying that the 640x480 mode is just a software manipulation of the 160x120 video stream?

If ths is the case then quite probably this is why Phillips doesn't want the driver opened.

Can you explain the lower fram rate for 640x480 compared to 160x120?

I'll go an rip my Pro3000 and check the specs for the CCD.

Re:advice requested - a potential loss for LavaRnd

[josepha48]

I'd suggest that if this is your request, that you take over maintainership of the pwc module. It was released under the GPL so there is no reason that you cannot maintain it now.

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

[Usquebaugh]

Hmmm,

Have you tried this on a Windows machine?

The reason I'm sceptical is that my Pro3000 uses a SONY ICX098AK CCD. The overview and tech specs would tend me to believe that the device can do VGA without software. Why would Phillips/Logitech fake it?

Re:advice requested - a potential loss for LavaRnd

[advocate_one]

correct... just pick it up, and drop the binary hook.. there's nothing he can do about it as he released it under the gpl. And as you've already realised what the proprietary binary bit is doing, you can implement that yourself using your own algorithm in the current module as a user option.

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

[chongo]

To whom / where does one say: "I am willing to maintain the PWC open source code"?

I've hacked kernels for years, even done a bit inside Linux from time to time. I've even pondered writing a /dev/lavarnd kernel module interface (because of statistical DFT Spectral flaws in /dev/random), but that is a different story. :-)

I'd be happy to yank the PWXC hooks and maintain just the existing PWC interface. ... unless somebody else wants to or is doing it already.

Re:advice requested - a potential loss for LavaRnd

[Usquebaugh]

I was hoping to have a test under windows to eliminate the PCWX factor.

I guess I'll have to put mine under a scope here at work and see what I see. I am astonished that Sony/Phillips/Logitech would be so underhand as to advertise a VGA webcam with only 160x120 CCD! I'm also wondering why nobody else has noticed this? The same CCD is being used in a number of differing cameras including some firewire models.

My understanding was that the webcam took the image at 640x480 but dropped the frames per sec due to the bandwidth of USB. I'm pretty sure they never said the camera could do VGA at 30fps, I think 15 was the max with compression. If all they were doing was some simple image manipultation in the driver there would be no need to drop the fps.

My opinion at this stage is that the CCD is 640x480 and the driver does decompression not interpolation. If PWCX was open source I could eliminate that from this issue.

Re:advice requested - a potential loss for LavaRnd

[Carnildo]

You could send a message to the Linux Kernel Mailing List.

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

Re:advice requested - a potential loss for LavaRnd

[0x0d0a]

It could also be due to (unlikely as it sounds) superresolution processing on-camera or on-host that requires multiple frames to be captured.

Re:advice requested - a potential loss for LavaRnd

[Anonymous Coward]

Part of the problem is that when people start changing your code against your wishes and distributing the changes then you have lost control of it.

After working so hard and so long at something, only to have it altered by someone else, who, in their right mind would allow it to continue and allow their name to be associated or used with works that someone else hacks up?

He would be right and it would be reasonable to demand that distribution of such altered works stop.

After allowing some time for cooling off, perhaps someone could ask him if they could take over the project? There are quite a few with a vested interest in keeping pwc in the kernel.

Re:advice requested - a potential loss for LavaRnd

[chongo]

I wish to correct the above. The pwc module only supports 15 fps at 640x480. So the bandwidth is:

640*480*1.5 octets*15/sec = 6912000 octets/sec

Re:advice requested - a potential loss for LavaRnd

[josepha48]

FYI: without the pwcx module the camera only displays resolutions of 160x120. With the pwcx module it then goes UP to 640x480.

If this module goes out of the kernel, then people like me who bought the cam because it could do 640x480 are basically screwed.

So what supported webcams do 640x480 under Linux and do it well?

Re:advice requested - a potential loss for LavaRnd

[Anonymous Coward]

Your assumptions are wrong in many points:

pwcx can do VGA@15fps or CIF@30fps - so datarate (raw) is somewhat about 7MByte/s. Ok, 7 times to much for USB1.1. But now compressions comes into play.

Even a simple 2D-DPCM can remove a lot of redundancy from an image, for typical natural scenes (remember, this is a webcam, not a device for measurement) datarate goes down to 40% (lossless!), so this would be 2.8MByte/s. If you throw away all prediction errors smaller than say +-2, datarate goes down even further, smoothing out much noise, but almost no detail.

There is another way to reduce datarate, and this is redundancy not in the spatial domain (as above), but in the temporal domain. For typical webcam applications, most of the scene is static, so you can just take the previous image and transfer only the difference - motion compensation helps, but it is not needed! The pwc seems to do this, just do some fast movements in front of the camera, and you will see the image becomes blurry. As the movement stops, the image becomes sharp again.

So transferring 640x480@15fps _is_ possible with some tradeoffs, which are not bad for webcam applications.

Instead of making some claims which are badly guessed, you should have measured. The right way to measure the resolution of imaging device are specialized charts, for example the USAF 1951 Test Charts, or a Siemensstern. I did this, an I have measured a vertical resolution of about 400 lines, which is really good, and imho limited by the cheap lens.

Stefan aka Lurchi

Re:advice requested - a potential loss for LavaRnd

[Anonymous Coward]

Hmm the 4x4 pattern could also be coming from the use of a 4x4 DCT grid. Don't have such a camera so I can't test ;P

Seems nobody understood the problem ...

[HawkingMattress]

PCW is *not* a binary module, it's GPL. What the kernel mainteners removed is a hook which could allow to load a decompressor.
This decompressor could have been anything,GPL or not. It just happens that the developper had had acces through a DNA to informations from phillips, which made it possible to make a decompressor, and vastly improve the cam's performance and capacities. Because of the DNA, he had to ship this in binary form only, but it wasn't inside the kernel, it was cleanly separated from the pcw module.
Removing the hook is stupid, since if some people didn't want to load a binary only thing they could still try to make a GPL decompressor, and if some others wanted to load a binary only decompressor using this hook well it was their own choice !
It didn't taint the kernel, only offered to load something into it, whatever it was...

On the other hand, the author states somewhere on the LKML that his DNA with philips expired more than a year ago, but he still doesn't want to release the source because he feels he would loose the thurst phillips gave him.
If the DNA is over well it's over, they didn't put a date on it just because... Sounds like he likes to keep the source for himself to me...
Futhermore the pcw module could still be used without this hook, the cam still worked, but wasn't 100% exploited that's all. Or he could simply have chosen to go userspace and call it a day. But he got pissed and decided to just remove everything.

So if you ask me, both side don't want to listen to each other, act childish and just look dumb. They should both get a life and do something else sometimes...

Re:Seems nobody understood the problem ...

[josepha48]

LOL... DNA... I think its NDA... In reading your post I actually thought he had to give some of his own DNA to get the information ROTFLOL... and it sounded really weird, then I realized that you must have meant NDA ( none disclosure agreement ).

I haven't had my coffee this morning so I'm a little slow at these things :-).

download location

[545fun]

If you have on of these webcams and still want to use the drivers, you can download them (pwc-9.0.2.tar.gz and pwcx-9.0.tar.gz) at http://www.superhomepage.com/pwc/.

They work with my pcvc740k model and linux 2.6.8.1.

By the way-Nvidia, ATI.

[Anonymous Coward]

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

Two words: Nvidia and ATI. Maybe Phillips can borrow their excuses. "There's super-secret figure-it-all-out IP in the driver and we can't tell you." Now can we have into the kernel?

Re:By the way-Nvidia, ATI.

[Proud like a god]

No part of the binary drivers from those companies is in the kernel code. Those companies provide compilable code that wraps against whatever kernel version you have so that their binary code can be executed like other modules/drivers.

Misguided-BSD.

[Anonymous Coward]

"If Linus doesn't recognise this reality I suspect it may eventually fork."

I believe it's called BSD.

Some want to share and modify programs.

[jbn-o]

Some people actually want to share programs with complete corresponding source code. Therefore, they don't like to have proprietary code on their system. There are (as other posters have described) practical problems with non-free programs too.

I hope people don't frame this issue in terms of practical utility (because down that road lies giving up software freedom for whatever is convenient to proprietors) but instead, frame the issue in terms of our ability to do what made the systems we cherish -- preserve our freedom to share and modify software.

Re:Some want to share and modify programs.

[Anonymous Coward]

You say that as if keeping the source open wasn't an issue of practical utility. But of course open source is very much about practical utility. It is rather the hardware manufacturers that are being ideological when they try to close off all documentation of their generic hardware, thus devaluing their own product.

Re:Some want to share and modify programs.

[jbn-o]

I see it as a freedom because I think practical use is ambiguous and limited in scope. But I think you'll find that we agree more than we disagree. You're right: The open source movement very much focuses on practical utility (that movement's message is a development methodology). But they don't always include the users in that message. I want complete source code under an irrevocable license that allows me to share and modify the software. Software freedom is always defined in terms of what a user is allowed to do.

But my experience is that many people don't see it that way; practical utility is defined very narrowly: the debate is framed in terms of immediate use -- "Can I run the thing now?". Lots of people are willing to buy into a monopoly if they want to do something their old computer system won't let them do. These users have been successfully divided and kept helpless by these monopolies.

If we frame the issue of supporting hardware like they do, we'll confuse a monopoly for genuine support (nVidia graphics cards work well, I'm told, when you install their proprietary drivers, if you define "work[ing]" as something other than software freedom). We, as a culture, have to learn to value sharing and modification so that we can make the devices do what we want them to do. This is why I prefer to frame the debate in terms of freedom to do what I want to do, rather than making the device work according to what functions the manufacturer approves of.

He (ahem) VOLUNTEERED.

[Anonymous Coward]

It is interesting that so many people slam the pwc & pwcx modules author for not putting up with what he feels is excessive idealism with regard to kernel purity.

Seems that people fail to realize that the author VOLUNTEERED his work. As such he has no obligation to continue VOLUNTEERING and putting up with crap.

He also claims copyrights on the modules and is free to demand their removal regardless of the GPL. The GPL does not override someone's copyrights, contrary to some ignorant folk's notions.

A lot of commentators seem to make assumptions about the GPL. It's pretty clear from the comments that they have either not read it or do not understand it.

And then there are the vast amount of other ignorant comments which, unfortunately, overshadow the few intelligent ones...

Re:He (ahem) VOLUNTEERED.

[man_ls]

Good point you raised. As the author, he is within his legal rights to terminate the GPL at his discretion, and thus revoke your rights to use and distribute the package.

Re:He (ahem) VOLUNTEERED.

[Anonymous Coward]

This can't be true. If it were, it would be a major hole in the copyright system. I could give you a piece of code under the any license that says you can do whatever you want with the code, but that I still retain the copyright. Then I can revoke your rights after you've exercised them and sue you for infringement.

This has nothing to do with the GPL, so your statement must be wrong. The contributor can't do a thing about code he has already contributed under a specific license. What he can do is make different licensing arrangements for the same code, but that's very different from what you are saying.

Re:He (ahem) VOLUNTEERED.

[Anonymous Coward]

Null statement! You contradict yourself.

I see you did not read the sundry comments stating that his modules must stay with the kernel per the GPL. The response was made relative to those comments.

I see you also do not understand copyright law.

As the copyright holder he has the right to have his modules removed from all future distributions of the kernel. He can also bar anyone from redistributing his modules in the future.

Those who have his modules already will not be required to return them.

These are the same rights that any copyright holder possesses.

Re:He (ahem) VOLUNTEERED.

[Anonymous Coward]

He has already given the kernel maintainers (and everyone else) an irrevocable license (the GPL) to redistribute specific versions of the code. The kernel maintainers can continue to include the module under the terms of the license. Nowhere in the GPL does it say that you must stop distributing if the copyright holder changes his mind -- the entire point of the license is quite to the contrary.

Re:He (ahem) VOLUNTEERED.

[Anonymous Coward]

You must inform Richard Stallman and EFF of this!!!

Hurry!!!

This is far too important to just leave be here!

Especially as EFF has already acknowledged that the rights of copyright holder take precedence over the GPL.

Mr. Stallman discussed this in an effort to allay the fears of copyright holders that their works would be usurped under the GPL and recommended policy to ensure that copyrights are respected.

You _must_ contact RMS at once and inform him of his error!

And tell Linus that he has no right to trademark Linux, too, while you're at it!

But seriously... Your interpretation of the GPL is the same as that which microsoft tells vendors: that the GPL takes away their rights. That is why vendors are afraid to produce anything for Linux.

Both you and Microsoft are wrong.

This annoys me a lot

[twem2]

Okay, I've just ordered one of the webcams this module supports, and now I find that I can't use it with my primary desktop. That annoys me. I made my decision to buy it based on the fact that it was supported.

Okay, I understand why some people want to have a 'pure' kernel, and I understand the technical advantages. But this module is actively maintained and he would try to sort out any problems.

Linux will /never/ make inroads onto the desktop market if it doesn't work out of the box, and deliberately removing support for a common piece of hardware does not help that.
People do not want to have to patch their kernels.

It is Philip's right to ask him to sign an NDA, it is their technology. You may not agree, but the right they exercise is what makes the GPL a valid license.

I also think that he's throwing something of a tantrum by demanding the removal of the code from the kernel. That's a pointless move and seeks to alienate the users even more.

I just wish all the zealots on every side would just get over themselves and realise that people want to use the best software for the job. For the first time in my computing life, Windows has won as the best platform for something. This is a sad day...
I am glad that I have kept a Windows computer around. I never thought I'd say that.

So which webcams -are- well supported by Linux?

[dpp]

And I was just about to buy one of these cameras :(

So, can anyone suggest some webcams which are well supported by Linux? I'd taken a look at several drivers, but the PWC/PWCX ones seemed to be the best.

With some of the others it seemed to be a lottery whether you'd be able to get a webcam with a compatible chipset (no matter what model number the manufacturer might use on the box).

Re:So which webcams -are- well supported by Linux?

[chongo]

Try webcams based on the ov511 module. The LavaRnd project uses the D-LINK DSB-C100 webcam as one of its reference entropy sources because it was "plug and play" for recent 2.4 and all 2.6 kernels. A search at Bizrate shows the DLink webcam going for about $20 US.

Another camera we tested that is "plug and play" for recent 2.4 and all all 2.6 kernels are camera based on the se401 module. In our next release of LavaRnd, we will be adding support for Kensington VideoCAM PC Camera model 67014. This camera is already supported as a normal webcam ... we are just getting around to making it a reference LavaRnd entropy source because someone donated one to the project. These cameras seem to sell from $25 to $41 US. Specs suggest that models 67015 thru 67017 should work as well as model 67014; although we have only tested the 67014 model.

When properly "mis-tuned" and lens capped, these webcams make good entropy sources. And of course, they take reasonable pictures when they are used as they were originally intended to be used. :-)

Our list is by no means complete. There are others we are sure. If anyone has another other well supported webcams, please chime in ...

lazy developer - just pissed its not done his way

[Anonymous Coward]

screw him. there are other ways to do it. he's just cranky that it wasn't done his way.

Pretending Linux doesn't exist is easier, maybe

[grimharvest]

The hardware companies are still are not taking Linux seriously despite it have a marketshare relative to the Mac, and so we still have to rely on the efforts of people like this guy. The kernel team is annoyed, the developer is annoyed, the users are annoyed, and still the corporations are either too lazy or too stupid to port drivers for their products, as if the porting of those drivers would seriously inconvenience them. What's it going to take before they get on the bandwagon? Linux is not just going to go away. It's not shrinking in marketshare, it's growing. It has the backing of many corporations and even gets contributions from the likes of the NSA. What's it going to take for them to stop pretending Linux doesn't exist?

Re:Pretending Linux doesn't exist is easier, maybe

[Anonymous Coward]

What a great idea!

Piss the vendors off. That will turn them round, right?

Re:lazy developer - just pissed its not done his w

[0x0d0a]

And you're capable of doing better?

And willing?

No?

Then I don't see how you have any grounds to complain about him being "lazy". He's an unpaid volunteer giving his work to you.

Re:Bye general computing, hello do what we tell yo

[LordLucless]

Some asshat just thinks the concept it's impure and may cause bugs...wth? It's my decision

Damn straight it is. You want the hook? Use the old kernels that still have it. Or download the kernel source, and stick the hook back in yourself. One of the nice things about Open Source software is if you don't like a decision the developers have made, you can fix it yourself if you are sufficiently motivated.

What is the new best Linux webcam choice?

[0x0d0a]

Can anyone recommend new feasible choices for low-cost video cameras for Linux use? I've been wanting to pick one up for a bit, and the camera I was looking at was an affected model. :-(

I'd really like to get a camera that has an all-GPL driver, if possible.

Re:What is the new best Linux webcam choice?

[JohnFluxx]

you could go to the link in the post you replied to: webcam.sourceforge.net

Re:Bye general computing, hello do what we tell yo

[pocopoco]

*shrug* If you like to play the latest games having a Windows boot is a neccesity. Sorry to say it, but it's still true. For programming I use Linux, and my file server. I hate the GUI (using KDE currently), though. If I copy something, close the app, and then go to paste, for example..gah.

I'd like to see a survey on how many people run both OSes, I'd suspect many more than run Linux alone. ;p So in other words, I'd find someone with only Linux to be the weird one, not the one you'd assume when criticising someone.

Re:Bye general computing, hello do what we tell yo

[Anonymous Coward]

necessity...criticizing...oh, my, we're going to get spelling Nazis as well as Linux purists now ^^

Libusb still new

[0x0d0a]

Libusb is cool, and lets you do lots of stuff that would otherwise be in kernelspace, but was changing not long ago -- I was going to write an X10 libusb controlling program a while back, but the libusb software shipped by Red Hat at the time was missing necessary functionality.

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.

RTFP

[leonbrooks]

Third choice is rewrite the drive to use libusb instead. Which I would do if I had a Phillips camera.

IRL, I'd rather have an Ethernet-connected camera and get decent distance out of the sucker.

If Phillips choose to make their gear hard to work with, they can't expect free support for it. Evolution in action.

As an owner...

[ImaLamer]

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

I own this "$50 web cam" and I love it. Never worked in linux until lately but hey, can't complain the kernel (thus whole OS) is free.

The point is that linux was created as a free alternative to other software (minix). It was written for x86 systems for god sakes, not huge expensive machines.

I see this as a huge step back in term of usability. Linux was made to run on cheap hardware (x86) and now that it's gone somewhat-mainstream and entered the coporate marketshare there is too many problems in supporting *silly* stuff like this.

Maybe this will get Philips to support us, maybe not. I don't care. Personally I find end-user linux (webcam/video) apps lacking. I'm not a programmer so most are useless to me.

But when you complain about "undocumented" anything you forget that much of the hardware supported by the kernel and it's modules are undocumented. Hell, most kernel options are undocumented. There is always going to be a fight between supporting hardware that doesn't want to be anywhere but on Windows systems and people who need it supported.

Let's say I had this camera for security, monitoring a server room. Nothing fancy, just a live picture. Well there goes a shot at $150 system (PC+Camera) that does the job of a $1500 camera. Point is, you can make this camera anything you want once it's plugged into a linux box - the point was supposed to be that I could do anything I want. Now it seems restrictive.

I don't know (and that is a problem too, it's early and I'm just typing.)

Revoking license?

[Anonymous Coward]

In case the answer is "No", then I will:
- demand that the PWC driver is removed from any further Linux kernel releases; Open source or not, it's still _my_ work.

His work that he licensed under GPL (the GPL'ed portion at least). Can he do that?

Even if it's a limited-functionality driver with secrets stuffed into a binary-only module it'll probably help other developers perhaps to develop libusb-based alternative, or to maintain the binary-free subset.

I don't understand..

[21chrisp]

why this is such a big issue and using so many propietary (closed source) kernel modules isn't. I know my nvidia drivers are closed source.. and ATI's are also. Yeah I know this works in a little bit different manner.. but really.. it's the same result: the kernel is linking to closed source code.

In order for Linux to be a viable platform corporations will need to be able to produce drivers for their products (not just volunteers). Of course, many times those drivers will need to closed source. It's hard to fault a company for trying to protect their IP. Sure, it's better for us to have the driver as open source.. but if it's not good for the company gues what? No linux drivers. In the end, Linux is giving the same companies it's trying to prove its product to the big middle finger. The end result will be purely CLOSED source platforms. If open source is unwilling to allow people to create closed source applications for it's platform, then those people will just keep doing things they way they've always done it. It's not like we're giving them motivation to change!