Linux loses the Philips webcam driver

Posted Aug 27, 2004 17:15 UTC (Fri) by iabervon (subscriber, #722)
Parent article: Linux loses the Philips webcam driver

It seems to me like the generally accepted way to arrange this is to have the driver support a mode where it sends the data compressed in the weird way, and have a userspace binary-only program or library decompress it. It's not the problem of the open source driver or the kernel if the data that a device produces is in some weird proprietary format, if that's what the hardware actually does. For that matter, userspace might want to do something with the data still in that format; I could imagine streaming the data, still encoded, to a different machine (from your desktop machine to your web server?). If the compression is actually worthwhile, you might as well leave it compressed that way in transit.

Ironically, this position was recently expressed by Alan Cox in an unrelated thread about using floating point in the kernel.

Compressed? Fine.

Posted Aug 27, 2004 17:40 UTC (Fri) by ncm (guest, #165) [Link] (4 responses)

Yes. It seems as if this could have been resolved by asking the maintainer to move the proprietary scheiss to user-space, and have the device node deliver compressed material directly. Surely the commands to put the camera into the higher-resolution mode aren't considered secret?

Maybe it's all water under the bridge now, but next time it could be different. It seems that the maintainer was confronted with this in public, and felt he was backed to the wall. It might have been handled much more delicately, and we all would have ended up winning. Not only would we still have support in the kernel, but orders of magnitude more people would be in a position to experiment with reverse-engineering the compression.

Compressed? Fine.

Posted Aug 29, 2004 1:47 UTC (Sun) by lutchann (subscriber, #8872) [Link]

The only binary-only code in the 9.x drivers was a .a file with the decompressor routines. This was linked against some glue code to make pwcx.ko for 2.6 kernels and pwcx.o for 2.4 kernels, but there was also the option to compile the .a file into user-space code and do the "proprietary" decompression in user space. Then you could get the high resolutions with no binary-only code in the kernel.

This is not a technical issue at all; it is a disagreement between Nemosoft and the rest of the community about the tolerance for binary-only modules in the kernel.

Compressed? Fine.

Posted Aug 29, 2004 21:46 UTC (Sun) by jjs (guest, #10315) [Link] (2 responses)

Check the below link to an e-mail to the lkml - Nemosoft plans on doing just that. Following the various threads on lkml, he wanted it pulled because without the driver, pwc was broken, and he didn't want to answer all the "why is my driver broken" questions when the correct solution was fix the problem.

http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/2017...

Author's voice

Posted Aug 30, 2004 13:21 UTC (Mon) by primorec (guest, #2740) [Link]

http://www.smcc.demon.nl/webcam/

Still clueless

Posted Aug 30, 2004 19:08 UTC (Mon) by ncm (guest, #165) [Link]

It sounds like Nemosoft still hasn't figured out what happened, and is blaming the Linux kernel maintainers.

What's odd is that I don't see any hint that he bothered to contact Philips and ask how they feel about abiding by the letter of the NDA, so he could release the source to the decompressor. Instead, he preferred to play chicken with the kernel maintainers because he doesn't agree with their policy. It looks like they recognized that was what he was really up to, and refused to play.