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
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.