[Prev][Next][Index][Thread]

Re: Quickcam device driver for Linux


>> Yes, this is true, but ioperm() is very very very *Intel* linux specific.
>> Linux is no longer an Intel-only product, it is running on many many
>> platforms. Also this will not work at all with non-linux.

 Linux simply provides a hook to features found in the Intel chip.
I suspect that many other Unixes on 386's also support something like this.

 This ioperm() and associated functions (inb, outb) are the only 
portability problems for this code.  Contrast that with a device
driver would would have three orders of magnitude more OS dependent code
in it.  


>> you have a total of about 300K or
>> more of data per second traveling through the network layer of the kernel
>> continuously, I'm not so sure I'd be so quick to call that insignificant.

 I don't know of that is significant or not (especially when contrasted
against the high cost of the polling loops needed for capturing a picture
in the first place).   But in any event it would be easy to special
case the situation where the client and server were both on the 
same machine.  In this case they could used a shared memory block
to transfer the data.  This eliminates the cost of the transfer
from server to client.  Contrast that to the device driver solution
where you would capture into kernel memory and then have to copy
the data to user space.    But I'll ignore this cost and say 
that the cost of the device driver and the camera server solutions
are very similar, so we'll eliminate that as an issue.


>> Why don't we do this with ethernet cards or video cards or audio
>> cards or hard disk controller cards? Why is the QuickCam(tm) perceived to
>> be so different from any other type of device that they don't fit the
>> normal device interface model? Excuse me, but I just don't understand this
>> perception......
 
 There are many many reasons why disks and network cards need device
drivers.    There is no reason that the Quickcam needs a device driver
(the current set of quickcam programs being evidence of that).
Could a device driver be written for the Quickcam? Yes, and we have an 
existance proof for that.    

So if you believe that we have limited resources to develop quickcam
interface code, the question is whether the time is best spent 
working on a device driver or something else (like the camera server).

I'll tell you why working on the device driver is a bad idea:

The Quickcam is made by one company, its low level interface is designed by
that company, it follows no standard and it is subject to drastic change
from revision to revision.   It is unlike any other device you have
on your machine.

Peoples' interest with the Quickcam comes and goes.  Mike, you may 
write a great device driver for the current color cam and then six
months from now be off doing something else.

Meanwhile the Linux kernel folks will change around how device drivers
work and your driver will cease to work in the newest kernel.  
Or, perhaps, Connectix will come out with a better color camera (or 
the decompression algorithm) your driver will cease to work on that.  
You won't be around to 
fix the driver and there may be no one else who wants to undertake this.
As a result the old qcam code will be dusted off and people will
start making mods to it since nearly everyone feels comfortable
hacking on that.   So things will diverge and the new stuff will
be in the qcam code and people with old kernels will still use the driver
version.  

Basically to support a device driver you need a really large user
(and device-driver hacker) community and a stable hardware platform.   
You have neither with the Quickcam.

But I'm not saying that people shouldn't write a device driver.
I think that it is an interesting project.   Just don't be disappointed
if it doesn't catch on.  I need my Linux machine running 100% of the time
and I know from personal experience that the quickcam can be flakey
(not respond correctly to commands)  so I'd be concerned that the driver would
not handle all these cases gracefully and wedge my machine.    
It will take lots of testing with lots of quickcams to ensure that it
can handle the various quirks.

All in all I think that the best interface to the quickcam is still
the user-mode process so that's were I'll be spending my time.


-sean foderaro
References: