Philips webcam

[Thomas Kaiser]

Derek Broughton wrote:
> Dotan Cohen wrote:
> 
>> On 06/01/2008, Derek Broughton <news at pointerstop.ca> wrote:
>>> No.  Just because it works, doesn't mean it's right.  I can see Linus'
>>> point.
>> Linus is right. He has a very good, valid reason for keeping these
>> drivers out of the kernel. The Linux kernel would be a mess if
>> everything got it. However, the users are right too. They (we) want
>> things to work.
> 
> Yes - but then they have to buy hardware that's certified to work.  In your
> case, I realize you did - but the manufacturer essentially lied.
> 
> Windows users don't buy hardware that won't run their OS.  Apple users
> don't.  Why are Linux users always expecting uncertified hardware to work?
> 
> I realize that it's only a week since I argued that Linux is at fault in the
> issue of the hard drive head-retraction problem, and not the manufacturer,
> but in this case the problem really is the manufacturer - the compression
> software has to come out of the kernel driver into user space, because you
> just can't do that in a kernel.

Derek, yes you are right. The manufacturer should provide a driver or at least 
make the documentation for interested kernel driver developer available.

For the compression thing you are right, too. It should be avoided to do this in 
kernel space. But the problem is that V4L and neither V4L2 does provide a 
interface to hand the raw stream from the cam to user space :-( That's the 
reason why gspca has included a (tiny as possible) JPEG decoder in the kernel 
module. The other problem is that then the user space application has to know 
how to decoded the stream and there are a lot of cam viewer application. So we 
need a decompression (or codec) library where the cam viewer application can 
link to (or dynamically load) to understand the raw stream. Nothing exist in 
Linux, yet :-(

For a lot of cams, gspca is the only way to get them work!

Thomas



-- 
http://www.kaiser-linux.li