Remove videobook.tmpl

This document describes the long-deprecated V4L1 interface.  In-tree, it
can only serve to encourage developers to write drivers to the wrong API.
Remove it in favor of the V4L2 documentation which must surely show up
someday.

Acked-by: Alan Cox <alan@redhat.com>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

2 files changed, 1 insertions, 1655 deletions

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 1615350b7b5..fabc06466b9 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,7 +6,7 @@
 # To add a new book the only step required is to add the book to the
 # list of DOCBOOKS.
 
-DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
+DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml \
 	    kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
 	    procfs-guide.xml writing_usb_driver.xml networking.xml \
 	    kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl
deleted file mode 100644
index 0bc25949b66..00000000000
--- a/Documentation/DocBook/videobook.tmpl
+++ /dev/null
@@ -1,1654 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
-	"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
-
-<book id="V4LGuide">
- <bookinfo>
-  <title>Video4Linux Programming</title>
-  
-  <authorgroup>
-   <author>
-    <firstname>Alan</firstname>
-    <surname>Cox</surname>
-    <affiliation>
-     <address>
-      <email>alan@redhat.com</email>
-     </address>
-    </affiliation>
-   </author>
-  </authorgroup>
-
-  <copyright>
-   <year>2000</year>
-   <holder>Alan Cox</holder>
-  </copyright>
-
-  <legalnotice>
-   <para>
-     This documentation is free software; you can redistribute
-     it and/or modify it under the terms of the GNU General Public
-     License as published by the Free Software Foundation; either
-     version 2 of the License, or (at your option) any later
-     version.
-   </para>
-      
-   <para>
-     This program is distributed in the hope that it will be
-     useful, but WITHOUT ANY WARRANTY; without even the implied
-     warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-     See the GNU General Public License for more details.
-   </para>
-      
-   <para>
-     You should have received a copy of the GNU General Public
-     License along with this program; if not, write to the Free
-     Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-     MA 02111-1307 USA
-   </para>
-      
-   <para>
-     For more details see the file COPYING in the source
-     distribution of Linux.
-   </para>
-  </legalnotice>
- </bookinfo>
-
-<toc></toc>
-
-  <chapter id="intro">
-      <title>Introduction</title>
-  <para>
-        Parts of this document first appeared in Linux Magazine under a
-        ninety day exclusivity.
-  </para>
-  <para>
-        Video4Linux is intended to provide a common programming interface
-        for the many TV and capture cards now on the market, as well as
-        parallel port and USB video cameras. Radio, teletext decoders and
-        vertical blanking data interfaces are also provided.
-  </para>
-  </chapter>
-  <chapter id="radio">
-        <title>Radio Devices</title>
-  <para>
-        There are a wide variety of radio interfaces available for PC's, and these
-        are generally very simple to program. The biggest problem with supporting
-        such devices is normally extracting documentation from the vendor.
-  </para>
-  <para>
-        The radio interface supports a simple set of control ioctls standardised
-        across all radio and tv interfaces. It does not support read or write, which
-        are used for video streams. The reason radio cards do not allow you to read
-        the audio stream into an application is that without exception they provide
-        a connection on to a soundcard. Soundcards can be used to read the radio
-        data just fine. 
-  </para>
-  <sect1 id="registerradio">
-  <title>Registering Radio Devices</title>
-  <para>
-        The Video4linux core provides an interface for registering devices. The
-        first step in writing our radio card driver is to register it.
-  </para>
-  <programlisting>
-
-
-static struct video_device my_radio
-{
-        "My radio",
-        VID_TYPE_TUNER,
-        radio_open.
-        radio_close,
-        NULL,                /* no read */
-        NULL,                 /* no write */
-        NULL,                /* no poll */
-        radio_ioctl,
-        NULL,                /* no special init function */
-        NULL                /* no private data */
-};
-
-
-  </programlisting>
-  <para>
-        This declares our video4linux device driver interface. The VID_TYPE_ value
-        defines what kind of an interface we are, and defines basic capabilities.
-  </para>
-  <para>
-        The only defined value relevant for a radio card is VID_TYPE_TUNER which
-        indicates that the device can be tuned. Clearly our radio is going to have some
-        way to change channel so it is tuneable.
-  </para>
-  <para>
-        We declare an open and close routine, but we do not need read or write,
-        which are used to read and write video data to or from the card itself. As
-        we have no read or write there is no poll function.
-  </para>
-  <para>
-        The private initialise function is run when the device is registered. In
-        this driver we've already done all the work needed. The final pointer is a
-        private data pointer that can be used by the device driver to attach and
-        retrieve private data structures. We set this field "priv" to NULL for
-        the moment.
-  </para>
-  <para>
-        Having the structure defined is all very well but we now need to register it
-        with the kernel. 
-  </para>
-  <programlisting>
-
-
-static int io = 0x320;
-
-int __init myradio_init(struct video_init *v)
-{
-        if(!request_region(io, MY_IO_SIZE, "myradio"))
-        {
-                printk(KERN_ERR 
-                    "myradio: port 0x%03X is in use.\n", io);
-                return -EBUSY;
-        }
-
-        if(video_device_register(&amp;my_radio, VFL_TYPE_RADIO)==-1) {
-                release_region(io, MY_IO_SIZE);
-                return -EINVAL;
-        }		
-        return 0;
-}
-
-  </programlisting>
-  <para>
-        The first stage of the initialisation, as is normally the case, is to check 
-        that the I/O space we are about to fiddle with doesn't belong to some other 
-        driver. If it is we leave well alone. If the user gives the address of the 
-        wrong device then we will spot this. These policies will generally avoid 
-        crashing the machine.
-  </para>
-  <para>
-        Now we ask the Video4Linux layer to register the device for us. We hand it
-        our carefully designed video_device structure and also tell it which group
-        of devices we want it registered with. In this case VFL_TYPE_RADIO.
-  </para>
-  <para>
-        The types available are
-  </para>
-   <table frame="all" id="Device_Types"><title>Device Types</title>
-   <tgroup cols="3" align="left">
-   <tbody>
-   <row>
-        <entry>VFL_TYPE_RADIO</entry><entry>/dev/radio{n}</entry><entry>
-
-        Radio devices are assigned in this block. As with all of these
-        selections the actual number assignment is done by the video layer
-        accordijng to what is free.</entry>
-	</row><row>
-        <entry>VFL_TYPE_GRABBER</entry><entry>/dev/video{n}</entry><entry>
-        Video capture devices and also -- counter-intuitively for the name --
-        hardware video playback devices such as MPEG2 cards.</entry>
-	</row><row>
-        <entry>VFL_TYPE_VBI</entry><entry>/dev/vbi{n}</entry><entry>
-        The VBI devices capture the hidden lines on a television picture
-        that carry further information like closed caption data, teletext
-        (primarily in Europe) and now Intercast and the ATVEC internet
-        television encodings.</entry>
-	</row><row>
-        <entry>VFL_TYPE_VTX</entry><entry>/dev/vtx[n}</entry><entry>
-        VTX is 'Videotext' also known as 'Teletext'. This is a system for
-        sending numbered, 40x25, mostly textual page images over the hidden
-        lines. Unlike the /dev/vbi interfaces, this is for 'smart' decoder 
-        chips. (The use of the word smart here has to be taken in context,
-        the smartest teletext chips are fairly dumb pieces of technology).
-	</entry>
-    </row>
-    </tbody>
-    </tgroup>
-    </table>
-  <para>
-        We are most definitely a radio.
-  </para>
-  <para>
-        Finally we allocate our I/O space so that nobody treads on us and return 0
-        to signify general happiness with the state of the universe.
-  </para>
-  </sect1>
-  <sect1 id="openradio">
-  <title>Opening And Closing The Radio</title>
-
-  <para>
-        The functions we declared in our video_device are mostly very simple.
-        Firstly we can drop in what is basically standard code for open and close. 
-  </para>
-  <programlisting>
-
-
-static int users = 0;
-
-static int radio_open(struct video_device *dev, int flags)
-{
-        if(users)
-                return -EBUSY;
-        users++;
-        return 0;
-}
-
-  </programlisting>
-  <para>
-        At open time we need to do nothing but check if someone else is also using
-        the radio card. If nobody is using it we make a note that we are using it,
-        then we ensure that nobody unloads our driver on us.
-  </para>
-  <programlisting>
-
-
-static int radio_close(struct video_device *dev)
-{
-        users--;
-}
-
-  </programlisting>
-  <para>
-        At close time we simply need to reduce the user count and allow the module
-        to become unloadable.
-  </para>
-  <para>
-        If you are sharp you will have noticed neither the open nor the close
-        routines attempt to reset or change the radio settings. This is intentional.
-        It allows an application to set up the radio and exit. It avoids a user
-        having to leave an application running all the time just to listen to the
-        radio. 
-  </para>
-  </sect1>
-  <sect1 id="ioctlradio">
-  <title>The Ioctl Interface</title>
-  <para>
-        This leaves the ioctl routine, without which the driver will not be
-        terribly useful to anyone.
-  </para>
-  <programlisting>
-
-
-static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
-{
-        switch(cmd)
-        {
-                case VIDIOCGCAP:
-                {
-                        struct video_capability v;
-                        v.type = VID_TYPE_TUNER;
-                        v.channels = 1;
-                        v.audios = 1;
-                        v.maxwidth = 0;
-                        v.minwidth = 0;
-                        v.maxheight = 0;
-                        v.minheight = 0;
-                        strcpy(v.name, "My Radio");
-                        if(copy_to_user(arg, &amp;v, sizeof(v)))
-                                return -EFAULT;
-                        return 0;
-                }
-
-  </programlisting>
-  <para>
-        VIDIOCGCAP is the first ioctl all video4linux devices must support. It
-        allows the applications to find out what sort of a card they have found and
-        to figure out what they want to do about it. The fields in the structure are
-  </para>
-   <table frame="all" id="video_capability_fields"><title>struct video_capability fields</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-        <entry>name</entry><entry>The device text name. This is intended for the user.</entry>
-	</row><row>
-        <entry>channels</entry><entry>The number of different channels you can tune on
-                        this card. It could even by zero for a card that has
-                        no tuning capability. For our simple FM radio it is 1. 
-                        An AM/FM radio would report 2.</entry>
-	</row><row>
-        <entry>audios</entry><entry>The number of audio inputs on this device. For our
-                        radio there is only one audio input.</entry>
-	</row><row>
-        <entry>minwidth,minheight</entry><entry>The smallest size the card is capable of capturing
-		        images in. We set these to zero. Radios do not
-                        capture pictures</entry>
-	</row><row>
-        <entry>maxwidth,maxheight</entry><entry>The largest image size the card is capable of
-                                      capturing. For our radio we report 0.
-				</entry>
-	</row><row>
-        <entry>type</entry><entry>This reports the capabilities of the device, and
-                        matches the field we filled in in the struct
-                        video_device when registering.</entry>
-    </row>
-    </tbody>
-    </tgroup>
-    </table>
-  <para>
-        Having filled in the fields, we use copy_to_user to copy the structure into
-        the users buffer. If the copy fails we return an EFAULT to the application
-        so that it knows it tried to feed us garbage.
-  </para>
-  <para>
-        The next pair of ioctl operations select which tuner is to be used and let
-        the application find the tuner properties. We have only a single FM band
-        tuner in our example device.
-  </para>
-  <programlisting>
-
-
-                case VIDIOCGTUNER:
-                {
-                        struct video_tuner v;
-                        if(copy_from_user(&amp;v, arg, sizeof(v))!=0)
-                                return -EFAULT;
-                        if(v.tuner)
-                                return -EINVAL;
-                        v.rangelow=(87*16000);
-                        v.rangehigh=(108*16000);
-                        v.flags = VIDEO_TUNER_LOW;
-                        v.mode = VIDEO_MODE_AUTO;
-                        v.signal = 0xFFFF;
-                        strcpy(v.name, "FM");
-                        if(copy_to_user(&amp;v, arg, sizeof(v))!=0)
-                                return -EFAULT;
-                        return 0;
-                }
-
-  </programlisting>
-  <para>
-        The VIDIOCGTUNER ioctl allows applications to query a tuner. The application
-        sets the tuner field to the tuner number it wishes to query. The query does
-        not change the tuner that is being used, it merely enquires about the tuner
-        in question.
-  </para>
-  <para>
-        We have exactly one tuner so after copying the user buffer to our temporary
-        structure we complain if they asked for a tuner other than tuner 0. 
-  </para>
-  <para>
-        The video_tuner structure has the following fields
-  </para>
-   <table frame="all" id="video_tuner_fields"><title>struct video_tuner fields</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-        <entry>int tuner</entry><entry>The number of the tuner in question</entry>
-   </row><row>
-        <entry>char name[32]</entry><entry>A text description of this tuner. "FM" will do fine.
-                        This is intended for the application.</entry>
-   </row><row>
-        <entry>u32 flags</entry>
-        <entry>Tuner capability flags</entry>
-   </row>
-   <row>
-        <entry>u16 mode</entry><entry>The current reception mode</entry>
-
-   </row><row>
-        <entry>u16 signal</entry><entry>The signal strength scaled between 0 and 65535. If
-                        a device cannot tell the signal strength it should
-                        report 65535. Many simple cards contain only a 
-                        signal/no signal bit. Such cards will report either
-                        0 or 65535.</entry>
-
-   </row><row>
-        <entry>u32 rangelow, rangehigh</entry><entry>
-                        The range of frequencies supported by the radio
-                        or TV. It is scaled according to the VIDEO_TUNER_LOW
-                        flag.</entry>
-
-    </row>
-    </tbody>
-    </tgroup>
-    </table>
-
-   <table frame="all" id="video_tuner_flags"><title>struct video_tuner flags</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-	<entry>VIDEO_TUNER_PAL</entry><entry>A PAL TV tuner</entry>
-	</row><row>
-        <entry>VIDEO_TUNER_NTSC</entry><entry>An NTSC (US) TV tuner</entry>
-	</row><row>
-        <entry>VIDEO_TUNER_SECAM</entry><entry>A SECAM (French) TV tuner</entry>
-	</row><row>
-        <entry>VIDEO_TUNER_LOW</entry><entry>
-             The tuner frequency is scaled in 1/16th of a KHz
-             steps. If not it is in 1/16th of a MHz steps
-	</entry>
-	</row><row>
-        <entry>VIDEO_TUNER_NORM</entry><entry>The tuner can set its format</entry>
-	</row><row>
-        <entry>VIDEO_TUNER_STEREO_ON</entry><entry>The tuner is currently receiving a stereo signal</entry>
-        </row>
-    </tbody>
-    </tgroup>
-    </table>
-
-   <table frame="all" id="video_tuner_modes"><title>struct video_tuner modes</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-                <entry>VIDEO_MODE_PAL</entry><entry>PAL Format</entry>
-   </row><row>
-                <entry>VIDEO_MODE_NTSC</entry><entry>NTSC Format (USA)</entry>
-   </row><row>
-                <entry>VIDEO_MODE_SECAM</entry><entry>French Format</entry>
-   </row><row>
-                <entry>VIDEO_MODE_AUTO</entry><entry>A device that does not need to do
-                                        TV format switching</entry>
-   </row>
-    </tbody>
-    </tgroup>
-    </table>
-  <para>
-        The settings for the radio card are thus fairly simple. We report that we
-        are a tuner called "FM" for FM radio. In order to get the best tuning
-        resolution we report VIDEO_TUNER_LOW and select tuning to 1/16th of KHz. Its
-        unlikely our card can do that resolution but it is a fair bet the card can
-        do better than 1/16th of a MHz. VIDEO_TUNER_LOW is appropriate to almost all
-        radio usage.
-  </para>
-  <para>
-        We report that the tuner automatically handles deciding what format it is
-        receiving - true enough as it only handles FM radio. Our example card is
-        also incapable of detecting stereo or signal strengths so it reports a
-        strength of 0xFFFF (maximum) and no stereo detected.
-  </para>
-  <para>
-        To finish off we set the range that can be tuned to be 87-108Mhz, the normal
-        FM broadcast radio range. It is important to find out what the card is
-        actually capable of tuning. It is easy enough to simply use the FM broadcast
-        range. Unfortunately if you do this you will discover the FM broadcast
-        ranges in the USA, Europe and Japan are all subtly different and some users
-        cannot receive all the stations they wish.
-  </para>
-  <para>
-        The application also needs to be able to set the tuner it wishes to use. In
-        our case, with a single tuner this is rather simple to arrange.
-  </para>
-  <programlisting>
-
-                case VIDIOCSTUNER:
-                {
-                        struct video_tuner v;
-                        if(copy_from_user(&amp;v, arg, sizeof(v)))
-                                return -EFAULT;
-                        if(v.tuner != 0)
-                                return -EINVAL;
-                        return 0;
-                }
-
-  </programlisting>
-  <para>
-        We copy the user supplied structure into kernel memory so we can examine it. 
-        If the user has selected a tuner other than zero we reject the request. If 
-        they wanted tuner 0 then, surprisingly enough, that is the current tuner already.
-  </para>
-  <para>
-        The next two ioctls we need to provide are to get and set the frequency of
-        the radio. These both use an unsigned long argument which is the frequency.
-        The scale of the frequency depends on the VIDEO_TUNER_LOW flag as I
-        mentioned earlier on. Since we have VIDEO_TUNER_LOW set this will be in
-        1/16ths of a KHz.
-  </para>
-  <programlisting>
-
-static unsigned long current_freq;
-
-
-
-                case VIDIOCGFREQ:
-                        if(copy_to_user(arg, &amp;current_freq, 
-                                sizeof(unsigned long))
-                                return -EFAULT;
-                        return 0;
-
-  </programlisting>
-  <para>
-        Querying the frequency in our case is relatively simple. Our radio card is
-        too dumb to let us query the signal strength so we remember our setting if 
-        we know it. All we have to do is copy it to the user.
-  </para>
-  <programlisting>
-
-
-                case VIDIOCSFREQ:
-                {
-                        u32 freq;
-                        if(copy_from_user(arg, &amp;freq, 
-                                sizeof(unsigned long))!=0)
-                                return -EFAULT;
-                        if(hardware_set_freq(freq)&lt;0)
-                                return -EINVAL;
-                        current_freq = freq;
-                        return 0;
-                }
-
-  </programlisting>
-  <para>
-        Setting the frequency is a little more complex. We begin by copying the
-        desired frequency into kernel space. Next we call a hardware specific routine
-        to set the radio up. This might be as simple as some scaling and a few
-        writes to an I/O port. For most radio cards it turns out a good deal more
-        complicated and may involve programming things like a phase locked loop on
-        the card. This is what documentation is for. 
-  </para>
-  <para>
-        The final set of operations we need to provide for our radio are the 
-        volume controls. Not all radio cards can even do volume control. After all
-        there is a perfectly good volume control on the sound card. We will assume
-        our radio card has a simple 4 step volume control.
-  </para>
-  <para>
-        There are two ioctls with audio we need to support
-  </para>
-  <programlisting>
-
-static int current_volume=0;
-
-                case VIDIOCGAUDIO:
-                {
-                        struct video_audio v;
-                        if(copy_from_user(&amp;v, arg, sizeof(v)))
-                                return -EFAULT;
-                        if(v.audio != 0)
-                                return -EINVAL;
-                        v.volume = 16384*current_volume;
-                        v.step = 16384;
-                        strcpy(v.name, "Radio");
-                        v.mode = VIDEO_SOUND_MONO;
-                        v.balance = 0;
-                        v.base = 0;
-                        v.treble = 0;
-                        
-                        if(copy_to_user(arg. &amp;v, sizeof(v)))
-                                return -EFAULT;
-                        return 0;
-                }
-
-  </programlisting>
-  <para>
-        Much like the tuner we start by copying the user structure into kernel
-        space. Again we check if the user has asked for a valid audio input. We have
-        only input 0 and we punt if they ask for another input.
-  </para>
-  <para>
-        Then we fill in the video_audio structure. This has the following format
-  </para>
-   <table frame="all" id="video_audio_fields"><title>struct video_audio fields</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-   <entry>audio</entry><entry>The input the user wishes to query</entry>
-   </row><row>
-   <entry>volume</entry><entry>The volume setting on a scale of 0-65535</entry>
-   </row><row>
-   <entry>base</entry><entry>The base level on a scale of 0-65535</entry>
-   </row><row>
-   <entry>treble</entry><entry>The treble level on a scale of 0-65535</entry>
-   </row><row>
-   <entry>flags</entry><entry>The features this audio device supports
-   </entry>
-   </row><row>
-   <entry>name</entry><entry>A text name to display to the user. We picked
-                        "Radio" as it explains things quite nicely.</entry>
-   </row><row>
-   <entry>mode</entry><entry>The current reception mode for the audio
-
-                We report MONO because our card is too stupid to know if it is in
-                mono or stereo. 
-   </entry>
-   </row><row>
-   <entry>balance</entry><entry>The stereo balance on a scale of 0-65535, 32768 is
-                        middle.</entry>
-   </row><row>
-   <entry>step</entry><entry>The step by which the volume control jumps. This is
-                        used to help make it easy for applications to set 
-                        slider behaviour.</entry>
-   </row>
-   </tbody>
-   </tgroup>
-   </table>
-
-   <table frame="all" id="video_audio_flags"><title>struct video_audio flags</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-                <entry>VIDEO_AUDIO_MUTE</entry><entry>The audio is currently muted. We
-                                        could fake this in our driver but we
-                                        choose not to bother.</entry>
-   </row><row>
-                <entry>VIDEO_AUDIO_MUTABLE</entry><entry>The input has a mute option</entry>
-   </row><row>
-                <entry>VIDEO_AUDIO_TREBLE</entry><entry>The  input has a treble control</entry>
-   </row><row>
-                <entry>VIDEO_AUDIO_BASS</entry><entry>The input has a base control</entry>
-   </row>
-   </tbody>
-   </tgroup>
-   </table>
-
-   <table frame="all" id="video_audio_modes"><title>struct video_audio modes</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-                <entry>VIDEO_SOUND_MONO</entry><entry>Mono sound</entry>
-   </row><row>
-                <entry>VIDEO_SOUND_STEREO</entry><entry>Stereo sound</entry>
-   </row><row>
-                <entry>VIDEO_SOUND_LANG1</entry><entry>Alternative language 1 (TV specific)</entry>
-   </row><row>
-                <entry>VIDEO_SOUND_LANG2</entry><entry>Alternative language 2 (TV specific)</entry>
-   </row>
-   </tbody>
-   </tgroup>
-   </table>
-  <para>
-        Having filled in the structure we copy it back to user space.
-  </para>
-  <para>
-        The VIDIOCSAUDIO ioctl allows the user to set the audio parameters in the
-        video_audio structure. The driver does its best to honour the request.
-  </para>
-  <programlisting>
-
-                case VIDIOCSAUDIO:
-                {
-                        struct video_audio v;
-                        if(copy_from_user(&amp;v, arg, sizeof(v)))
-                                return -EFAULT;
-                        if(v.audio)
-                                return -EINVAL;
-                        current_volume = v/16384;
-                        hardware_set_volume(current_volume);
-                        return 0;
-                }
-
-  </programlisting>
-  <para>
-        In our case there is very little that the user can set. The volume is
-        basically the limit. Note that we could pretend to have a mute feature
-        by rewriting this to 
-  </para>
-  <programlisting>
-
-                case VIDIOCSAUDIO:
-                {
-                        struct video_audio v;
-                        if(copy_from_user(&amp;v, arg, sizeof(v)))
-                                return -EFAULT;
-                        if(v.audio)
-                                return -EINVAL;
-                        current_volume = v/16384;
-                        if(v.flags&amp;VIDEO_AUDIO_MUTE)
-                                hardware_set_volume(0);
-                        else
-                                hardware_set_volume(current_volume);
-                        current_muted = v.flags &amp; 
-                                              VIDEO_AUDIO_MUTE;
-                        return 0;
-                }
-
-  </programlisting>
-  <para>
-        This with the corresponding changes to the VIDIOCGAUDIO code to report the
-        state of the mute flag we save and to report the card has a mute function,
-        will allow applications to use a mute facility with this card. It is
-        questionable whether this is a good idea however. User applications can already
-        fake this themselves and kernel space is precious.
-  </para>
-  <para>
-        We now have a working radio ioctl handler. So we just wrap up the function
-  </para>
-  <programlisting>
-
-
-        }
-        return -ENOIOCTLCMD;
-}
-
-  </programlisting>
-  <para>
-        and pass the Video4Linux layer back an error so that it knows we did not
-        understand the request we got passed.
-  </para>
-  </sect1>
-  <sect1 id="modradio">
-  <title>Module Wrapper</title>
-  <para>
-        Finally we add in the usual module wrapping and the driver is done.
-  </para>
-  <programlisting>
-
-#ifndef MODULE
-
-static int io = 0x300;
-
-#else
-
-static int io = -1;
-
-#endif
-
-MODULE_AUTHOR("Alan Cox");
-MODULE_DESCRIPTION("A driver for an imaginary radio card.");
-module_param(io, int, 0444);
-MODULE_PARM_DESC(io, "I/O address of the card.");
-
-static int __init init(void)
-{
-        if(io==-1)
-        {
-                printk(KERN_ERR 
-         "You must set an I/O address with io=0x???\n");
-                return -EINVAL;
-        }
-        return myradio_init(NULL);
-}
-
-static void __exit cleanup(void)
-{
-        video_unregister_device(&amp;my_radio);
-        release_region(io, MY_IO_SIZE);
-}
-
-module_init(init);
-module_exit(cleanup);
-
-  </programlisting>
-  <para>
-        In this example we set the IO base by default if the driver is compiled into
-        the kernel: you can still set it using "my_radio.irq" if this file is called <filename>my_radio.c</filename>. For the module we require the
-        user sets the parameter. We set io to a nonsense port (-1) so that we can
-        tell if the user supplied an io parameter or not.
-  </para>
-  <para>
-        We use MODULE_ defines to give an author for the card driver and a
-        description. We also use them to declare that io is an integer and it is the
-        address of the card, and can be read by anyone from sysfs.
-  </para>
-  <para>
-        The clean-up routine unregisters the video_device we registered, and frees
-        up the I/O space. Note that the unregister takes the actual video_device
-        structure as its argument. Unlike the file operations structure which can be
-        shared by all instances of a device a video_device structure as an actual
-        instance of the device. If you are registering multiple radio devices you
-        need to fill in one structure per device (most likely by setting up a
-        template and copying it to each of the actual device structures).
-  </para>
-  </sect1>
-  </chapter>
-  <chapter id="Video_Capture_Devices">
-        <title>Video Capture Devices</title>
-  <sect1 id="introvid">
-  <title>Video Capture Device Types</title>
-  <para>
-        The video capture devices share the same interfaces as radio devices. 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 both combine the two driver examples.
-  </para>
-  <para>
-        Video capture devices divide into four categories. A little technology
-        backgrounder. Full motion video even at television resolution (which is
-        actually fairly low) is pretty resource-intensive. You are continually
-        passing megabytes of data every second from the capture card to the display. 
-        several alternative approaches have emerged because copying this through the 
-        processor and the user program is a particularly bad idea .
-  </para>
-  <para>
-        The first is to add the television image onto the video output directly.
-        This is also how some 3D cards work. These basic cards can generally drop the
-        video into any chosen rectangle of the display. Cards like this, which
-        include most mpeg1 cards that used the feature connector,  aren't very
-        friendly in a windowing environment. They don't understand windows or
-        clipping. The video window is always on the top of the display.
-  </para>
-  <para>
-        Chroma keying is a technique used by cards to get around this. It is an old
-        television mixing trick where you mark all the areas you wish to replace
-        with a single clear colour that isn't used in the image - TV people use an
-        incredibly bright blue while computing people often use a particularly
-        virulent purple. Bright blue occurs on the desktop. Anyone with virulent
-        purple windows has another problem besides their TV overlay.
-  </para>
-  <para>
-        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 smartness on the part of the video
-        capture chip, as well as a suitable video card. Programming this kind of
-        card and more so debugging it can be extremely tricky. There are some quite
-        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. 
-  </para>
-  <para>
-        To keep our example fairly simple we will assume a card that supports
-        overlaying a flat rectangular image onto the frame buffer output, and which
-        can also capture stuff into processor memory.
-  </para>
-  </sect1>
-  <sect1 id="regvid">
-  <title>Registering Video Capture Devices</title>
-  <para>
-        This time we need to add more functions for our camera device.
-  </para>
-  <programlisting>
-static struct video_device my_camera
-{
-        "My Camera",
-        VID_TYPE_OVERLAY|VID_TYPE_SCALES|\
-        VID_TYPE_CAPTURE|VID_TYPE_CHROMAKEY,
-        camera_open.
-        camera_close,
-        camera_read,      /* no read */
-        NULL,             /* no write */
-        camera_poll,      /* no poll */
-        camera_ioctl,
-        NULL,             /* no special init function */
-        NULL              /* no private data */
-};
-  </programlisting>
-  <para>
-        We need a read() function which is used for capturing data from
-        the card, and we need a poll function so that a driver can wait for the next
-        frame to be captured.
-  </para>
-  <para>
-        We use the extra video capability flags that did not apply to the
-        radio interface. The video related flags are
-  </para>
-   <table frame="all" id="Capture_Capabilities"><title>Capture Capabilities</title>
-   <tgroup cols="2" align="left">
-   <tbody>
-   <row>
-<entry>VID_TYPE_CAPTURE</entry><entry>We support image capture</entry>
-</row><row>
-<entry>VID_TYPE_TELETEXT</entry><entry>A teletext capture device (vbi{n])</entry>
-</row><row>
-<entry>VID_TYPE_OVERLAY</entry><entry>The image can be directly overlaid onto the
-                                frame buffer</entry>
-</row><row>