Termination of the Philips Webcam Driver (pwc)

As a third party, I issue a plea for mediation.

Over on the linux-usb-devel mailing list, a spat has arisin
between the Linux 2.6 USB maintainer, Greg K-H, and Nemosoft, the author of the driver (drivers/usb/media/pwc*) for certain Philips-based Web cameras. As a result, Nemosoft has asked that his driver be removed from the Linux 2.6 kernel.

The driver is structured as two modules: an open-source
module, included in the standard Linux kernel for years, which controls the basic operations of the camera chip, and a closed-source module, distributed in object format independently of the Linux kernel, that provides decompression services for proprietary codecs that are used for higher-resolution modes in some Web cameras based on this chip family. A hook in the open-source driver allows decompression modules (codec modules) (which may, after all, be either open source or proprietary) to register with the main driver.

Citing the fact that the only current use of the hook was to
register a non-open-source module, and citing a policy statement by Linux Torvalds (see the discussion on the linux-usb-devel archive for details), Greg K-H removed the hook from Nemosoft's in-kernel driver, and Nemosoft withdrew his driver from Linux.

As a not uninterested bystander (I just invested $200 of my
personal money in Logitech web cameras on the strength of the pwc driver, based on Web research only two days old now!), I appeal for higher-level arbitration in this issue. I, personally, would prefer a pure open-source kernel, and in fact, Nemosoft posted that he has at this time the opportunity to discuss with Philips the possibility of open-sourcing the codecs involved. However, Greg K-H's unilateral decision to excise the pwc codec hook has so infuriated Nemosoft that, unless another maintainer for this driver steps forth, we may be left with no Linux support at all for this popular family of web cameras.

Craig Milo Rogers

It's not up to him to decide. He can step down from his maintainership, but he can't force the driver to be removed.

Yes and no. From a legal standpoint you're right. However, we should also be polite. If he's the sole author, and he asks for it, I think it's reasonable to honor his wishes.

Of course if some new maintainer shows up and decides to infer how the device worked by looking at the original open-source code, that's also clearly fine.

I don't want people to play lawyer. Honoring peoples rights to the code they write is more important than just the law.

Linus

Umm, just because he's piised off we shouldn't removed support for hardware. it's not like the driver suddenly stops from working because it's unmaintained.

Bit rot does occur in unmaintained Linux kernel drivers; I
believe I've seen it happen. More immediately, though, is that the driver suddenly stops working (in effect) for new users who can no acquire a copy of the proprietary codec module, pwcx. Without pcwx, my brand new Logitech Web cameras are likely to be seriously crippled. I didn't get a copy of pcwx before the website that distributed it shut off access.

I'm seriously considering offering Nemosoft money for a
licence for pwcx. Of course, I'd need seperate copies for x86 and x86_64 architectures... Economic rationality rears its ugly head:
the overhead costs might be too high.

Craig Milo Rogers

You didn't read what I wrote.

We don't remove drivers because the maintainers go away. There's tons of drivers that have no maintainer.

We remove drivers because the author _asks_ us to. If the person who wrote the code doesn't want the code in the kernel, that's a pretty big deal.

Linus

What if someone steps up and want to maintain and extend this piece of code ? Will you forbid him (as in "not in my tree") ?

Xav

I'd suggest you contact the people who have worked on that driver (there's certainly people outside of nemosoft, at least according to the changelogs) and see what they feel like and try to gauge how much they were part of driver development.

I'd _really_ prefer not to step on original authors toes.

Quite frankly, the best option is for people who love the driver to plead with the author(s). It's totally pointless to flame him/them, that will just irritate them and make them less likely to be inclined to say "sure, go ahead and maintain the old driver".

But Greg is right - we don't keep hooks that are there purely for binary drivers. If somebody wants a binary driver, it had better be a whole independent thing - and it won't be distributed with the kernel.

Linus

If you read Nemosoft's final driver release (which has been
reposted, and of which I now have a copy), you can see that he was rewriting his code to move the proprietary codecs out of the kernel entirely, and into user-mode libraries to be linked with consenting applications -- he was quite sensitive to the kernel issues involved. Of course, this is still nowhere as good as a wholly open source solution, a position with which I think Nemosoft concurs, based on his messages.

Linus, would you adress a moot issue, please? If Nemosoft (or
someone else) were to release some of the codecs in question as one or more open-source loadable kernel modules (similar to sound card support modules in the ALSA system), while other codecs remain binary-only loadable kernel modules (distributed outside the kernel, but using the same hook as the open-source loadable modules), would the pwc driver and codec extension hook be allowable, in your opinion, please?

Craig Milo Rogers

If he was moving the binary stuff out of kernel space into userspace, do we even need that at all? Once the binary part is out of the kernel, presumably there's no problem any more ... and we could just stick the remains of the driver back in, with no magic hooks any more ...

M.

That sounds quite good, in my opinion.

Clearly open-source code that does it all would be nice, whether in user space or kernel space. But lacking that, a kernel driver that does the basics (ie you can still use it without any binary stuff), coupled with a user library that can decode the compressed frames is pretty good already.

One thing to note that people may not understand: open source is about more than "rabid zealotry" like some people seem to think. Open source is _important_ from a technical angle. Not just looking for bugs and supporting it, but for "small details" like "hey, it works on my ppc64 machine too".

The fact is, Linux has been a hell of a lot more successful at moving to things like x86-64 and ppc64 than Windows will _ever_ be. And the reason is open source drivers.

So guys, this is not about zealotry. This is about hardnosed technical decisions where closed-source binary drivers are actually _detrimental_ to Linux because they have a tendency to lock people into setups that aren't good.

Whenever somebody says "accept the driver to help users", they are missing the big picture. A binary driver SCREWS OVER users on other architectures. It pretty much guarantees that those other architectures will never be supported. (And that's totally ignoring the maintenance issues even on regular x86).

I'd be leery.

In ALSA, the module interface is about open source drivers, and whatever binary modules exist are very much a small detail that almost nobody really needs to care about. It seriously sounds like the PWC case would be different, with the binary codecs being the most important ones. That makes any open-source ones pretty pointless.

So I'd personally much prefer the user mode approach. At that point it's still closed-source, but at least there is not even a whiff of a "hook" inside the kernel.

Linus

Amen.

This has been a big problem in wireless area, where vendors love to provide BLOBs of code which inevitably work only on 32-bit x86.

Jeff

Greetings,

And not even too good to be true. In PWC 9.0 I introduced a RAW mode that passes the compressed stream through unmodified, together with some support ioctl()s.

Well, there's cross-compiling. You're probably not aware of this, but the most recent PWC major version increase included some changes that would make it a lot easier for me to cross-compile the real decompressor core to any platform that GCC supports. The code is (was) turned into a library (.a) which can be used as a user-program library, or turned into a kernel module with a bit of glue code. So far, 6 different platforms in various 'flavors' were supported, and the number was growing.

Still not a perfect solution, but it means less and less people were 'screwed over', with relatively little effort (all they had to do was point me to a cross-compiler toolchain...). I think I was supporting more platforms than nVidia ever will :-P

[snip]

My problem with that is that it makes using such cams a lot harder for both users and developers of webcam tools. Basicly, every tool that wanted to use webcam X that has some binary-only library would need to specifically support it, use probing routines, check which formats are supported, set up the decompressor, push the data through it, etc. Conversely, every user that wanted to use webcams X, Y and Z would need to check first if they are all supported by the program(s) he would like to use.

The point is, the current API for video devices is the Video4Linux of Video4Linux2 interface. It's relative simple one, but it _works_ the same on all hardware, either TV card or webcam. What you're proposing is fragmenting that support into programs that support X, Y or Z, or only a subset, or none, based on whether or not the developer of said tool had the time, skill and desire to incorporate these libraries into their program.

So instead of putting the support burden on one person (me), you want to distribute it among a few dozen software developers. I don't think that's really smart. It also takes the fun out of hacking a small webcam tool together for whatever purpose, if you need a ton of extra tools, libraries and program just to get one image.

A solution could be something like JACK for the ALSA sound cards, but then for video. But you need a compelling reason, and somebody (somebodies) to design, write and maintain it.

Anyway... wether or not PWC was illegal under the GPL, technically undesirable or just not good enough, is irrelevant now. The damage has been done, and that's just sad.

- Nemosoft

On Fri, Aug 27, 2004 at 11:42:30PM +0200, Nemosoft Unv. scribbled:
[snip]

Forgive me if I'm talking bullshit, but wouldn't it be possible for you to route the stream through a device with an entry in /dev/ which would be opened by a userspace daemon which would take the stream from the in-kernel pwc driver, apply all the codec magic to it, and then give it back to the driver in the kernel so that the application that grabs the frames would get the processed data? That way you would need only one userlevel daemon to support the codecs and all the other apps would just read the data from the framebuffer.

regards,

marek

I wonder if something like uinput is possible/desirable for v4l?

Dmitry

Hi!

It would certainly be nice (taking streamed video from net and feeding it to your favouite application?)

Something like jack would be even nicer,
but that's off-topic for l-k.

64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Pardon me for arguing, but my experience says that it need not
be as difficult for the application program as you describe, although a tad complex for the driver & library writer(s). Applications see a user-mode API, and whether the codecs (in this case) reside in the kernel or in their own process need not be of interest to them: it is quite possible to make an API that isolates the application from this detail. Probing routines, interrupt support, etc. would be handled by kernel drivers, which for the purposes of the present discussion we've been assuming are open source kernel modules. The decompression libraries, which may or may not be closed-source, would be loaded from a standard library location using an agreed-upon naming convention.

The mechanics to make this work are well known, although
tedious. The kernel driver(s) will supply an identifier for the type(s) of card(s) that are presently available. The identifier(s) will be use to load a library(s) based on a mapping scheme; here are three common schemes: 1) use the identifier as part of the library name , 2) provide a module map file (ala kernel modules), and 3) scan the available libraries on application startup and have them self-register (ala mozilla).

Distribution of the drivers and libraries is also a well-known
problem. Linux distributions will typically come with certain drivers and/or codes preinstalled (depending upon the purpose of the distribution, the intellectual property issues involved, etc.) Vendors (enlightened ones!) will provide drivers and libraries on the CDROMs (or other media) that accompany their products. Web sites (vendor supported or not) will offer online upgrades for drivers and/or libraries.

Not at all. The application writers might not see any difference
at all from the present V4L2 interface, depending upon the details of the API for encasulating the decompression libraries. There may very well be card-specific features that the applications have to know about, but that issue is independent of the location of the decompression routines.

I'm struggling to compile GnomeMeeting from CVS. I certainly
suffer at times from having to deal with dozens of libraries, each loaded from their own little niche on Sourceforge or Apache.org, etc., for various projects. However, and again please permit me to disagree with you, I don't think that Web camera support will be quite that complex. All you need is a common framework, and the driver(s) and library(s) for the card(s) installed on your machine.

So long as someone is available to maintain the closed-source
codecs (while, we all hope, working in parallel with the manufacturers involved to secure open-source licensing for any currently closed-source components), I am confident that we can put together a team to implement the rest. I would be pleased to be on the team.

Please... don't tell me that you've deleted the source files
for pwcx!!! That would be sad. Also, I hope that you are willing to consider continuing to maintain the closed-source codecs in pwcx for a while longer, under some circumstances. Your expertise and willingness to help others is really the most valuable resource here, and it would indeed be truly sad if it has been exhausted.

Craig Milo Rogers

Suddenly my hopes seem to have paid off after the rumor that you'd switch to ppc64. Indeed the nicest hardware in the world is one of those pieces which have the most troubles running Linux in its full shininess just because some of the components are "supported on Linux" only in form of some binary non-SMP x86 crap or not supported at all. While the latter is not a problem at all[1] the former will always bite people sometimes even *if* they are running the correct architecture. The only way to show protest is to not buy those products at all and let the manufacturer know in clear terms why they've just missed another $50-$50000 deal[2], if enough people are doing this, there's a slight chance that the company will reconsider their screw-up. If people continue using what's there because it "is better than nothing" then all others will be even more treated as idiots because "the drivers obviously work".

