v4l2-spec: convert it to use DocBook XML 4.1.2

From: Mauro Carvalho Chehab <mchehab@redhat.com>

DocBook XML 4.1.2 is the docbook dialect spoken at Linux kernel. By
using it, we can now consider adding V4L2 API docs at the kernel tree.

As a bonus, added support for xmlto, with seems to be better supported
nowadays.

Another additional bounus is that two new Makefile targets were added:
	make man - Create V4L2 API man pages
	make man_install - Install V4L2 API man pages

By allowing the addition of V4L2 manpages, it is now easier for
developer to quickly check about a V4L2 API or libv4l2 call syntax and
expected return values.

Priority: normal

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

1 files changed, 71 insertions, 71 deletions

diff --git a/v4l2-spec/compat.sgml b/v4l2-spec/compat.sgml
index 07b3b4058..3a05a869b 100644
--- a/v4l2-spec/compat.sgml
+++ b/v4l2-spec/compat.sgml
@@ -23,8 +23,8 @@ API.</para>
       <para>For compatibility reasons the character device file names
 recommended for V4L2 video capture, overlay, radio, teletext 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>
+listed in <xref linkend="devices" /> and below in <xref
+	  linkend="v4l-dev" />.</para>
 
       <para>The V4L <filename>videodev</filename> module automatically
 assigns minor numbers to drivers in load order, depending on the
@@ -85,14 +85,14 @@ not compatible with V4L or V4L2.</para> </footnote>,
 
       <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>
+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>
+	  linkend="driver" />.</para>
     </section>
 
     <section>
@@ -109,7 +109,7 @@ equivalent to V4L2's &VIDIOC-QUERYCAP;.</para>
 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
+capturing. See <xref linkend="open" /> for an
 introduction.<informaltable>
 	  <tgroup cols="3">
 	    <thead>
@@ -154,7 +154,7 @@ field <structfield>capability</structfield> of
 &v4l2-framebuffer;</entry>
 		<entry>Whether chromakey overlay is supported. For
 more information on overlay see
-<xref linkend="overlay">.</entry>
+<xref linkend="overlay" />.</entry>
 	      </row>
 	      <row>
 		<entry><constant>VID_TYPE_CLIPPING</constant></entry>
@@ -162,7 +162,7 @@ more information on overlay see
 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>
+supported, see <xref linkend="overlay" />.</entry>
 	      </row>
 	      <row>
 		<entry><constant>VID_TYPE_FRAMERAM</constant></entry>
@@ -170,7 +170,7 @@ supported, see <xref linkend="overlay">.</entry>
 <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>
+see <xref linkend="overlay" />.</entry>
 	      </row>
 	      <row>
 		<entry><constant>VID_TYPE_SCALES</constant></entry>
@@ -180,7 +180,7 @@ 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>
+		    linkend="crop" />.</entry>
 	      </row>
 	      <row>
 		<entry><constant>VID_TYPE_MONOCHROME</constant></entry>
@@ -188,7 +188,7 @@ For more information on cropping and scaling see <xref
 		<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>
+formats see <xref linkend="pixfmt" />.</entry>
 	      </row>
 	      <row>
 		<entry><constant>VID_TYPE_SUBCAPTURE</constant></entry>
@@ -197,7 +197,7 @@ formats see <xref linkend="pixfmt">.</entry>
 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>
+		    linkend="crop" />.</entry>
 	      </row>
 	      <row>
 		<entry><constant>VID_TYPE_MPEG_DECODER</constant></entry>
@@ -231,7 +231,7 @@ by <structfield>capabilities</structfield> flag
 <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>
+	  linkend="audio" />.</para>
 
       <para>The <structfield>maxwidth</structfield>,
 <structfield>maxheight</structfield>,
@@ -250,7 +250,7 @@ video standard, cropping and scaling limitations.</para>
 <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>
+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
@@ -284,7 +284,7 @@ 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>
+	  linkend="tuner" />.</para>
 
       <para>The redundant <constant>VIDEO_VC_TUNER</constant> flag was
 dropped. Video inputs associated with a tuner are of type
@@ -294,7 +294,7 @@ dropped. Video inputs associated with a tuner are of type
 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>
+how to switch between them see <xref linkend="audio" />.</para>
 
       <para>The <structfield>norm</structfield> field describing the
 supported video standards was replaced by
@@ -303,7 +303,7 @@ supported video standards was replaced by
 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
+to video standards, see <xref linkend="standard" /> for more
 information.</para>
     </section>
 
@@ -315,7 +315,7 @@ information.</para>
 <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>
+covered in <xref linkend="tuner" />.</para>
 
       <para>The <structfield>tuner</structfield> field counting tuners
 was renamed to <structfield>index</structfield>. The fields
@@ -330,7 +330,7 @@ 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">.
+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),
@@ -403,7 +403,7 @@ fields where replaced by V4L2 controls accessible with the
 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>
+linkend="control" />.</para>
 
       <para>The <structfield>depth</structfield> (average number of
 bits per pixel) of a video image is implied by the selected image
@@ -455,7 +455,7 @@ linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR24</constant></link></para></entr
 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>
+swapped variants. For details see <xref linkend="pixfmt-rgb" />.</para>
 		    </footnote></para></entry>
 	      </row>
 	      <row>
@@ -522,7 +522,7 @@ linkend="V4L2-PIX-FMT-YVU410"><constant>V4L2_PIX_FMT_YVU410</constant></link></p
 	</informaltable></para>
 
       <para>V4L2 image formats are defined in <xref
-linkend="pixfmt">. The image format can be selected with the
+linkend="pixfmt" />. The image format can be selected with the
 &VIDIOC-S-FMT; ioctl.</para>
     </section>
 
@@ -534,7 +534,7 @@ linkend="pixfmt">. The image format can be selected with the
 <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>
+discussed in <xref linkend="audio" />.</para>
 
       <para>The <structfield>audio</structfield> "channel number"
 field counting audio inputs was renamed to
@@ -555,7 +555,7 @@ 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
+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>
 
@@ -608,7 +608,7 @@ attribute replacing the struct <structname>video_audio</structname>
 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>
+controls see <xref linkend="control" />.</para>
     </section>
 
     <section>
@@ -624,7 +624,7 @@ defines a flag to indicate non-destructive overlays instead of a
 &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
+	  linkend="pixfmt-rgb" /> for a list of RGB formats and their
 respective color depths.</para>
 
       <para>Instead of the special ioctls
@@ -680,7 +680,7 @@ defines the <constant>VIDIOCGCAPTURE</constant> and
 <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>
+<xref linkend="crop" /> for details.</para>
 
       <para>The <structfield>x</structfield>,
 <structfield>y</structfield>, <structfield>width</structfield> and
@@ -723,7 +723,7 @@ ioctls. V4L2 uses the general-purpose data format negotiation ioctls
 union is used.</para>
 
 	<para>For more information about the V4L2 read interface see
-<xref linkend="rw">.</para>
+<xref linkend="rw" />.</para>
       </section>
       <section>
 	<title>Capturing using memory mapping</title>
@@ -796,7 +796,7 @@ queues. Applications can query the signal status, if known, with the
 	</informaltable>
 
 	<para>For a more in-depth discussion of memory mapping and
-examples, see <xref linkend="mmap">.</para>
+examples, see <xref linkend="mmap" />.</para>
       </section>
     </section>
 
@@ -859,7 +859,7 @@ correct values.</para></footnote></para></entry>
 <constant>VIDIOCSVBIFMT</constant> ioctls using struct
 <structname>vbi_format</structname> were added to determine the VBI
 image parameters. These ioctls are only partially compatible with the
-V4L2 VBI interface specified in <xref linkend="raw-vbi">.</para>
+V4L2 VBI interface specified in <xref linkend="raw-vbi" />.</para>
 
       <para>An <structfield>offset</structfield> field does not
 exist, <structfield>sample_format</structfield> is supposed to be
