aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/DocBook
diff options
context:
space:
mode:
authorPawel Osciak <pawel@osciak.com>2011-01-16 11:53:31 -0500
committerMauro Carvalho Chehab <mchehab@redhat.com>2011-03-21 19:32:05 -0400
commitd39155d91d034e2b2c9154892e29c8a8eb193b7f (patch)
tree4f61e74a30e17ef8381e6846056f3c3ce185e70e /Documentation/DocBook
parent87a0c94ce616b231f3c0bd09d7dbd39d43b0557a (diff)
[media] Remove compatibility layer from multi-planar API documentation
This feature will probably be moved to libv4l2. Signed-off-by: Pawel Osciak <pawel@osciak.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/DocBook')
-rw-r--r--Documentation/DocBook/v4l/planar-apis.xml35
-rw-r--r--Documentation/DocBook/v4l/vidioc-querycap.xml22
2 files changed, 18 insertions, 39 deletions
diff --git a/Documentation/DocBook/v4l/planar-apis.xml b/Documentation/DocBook/v4l/planar-apis.xml
index 7f3f5527057e..878ce2040488 100644
--- a/Documentation/DocBook/v4l/planar-apis.xml
+++ b/Documentation/DocBook/v4l/planar-apis.xml
@@ -2,10 +2,10 @@
2 <title>Single- and multi-planar APIs</title> 2 <title>Single- and multi-planar APIs</title>
3 3
4 <para>Some devices require data for each input or output video frame 4 <para>Some devices require data for each input or output video frame
5 to be placed in discontiguous memory buffers. In such cases one 5 to be placed in discontiguous memory buffers. In such cases, one
6 video frame has to be addressed using more than one memory address, i.e. one 6 video frame has to be addressed using more than one memory address, i.e. one
7 pointer per "plane". A plane is a sub-buffer of current frame. For examples 7 pointer per "plane". A plane is a sub-buffer of the current frame. For
8 of such formats see <xref linkend="pixfmt" />.</para> 8 examples of such formats see <xref linkend="pixfmt" />.</para>
9 9
10 <para>Initially, V4L2 API did not support multi-planar buffers and a set of 10 <para>Initially, V4L2 API did not support multi-planar buffers and a set of
11 extensions has been introduced to handle them. Those extensions constitute 11 extensions has been introduced to handle them. Those extensions constitute
@@ -14,8 +14,8 @@
14 <para>Some of the V4L2 API calls and structures are interpreted differently, 14 <para>Some of the V4L2 API calls and structures are interpreted differently,
15 depending on whether single- or multi-planar API is being used. An application 15 depending on whether single- or multi-planar API is being used. An application
16 can choose whether to use one or the other by passing a corresponding buffer 16 can choose whether to use one or the other by passing a corresponding buffer
17 type to its ioctl calls. Multi-planar versions of buffer types are suffixed with 17 type to its ioctl calls. Multi-planar versions of buffer types are suffixed
18 an `_MPLANE' string. For a list of available multi-planar buffer types 18 with an `_MPLANE' string. For a list of available multi-planar buffer types
19 see &v4l2-buf-type;. 19 see &v4l2-buf-type;.
20 </para> 20 </para>
21 21
@@ -24,28 +24,9 @@
24 <para>Multi-planar API introduces new multi-planar formats. Those formats 24 <para>Multi-planar API introduces new multi-planar formats. Those formats
25 use a separate set of FourCC codes. It is important to distinguish between 25 use a separate set of FourCC codes. It is important to distinguish between
26 the multi-planar API and a multi-planar format. Multi-planar API calls can 26 the multi-planar API and a multi-planar format. Multi-planar API calls can
27 handle all single-planar formats as well, while the single-planar API cannot 27 handle all single-planar formats as well (as long as they are passed in
28 handle multi-planar formats. Applications do not have to switch between APIs 28 multi-planar API structures), while the single-planar API cannot
29 when handling both single- and multi-planar devices and should use the 29 handle multi-planar formats.</para>
30 multi-planar API version for both single- and multi-planar formats.
31 Drivers that do not support multi-planar API can still be handled with it,
32 utilizing a compatibility layer built into standard V4L2 ioctl handling.
33 </para>
34 </section>
35
36 <section>
37 <title>Single and multi-planar API compatibility layer</title>
38 <para>In most cases<footnote><para>The compatibility layer does not cover
39 drivers that do not use video_ioctl2() call.</para></footnote>, applications
40 can use the multi-planar API with older drivers that support
41 only its single-planar version and vice versa. Appropriate conversion is
42 done seamlessly for both applications and drivers in the V4L2 core. The
43 general rule of thumb is: as long as an application uses formats that
44 a driver supports, it can use either API (although use of multi-planar
45 formats is only possible with the multi-planar API). The list of formats
46 supported by a driver can be obtained using the &VIDIOC-ENUM-FMT; call.
47 It is possible, but discouraged, for a driver or an application to support
48 and use both versions of the API.</para>
49 </section> 30 </section>
50 31
51 <section> 32 <section>
diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml
index 93699769cd07..f29f1b86213c 100644
--- a/Documentation/DocBook/v4l/vidioc-querycap.xml
+++ b/Documentation/DocBook/v4l/vidioc-querycap.xml
@@ -142,30 +142,28 @@ this array to zero.</entry>
142 <row> 142 <row>
143 <entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry> 143 <entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry>
144 <entry>0x00000001</entry> 144 <entry>0x00000001</entry>
145 <entry>The device supports single-planar formats through the <link 145 <entry>The device supports the single-planar API through the <link
146linkend="capture">Video Capture</link> interface. An application can use either 146linkend="capture">Video Capture</link> interface.</entry>
147<link linkend="planar-apis">the single or the multi-planar API</link>.</entry>
148 </row> 147 </row>
149 <row> 148 <row>
150 <entry><constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant></entry> 149 <entry><constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant></entry>
151 <entry>0x00001000</entry> 150 <entry>0x00001000</entry>
152 <entry>The device supports multi-planar formats through the <link 151 <entry>The device supports the
153linkend="capture">Video Capture</link> interface. An application has to use the 152 <link linkend="planar-apis">multi-planar API</link> through the
154<link linkend="planar-apis">multi-planar API</link>.</entry> 153 <link linkend="capture">Video Capture</link> interface.</entry>
155 </row> 154 </row>
156 <row> 155 <row>
157 <entry><constant>V4L2_CAP_VIDEO_OUTPUT</constant></entry> 156 <entry><constant>V4L2_CAP_VIDEO_OUTPUT</constant></entry>
158 <entry>0x00000002</entry> 157 <entry>0x00000002</entry>
159 <entry>The device supports single-planar formats through the <link 158 <entry>The device supports the single-planar API through the <link
160linkend="output">Video Output</link> interface. An application can use either 159linkend="output">Video Output</link> interface.</entry>
161<link linkend="planar-apis">the single or the multi-planar API</link>.</entry>
162 </row> 160 </row>
163 <row> 161 <row>
164 <entry><constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant></entry> 162 <entry><constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant></entry>
165 <entry>0x00002000</entry> 163 <entry>0x00002000</entry>
166 <entry>The device supports multi-planar formats through the <link 164 <entry>The device supports the
167linkend="output">Video Output</link> interface. An application has to use the 165 <link linkend="planar-apis">multi-planar API</link> through the
168<link linkend="planar-apis">multi-planar API</link>.</entry> 166 <link linkend="output">Video Output</link> interface.</entry>
169 </row> 167 </row>
170 <row> 168 <row>
171 <entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry> 169 <entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>