re: load & brightness

On Tue, 23 Jan 1996, Paul Chinn wrote:

> 1. make sure the code that sends commands to start image transfer
> doesn't get interrupted- which I believe can only be done in kernel
> driver

I vote for number 1...  I REALLY think that the entire driver should be 
in the kernel.  I've implemented most of a kernel driver for FreeBSD and 
I'll report my results as soon as I'm done (I'll be a bit delayed 'cause 
I had to return my defective QuickCam for replacement)...

I think we should all talk about implementing xfqcam, qcam, and the other
user programs using a kernel driver.  This will allow the programs to be
abstracted for many operating systems (My driver for example will work
with only minor mods for all of the BSD derivatives).

Also, if we are to standardize on a kernel device based system.  We 
should discuss the interface.  Thomas has layed out an excellent 
framework for a driver in the Linux driver, but I'd like to make 2 comments 
about it (And the user programs that would use it):

1- ioctl's for Brightness, Contrast, White Balance, and Reset should be 
   implemented on a seperate device called /dev/quickcamctl.  I believe 
   this would be better because a SEPERATE user program could be written 
   to control these parameters, thus greatly simplifying apps like 
   MBONE-tools.  For example, a simple (reusable) X program could be left
   running to control the quickcam's brightness, etc-- and programs like nv
   can simply transfer the image from the kernel's quickcam framebuffer.

2- All user programs should expect the devices to be named:
	Main: 	 /dev/quickcam  OR /dev/qc0	Where 0 can be 0, 1, or 2
	Control: /dev/quickcamctl OR /dev/qc0ctl
   Rational:  Shorter devices named like the latter (from above) are more 
		standard under BSD-derivative operating system's,  Also, this
		will allow for multiple quickcam's if installed.


Follow-Ups: References: