OS independant QuickCam driver (FreeBSD top end, but generic back end)
Subject: OS independant QuickCam driver (FreeBSD top end, but generic back end)
From: Paul Traina <pst@Shockwave.COM>
Date: Fri, 1 Mar 1996 20:19:04 -0800 (PST)
From crynwr.com!aliaslinux-connectix-owner Fri Mar 1 23: 19:10 1996
Here's the README:
This is the official release 1.0 of the FreeBSD+ Connectix QuickCam driver.
The code, as-is will run under FreeBSD 2.2-current, however if you're running
2.2-current, be aware that this distribution is already in all 2.2-current
releases dated 2-March-1996 and later.
The driver has been broken up into several files in hopes of making it easier
to use the camera specific code, unchanged, on other platforms.
qcam.c - Free/Net/BSDI specific kernel driver support
qcamio.c - generic camera control logic (the nasty stuff!)
qcamreg.h - command definitions for the camera (generic)
qcam.h - standard ioctl interface for applications (generic)
qcamdefs.h - environment specific glue to keep qcamio.c generic
qcam.4 - manual page for driver
qcamcontrol/ - sample application to control camera and grab
qcamtime/ - the driver can be compiled to store timing
histograms, this program reads them out of BSD
based kernels -- it's only for driver hackers
interested in timing
* register definitions are far from perfect (this driver is reverse
engineered, no documentation from Connectix was available)
* currently bidirectional 4bpp mode isn't quite right yet, it looks
like for every 3 lines we read, we should keep the first and throw
away the second two ... bizzare?
* the system can wait a REALLY long time between sending the xfermode
command and when the first byte is ready -- this makes the driver
unsuitable for full-motion video when running in kernel mode until
we can figure out how to take an interrupt off the camera (which may
not be possible). I've written a user-mode replacement for qcam.c
and will be releasing it as soon as I'm reasonably happy with it.
Running in user mode means we aren't spin-waiting in the kernel
for that first character, but it still sucks CPU down badly.
For people interested in details, it's only the first byte that
takes a long time, the rest of the bytes come down almost
* Some of the work I did on interleaving I/O and data format
conversion has been un-done to make it easier to experiment.
The next release should have everything fully interleaved to
make maximum use of the CPU during data transfers.
Use the code in good health. You're free to do with it as you wish as
long as you follow the Berkeley style copyright. If you make changes,
please feed them back to me, as I'd like to produce a unified distribution
of this driver that works under FreeBSD 2.1, 2.2 and later, NetBSD, BSDI,
and Linux, as well as user-mode versions of the code for experimentation.
Updated versions of the driver should be available from:
Paul Traina email@example.com
Shockwave Engineering 1 March 1996