[1] Assuming the hardware in question is not a notebook and the component vital.
[2] Depending very much on the price of the product and the quantity.

Servus,
Daniel

pwcx module was never distributed with the kernel, so the whole problem
is with the existence of hooks that it uses in the pwc driver (that is usable on its own). I agree that it's not a good idea to keep hooks in the driver that are unlikely to be used by anything other than proprietary codecs and converters. However IIRC, V4l2 was supposed to have a userspace codec interface, that, if actually implemented, would completely replace the functionality of pwc to pwcx interface -- and do it in a cleaner manner, too.

I really don't understand why it wasn't done already because clearly
there is a need to support devices with builtin compression, both open and proprietary, in a consistent manner. However since it was not done, maybe it's a better idea to use the situation as a testbed for v4l2 codecs interface, and keep the kernel hook until the v4l2 interface with a userspace codec is released as a replacement. Then we can have a usable driver, and codecs will be moved to where they belong.

The issue of codecs being proprietary is separate, and even if they will
be opened, it will be still a bad idea to keep them in the kernel. It also would be inconsistent with other decisions where all kinds of conversions, even trivial ones, were moved into userspace.

Alex

So how come we allow drivers which load binary firmware into the kernel? And there are plenty of them...

There isn't very much difference between binary firmware and the binary module in this case. Lets see what each of these does:

- binary firmware: protects the intellectual rights of the people who designed the chips by not showing anyone how they work by not showing the original program code that drives the chips

- binary module at hand: protects the intellectual rights of the people who designed the chips by not showing anyone how they work by not showing the original program code that drives the extended functionality of the chips

Sound simillar?

IMHO they are identical except that the firmware is downloaded to the hardware and executed by a different cpu while the binary module is executed by the host cpu.

So how come binary firmware is welcome and binary modules which extend functionality are not?

Just curious. (I personally prefer everything to be OSS but I do understand that some companies do not want to do this and I do have sympathy for their reasons in some cases.)

Best regards,

Anton

Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

I was a bit fast, there is the issue of different arhitectures for the host cpu but if the producers of the binary code care they would produce the appropriate binary code for each architecture. I do not know if this is done in this case or not but it certainly is doable...

Best regards,

Anton

Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Not just the different architectures: also different CONFIG options (e.g. SMP vs. UP).

Open Source drivers with binary firmware are `automatically'[*] supported on whatever Linux kernel you want.

Binary-only drivers are supported on one architecture, for one specific kernel version, for one combination of config options.

Although Open Source firmware would be very nice, hardware + firmware can more or less be considered equivalent to ordinary hardware, i.e. the manufacturer _could_ have done everything in hardware. That's similar to CPUs with hardwired logic and CPUs with (programmable) microcode. The firmware has the advantage that you can fix `hardware' bugs without running a new generation of the actual hardware.

Gr{oetje,eeting}s,

Geert

[*] Within reasonable constraints.

P.S. Perhaps I sound a bit more permissive than usual, but it's getting late

     ;-)

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Beause firmware is a clearly separate part.

It's not a part of the kernel at all - it doesn't even run on the same CPU, for christ sake! Firmware if anything is _further_ removed from the kernel than user programs are.

Go back and read this same thread three or four months ago. You are barking up the wrong tree. There is a HUGE difference between a binary kernel module running inside the kernel, and a firmware image running on another CPU entirely behind a bridge.

There's a huge conceptual separation, but there's also an actual _physical_ separation. How much different do you want things to be?

Firmware on a device is logically equivalent to the kernel running on another machine entirely. A USB device firmware is from a logical (and technical) standpoint not really any different than a fileserver running on a different computer.

Linus

Yup.

In that fact's what a lot of modern RAID firmwares are, an RTOS running on a generic CPU. Some NIC firmwares too.

Jeff

