I've written a driver for the Logitech QuickCam Web cam. This camera was (is?) popular for PCs, but Logitech did not release MacOS drivers for it. This is an attempt to rectify that situation.
Download version 1.0 of the Logitech QuickCam Web extension (24 kB), drop it into your Extensions folder, and restart. Note that this is copyrighted software. You are licensed to use it only only on your own machines, and you expressly may not redistribute it in any way, shape, or form; though you may of course refer other people to download it from this page.
The extension is a vendor- and product-specific 'usbd' USB native driver and a QuickTime Video Digitizer 'vdig' Component, written in C++ using Metrowerks CodeWarrior. I paid much attention to efficiency of coding and libraries: the entire extension is less than 60 kB in size.
During development I used an 'ndrv' extension which auto-registered the USB driver, and a 'thng' extension with the video Component. Although this facilitated the development process, I strongly resisted having to distribute two separate files because it is poor user interface and little ‘Murphy-proof’. Merging the two proved to be a bit of a challenge, however.
One major obstacle that had to be overcome was the fact that USB drivers are loaded very early in the boot process. It is impossible for the driver to link to the QuickTime shared libraries because they aren't loaded that early. The solution was to split the driver into two separate Code Fragments: the first fragment declares the USB driver and registers the Component, or at least that part of it which implements the Component ‘class’ functions. When a video application instantiates the Component, the second Fragment is connected which is linked to the system libraries that aren't present at early boot time. This actually has a benefit in that most of the overhead of linking is not incurred unless and until the camera is actually used. I register a new Component for each camera. I believe is the right thing to do, though I'm unable to test and verify that.
The second fragment actually links back to the first, because that contains the USB driver code. Since the Code Fragment manager doesn't know to examine the 'cfrg' resource of a native driver file, I was only actually able to get this linking to work by exploiting a feature of the USB Manager which lets USB ‘shims’ register themselves at run-time as shared libraries. A great benefit of the MacOS Code Fragment Manager is this ability to contain multiple independently-linked fragments in a single file, so that the internal structure is hidden from the user.
I've gotten into the habit of using the MacOS StdCLib in preference to Metrowerks' Standard Library (MSL) as much as possible. Since Standard C support is built into and supported by the operating system, having every application and extension include their own private copies of the libraries is just wasteful. Also, I tend to avoid using the more extravagant features of the Standard C++ library. A little bit of extra work then has to be done with the Preferred Executable Format (PEF) initialization to allow exceptions to be thrown across fragment boundaries.
I've gotten out of the habit of using the Component Manager dispatch functions, which are (out of necessity) still implemented in 68k code and hence incur four mode switches per Component call.
The STV610 ASIC which interfaces the image sensor to USB is not documented, though the VV6410 image sensor thankfully is.
All pages under this domain © Copyright 1999-2003 by: Ben Hekster