Preliminary

Support for FireWire cameras is being written for the QNX operating system.

The application-level view

From the application's perspective, FireWire cameras look like openable devices. They appear in the directory /dev/fw0 and can be opened. Various device control functions can be sent to them, and they can be read. Normal operation is to open the device, command the taking of a frame with a device control function, and reading a frame.

Complexities

Behind all this is a rather excessive amount of machinery.

Hot-plugging and device discovery

FireWire is a hot-pluggable bus. It's possible for devices to be plugged in, unplugged, or for something on the bus to reset the bus. There are no permanent device numbers. Devices are thus identified by manufacturer, product code, and serial number. Here's an example:

This FireWire bus has four nodes. Two are Unibrain cameras, model 61 (the "Fire-I"). One is a PC with a Pinnacle Micro machine running Windows 2000. The machine on which this "ls" was run, a PC running QNX, does not appear; you can't talk to the node you're on.

There's no way to tell which device is which other than by keeping track of serial numbers. Symbolic links can be useful here.

Camera setup

Various camera setup functions must be performed before taking a picture and reading it.

[***MORE***]

Attempts to read before completing setup return the Posix status ENOTCONN. If a camera is unplugged and plugged back in, it loses its settings, so in that situation ENOTCONN is also returned. Performing setup again will restore normal operation.

Error recovery

A bus reset or an I/O problem is reported as a Posix status of EIO. This is recoverable. Taking another frame and reading it should work. Any partially-read frame should be discarded.

If a device is actually unplugged, loses power, or crashes, the situation is more difficult. Attempts to talk to an unplugged device return a status of ENODEV. New open attempts return ENODEV, and when the last open descriptor has been closed, the device disappears from the /dev/fw0 directory.

But the device might come back. If the application does not close the open descriptor after an ENODEV error, and the device is plugged back in, it will become readable again. But the device will have forgotten its internal setup parameters. So ENOTCONN is returned, indicating that the device needs to be set up again. ENOTCONN is returned only for read, not devctl.

Thus, a minimal recovery strategy is to retry all EIO, ENODEV, and ENOTCONN errors after a time delay. The retry should perform the entire setup sequence for the camera and take a new frame before reading again. Closing and reopening the device is also an option, but note that the device disappears from the directory when unplugged and closed.

Streaming

FireWire digital cameras are streaming devices, even when operated one frame at a time. This complicates operation. The actual image data transfer is one-way, with no acknowledgements.

Internals

The support program is a QNX resource manager program named "devfw-ohci". While it should be integrated into the QNX automatic configuration system, it currently is not.

The driver currently contains software from several sources. It uses the Mindready SEDnet LLA interface to the FireWire controller. This is a commercial product, but it doesn't do much. All it really does is provide a very low level interface to the controller chip.

This resource manager supports internal device interface classes for different classes of devices. Currently, the only one supported is 1394 DV-type cameras, but this may change.

Camera support is provided using the "dc1394" library used for Linux. This library consists mostly of functions which issue the appropriate camera commands for various camera modes.