Not just modern, old controllers too, eg DAC960 (i960), ExtremeRAID (StrongARM), Compaq Smart-2 (AMD 29k), etc. Hard disks too. Do a strings on Seagate SCSI disk firmware, the 'BOS' RTOS iirc. Intel IXP2x00 network accelerators are Xscale+added bits (there's a port of Fedora for them!).

Linux could be one of several OSes running on any given PC.

regards,

Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
Fortune:
One possible reason that things aren't going according to plan
is that there never was a plan in the first place.

Better still: as more manufacturers adopt embedded Linux for
their chips, there could be several Linuxes (Linuxen?) running on any given PC.

Craig Milo Rogers

On the constructive site of this:
Does anybody have a clue yet of how hard it will be to reverse engineer the protocol from Philips and get this back into the tree again?

Then the author shouldn't have GPL'd it. Its one author who gave irrevocable rights versus tens of thousands of users.

Absolutely. I can't see why it should be other than that unless people want Linux to become more unfriendly and more "ruled" like a big company. People contribute code for free, so they should be allowed to decide whenever they want it to be removed.

Christian Fromme

chris at kaner.shacknet.nu
PGP-Pubkey: http://www.informatik.fh-wiesbaden.de/~cfrom001/pgp/index.html

And what happens to the S/390 users the day IBM says "oh we've changed our mind". If they want to be able to randomly revoke everyone rights they should use an appropriately evil license and say so up front.

You can't change the deal later on.

He is not sole author. Large parts of the code are based on other authors work and simply copied from the standard framework. Please put back the version without the hooks. It is useful to all sorts of people in that form.

When the author GPL'd it he gave up his rights to remove it. Expecting people to clean-room reverse engineer GPL source is a joke.

Alan

Are you willing to stand up for that and be the maintainer for it?

I'm disgusted by how many people have been complaining, yet when I ask people to step up and actually _do_ something about it, people suddenly become very quiet, or continue complaining about it ignoring the fundamental issue.

Everybody (including you, Alan, so don't go hoity-toity on us) has apparently totally ignored my calls for a new maintainer, and asking the people involved who wrote parts of the driver for their input. I quote an email from me:

Date: Fri, 27 Aug 2004 11:13:09 -0700 (PDT)
From: Linus Torvalds <[email protected]>
To: Xavier Bestel <[email protected]>
Cc: Christoph Hellwig <[email protected]>,
Craig Milo Rogers <[email protected]>,
Kernel Mailing List <[email protected]>, [email protected]
Subject: Re: Termination of the Philips Webcam Driver (pwc)

On Fri, 27 Aug 2004, Xavier Bestel wrote:
>
> What if someone steps up and want to maintain and extend this piece of > code ? Will you forbid him (as in "not in my tree") ?

I'd suggest you contact the people who have worked on that driver (there's certainly people outside of nemosoft, at least according to the changelogs) and see what they feel like and try to gauge how much they were part of driver development.

...

I've got _lots_ of emails in my mailbox complaining.

I don't have a _single_ one actually responding for my calls to actually _do_ something about the driver.

Until people turn from whiners to doers, nothing will happen.

Linus

Someone has contacted me and Nemosoft and is willing to be the maintainer, so it looks like this will happen. That person is currently working with Nemosoft to hash out a few issues and should soon be sending a patch in to add the driver back, minus the hook.

At least that's what they say they will do :)

thanks,

greg k-h

Yes.

...

I beg your pardon, but that is not true. I volunteered to be
a maintainer of the open-source pwc driver in one of my messages of the 27th. Quote:

So long as someone is available to maintain the closed-source codecs (while, we all hope, working in parallel with the manufacturers involved to secure open-source licensing for any currently closed-source components), I am confident that we can put together a team to implement the rest. I would be pleased to be on the team.

I then submitted an overall design for a revised open-source
driver, and a graceful transition plan. Please see my message
entitled: "PWC: A Plea for Grace" for details.

I've discussed some of my proposal for maintenance pf pwc with
Nemosoft offline (apparently, I'm not the only one discussing pwc maintenance with Nemosoft offline), and received what I believe is a favorable response.

Craig Milo Rogers