Termination of the Philips Webcam Driver (pwc)

Termination of the Philips Webcam Driver (pwc)

[Craig Milo Rogers]

	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

Re: Termination of the Philips Webcam Driver (pwc)

[Christoph Hellwig]

On Thu, Aug 26, 2004 at 04:32:53PM -0700, Craig Milo Rogers wrote:
> 	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.

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.

Re: Termination of the Philips Webcam Driver (pwc)

[Linus Torvalds]

On Fri, 27 Aug 2004, Christoph Hellwig wrote:
> 
> 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

Re: Termination of the Philips Webcam Driver (pwc)

[Christoph Hellwig]

On Thu, Aug 26, 2004 at 05:03:42PM -0700, Linus Torvalds wrote:
> 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.

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.

Re: Termination of the Philips Webcam Driver (pwc)

[Craig Milo Rogers]

On 04.08.27, Christoph Hellwig wrote:
> On Thu, Aug 26, 2004 at 05:03:42PM -0700, Linus Torvalds wrote:
> > 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.
> 
> 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

Re: Termination of the Philips Webcam Driver (pwc)

[Linus Torvalds]

On Fri, 27 Aug 2004, Christoph Hellwig wrote:
> 
> 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.

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

Re: Termination of the Philips Webcam Driver (pwc)

[Xavier Bestel]

Le ven 27/08/2004 à 19:28, Linus Torvalds a écrit :

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

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

Re: Termination of the Philips Webcam Driver (pwc)

[Linus Torvalds]

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

Re: Termination of the Philips Webcam Driver (pwc)

[Craig Milo Rogers]

On 04.08.27, Linus Torvalds wrote:
> 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.

	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

Re: Termination of the Philips Webcam Driver (pwc)

[Linus Torvalds]

On Fri, 27 Aug 2004, Craig Milo Rogers wrote:
> 
> 	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 

That sounds quite good, in my opinion. 

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

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

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

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

Re: Termination of the Philips Webcam Driver (pwc)

[Jeff Garzik]

Linus Torvalds wrote:
> 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).

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

Re: Termination of the Philips Webcam Driver (pwc)

[Nemosoft Unv.]

Greetings,

On Friday 27 August 2004 21:06, Linus Torvalds wrote:
> On Fri, 27 Aug 2004, Craig Milo Rogers wrote:
> > 	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
>
> That sounds quite good, in my opinion.

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.

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

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

> > 	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?
>
> I'd be leery.

[snip]

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

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

Re: Termination of the Philips Webcam Driver (pwc)

[Marek Habersack]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

On Fri, Aug 27, 2004 at 11:42:30PM +0200, Nemosoft Unv. scribbled:
[snip]
> > 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.
> 
> 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.
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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Termination of the Philips Webcam Driver (pwc)

[Dmitry Torokhov]

On Friday 27 August 2004 05:49 pm, Marek Habersack wrote:
> On Fri, Aug 27, 2004 at 11:42:30PM +0200, Nemosoft Unv. scribbled:
> [snip]
> > > 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.
> > 
> > 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.
> 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.
> 

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

-- 
Dmitry

Re: Termination of the Philips Webcam Driver (pwc)

[Pavel Machek]

Hi!

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


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         

Re: Termination of the Philips Webcam Driver (pwc)

[Craig Milo Rogers]

On 04.08.27, Nemosoft Unv. wrote:
> > 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.
> 
> 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.

	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.

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

	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.

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

	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.

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

	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.

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

	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

non-i386 architectures (Re: Termination of the Philips Webcam Driver (pwc))

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On 27.08.2004, at 21:06, Linus Torvalds wrote:

> 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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: Termination of the Philips Webcam Driver (pwc)

[Martin J. Bligh]

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

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.

Re: Termination of the Philips Webcam Driver (pwc)

[Alex Belits]

On Fri, 27 Aug 2004, Linus Torvalds wrote:

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

  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

Re: Termination of the Philips Webcam Driver (pwc)

[Anton Altaparmakov]

On Fri, 27 Aug 2004, Linus Torvalds wrote:
> 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.

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/

Re: Termination of the Philips Webcam Driver (pwc)

[Anton Altaparmakov]

On Fri, 27 Aug 2004, Anton Altaparmakov wrote:

> On Fri, 27 Aug 2004, Linus Torvalds wrote:
> > 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.
> 
> 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.

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

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

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/

Re: Termination of the Philips Webcam Driver (pwc)

[Geert Uytterhoeven]

On Fri, 27 Aug 2004, Anton Altaparmakov wrote:
> On Fri, 27 Aug 2004, Anton Altaparmakov wrote:
> > On Fri, 27 Aug 2004, Linus Torvalds wrote:
> > > 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.
> >
> > 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.
>
> 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...

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 -- geert@linux-m68k.org

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

Re: Termination of the Philips Webcam Driver (pwc)

[Linus Torvalds]

On Fri, 27 Aug 2004, Anton Altaparmakov wrote:
> 
> So how come we allow drivers which load binary firmware into the kernel?  
> And there are plenty of them...

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.

> There isn't very much difference between binary firmware and the binary 
> module in this case. 

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

Re: Termination of the Philips Webcam Driver (pwc)

[Jeff Garzik]

Linus Torvalds wrote:
> Firmware on a device is logically equivalent to the kernel running on
> another machine entirely.

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

Re: Termination of the Philips Webcam Driver (pwc)

[Paul Jakma]

On Fri, 27 Aug 2004, Jeff Garzik wrote:

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

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.

> 	Jeff

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	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.

Re: Termination of the Philips Webcam Driver (pwc)

[Craig Milo Rogers]

On 04.08.28, Paul Jakma wrote:
> Linux could be one of several OSes running on any given PC.

	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

Re: Termination of the Philips Webcam Driver (pwc)

[Norbert van Nobelen]

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?

On Friday 27 August 2004 20:13, you wrote:
> 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'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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Termination of the Philips Webcam Driver (pwc)

[Alan Cox]

On Gwe, 2004-08-27 at 18:28, Linus Torvalds wrote:
> 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.

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

Re: Termination of the Philips Webcam Driver (pwc)

[chris]

Linus Torvalds <torvalds@osdl.org> wrote:

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

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

Re: Termination of the Philips Webcam Driver (pwc)

[Alan Cox]

On Sad, 2004-08-28 at 10:26, chris wrote:
> 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.

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.

Re: Termination of the Philips Webcam Driver (pwc)

[Alan Cox]

On Gwe, 2004-08-27 at 01:03, Linus Torvalds wrote:
> 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.

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

Re: Termination of the Philips Webcam Driver (pwc)

[Linus Torvalds]

On Sun, 29 Aug 2004, Alan Cox wrote:
> 
> 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.

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 <torvalds@osdl.org>
	To: Xavier Bestel <xavier.bestel@free.fr>
	Cc: Christoph Hellwig <hch@infradead.org>,
	    Craig Milo Rogers <rogers@isi.edu>,
	    Kernel Mailing List <linux-kernel@vger.kernel.org>,
	    webcam@smcc.demon.nl
	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

Re: Termination of the Philips Webcam Driver (pwc)

[Alan Cox]

On Sul, 2004-08-29 at 19:09, Linus Torvalds wrote:
> Are you willing to stand up for that and be the maintainer for it?

Yes.

Re: Termination of the Philips Webcam Driver (pwc)

[Greg KH]

On Sun, Aug 29, 2004 at 11:09:22AM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 29 Aug 2004, Alan Cox wrote:
> > 
> > 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.
> 
> Are you willing to stand up for that and be the maintainer for it?

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

Re: Termination of the Philips Webcam Driver (pwc)

[Craig Milo Rogers]

On 04.08.29, Linus Torvalds wrote:
> 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 don't have a _single_ one actually responding for my calls to actually 
> _do_ something about the driver.

	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

Re: Termination of the Philips Webcam Driver (pwc)

[Koos Vriezen]

On Fri, 27 Aug 2004, Linus Torvalds wrote:
> On Fri, 27 Aug 2004, Christoph Hellwig wrote:
> >
> > 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.

Doubtfully of course. I maintain a small OSS applicatione and although
it sucks, it wouldn't be there where it is now w/o input from others.
Some are better at writing code, others making patches and others
complaing why XYZ doesn't work. But all do contribute. 
Imho it would be very unpolite to them to just say, thanks for
everything but this app is dead and btw. I removed all references to it.
Please play be the rules, GPL is GPL period (and don't make this a weak
spot for OSS by being soft).

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

