diff options
Diffstat (limited to 'v4l2-spec/io.sgml')
| -rw-r--r-- | v4l2-spec/io.sgml | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/v4l2-spec/io.sgml b/v4l2-spec/io.sgml index 957ffa0bc..f92f24323 100644 --- a/v4l2-spec/io.sgml +++ b/v4l2-spec/io.sgml @@ -17,12 +17,12 @@ yet.</para> <para>Video overlay can be considered another I/O method, although the application does not directly receive the image data. It is selected by initiating video overlay with the &VIDIOC-S-FMT; ioctl. -For more information see <xref linkend="overlay">.</para> +For more information see <xref linkend="overlay" />.</para> <para>Generally exactly one I/O method, including overlay, is associated with each file descriptor. The only exceptions are applications not exchanging data with a driver ("panel applications", -see <xref linkend="open">) and drivers permitting simultaneous video capturing +see <xref linkend="open" />) and drivers permitting simultaneous video capturing and overlay using the same file descriptor, for compatibility with V4L and earlier versions of V4L2.</para> @@ -414,7 +414,7 @@ the frames are not properly stamped by the sender. This is frequently the case with USB cameras. Here timestamps refer to the instant the field or frame was received by the driver, not the capture time. These devices identify by not enumerating any video standards, see <xref -linkend="standard">.</para> +linkend="standard" />.</para> <para>Similar limitations apply to output timestamps. Typically the video hardware locks to a clock controlling the video timing, the @@ -472,14 +472,14 @@ refers to an input stream, applications when an output stream.</entry> <entry><structfield>flags</structfield></entry> <entry></entry> <entry>Flags set by the application or driver, see <xref -linkend="buffer-flags">.</entry> +linkend="buffer-flags" />.</entry> </row> <row> <entry>&v4l2-field;</entry> <entry><structfield>field</structfield></entry> <entry></entry> <entry>Indicates the field order of the image in the -buffer, see <xref linkend="v4l2-field">. This field is not used when +buffer, see <xref linkend="v4l2-field" />. This field is not used when the buffer contains VBI data. Drivers must set it when <structfield>type</structfield> refers to an input stream, applications when an output stream.</entry> @@ -534,7 +534,7 @@ time.</para><para>Note this may count the frames received e.g. over USB, without taking into account the frames dropped by the remote hardware due to limited compression throughput or bus bandwidth. These devices identify by not enumerating any video -standards, see <xref linkend="standard">.</para></entry> +standards, see <xref linkend="standard" />.</para></entry> </row> <row> <entry>&v4l2-memory;</entry> @@ -555,7 +555,7 @@ in accordance with the selected I/O method.</entry> <constant>V4L2_MEMORY_MMAP</constant> this is the offset of the buffer from the start of the device memory. The value is returned by the driver and apart of serving as parameter to the &func-mmap; function -not useful for applications. See <xref linkend="mmap"> for details.</entry> +not useful for applications. See <xref linkend="mmap" /> for details.</entry> </row> <row> <entry></entry> @@ -564,7 +564,7 @@ not useful for applications. See <xref linkend="mmap"> for details.</entry> <entry>When <structfield>memory</structfield> is <constant>V4L2_MEMORY_USERPTR</constant> this is a pointer to the buffer (casted to unsigned long type) in virtual memory, set by the -application. See <xref linkend="userp"> for details.</entry> +application. See <xref linkend="userp" /> for details.</entry> </row> <row> <entry>__u32</entry> @@ -604,48 +604,48 @@ number of a video input as in &v4l2-input; field <entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant></entry> <entry>1</entry> <entry>Buffer of a video capture stream, see <xref - linkend="capture">.</entry> + linkend="capture" />.</entry> </row> <row> <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant></entry> <entry>2</entry> <entry>Buffer of a video output stream, see <xref - linkend="output">.</entry> + linkend="output" />.</entry> </row> <row> <entry><constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant></entry> <entry>3</entry> - <entry>Buffer for video overlay, see <xref linkend="overlay">.</entry> + <entry>Buffer for video overlay, see <xref linkend="overlay" />.</entry> </row> <row> <entry><constant>V4L2_BUF_TYPE_VBI_CAPTURE</constant></entry> <entry>4</entry> <entry>Buffer of a raw VBI capture stream, see <xref - linkend="raw-vbi">.</entry> + linkend="raw-vbi" />.</entry> </row> <row> <entry><constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant></entry> <entry>5</entry> <entry>Buffer of a raw VBI output stream, see <xref - linkend="raw-vbi">.</entry> + linkend="raw-vbi" />.</entry> </row> <row> <entry><constant>V4L2_BUF_TYPE_SLICED_VBI_CAPTURE</constant></entry> <entry>6</entry> <entry>Buffer of a sliced VBI capture stream, see <xref - linkend="sliced">.</entry> + linkend="sliced" />.</entry> </row> <row> <entry><constant>V4L2_BUF_TYPE_SLICED_VBI_OUTPUT</constant></entry> <entry>7</entry> <entry>Buffer of a sliced VBI output stream, see <xref - linkend="sliced">.</entry> + linkend="sliced" />.</entry> </row> <row> <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant></entry> <entry>8</entry> <entry>Buffer for video output overlay (OSD), see <xref - linkend="osd">. Status: <link + linkend="osd" />. Status: <link linkend="experimental">Experimental</link>.</entry> </row> <row> @@ -667,7 +667,7 @@ linkend="experimental">Experimental</link>.</entry> <entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry> <entry>0x0001</entry> <entry>The buffer resides in device memory and has been mapped -into the application's address space, see <xref linkend="mmap"> for details. +into the application's address space, see <xref linkend="mmap" /> for details. Drivers set or clear this flag when the <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link @@ -769,7 +769,7 @@ pointer</link> I/O.</entry> <title>Timecodes</title> <para>The <structname>v4l2_timecode</structname> structure is -designed to hold a <xref linkend="smpte12m"> or similar timecode. +designed to hold a <xref linkend="smpte12m" /> or similar timecode. (struct <structname>timeval</structname> timestamps are stored in &v4l2-buffer; field <structfield>timestamp</structfield>.)</para> @@ -782,12 +782,12 @@ designed to hold a <xref linkend="smpte12m"> or similar timecode. <entry>__u32</entry> <entry><structfield>type</structfield></entry> <entry>Frame rate the timecodes are based on, see <xref - linkend="timecode-type">.</entry> + linkend="timecode-type" />.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>flags</structfield></entry> - <entry>Timecode flags, see <xref linkend="timecode-flags">.</entry> + <entry>Timecode flags, see <xref linkend="timecode-flags" />.</entry> </row> <row> <entry>__u8</entry> @@ -1043,10 +1043,10 @@ line, top field first. The bottom field is transmitted first.</entry> <title>Field Order, Top Field First Transmitted</title> <mediaobject> <imageobject> - <imagedata fileref="fieldseq_tb.pdf" format="PS"> + <imagedata fileref="fieldseq_tb.pdf" format="PS" /> </imageobject> <imageobject> - <imagedata fileref="fieldseq_tb.gif" format="GIF"> + <imagedata fileref="fieldseq_tb.gif" format="GIF" /> </imageobject> </mediaobject> </figure> @@ -1055,10 +1055,10 @@ line, top field first. The bottom field is transmitted first.</entry> <title>Field Order, Bottom Field First Transmitted</title> <mediaobject> <imageobject> - <imagedata fileref="fieldseq_bt.pdf" format="PS"> + <imagedata fileref="fieldseq_bt.pdf" format="PS" /> </imageobject> <imageobject> - <imagedata fileref="fieldseq_bt.gif" format="GIF"> + <imagedata fileref="fieldseq_bt.gif" format="GIF" /> </imageobject> </mediaobject> </figure> |