[media] DocBook: Move all media docbook stuff into its own directory

This patch addresses several issues pointed by Randy Dunlap
<rdunlap@xenotime.net> at changeset ece722c:

- In the generated index.html file, "media" is listed first, but it
  should be listed in alphabetical order, not first.

- The generated files are (hidden) in .tmpmedia/

- The link from the top-level index.html file to "media" is to
  media/index.html, but the file is actually in .tmpmedia/media/index.html

- Please build docs with and without using "O=builddir" and test that.

- Would it be possible for media to have its own Makefile instead of
  merging into this one?

Due to the way cleandocs target works, I had to rename the media DocBook
to media_api, otherwise cleandocs would remove the /media directory.

Thanks-to: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

1 files changed, 0 insertions, 2500 deletions

diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml
deleted file mode 100644
index 9f7cd4f2579..00000000000
--- a/Documentation/DocBook/v4l/compat.xml
+++ /dev/null
@@ -1,2500 +0,0 @@
-  <title>Changes</title>
-
-  <para>The following chapters document the evolution of the V4L2 API,
-errata or extensions. They are also intended to help application and
-driver writers to port or update their code.</para>
-
-  <section id="diff-v4l">
-    <title>Differences between V4L and V4L2</title>
-
-    <para>The Video For Linux API was first introduced in Linux 2.1 to
-unify and replace various TV and radio device related interfaces,
-developed independently by driver writers in prior years. Starting
-with Linux 2.5 the much improved V4L2 API replaces the V4L API,
-although existing drivers will continue to support V4L applications in
-the future, either directly or through the V4L2 compatibility layer in
-the <filename>videodev</filename> kernel module translating ioctls on
-the fly. For a transition period not all drivers will support the V4L2
-API.</para>
-
-    <section>
-      <title>Opening and Closing Devices</title>
-
-      <para>For compatibility reasons the character device file names
-recommended for V4L2 video capture, overlay, radio and raw
-vbi capture devices did not change from those used by V4L. They are
-listed in <xref linkend="devices" /> and below in <xref
-	  linkend="v4l-dev" />.</para>
-
-      <para>The teletext devices (minor range 192-223) have been removed in
-V4L2 and no longer exist. There is no hardware available anymore for handling
-pure teletext. Instead raw or sliced VBI is used.</para>
-
-      <para>The V4L <filename>videodev</filename> module automatically
-assigns minor numbers to drivers in load order, depending on the
-registered device type. We recommend that V4L2 drivers by default
-register devices with the same numbers, but the system administrator
-can assign arbitrary minor numbers using driver module options. The
-major device number remains 81.</para>
-
-      <table id="v4l-dev">
-	<title>V4L Device Types, Names and Numbers</title>
-	<tgroup cols="3">
-	  <thead>
-	    <row>
-	      <entry>Device Type</entry>
-	      <entry>File Name</entry>
-	      <entry>Minor Numbers</entry>
-	    </row>
-	  </thead>
-	  <tbody valign="top">
-	    <row>
-	      <entry>Video capture and overlay</entry>
-	      <entry><para><filename>/dev/video</filename> and
-<filename>/dev/bttv0</filename><footnote> <para>According to
-Documentation/devices.txt these should be symbolic links to
-<filename>/dev/video0</filename>. Note the original bttv interface is
-not compatible with V4L or V4L2.</para> </footnote>,
-<filename>/dev/video0</filename> to
-<filename>/dev/video63</filename></para></entry>
-	      <entry>0-63</entry>
-	    </row>
-	    <row>
-	      <entry>Radio receiver</entry>
-	      <entry><para><filename>/dev/radio</filename><footnote>
-		    <para>According to
-<filename>Documentation/devices.txt</filename> a symbolic link to
-<filename>/dev/radio0</filename>.</para>
-		  </footnote>, <filename>/dev/radio0</filename> to
-<filename>/dev/radio63</filename></para></entry>
-	      <entry>64-127</entry>
-	    </row>
-	    <row>
-	      <entry>Raw VBI capture</entry>
-	      <entry><para><filename>/dev/vbi</filename>,
-<filename>/dev/vbi0</filename> to
-<filename>/dev/vbi31</filename></para></entry>
-	      <entry>224-255</entry>
-	    </row>
-	  </tbody>
-	</tgroup>
-      </table>
-
-      <para>V4L prohibits (or used to prohibit) multiple opens of a
-device file. V4L2 drivers <emphasis>may</emphasis> support multiple
-opens, see <xref linkend="open" /> for details and consequences.</para>
-
-      <para>V4L drivers respond to V4L2 ioctls with an &EINVAL;. The
-compatibility layer in the V4L2 <filename>videodev</filename> module
-can translate V4L ioctl requests to their V4L2 counterpart, however a
-V4L2 driver usually needs more preparation to become fully V4L
-compatible. This is covered in more detail in <xref
-	  linkend="driver" />.</para>
-    </section>
-
-    <section>
-      <title>Querying Capabilities</title>
-
-      <para>The V4L <constant>VIDIOCGCAP</constant> ioctl is
-equivalent to V4L2's &VIDIOC-QUERYCAP;.</para>
-
-      <para>The <structfield>name</structfield> field in struct
-<structname>video_capability</structname> became
-<structfield>card</structfield> in &v4l2-capability;,
-<structfield>type</structfield> was replaced by
-<structfield>capabilities</structfield>. Note V4L2 does not
-distinguish between device types like this, better think of basic
-video input, video output and radio devices supporting a set of
-related functions like video capturing, video overlay and VBI
-capturing. See <xref linkend="open" /> for an
-introduction.<informaltable>
-	  <tgroup cols="3">
-	    <thead>
-	      <row>
-		<entry>struct
-<structname>video_capability</structname>
-<structfield>type</structfield></entry>
-		<entry>&v4l2-capability;
-<structfield>capabilities</structfield> flags</entry>
-		<entry>Purpose</entry>
-	      </row>
-	    </thead>
-	    <tbody valign="top">
-	      <row>
-		<entry><constant>VID_TYPE_CAPTURE</constant></entry>
-		<entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry>
-		<entry>The <link linkend="capture">video
-capture</link> interface is supported.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_TUNER</constant></entry>
-		<entry><constant>V4L2_CAP_TUNER</constant></entry>
-		<entry>The device has a <link linkend="tuner">tuner or
-modulator</link>.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_TELETEXT</constant></entry>
-		<entry><constant>V4L2_CAP_VBI_CAPTURE</constant></entry>
-		<entry>The <link linkend="raw-vbi">raw VBI
-capture</link> interface is supported.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_OVERLAY</constant></entry>
-		<entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>
-		<entry>The <link linkend="overlay">video
-overlay</link> interface is supported.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_CHROMAKEY</constant></entry>
-		<entry><constant>V4L2_FBUF_CAP_CHROMAKEY</constant> in
-field <structfield>capability</structfield> of
-&v4l2-framebuffer;</entry>
-		<entry>Whether chromakey overlay is supported. For
-more information on overlay see
-<xref linkend="overlay" />.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_CLIPPING</constant></entry>
-		<entry><constant>V4L2_FBUF_CAP_LIST_CLIPPING</constant>
-and <constant>V4L2_FBUF_CAP_BITMAP_CLIPPING</constant> in field
-<structfield>capability</structfield> of &v4l2-framebuffer;</entry>
-		<entry>Whether clipping the overlaid image is
-supported, see <xref linkend="overlay" />.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_FRAMERAM</constant></entry>
-		<entry><constant>V4L2_FBUF_CAP_EXTERNOVERLAY</constant>
-<emphasis>not set</emphasis> in field
-<structfield>capability</structfield> of &v4l2-framebuffer;</entry>
-		<entry>Whether overlay overwrites frame buffer memory,
-see <xref linkend="overlay" />.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_SCALES</constant></entry>
-		<entry><constant>-</constant></entry>
-		<entry>This flag indicates if the hardware can scale
-images. The V4L2 API implies the scale factor by setting the cropping
-dimensions and image size with the &VIDIOC-S-CROP; and &VIDIOC-S-FMT;
-ioctl, respectively. The driver returns the closest sizes possible.
-For more information on cropping and scaling see <xref
-		    linkend="crop" />.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_MONOCHROME</constant></entry>
-		<entry><constant>-</constant></entry>
-		<entry>Applications can enumerate the supported image
-formats with the &VIDIOC-ENUM-FMT; ioctl to determine if the device
-supports grey scale capturing only. For more information on image
-formats see <xref linkend="pixfmt" />.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_SUBCAPTURE</constant></entry>
-		<entry><constant>-</constant></entry>
-		<entry>Applications can call the &VIDIOC-G-CROP; ioctl
-to determine if the device supports capturing a subsection of the full
-picture ("cropping" in V4L2). If not, the ioctl returns the &EINVAL;.
-For more information on cropping and scaling see <xref
-		    linkend="crop" />.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_MPEG_DECODER</constant></entry>
-		<entry><constant>-</constant></entry>
-		<entry>Applications can enumerate the supported image
-formats with the &VIDIOC-ENUM-FMT; ioctl to determine if the device
-supports MPEG streams.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_MPEG_ENCODER</constant></entry>
-		<entry><constant>-</constant></entry>
-		<entry>See above.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_MJPEG_DECODER</constant></entry>
-		<entry><constant>-</constant></entry>
-		<entry>See above.</entry>
-	      </row>
-	      <row>
-		<entry><constant>VID_TYPE_MJPEG_ENCODER</constant></entry>
-		<entry><constant>-</constant></entry>
-		<entry>See above.</entry>
-	      </row>
-	    </tbody>
-	  </tgroup>
-	</informaltable></para>
-
-      <para>The <structfield>audios</structfield> field was replaced
-by <structfield>capabilities</structfield> flag
-<constant>V4L2_CAP_AUDIO</constant>, indicating
-<emphasis>if</emphasis> the device has any audio inputs or outputs. To
-determine their number applications can enumerate audio inputs with
-the &VIDIOC-G-AUDIO; ioctl. The audio ioctls are described in <xref
-	  linkend="audio" />.</para>
-
-      <para>The <structfield>maxwidth</structfield>,
-<structfield>maxheight</structfield>,
-<structfield>minwidth</structfield> and
-<structfield>minheight</structfield> fields were removed. Calling the
-&VIDIOC-S-FMT; or &VIDIOC-TRY-FMT; ioctl with the desired dimensions
-returns the closest size possible, taking into account the current
-video standard, cropping and scaling limitations.</para>
-    </section>
-
-    <section>
-      <title>Video Sources</title>
-
-      <para>V4L provides the <constant>VIDIOCGCHAN</constant> and
-<constant>VIDIOCSCHAN</constant> ioctl using struct
-<structname>video_channel</structname> to enumerate
-the video inputs of a V4L device. The equivalent V4L2 ioctls
-are &VIDIOC-ENUMINPUT;, &VIDIOC-G-INPUT; and &VIDIOC-S-INPUT;
-using &v4l2-input; as discussed in <xref linkend="video" />.</para>
-
-      <para>The <structfield>channel</structfield> field counting
-inputs was renamed to <structfield>index</structfield>, the video
-input types were renamed as follows: <informaltable>
-	  <tgroup cols="2">
-	    <thead>
-	      <row>
-		<entry>struct <structname>video_channel</structname>
-<structfield>type</structfield></entry>
-		<entry>&v4l2-input;
-<structfield>type</structfield></entry>
-	      </row>
-	    </thead>
-	    <tbody valign="top">
-	      <row>
-		<entry><constant>VIDEO_TYPE_TV</constant></entry>
-		<entry><constant>V4L2_INPUT_TYPE_TUNER</constant></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_TYPE_CAMERA</constant></entry>
-		<entry><constant>V4L2_INPUT_TYPE_CAMERA</constant></entry>
-	      </row>
-	    </tbody>
-	  </tgroup>
-	</informaltable></para>
-
-      <para>Unlike the <structfield>tuners</structfield> field
-expressing the number of tuners of this input, V4L2 assumes each video
-input is connected to at most one tuner. However a tuner can have more
-than one input, &ie; RF connectors, and a device can have multiple
-tuners. The index number of the tuner associated with the input, if
-any, is stored in field <structfield>tuner</structfield> of
-&v4l2-input;. Enumeration of tuners is discussed in <xref
-	  linkend="tuner" />.</para>
-
-      <para>The redundant <constant>VIDEO_VC_TUNER</constant> flag was
-dropped. Video inputs associated with a tuner are of type
-<constant>V4L2_INPUT_TYPE_TUNER</constant>. The
-<constant>VIDEO_VC_AUDIO</constant> flag was replaced by the
-<structfield>audioset</structfield> field. V4L2 considers devices with
-up to 32 audio inputs. Each set bit in the
-<structfield>audioset</structfield> field represents one audio input
-this video input combines with. For information about audio inputs and
-how to switch between them see <xref linkend="audio" />.</para>
-
-      <para>The <structfield>norm</structfield> field describing the
-supported video standards was replaced by
-<structfield>std</structfield>. The V4L specification mentions a flag
-<constant>VIDEO_VC_NORM</constant> indicating whether the standard can
-be changed. This flag was a later addition together with the
-<structfield>norm</structfield> field and has been removed in the
-meantime. V4L2 has a similar, albeit more comprehensive approach
-to video standards, see <xref linkend="standard" /> for more
-information.</para>
-    </section>
-
-    <section>
-      <title>Tuning</title>
-
-      <para>The V4L <constant>VIDIOCGTUNER</constant> and
-<constant>VIDIOCSTUNER</constant> ioctl and struct
-<structname>video_tuner</structname> can be used to enumerate the
-tuners of a V4L TV or radio device. The equivalent V4L2 ioctls are
-&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; using &v4l2-tuner;. Tuners are
-covered in <xref linkend="tuner" />.</para>
-
-      <para>The <structfield>tuner</structfield> field counting tuners
-was renamed to <structfield>index</structfield>. The fields
-<structfield>name</structfield>, <structfield>rangelow</structfield>
-and <structfield>rangehigh</structfield> remained unchanged.</para>
-
-      <para>The <constant>VIDEO_TUNER_PAL</constant>,
-<constant>VIDEO_TUNER_NTSC</constant> and
-<constant>VIDEO_TUNER_SECAM</constant> flags indicating the supported
-video standards were dropped. This information is now contained in the
-associated &v4l2-input;. No replacement exists for the
-<constant>VIDEO_TUNER_NORM</constant> flag indicating whether the
-video standard can be switched. The <structfield>mode</structfield>
-field to select a different video standard was replaced by a whole new
-set of ioctls and structures described in <xref linkend="standard" />.
-Due to its ubiquity it should be mentioned the BTTV driver supports
-several standards in addition to the regular
-<constant>VIDEO_MODE_PAL</constant> (0),
-<constant>VIDEO_MODE_NTSC</constant>,
-<constant>VIDEO_MODE_SECAM</constant> and
-<constant>VIDEO_MODE_AUTO</constant> (3). Namely N/PAL Argentina,
-M/PAL, N/PAL, and NTSC Japan with numbers 3-6 (sic).</para>
-
-      <para>The <constant>VIDEO_TUNER_STEREO_ON</constant> flag
-indicating stereo reception became
-<constant>V4L2_TUNER_SUB_STEREO</constant> in field
-<structfield>rxsubchans</structfield>. This field also permits the
-detection of monaural and bilingual audio, see the definition of
-&v4l2-tuner; for details. Presently no replacement exists for the
-<constant>VIDEO_TUNER_RDS_ON</constant> and
-<constant>VIDEO_TUNER_MBS_ON</constant> flags.</para>
-
-      <para> The <constant>VIDEO_TUNER_LOW</constant> flag was renamed
-to <constant>V4L2_TUNER_CAP_LOW</constant> in the &v4l2-tuner;
-<structfield>capability</structfield> field.</para>
-
-      <para>The <constant>VIDIOCGFREQ</constant> and
-<constant>VIDIOCSFREQ</constant> ioctl to change the tuner frequency
-where renamed to &VIDIOC-G-FREQUENCY; and  &VIDIOC-S-FREQUENCY;. They
-take a pointer to a &v4l2-frequency; instead of an unsigned long
-integer.</para>
-    </section>
-
-    <section id="v4l-image-properties">
-      <title>Image Properties</title>
-
-      <para>V4L2 has no equivalent of the
-<constant>VIDIOCGPICT</constant> and <constant>VIDIOCSPICT</constant>
-ioctl and struct <structname>video_picture</structname>. The following
-fields where replaced by V4L2 controls accessible with the
-&VIDIOC-QUERYCTRL;, &VIDIOC-G-CTRL; and &VIDIOC-S-CTRL; ioctls:<informaltable>
-	  <tgroup cols="2">
-	    <thead>
-	      <row>
-		<entry>struct <structname>video_picture</structname></entry>
-		<entry>V4L2 Control ID</entry>
-	      </row>
-	    </thead>
-	    <tbody valign="top">
-	      <row>
-		<entry><structfield>brightness</structfield></entry>
-		<entry><constant>V4L2_CID_BRIGHTNESS</constant></entry>
-	      </row>
-	      <row>
-		<entry><structfield>hue</structfield></entry>
-		<entry><constant>V4L2_CID_HUE</constant></entry>
-	      </row>
-	      <row>
-		<entry><structfield>colour</structfield></entry>
-		<entry><constant>V4L2_CID_SATURATION</constant></entry>
-	      </row>
-	      <row>
-		<entry><structfield>contrast</structfield></entry>
-		<entry><constant>V4L2_CID_CONTRAST</constant></entry>
-	      </row>
-	      <row>
-		<entry><structfield>whiteness</structfield></entry>
-		<entry><constant>V4L2_CID_WHITENESS</constant></entry>
-	      </row>
-	    </tbody>
-	  </tgroup>
-	</informaltable></para>
-
-      <para>The V4L picture controls are assumed to range from 0 to
-65535 with no particular reset value. The V4L2 API permits arbitrary
-limits and defaults which can be queried with the &VIDIOC-QUERYCTRL;
-ioctl. For general information about controls see <xref
-linkend="control" />.</para>
-
-      <para>The <structfield>depth</structfield> (average number of
-bits per pixel) of a video image is implied by the selected image
-format. V4L2 does not explicitely provide such information assuming
-applications recognizing the format are aware of the image depth and
-others need not know. The <structfield>palette</structfield> field
-moved into the &v4l2-pix-format;:<informaltable>
-	  <tgroup cols="2">
-	    <thead>
-	      <row>
-		<entry>struct <structname>video_picture</structname>
-<structfield>palette</structfield></entry>
-		<entry>&v4l2-pix-format;
-<structfield>pixfmt</structfield></entry>
-	      </row>
-	    </thead>
-	    <tbody valign="top">
-	      <row>
-		<entry><constant>VIDEO_PALETTE_GREY</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-GREY"><constant>V4L2_PIX_FMT_GREY</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_HI240</constant></entry>
-		<entry><para><link
-linkend="pixfmt-reserved"><constant>V4L2_PIX_FMT_HI240</constant></link><footnote>
-		      <para>This is a custom format used by the BTTV
-driver, not one of the V4L2 standard formats.</para>
-		    </footnote></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_RGB565</constant></entry>
-		<entry><para><link
-linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_RGB565</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_RGB555</constant></entry>
-		<entry><para><link
-linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_RGB555</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_RGB24</constant></entry>
-		<entry><para><link
-linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR24</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_RGB32</constant></entry>
-		<entry><para><link
-linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR32</constant></link><footnote>
-		      <para>Presumably all V4L RGB formats are
-little-endian, although some drivers might interpret them according to machine endianess. V4L2 defines little-endian, big-endian and red/blue
-swapped variants. For details see <xref linkend="pixfmt-rgb" />.</para>
-		    </footnote></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_YUV422</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-YUYV"><constant>V4L2_PIX_FMT_YUYV</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><para><constant>VIDEO_PALETTE_YUYV</constant><footnote>
-		      <para><constant>VIDEO_PALETTE_YUV422</constant>
-and <constant>VIDEO_PALETTE_YUYV</constant> are the same formats. Some
-V4L drivers respond to one, some to the other.</para>
-		    </footnote></para></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-YUYV"><constant>V4L2_PIX_FMT_YUYV</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_UYVY</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-UYVY"><constant>V4L2_PIX_FMT_UYVY</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_YUV420</constant></entry>
-		<entry>None</entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_YUV411</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-Y41P"><constant>V4L2_PIX_FMT_Y41P</constant></link><footnote>
-		      <para>Not to be confused with
-<constant>V4L2_PIX_FMT_YUV411P</constant>, which is a planar
-format.</para> </footnote></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_RAW</constant></entry>
-		<entry><para>None<footnote> <para>V4L explains this
-as: "RAW capture (BT848)"</para> </footnote></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_YUV422P</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-YUV422P"><constant>V4L2_PIX_FMT_YUV422P</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_YUV411P</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-YUV411P"><constant>V4L2_PIX_FMT_YUV411P</constant></link><footnote>
-		      <para>Not to be confused with
-<constant>V4L2_PIX_FMT_Y41P</constant>, which is a packed
-format.</para> </footnote></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_YUV420P</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-YVU420"><constant>V4L2_PIX_FMT_YVU420</constant></link></para></entry>
-	      </row>
-	      <row>
-		<entry><constant>VIDEO_PALETTE_YUV410P</constant></entry>
-		<entry><para><link
-linkend="V4L2-PIX-FMT-YVU410"><constant>V4L2_PIX_FMT_YVU410</constant></link></para></entry>
-	      </row>
-	    </tbody>
-	  </tgroup>
-	</informaltable></para>
-
-      <para>V4L2 image formats are defined in <xref
-linkend="pixfmt" />. The image format can be selected with the
-&VIDIOC-S-FMT; ioctl.</para>
-    </section>
-
-    <section>
-      <title>Audio</title>
-
-      <para>The <constant>VIDIOCGAUDIO</constant> and
-<constant>VIDIOCSAUDIO</constant> ioctl and struct
-<structname>video_audio</structname> are used to enumerate the
-audio inputs of a V4L device. The equivalent V4L2 ioctls are
-&VIDIOC-G-AUDIO; and &VIDIOC-S-AUDIO; using &v4l2-audio; as
-discussed in <xref linkend="audio" />.</para>
-
-      <para>The <structfield>audio</structfield> "channel number"
-field counting audio inputs was renamed to
-<structfield>index</structfield>.</para>
-
-      <para>On <constant>VIDIOCSAUDIO</constant> the
-<structfield>mode</structfield> field selects <emphasis>one</emphasis>
-of the <constant>VIDEO_SOUND_MONO</constant>,
-<constant>VIDEO_SOUND_STEREO</constant>,
-<constant>VIDEO_SOUND_LANG1</constant> or
-<constant>VIDEO_SOUND_LANG2</constant> audio demodulation modes. When
-the current audio standard is BTSC
-<constant>VIDEO_SOUND_LANG2</constant> refers to SAP and
-<constant>VIDEO_SOUND_LANG1</constant> is meaningless. Also
-undocumented in the V4L specification, there is no way to query the
-selected mode. On <constant>VIDIOCGAUDIO</constant> the driver returns
-the <emphasis>actually received</emphasis> audio programmes in this
-field. In the V4L2 API this information is stored in the &v4l2-tuner;
-<structfield>rxsubchans</structfield> and
-<structfield>audmode</structfield> fields, respectively. See <xref
-linkend="tuner" /> for more information on tuners. Related to audio
-modes &v4l2-audio; also reports if this is a mono or stereo
-input, regardless if the source is a tuner.</para>
-
-      <para>The following fields where replaced by V4L2 controls
-accessible with the &VIDIOC-QUERYCTRL;, &VIDIOC-G-CTRL; and
-&VIDIOC-S-CTRL; ioctls:<informaltable>
-	  <tgroup cols="2">
-	    <thead>
-	      <row>
-		<entry>struct
-<structname>video_audio</structname></entry>
-		<entry>V4L2 Control ID</entry>
-	      </row>
-	    </thead>
-	    <tbody valign="top">
-	      <row>
-		<entry><structfield>volume</structfield></entry>
-		<entry><constant>V4L2_CID_AUDIO_VOLUME</constant></entry>
-	      </row>
-	      <row>
-		<entry><structfield>bass</structfield></entry>
-		<entry><constant>V4L2_CID_AUDIO_BASS</constant></entry>
-	      </row>
-	      <row>
-		<entry><structfield>treble</structfield></entry>
-		<entry><constant>V4L2_CID_AUDIO_TREBLE</constant></entry>
-	      </row>
-	      <row>
-		<entry><structfield>balance</structfield></entry>
-		<entry><constant>V4L2_CID_AUDIO_BALANCE</constant></entry>
-	      </row>
-	    </tbody>
-	  </tgroup>
-	</informaltable></para>
-
-      <para>To determine which of these controls are supported by a
-driver V4L provides the <structfield>flags</structfield>
-<constant>VIDEO_AUDIO_VOLUME</constant>,
-<constant>VIDEO_AUDIO_BASS</constant>,
-<constant>VIDEO_AUDIO_TREBLE</constant> and
-<constant>VIDEO_AUDIO_BALANCE</constant>. In the V4L2 API the
-&VIDIOC-QUERYCTRL; ioctl reports if the respective control is
-supported. Accordingly the <constant>VIDEO_AUDIO_MUTABLE</constant>
-and <constant>VIDEO_AUDIO_MUTE</constant> flags where replaced by the
-boolean <constant>V4L2_CID_AUDIO_MUTE</constant> control.</para>
-
-      <para>All V4L2 controls have a <structfield>step</structfield>
-attribute replacing the struct <structname>video_audio</structname>
-<structfield>step</structfield> field. The V4L audio controls are
-assumed to range from 0 to 65535 with no particular reset value. The
-V4L2 API permits arbitrary limits and defaults which can be queried
-with the &VIDIOC-QUERYCTRL; ioctl. For general information about
-controls see <xref linkend="control" />.</para>
-    </section>
-
-    <section>
-      <title>Frame Buffer Overlay</title>
-
-      <para>The V4L2 ioctls equivalent to
-<constant>VIDIOCGFBUF</constant> and <constant>VIDIOCSFBUF</constant>
-are &VIDIOC-G-FBUF; and &VIDIOC-S-FBUF;. The
-<structfield>base</structfield> field of struct
-<structname>video_buffer</structname> remained unchanged, except V4L2
-defines a flag to indicate non-destructive overlays instead of a
-<constant>NULL</constant> pointer. All other fields moved into the
-&v4l2-pix-format; <structfield>fmt</structfield> substructure of
-&v4l2-framebuffer;. The <structfield>depth</structfield> field was
-replaced by <structfield>pixelformat</structfield>. See <xref
-	  linkend="pixfmt-rgb" /> for a list of RGB formats and their
-respective color depths.</para>
-
-      <para>Instead of the special ioctls
-<constant>VIDIOCGWIN</constant> and <constant>VIDIOCSWIN</constant>
-V4L2 uses the general-purpose data format negotiation ioctls
-&VIDIOC-G-FMT; and &VIDIOC-S-FMT;. They take a pointer to a
-&v4l2-format; as argument. Here the <structfield>win</structfield>
-member of the <structfield>fmt</structfield> union is used, a
-&v4l2-window;.</para>
-
-      <para>The <structfield>x</structfield>,
-<structfield>y</structfield>, <structfield>width</structfield> and
-<structfield>height</structfield> fields of struct
-<structname>video_window</structname> moved into &v4l2-rect;
-substructure <structfield>w</structfield> of struct
-<structname>v4l2_window</structname>. The
-<structfield>chromakey</structfield>,
-<structfield>clips</structfield>, and
-<structfield>clipcount</structfield> fields remained unchanged. Struct
-<structname>video_clip</structname> was renamed to &v4l2-clip;, also
-containing a struct <structname>v4l2_rect</structname>, but the
-semantics are still the same.</para>
-
-      <para>The <constant>VIDEO_WINDOW_INTERLACE</constant> flag was
-dropped. Instead applications must set the
-<structfield>field</structfield> field to
-<constant>V4L2_FIELD_ANY</constant> or
-<constant>V4L2_FIELD_INTERLACED</constant>. The
-<constant>VIDEO_WINDOW_CHROMAKEY</constant> flag moved into
-&v4l2-framebuffer;, under the new name
-<constant>V4L2_FBUF_FLAG_CHROMAKEY</constant>.</para>
-
-      <para>In V4L, storing a bitmap pointer in
-<structfield>clips</structfield> and setting
-<structfield>clipcount</structfield> to
-<constant>VIDEO_CLIP_BITMAP</constant> (-1) requests bitmap
-clipping, using a fixed size bitmap of 1024 &times; 625 bits. Struct
-<structname>v4l2_window</structname> has a separate
-<structfield>bitmap</structfield> pointer field for this purpose and
-the bitmap size is determined by <structfield>w.width</structfield> and
-<structfield>w.height</structfield>.</para>
-
-      <para>The <constant>VIDIOCCAPTURE</constant> ioctl to enable or
-disable overlay was renamed to &VIDIOC-OVERLAY;.</para>
-    </section>
-
-    <section>
-      <title>Cropping</title>
-
-      <para>To capture only a subsection of the full picture V4L
-defines the <constant>VIDIOCGCAPTURE</constant> and
-<constant>VIDIOCSCAPTURE</constant> ioctls using struct
-<structname>video_capture</structname>. The equivalent V4L2 ioctls are
-&VIDIOC-G-CROP; and &VIDIOC-S-CROP; using &v4l2-crop;, and the related
-&VIDIOC-CROPCAP; ioctl. This is a rather complex matter, see
-<xref linkend="crop" /> for details.</para>
-
-      <para>The <structfield>x</structfield>,
-<structfield>y</structfield>, <structfield>width</structfield> and
-<structfield>height</structfield> fields moved into &v4l2-rect;
-substructure <structfield>c</structfield> of struct
-<structname>v4l2_crop</structname>. The
-<structfield>decimation</structfield> field was dropped. In the V4L2
-API the scaling factor is implied by the size of the cropping
-rectangle and the size of the captured or overlaid image.</para>
-
-      <para>The <constant>VIDEO_CAPTURE_ODD</constant>
-and <constant>VIDEO_CAPTURE_EVEN</constant> flags to capture only the
-odd or even field, respectively, were replaced by
-<constant>V4L2_FIELD_TOP</constant> and
-<constant>V4L2_FIELD_BOTTOM</constant> in the field named
-<structfield>field</structfield> of &v4l2-pix-format; and
-&v4l2-window;. These structures are used to select a capture or
-overlay format with the &VIDIOC-S-FMT; ioctl.</para>
-    </section>
-
-    <section>
-      <title>Reading Images, Memory Mapping</title>
-
-      <section>
-	<title>Capturing using the read method</title>
-
-	<para>There is no essential difference between reading images
-from a V4L or V4L2 device using the &func-read; function, however V4L2
-drivers are not required to support this I/O method. Applications can
-determine if the function is available with the &VIDIOC-QUERYCAP;
-ioctl. All V4L2 devices exchanging data with applications must support
-the &func-select; and &func-poll; functions.</para>
-
-	<para>To select an image format and size, V4L provides the
-<constant>VIDIOCSPICT</constant> and <constant>VIDIOCSWIN</constant>
-ioctls. V4L2 uses the general-purpose data format negotiation ioctls
-&VIDIOC-G-FMT; and &VIDIOC-S-FMT;. They take a pointer to a
-&v4l2-format; as argument, here the &v4l2-pix-format; named
-<structfield>pix</structfield> of its <structfield>fmt</structfield>
-union is used.</para>
-
-	<para>For more information about the V4L2 read interface see
-<xref linkend="rw" />.</para>
-      </section>
-      <section>
-	<title>Capturing using memory mapping</title>
-
-	<para>Applications can read from V4L devices by mapping
-buffers in device memory, or more often just buffers allocated in
-DMA-able system memory, into their address space. This avoids the data
-copying overhead of the read method. V4L2 supports memory mapping as
-well, with a few differences.</para>
-
-	<informaltable>
-	  <tgroup cols="2">
-	    <thead>
-	      <row>
-		<entry>V4L</entry>
-		<entry>V4L2</entry>
-	      </row>
-	    </thead>
-	    <tbody valign="top">
-	      <row>
-		<entry></entry>
-		<entry>The image format must be selected before
-buffers are allocated, with the &VIDIOC-S-FMT; ioctl. When no format
-is selected the driver may use the last, possibly by another
-application requested format.</entry>
-	      </row>
-	      <row>
-		<entry><para>Applications cannot change the number of
-buffers. The it is built into the driver, unless it has a module
-option to change the number when the driver module is
-loaded.</para></entry>
-		<entry><para>The &VIDIOC-REQBUFS; ioctl allocates the
-desired number of buffers, this is a required step in the initialization
-sequence.</para></entry>
-	      </row>
-	      <row>
-		<entry><para>Drivers map all buffers as one contiguous
-range of memory. The <constant>VIDIOCGMBUF</constant> ioctl is
-available to query the number of buffers, the offset of each buffer
-from the start of the virtual file, and the overall amount of memory
-used, which can be used as arguments for the &func-mmap;
-function.</para></entry>
-		<entry><para>Buffers are individually mapped. The
-offset and size of each buffer can be determined with the
-&VIDIOC-QUERYBUF; ioctl.</para></entry>
-	      </row>
-	      <row>
-		<e