I'm sure this will resolve one day (in the meantime, I've put what I had
on my hd on http://www.xs4all.nl/~jjvrieze/pwc.html, please alert if the
md5sum are incorrect for those having this somewhere too).

Koos

Re: Termination of the Philips Webcam Driver (pwc)

[Marcus Metzler]

>>>>> "Koos" == Koos Vriezen <koos.vriezen@xs4all.nl> writes:

    Koos> On Fri, 27 Aug 2004, Linus Torvalds wrote:
    >> On Fri, 27 Aug 2004, Christoph Hellwig wrote:
    >> >
    >> > 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.

    Koos> Doubtfully of course. I maintain a small OSS applicatione
    Koos> and although it sucks, it wouldn't be there where it is now
    Koos> w/o input from others.  Some are better at writing code,
    Koos> others making patches and others complaing why XYZ doesn't
    Koos> work. But all do contribute. Imho it would be very unpolite
    Koos> to them to just say, thanks for everything but this app is
    Koos> dead and btw. I removed all references to it.  Please play
    Koos> be the rules, GPL is GPL period (and don't make this a weak
    Koos> spot for OSS by being soft).

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

    Koos> I'm sure this will resolve one day (in the meantime, I've
    Koos> put what I had on my hd on
    Koos> http://www.xs4all.nl/~jjvrieze/pwc.html, please alert if the
    Koos> md5sum are incorrect for those having this somewhere too).

Under what license were the binary modules distributed ?

Marcus

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/
 |>>>             Quis custodiet ipsos custodies                 <<<|

Re: Termination of the Philips Webcam Driver (pwc)

[lkml-mail]

We have heard in several comments to the effect:

        pwc us useless without pwcx

While we don't want/intend to take sides in the pwcx/kernel dispute,
we want to make it clear that these claims are simply not true.
The pwc driver is very useful without pwcx.

The LavaRnd project uses webcams with lens caps an entropy sources
for generating random numbers (see http://www.lavarnd.org).  One of
our reference webcams is the Logitech QuickCam 3000 Pro - pwc730 webcam
(see http://www.lavarnd.org/developer/pwc730.html).

    [[You may have heard of the SGI classic lavarand that used
      Lava Lite(R) lamps to generate seeds.  LavaRnd generates
      random numbers by way of webcams instead of Lava Lite lamps.
      See: http://www.lavarnd.org/news/lavadiff.html for differences]]

LavaRnd uses only the pwc module.  In fact our hotplug script install
script does an rmmod of the pwcx module.  This is because we discovered
that the pwcx module reduced the entropy that the webcams provided.
The pwcx module made the webcam a poorer entropy source.

Please do not remove the pwc module from the Linux kernel.  Our users
depend on pwc without pwcx.

We (LavaRnd) do not want to take sides in this PWC/PWCX kernel dispute. If
this posting appears that way, then we apologize.  It is our hope
that some solution that is satisfactory to both sides can be reached.

We would be happy to discuss ways that the pwc might be maintained
in the linux kernel.  If we can help, please ask us (see
http://www.lavarnd.org/about-us/contact-us.html for our EMail address).

chongo (Landon Curt Noll) /\oo/\

Re: Termination of the Philips Webcam Driver (pwc)

[Greg KH]

On Fri, Aug 27, 2004 at 07:16:18PM -0700, lkml-mail@asthe.com wrote:
> 
> We would be happy to discuss ways that the pwc might be maintained
> in the linux kernel.  If we can help, please ask us (see
> http://www.lavarnd.org/about-us/contact-us.html for our EMail address).

Great.  Here's what you can do.  Take the patch availble at:
	http://linux.bkbits.net:8080/linux-2.5/cset@412d8e0cqutBsdGubqorXXCeHHdS2g
and apply it reversed to your kernel tree (with -R as an option to
patch).  That patch has the binary hook already removed.

Then clean up the text a bit to point to you as the maintainer, that no
one should bother the original author anymore, and such.  Cleanup and
change anything else that you think needs to be done to the driver, and
then send me that patch as documented in the
Documentation/SubmittingPatches in the kernel tree.

Then you would be the new maintainer of the driver, and the code would
be back in the kernel tree.

Sound good?

thanks,

greg k-h