@@ -881,12 +881,12 @@ parameters are invalid.</para>
 <constant>VIDIOCGUNIT</constant> ioctl. Applications can find the VBI
 device associated with a video capture device (or vice versa) by
 reopening the device and requesting VBI data. For details see
-<xref linkend="open">.</para>
+<xref linkend="open" />.</para>
 
       <para>No replacement exists for <constant>VIDIOCKEY</constant>,
 and the V4L functions for microcode programming. A new interface for
 MPEG compression and playback devices is documented in <xref
-	  linkend="extended-controls">.</para>
+	  linkend="extended-controls" />.</para>
     </section>
 
   </section>
@@ -1250,7 +1250,7 @@ into Linux 2.5.46.</para>
 
       <orderedlist>
 	<listitem>
-	  <para>As specified in <xref linkend="related">, drivers
+	  <para>As specified in <xref linkend="related" />, drivers
 must make related device functions available under all minor device
 numbers.</para>
 	</listitem>
@@ -1264,7 +1264,7 @@ flag, a V4L2 symbol which aliased the meaningless
 <constant>O_TRUNC</constant> to indicate accesses without data
 exchange (panel applications) was dropped. Drivers must stay in "panel
 mode" until the application attempts to initiate a data exchange, see
-<xref linkend="open">.</para>
+<xref linkend="open" />.</para>
 	</listitem>
 
 	<listitem>
@@ -1294,8 +1294,8 @@ set and was merged into the <structfield>flags</structfield> field.
 	  <para>The redundant fields
 <structfield>inputs</structfield>, <structfield>outputs</structfield>
 and <structfield>audios</structfield> were removed. These properties
-can be determined as described in <xref linkend="video"> and <xref
-linkend="audio">.</para>
+can be determined as described in <xref linkend="video" /> and <xref
+linkend="audio" />.</para>
 
 	  <para>The somewhat volatile and therefore barely useful
 fields <structfield>maxwidth</structfield>,
@@ -1303,15 +1303,15 @@ fields <structfield>maxwidth</structfield>,
 <structfield>minwidth</structfield>,
 <structfield>minheight</structfield>,
 <structfield>maxframerate</structfield> were removed. This information
-is available as described in <xref linkend="format"> and
-<xref linkend="standard">.</para>
+is available as described in <xref linkend="format" /> and
+<xref linkend="standard" />.</para>
 
 	  <para><constant>V4L2_FLAG_SELECT</constant> was removed. We
 believe the select() function is important enough to require support
 of it in all V4L2 drivers exchanging data with applications. The
 redundant <constant>V4L2_FLAG_MONOCHROME</constant> flag was removed,
 this information is available as described in <xref
-	      linkend="format">.</para>
+	      linkend="format" />.</para>
 	</listitem>
 
 	<listitem>
@@ -1383,7 +1383,7 @@ video standards beyond presenting the user a menu. Instead of
 enumerating supported standards with an ioctl applications can now
 refer to standards by &v4l2-std-id; and symbols defined in the
 <filename>videodev2.h</filename> header file. For details see <xref
-	      linkend="standard">. The &VIDIOC-G-STD; and
+	      linkend="standard" />. The &VIDIOC-G-STD; and
 &VIDIOC-S-STD; now take a pointer to this type as argument.
 &VIDIOC-QUERYSTD; was added to autodetect the received standard, if
 the hardware has this capability. In &v4l2-standard; an
@@ -1577,7 +1577,7 @@ field.<informaltable>
 &v4l2-buf-type;. Buffer types changed as mentioned above. A new
 <structfield>memory</structfield> field of type &v4l2-memory; was
 added to distinguish between I/O methods using buffers allocated
-by the driver or the application. See <xref linkend="io"> for
+by the driver or the application. See <xref linkend="io" /> for
 details.</para>
 	</listitem>
 
@@ -1595,7 +1595,7 @@ addition of a second memory mapping method the
 <structfield>offset</structfield> field moved into union
 <structfield>m</structfield>, and a new
 <structfield>memory</structfield> field of type &v4l2-memory; was
-added to distinguish between I/O methods. See <xref linkend="io">
+added to distinguish between I/O methods. See <xref linkend="io" />
 for details.</para>
 
 	  <para>The <constant>V4L2_BUF_REQ_CONTIG</constant>
@@ -1649,7 +1649,7 @@ to distinguish between field and frame (interlaced) overlay.</para>
 cropping and scaling interface. The previously unused struct
 <structname>v4l2_cropcap</structname> and
 <structname>v4l2_crop</structname> where redefined for this purpose.
-See <xref linkend="crop"> for details.</para>
+See <xref linkend="crop" /> for details.</para>
 	</listitem>
 
 	<listitem>
@@ -1683,7 +1683,7 @@ applications.</para>
 	<listitem>
 	  <para>The example transformation from RGB to YCbCr color
 space in the old V4L2 documentation was inaccurate, this has been
-corrected in <xref linkend="pixfmt">.<!-- 0.5670G should be
+corrected in <xref linkend="pixfmt" />.<!-- 0.5670G should be
 0.587, and 127/112 != 255/224 --></para>
 	</listitem>
       </orderedlist>
@@ -1702,7 +1702,7 @@ tuner whose type field reads <constant>V4L2_TUNER_RADIO</constant>.</para>
 
 	<listitem>
 	  <para>An optional driver access priority mechanism was
-added, see <xref linkend="app-pri"> for details.</para>
+added, see <xref linkend="app-pri" /> for details.</para>
 	</listitem>
 
 	<listitem>
@@ -1734,7 +1734,7 @@ must be recompiled, but not applications.</para>
 	</listitem>
 
 	<listitem>
-	  <para><xref linkend="overlay"> incorrectly stated that
+	  <para><xref linkend="overlay" /> incorrectly stated that
 clipping rectangles define regions where the video can be seen.
 Correct is that clipping rectangles define regions where
 <emphasis>no</emphasis> video shall be displayed and so the graphics
@@ -1756,7 +1756,7 @@ applications assuming a constant parameter need an update.</para>
       <title>V4L2 2003-11-05</title>
       <orderedlist>
 	<listitem>
-	  <para>In <xref linkend="pixfmt-rgb"> the following pixel
+	  <para>In <xref linkend="pixfmt-rgb" /> the following pixel
 formats were incorrectly transferred from Bill Dirks' V4L2
 specification. Descriptions below refer to bytes in memory, in
 ascending address order.<informaltable>
@@ -1795,7 +1795,7 @@ ascending address order.<informaltable>
 	    </informaltable> The
 <constant>V4L2_PIX_FMT_BGR24</constant> example was always
 correct.</para>
-	  <para>In <xref linkend="v4l-image-properties"> the mapping
+	  <para>In <xref linkend="v4l-image-properties" /> the mapping
 of the V4L <constant>VIDEO_PALETTE_RGB24</constant> and
 <constant>VIDEO_PALETTE_RGB32</constant> formats to V4L2 pixel formats
 was accordingly corrected.</para>
@@ -1805,7 +1805,7 @@ was accordingly corrected.</para>
 	  <para>Unrelated to the fixes above, drivers may still
 interpret some V4L2 RGB pixel formats differently. These issues have
 yet to be addressed, for details see <xref
-	      linkend="pixfmt-rgb">.</para>
+	      linkend="pixfmt-rgb" />.</para>
 	</listitem>
       </orderedlist>
     </section>
@@ -1844,7 +1844,7 @@ read-only.</para>
       <orderedlist>
 	<listitem>
 	  <para>The return value of the
-<xref linkend="func-open"> function was incorrectly documented.</para>
+<xref linkend="func-open" /> function was incorrectly documented.</para>
 	</listitem>
 
 	<listitem>
@@ -1872,7 +1872,7 @@ was not documented.</para>
       <orderedlist>
 	<listitem>
 	  <para>A new sliced VBI interface was added. It is documented
-in <xref linkend="sliced"> and replaces the interface first
+in <xref linkend="sliced" /> and replaces the interface first
 proposed in V4L2 specification 0.8.</para>
 	</listitem>
       </orderedlist>
@@ -1895,7 +1895,7 @@ and <constant>V4L2_STD_ATSC</constant> (a set of
 <constant>V4L2_STD_ATSC_16_VSB</constant>) were defined. Note the
 <constant>V4L2_STD_525_60</constant> set now includes
 <constant>V4L2_STD_NTSC_443</constant>. See also <xref
-	      linkend="v4l2-std-id">.</para>
+	      linkend="v4l2-std-id" />.</para>
 	</listitem>
 
 	<listitem>
@@ -1914,10 +1914,10 @@ was replaced by a struct
 
     <section>
       <title>V4L2 spec erratum 2005-11-27</title>
-      <para>The capture example in <xref linkend="capture-example">
+      <para>The capture example in <xref linkend="capture-example" />
 called the &VIDIOC-S-CROP; ioctl without checking if cropping is
 supported. In the video standard selection example in
-<xref linkend="standard"> the &VIDIOC-S-STD; call used the wrong
+<xref linkend="standard" /> the &VIDIOC-S-STD; call used the wrong
 argument type.</para>
     </section>
 
@@ -1999,18 +1999,18 @@ interface were not mentioned along with other buffer types.</para>
 	</listitem>
 
 	<listitem>
-	  <para>In <xref linkend="vidioc-g-audio"> it was clarified
+	  <para>In <xref linkend="vidioc-g-audio" /> it was clarified
 that the &v4l2-audio; <structfield>mode</structfield> field is a flags
 field.</para>
 	</listitem>
 
 	<listitem>
-	  <para><xref linkend="vidioc-querycap"> did not mention the
+	  <para><xref linkend="vidioc-querycap" /> did not mention the
 sliced VBI and radio capability flags.</para>
 	</listitem>
 
 	<listitem>
-	  <para>In <xref linkend="vidioc-g-frequency"> it was
+	  <para>In <xref linkend="vidioc-g-frequency" /> it was
 clarified that applications must initialize the tuner
 <structfield>type</structfield> field of &v4l2-frequency; before
 calling &VIDIOC-S-FREQUENCY;.</para>
@@ -2022,8 +2022,8 @@ in &v4l2-requestbuffers; has 2 elements, not 32.</para>
 	</listitem>
 
 	<listitem>
-	  <para>In <xref linkend="output"> and <xref
-	      linkend="raw-vbi"> the device file names
+	  <para>In <xref linkend="output" /> and <xref
+	      linkend="raw-vbi" /> the device file names
 <filename>/dev/vout</filename> which never caught on were replaced
 by <filename>/dev/video</filename>.</para>
 	</listitem>
@@ -2046,13 +2046,13 @@ and &VIDIOC-TRY-EXT-CTRLS; were added, a flag to skip unsupported
 controls with &VIDIOC-QUERYCTRL;, new control types
 <constant>V4L2_CTRL_TYPE_INTEGER64</constant> and
 <constant>V4L2_CTRL_TYPE_CTRL_CLASS</constant> (<xref
-	      linkend="v4l2-ctrl-type">), and new control flags
+	      linkend="v4l2-ctrl-type" />), and new control flags
 <constant>V4L2_CTRL_FLAG_READ_ONLY</constant>,
 <constant>V4L2_CTRL_FLAG_UPDATE</constant>,
 <constant>V4L2_CTRL_FLAG_INACTIVE</constant> and
 <constant>V4L2_CTRL_FLAG_SLIDER</constant> (<xref
-	      linkend="control-flags">). See <xref
-	      linkend="extended-controls"> for details.</para>
+	      linkend="control-flags" />). See <xref
+	      linkend="extended-controls" /> for details.</para>
 	</listitem>
       </orderedlist>
     </section>
@@ -2077,7 +2077,7 @@ compatibility</emphasis> with older drivers and applications.</para>
 
 	<listitem>
 	  <para>A new pixel format <constant>V4L2_PIX_FMT_RGB444</constant> (<xref
-linkend="rgb-formats">) was added.</para>
+linkend="rgb-formats" />) was added.</para>
 	</listitem>
       </orderedlist>
     </section>
