📄 driver-reject.html
字号:
<html><head> <title>Linux drivers for Philips USB webcams</title> <link rel="STYLESHEET" href="webcam.css" type="text/css"></head><body><h1>What happened to the driver in the main kernel? It barely works!</h1><p>On April 26th, I send a patch to the linux-usb-devel@ mailing list thatwould (finally) intregrate the open source part of the Philips webcam driverinto the main kernel tree. After waiting a while and seeing a few 2.4.5-prekernels come by without my driver, I nudged Johannes Erdfelt, the currentUSB maintainer, a bit and he re-sent the patch, and indeed it made it into2.4.5-pre5. At that point, Alan Cox (no introduction necessary) freaked out,and unpatched the most crucial part of the driver: the colour conversionroutines.<p>What seems to be the problem? The camera natively delivers the YUV 4:2:0colour format, but not many video tools understand that. So I wrote a coupleof routines in both C and x86 assembly to convert to RGB and some other YUVlook-a-likes. This allows the driver to work with 99.5% of all the tools outthere. However, this conversion is done in kernel space, between the pwccore and the user-interface calls like read() and mmap(), and that is whatAlan does not want. He says it should be done in the user programs, thatthey should be able to pick the 'smartest' format for them, and that kerneldrivers should not contain this kind of crap (his words). He also claimsthis policy has been there since 2.0.<p>Now while I agree that the kernel may not be the best place to put thiscolour conversion routines in (and instead write an easy to use library forthe video tools), I think it's simply unfair to break my driver for thisreason alone, especially considering the following:<ul> <li>Two other webcam drivers that are in the kernel now have (simple) colour conversion routines built-in. <li>Removing all but one palette from my driver will simply make it useless.</ul> <p>Alan says he is planning on removing the routines from the other driversas well for some time. But so far he hasn't, and if my modified driver wouldgo in, it would suddenly be a lot less functional than before, and even lessfunctional than the other drivers! This is simply unacceptable to me: I will<b>not</b> have a crippled driver into the kernel. Therefor, I told Johannesto remove my driver from the source tree until all other drivers have theirconversion routines removed; if this policy will be enforced, fine, but thenit should be applied to all drivers equally. Frankly, I think this will nothappen for a long time, because it will instantly break 90% of the videotools available to end-users (see the E-mail thread below).<p>I've pleaded, I've argumented, I've written long mails about it, and Icannot seem to get through... So far, I've tried not to get mad about this,and stayed polite and all that (this attitude is what got me the deal withPhilips in the first place), but having 1.5 years of work rejected aboutsome policy that never got enforced before, is really infuriating.<hr><p>The full E-mail conversion related to this subject is reproduced here, soyou can read for yourself. I've tried to put the mails in thread-order below.<pre>Date: Wed, 23 May 2001 14:52:08 +0100 (BST)From: Alan Cox <alan @ lxorguk.ukuu.org.uk>To: (Linus Torvalds) <torvalds @ transmeta.com>Subject: Re: Serious bad taste in pre5 patchCc: (Alan Cox) <alan @ lxorguk.ukuu.org.uk>, (Johannes Erdfelt) <jerdfelt @ valinux.com>, webcam @ smcc.demon.nl> On Wed, 23 May 2001, Alan Cox wrote:> > WTF did you merge it ?> Because it was sent to me by the USB maintainer.> > It needs serious brain damage removal before it should go into the tree> I have nothing against an anti-patch, but maybe there should be some> discussion (that I don't wan tto be part of ;)Johannes this is the basic fix up patch. It does the following- Make the driver compile with gcc 2.96/3.0 (fix incorrect abuse of ##)- Remove various other warnings by making a couple of code paths clearer- Remove all the format conversions- Remove the conversion library- Make the compressor symbols versioned. I can see what its trying to do with its binary modules but there is no guarantee the structures will be constant across builds/setups so it doesn't seem wise for the mainstream kernelFormat conversions are explicitly user space and this is very important bothfrom avoding kernel crap (count the number of '-' in the patch) and also toapps because video conferencing tools _need_ to know which formats are native so they can make intelligent performance decisions. H.263 at 15fps is hardenough without the driver lying and doing an expensive cache trashing reprocess of the data first.[As an aside - it might make sense to move all the magic uncompressors into a library not kernel space and use private video formats to indicate them](replies set to exclude Linus as requested)Alan[patch snipped]Date: Wed, 23 May 2001 10:53:06 -0700From: Johannes Erdfelt <jerdfelt @ valinux.com>To: alan @ lxorguk.ukuu.org.uk, webcam @ smcc.demon.nlSubject: Re: Serious bad taste in pre5 patchOn Wed, May 23, 2001, Alan Cox <alan @ lxorguk.ukuu.org.uk> wrote:> > On Wed, 23 May 2001, Alan Cox wrote:> > > WTF did you merge it ?> > Because it was sent to me by the USB maintainer.> > > It needs serious brain damage removal before it should go into the tree> > I have nothing against an anti-patch, but maybe there should be some> > discussion (that I don't wan tto be part of ;)> > Johannes this is the basic fix up patch. It does the following> > - Make the driver compile with gcc 2.96/3.0 (fix incorrect abuse of ##)> - Remove various other warnings by making a couple of code paths clearer> - Remove all the format conversions> - Remove the conversion library> - Make the compressor symbols versioned. I can see what its trying to do with> its binary modules but there is no guarantee the structures will be constant> across builds/setups so it doesn't seem wise for the mainstream kernel> > Format conversions are explicitly user space and this is very important both> from avoding kernel crap (count the number of '-' in the patch) and also to> apps because video conferencing tools _need_ to know which formats are native > so they can make intelligent performance decisions. H.263 at 15fps is hard> enough without the driver lying and doing an expensive cache trashing > reprocess of the data first.I think the patch is missing something. The patch you attached only removesvcvt.h, vcvt_c.c and vcvt_i386.S. It doesn't seem to touch any Makefile's,any symbol versioning or any macro's.Aside from the actual patch, I agree with you. The color conversion inkernel space was a bad precedent on my part. When I wrote the originalCPiA driver, the only applications available made horrible assumptionsabout the device it was using and blindly assumed it would support RGB.I'll go through the other USB v4l apps and see which ones we should removeYUV -> RGB for as well.> [As an aside - it might make sense to move all the magic uncompressors into> a library not kernel space and use private video formats to indicate them]That might be reasonable. I'm not too worried about this since it is justa driver afterall and the extra kernel memory wasted is at the discretionof the user.JEDate: Fri, 25 May 2001 10:48:44 +0200 (MEST)From: "Nemosoft Unv." <nemosoft @ smcc.demon.nl>To: Johannes Erdfelt <jerdfelt @ valinux.com>Subject: Re: Serious bad taste in pre5 patchGreetings,(I磎 reading this after my previous mail to Alan)On 23-May-01 Johannes Erdfelt wrote:> > I think the patch is missing something. The patch you attached only> removes> vcvt.h, vcvt_c.c and vcvt_i386.S. It doesn't seem to touch any Makefile's,> any symbol versioning or any macro's.> > Aside from the actual patch, I agree with you. The color conversion in> kernel space was a bad precedent on my part. When I wrote the original> CPiA driver, the only applications available made horrible assumptions> about the device it was using and blindly assumed it would support RGB.> > I'll go through the other USB v4l apps and see which ones we should remove> YUV -> RGB for as well.Okay, if you do that, I磍l accept removal of the conversion code out of mydriver as well. But boy, are you going to get spammed.... :( - NemosoftDate: Fri, 25 May 2001 09:58:03 +0200 (MEST)From: "Nemosoft Unv." <nemosoft @ smcc.demon.nl>To: Alan Cox <alan @ lxorguk.ukuu.org.uk>Subject: Re: Serious bad taste in pre5 patchCc: webcam @ smcc.demon.nl, (Johannes Erdfelt) <jerdfelt @ valinux.com>, (Linus Torvalds) <torvalds @ transmeta.com>Greetings,On 23-May-01 Alan Cox wrote:>> On Wed, 23 May 2001, Alan Cox wrote:>> > WTF did you merge it ?>> Because it was sent to me by the USB maintainer.>> > It needs serious brain damage removal before it should go into the tree>> I have nothing against an anti-patch, but maybe there should be some>> discussion (that I don't wan tto be part of ;)Agreed. But I *do* want to be part of it.> Johannes this is the basic fix up patch. It does the following> > - Make the driver compile with gcc 2.96/3.0 (fix incorrect abuse of ##)I磎 not sure what you mean by 碼buse⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -