Writing a Device Driver for Video-Capture - Rare information..valuable one

In order to explain the video-capture interface I will use the example of a camera that has no tuners or
audio input. This keeps the example relatively clean. To get audio capabilities, you can combine this
month’s driver with last month’s driver example.
Before I get into the details of video-capture devices, a little background on the technology is in order.
Full-motion video, even at television resolution (which is relatively low) is resource-intensive. These
devices continually pass megabytes of data every second from the capture card to the display. Because
copying this amount of data through a user application is often unfeasible, several alternative
approaches to television tuners have been developed.
The first is to transfer the television image onto the video output directly. This is also how some add-on
3D-rendering cards work, dropping the video into any chosen rectangle of the display. These cards,
which include most MPEG-1 cards that use a feature connector, aren’t very friendly in a windowing
environment. They don’t understand windows and clipping rectangles, which means that the video
window is always on top of the display.
Chromakeying is a technique used by cards to get around this. It is an old television mixing trick in
which you mark all the areas you wish to replace with a single clear color not used in the image — TV
people use an incredibly bright blue for this, while computing people tend to use a particularly virulent
purple. This is because bright blue occurs on the desktop, and anyone with virulent purple windows has
another problem besides their TV overlay.
The third approach is to copy the data from the capture card to the video card, but to do it directly
across the PCI bus. This relieves the processor from doing the work but does require some intelligence
on the part of the video-capture chip, as well as a suitable video card. Programming and debugging
these cards can be extremely tricky. There are some complicated interactions with the display, and you
may also have to cope with various chipset bugs that show up when PCI cards start talking to each
other directly (rather than via the CPU).
To keep our example fairly simple we will assume a card that supports overlaying a flat rectangular
image onto the frame-buffer output, uses chromakey for selecting the region on which to draw, and can
also capture video into processor memory.
The functions supported by our video-capture driver are shown in Listing One.
Listing One: Video-capture Driver
static struct video_device my_camera
{
“My Camera”,
VID_TYPE_OVERLAY|VID_TYPE_SCALES|VID_TYPE_CAPTURE|
VID_TYPE_CHROMAKEY,
VID_HARDWARE_MYCAMERA,
camera_open.
camera_close,
camera_read,
NULL, /* no write */
camera_poll,
camera_ioctl,
NULL, /* no special init function */
NULL /* no private data */
};
We are going to need a read function, which is used for capturing data from the card, and a poll
function so that a driver can wait for the next frame to be captured.
There are several additional video-capability flags that did not apply to the radio interface. These are:
VID_TYPE_CAPTURE: We support image capture.
VID_TYPE_TELETEXT: A teletext capture device (vbi[n])
VID_TYPE_OVERLAY: The image can be directly overlaid onto the frame buffer.
VID_TYPE_CHROMAKEY: Chromakey can be used to select which parts of the image to display.
VID_TYPE_CLIPPING: It is possible to give the board a list of rectangles to draw around.
VID_TYPE_FRAMERAM: The video capture goes into the video memory and actually changes it.
Applications need to know this so they can clean up after the card.
VID_TYPE_SCALES: The image can be scaled to various sizes, rather than being a single fixed size.
VID_TYPE_MONOCHROME: The capture will be monochrome. This isn’t a complete answer to the
question, since a mono camera on a color capture card will still produce monochrome output.
VID_TYPE_SUBCAPTURE: The card allows only part of its field of view to be captured. This
enables applications to avoid copying all of a large image into memory when only some section is
relevant.
We set VID_TYPE_CAPTURE so that we are seen as a capture card, VID_TYPE_CHROMAKEY so that
the application knows that it is time to draw in particularly virulent purple, and VID_TYPE_SCALES
because the video can be resized.