@@ -2087,7 +2087,7 @@ linkend="rgb-formats">) was added.</para>
       <orderedlist>
 	<listitem>
 	  <para><constant>V4L2_PIX_FMT_HM12</constant> (<xref
-linkend="reserved-formats">) is a YUV 4:2:0, not 4:2:2 format.</para>
+linkend="reserved-formats" />) is a YUV 4:2:0, not 4:2:2 format.</para>
 	</listitem>
       </orderedlist>
     </section>
@@ -2110,7 +2110,7 @@ later, and under a 3-clause BSD-style license.</para>
 	  <para>Two new field orders
 	  <constant>V4L2_FIELD_INTERLACED_TB</constant> and
 	  <constant>V4L2_FIELD_INTERLACED_BT</constant> were
-	  added. See <xref linkend="v4l2-field"> for details.</para>
+	  added. See <xref linkend="v4l2-field" /> for details.</para>
 	</listitem>
 
 	<listitem>
@@ -2265,7 +2265,7 @@ video encoding.</para>
 	  <para>The <constant>VIDIOC_G_CHIP_IDENT</constant> ioctl was renamed
 to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and &VIDIOC-DBG-G-CHIP-IDENT;
 was introduced in its place. The old struct <structname>v4l2_chip_ident</structname>
-was renamed to <structname id=v4l2-chip-ident-old>v4l2_chip_ident_old</structname>.</para>
+was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structname>.</para>
 	</listitem>
 	<listitem>
 	  <para>The pixel formats
@@ -2297,7 +2297,7 @@ was renamed to <structname id=v4l2-chip-ident-old>v4l2_chip_ident_old</structnam
       <title>V4L2 in Linux 2.6.32</title>
       <orderedlist>
 	<listitem>
-	  <para>Finalized the RDS capture API. See <xref linkend="rds"> for
+	  <para>Finalized the RDS capture API. See <xref linkend="rds" /> for
 more information.</para>
 	</listitem>
 	<listitem>
@@ -2360,7 +2360,7 @@ the V4L2 backward-compatibility layer. Since V4L2 permits multiple
 opens it is possible (if supported by the V4L2 driver) to capture
 video while an X client requested video overlay. Restrictions of
 simultaneous capturing and overlay are discussed in <xref
-	  linkend="overlay"> apply.</para>
+	  linkend="overlay" /> apply.</para>
 
       <para>Only marginally related to V4L2, XFree86 extended Xv to
 support hardware YUV to RGB conversion and scaling for faster video
@@ -2395,15 +2395,15 @@ and may change in the future.</para>
     <itemizedlist>
       <listitem>
 	<para>Video Output Overlay (OSD) Interface, <xref
-	    linkend="osd">.</para>
+	    linkend="osd" />.</para>
       </listitem>
 	<listitem>
 	<para><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant>,
-	&v4l2-buf-type;, <xref linkend="v4l2-buf-type">.</para>
+	&v4l2-buf-type;, <xref linkend="v4l2-buf-type" />.</para>
       </listitem>
       <listitem>
 	<para><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant>,
-&VIDIOC-QUERYCAP; ioctl, <xref linkend="device-capabilities">.</para>
+&VIDIOC-QUERYCAP; ioctl, <xref linkend="device-capabilities" />.</para>
       </listitem>
       <listitem>
 	<para>&VIDIOC-ENUM-FRAMESIZES; and
@@ -2436,7 +2436,7 @@ interfaces and should not be implemented in new drivers.</para>
       <listitem>
 	<para><constant>VIDIOC_G_MPEGCOMP</constant> and
 <constant>VIDIOC_S_MPEGCOMP</constant> ioctls. Use Extended Controls,
-<xref linkend="extended-controls">.</para>
+<xref linkend="extended-controls" />.</para>
       </listitem>
     </itemizedlist>
   </section>