Commit | Line | Data |
---|---|---|
8e080c2e MCC |
1 | <refentry id="vidioc-g-fbuf"> |
2 | <refmeta> | |
3 | <refentrytitle>ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF</refentrytitle> | |
4 | &manvol; | |
5 | </refmeta> | |
6 | ||
7 | <refnamediv> | |
8 | <refname>VIDIOC_G_FBUF</refname> | |
9 | <refname>VIDIOC_S_FBUF</refname> | |
10 | <refpurpose>Get or set frame buffer overlay parameters</refpurpose> | |
11 | </refnamediv> | |
12 | ||
13 | <refsynopsisdiv> | |
14 | <funcsynopsis> | |
15 | <funcprototype> | |
16 | <funcdef>int <function>ioctl</function></funcdef> | |
17 | <paramdef>int <parameter>fd</parameter></paramdef> | |
18 | <paramdef>int <parameter>request</parameter></paramdef> | |
19 | <paramdef>struct v4l2_framebuffer *<parameter>argp</parameter></paramdef> | |
20 | </funcprototype> | |
21 | </funcsynopsis> | |
22 | <funcsynopsis> | |
23 | <funcprototype> | |
24 | <funcdef>int <function>ioctl</function></funcdef> | |
25 | <paramdef>int <parameter>fd</parameter></paramdef> | |
26 | <paramdef>int <parameter>request</parameter></paramdef> | |
27 | <paramdef>const struct v4l2_framebuffer *<parameter>argp</parameter></paramdef> | |
28 | </funcprototype> | |
29 | </funcsynopsis> | |
30 | </refsynopsisdiv> | |
31 | ||
32 | <refsect1> | |
33 | <title>Arguments</title> | |
34 | ||
35 | <variablelist> | |
36 | <varlistentry> | |
37 | <term><parameter>fd</parameter></term> | |
38 | <listitem> | |
39 | <para>&fd;</para> | |
40 | </listitem> | |
41 | </varlistentry> | |
42 | <varlistentry> | |
43 | <term><parameter>request</parameter></term> | |
44 | <listitem> | |
45 | <para>VIDIOC_G_FBUF, VIDIOC_S_FBUF</para> | |
46 | </listitem> | |
47 | </varlistentry> | |
48 | <varlistentry> | |
49 | <term><parameter>argp</parameter></term> | |
50 | <listitem> | |
51 | <para></para> | |
52 | </listitem> | |
53 | </varlistentry> | |
54 | </variablelist> | |
55 | </refsect1> | |
56 | ||
57 | <refsect1> | |
58 | <title>Description</title> | |
59 | ||
60 | <para>Applications can use the <constant>VIDIOC_G_FBUF</constant> and | |
61 | <constant>VIDIOC_S_FBUF</constant> ioctl to get and set the | |
62 | framebuffer parameters for a <link linkend="overlay">Video | |
63 | Overlay</link> or <link linkend="osd">Video Output Overlay</link> | |
64 | (OSD). The type of overlay is implied by the device type (capture or | |
65 | output device) and can be determined with the &VIDIOC-QUERYCAP; ioctl. | |
66 | One <filename>/dev/videoN</filename> device must not support both | |
67 | kinds of overlay.</para> | |
68 | ||
69 | <para>The V4L2 API distinguishes destructive and non-destructive | |
70 | overlays. A destructive overlay copies captured video images into the | |
71 | video memory of a graphics card. A non-destructive overlay blends | |
72 | video images into a VGA signal or graphics into a video signal. | |
73 | <wordasword>Video Output Overlays</wordasword> are always | |
74 | non-destructive.</para> | |
75 | ||
76 | <para>To get the current parameters applications call the | |
77 | <constant>VIDIOC_G_FBUF</constant> ioctl with a pointer to a | |
78 | <structname>v4l2_framebuffer</structname> structure. The driver fills | |
79 | all fields of the structure or returns an &EINVAL; when overlays are | |
80 | not supported.</para> | |
81 | ||
82 | <para>To set the parameters for a <wordasword>Video Output | |
83 | Overlay</wordasword>, applications must initialize the | |
84 | <structfield>flags</structfield> field of a struct | |
85 | <structname>v4l2_framebuffer</structname>. Since the framebuffer is | |
86 | implemented on the TV card all other parameters are determined by the | |
87 | driver. When an application calls <constant>VIDIOC_S_FBUF</constant> | |
88 | with a pointer to this structure, the driver prepares for the overlay | |
89 | and returns the framebuffer parameters as | |
90 | <constant>VIDIOC_G_FBUF</constant> does, or it returns an error | |
91 | code.</para> | |
92 | ||
93 | <para>To set the parameters for a <wordasword>non-destructive | |
94 | Video Overlay</wordasword>, applications must initialize the | |
95 | <structfield>flags</structfield> field, the | |
96 | <structfield>fmt</structfield> substructure, and call | |
97 | <constant>VIDIOC_S_FBUF</constant>. Again the driver prepares for the | |
98 | overlay and returns the framebuffer parameters as | |
99 | <constant>VIDIOC_G_FBUF</constant> does, or it returns an error | |
100 | code.</para> | |
101 | ||
102 | <para>For a <wordasword>destructive Video Overlay</wordasword> | |
103 | applications must additionally provide a | |
104 | <structfield>base</structfield> address. Setting up a DMA to a | |
105 | random memory location can jeopardize the system security, its | |
106 | stability or even damage the hardware, therefore only the superuser | |
107 | can set the parameters for a destructive video overlay.</para> | |
108 | ||
109 | <!-- NB v4l2_pix_format is also specified in pixfmt.sgml.--> | |
110 | ||
111 | <table pgwide="1" frame="none" id="v4l2-framebuffer"> | |
112 | <title>struct <structname>v4l2_framebuffer</structname></title> | |
113 | <tgroup cols="4"> | |
114 | &cs-ustr; | |
115 | <tbody valign="top"> | |
116 | <row> | |
117 | <entry>__u32</entry> | |
118 | <entry><structfield>capability</structfield></entry> | |
119 | <entry></entry> | |
120 | <entry>Overlay capability flags set by the driver, see | |
121 | <xref linkend="framebuffer-cap" />.</entry> | |
122 | </row> | |
123 | <row> | |
124 | <entry>__u32</entry> | |
125 | <entry><structfield>flags</structfield></entry> | |
126 | <entry></entry> | |
127 | <entry>Overlay control flags set by application and | |
128 | driver, see <xref linkend="framebuffer-flags" /></entry> | |
129 | </row> | |
130 | <row> | |
131 | <entry>void *</entry> | |
132 | <entry><structfield>base</structfield></entry> | |
133 | <entry></entry> | |
134 | <entry>Physical base address of the framebuffer, | |
135 | that is the address of the pixel in the top left corner of the | |
136 | framebuffer.<footnote><para>A physical base address may not suit all | |
137 | platforms. GK notes in theory we should pass something like PCI device | |
138 | + memory region + offset instead. If you encounter problems please | |
139 | discuss on the linux-media mailing list: &v4l-ml;.</para></footnote></entry> | |
140 | </row> | |
141 | <row> | |
142 | <entry></entry> | |
143 | <entry></entry> | |
144 | <entry></entry> | |
145 | <entry>This field is irrelevant to | |
146 | <wordasword>non-destructive Video Overlays</wordasword>. For | |
147 | <wordasword>destructive Video Overlays</wordasword> applications must | |
148 | provide a base address. The driver may accept only base addresses | |
149 | which are a multiple of two, four or eight bytes. For | |
150 | <wordasword>Video Output Overlays</wordasword> the driver must return | |
151 | a valid base address, so applications can find the corresponding Linux | |
152 | framebuffer device (see <xref linkend="osd" />).</entry> | |
153 | </row> | |
154 | <row> | |
155 | <entry>&v4l2-pix-format;</entry> | |
156 | <entry><structfield>fmt</structfield></entry> | |
157 | <entry></entry> | |
158 | <entry>Layout of the frame buffer. The | |
159 | <structname>v4l2_pix_format</structname> structure is defined in <xref | |
160 | linkend="pixfmt" />, for clarification the fields and acceptable values | |
161 | are listed below:</entry> | |
162 | </row> | |
163 | <row> | |
164 | <entry></entry> | |
165 | <entry>__u32</entry> | |
166 | <entry><structfield>width</structfield></entry> | |
167 | <entry>Width of the frame buffer in pixels.</entry> | |
168 | </row> | |
169 | <row> | |
170 | <entry></entry> | |
171 | <entry>__u32</entry> | |
172 | <entry><structfield>height</structfield></entry> | |
173 | <entry>Height of the frame buffer in pixels.</entry> | |
174 | </row> | |
175 | <row> | |
176 | <entry></entry> | |
177 | <entry>__u32</entry> | |
178 | <entry><structfield>pixelformat</structfield></entry> | |
179 | <entry>The pixel format of the | |
180 | framebuffer.</entry> | |
181 | </row> | |
182 | <row> | |
183 | <entry></entry> | |
184 | <entry></entry> | |
185 | <entry></entry> | |
186 | <entry>For <wordasword>non-destructive Video | |
187 | Overlays</wordasword> this field only defines a format for the | |
188 | &v4l2-window; <structfield>chromakey</structfield> field.</entry> | |
189 | </row> | |
190 | <row> | |
191 | <entry></entry> | |
192 | <entry></entry> | |
193 | <entry></entry> | |
194 | <entry>For <wordasword>destructive Video | |
195 | Overlays</wordasword> applications must initialize this field. For | |
196 | <wordasword>Video Output Overlays</wordasword> the driver must return | |
197 | a valid format.</entry> | |
198 | </row> | |
199 | <row> | |
200 | <entry></entry> | |
201 | <entry></entry> | |
202 | <entry></entry> | |
203 | <entry>Usually this is an RGB format (for example | |
204 | <link linkend="V4L2-PIX-FMT-RGB565"><constant>V4L2_PIX_FMT_RGB565</constant></link>) | |
205 | but YUV formats (only packed YUV formats when chroma keying is used, | |
206 | not including <constant>V4L2_PIX_FMT_YUYV</constant> and | |
207 | <constant>V4L2_PIX_FMT_UYVY</constant>) and the | |
208 | <constant>V4L2_PIX_FMT_PAL8</constant> format are also permitted. The | |
209 | behavior of the driver when an application requests a compressed | |
210 | format is undefined. See <xref linkend="pixfmt" /> for information on | |
211 | pixel formats.</entry> | |
212 | </row> | |
213 | <row> | |
214 | <entry></entry> | |
215 | <entry>&v4l2-field;</entry> | |
216 | <entry><structfield>field</structfield></entry> | |
217 | <entry>Drivers and applications shall ignore this field. | |
218 | If applicable, the field order is selected with the &VIDIOC-S-FMT; | |
219 | ioctl, using the <structfield>field</structfield> field of | |
220 | &v4l2-window;.</entry> | |
221 | </row> | |
222 | <row> | |
223 | <entry></entry> | |
224 | <entry>__u32</entry> | |
225 | <entry><structfield>bytesperline</structfield></entry> | |
226 | <entry>Distance in bytes between the leftmost pixels in | |
227 | two adjacent lines.</entry> | |
228 | </row> | |
229 | <row> | |
230 | <entry spanname="hspan"><para>This field is irrelevant to | |
231 | <wordasword>non-destructive Video | |
232 | Overlays</wordasword>.</para><para>For <wordasword>destructive Video | |
233 | Overlays</wordasword> both applications and drivers can set this field | |
234 | to request padding bytes at the end of each line. Drivers however may | |
235 | ignore the requested value, returning <structfield>width</structfield> | |
236 | times bytes-per-pixel or a larger value required by the hardware. That | |
237 | implies applications can just set this field to zero to get a | |
238 | reasonable default.</para><para>For <wordasword>Video Output | |
239 | Overlays</wordasword> the driver must return a valid | |
240 | value.</para><para>Video hardware may access padding bytes, therefore | |
241 | they must reside in accessible memory. Consider for example the case | |
242 | where padding bytes after the last line of an image cross a system | |
243 | page boundary. Capture devices may write padding bytes, the value is | |
244 | undefined. Output devices ignore the contents of padding | |
245 | bytes.</para><para>When the image format is planar the | |
246 | <structfield>bytesperline</structfield> value applies to the largest | |
247 | plane and is divided by the same factor as the | |
248 | <structfield>width</structfield> field for any smaller planes. For | |
249 | example the Cb and Cr planes of a YUV 4:2:0 image have half as many | |
250 | padding bytes following each line as the Y plane. To avoid ambiguities | |
251 | drivers must return a <structfield>bytesperline</structfield> value | |
252 | rounded up to a multiple of the scale factor.</para></entry> | |
253 | </row> | |
254 | <row> | |
255 | <entry></entry> | |
256 | <entry>__u32</entry> | |
257 | <entry><structfield>sizeimage</structfield></entry> | |
258 | <entry><para>This field is irrelevant to | |
259 | <wordasword>non-destructive Video Overlays</wordasword>. For | |
260 | <wordasword>destructive Video Overlays</wordasword> applications must | |
261 | initialize this field. For <wordasword>Video Output | |
262 | Overlays</wordasword> the driver must return a valid | |
263 | format.</para><para>Together with <structfield>base</structfield> it | |
264 | defines the framebuffer memory accessible by the | |
265 | driver.</para></entry> | |
266 | </row> | |
267 | <row> | |
268 | <entry></entry> | |
269 | <entry>&v4l2-colorspace;</entry> | |
270 | <entry><structfield>colorspace</structfield></entry> | |
271 | <entry>This information supplements the | |
272 | <structfield>pixelformat</structfield> and must be set by the driver, | |
273 | see <xref linkend="colorspaces" />.</entry> | |
274 | </row> | |
275 | <row> | |
276 | <entry></entry> | |
277 | <entry>__u32</entry> | |
278 | <entry><structfield>priv</structfield></entry> | |
279 | <entry>Reserved for additional information about custom | |
280 | (driver defined) formats. When not used drivers and applications must | |
281 | set this field to zero.</entry> | |
282 | </row> | |
283 | </tbody> | |
284 | </tgroup> | |
285 | </table> | |
286 | ||
287 | <table pgwide="1" frame="none" id="framebuffer-cap"> | |
288 | <title>Frame Buffer Capability Flags</title> | |
289 | <tgroup cols="3"> | |
290 | &cs-def; | |
291 | <tbody valign="top"> | |
292 | <row> | |
293 | <entry><constant>V4L2_FBUF_CAP_EXTERNOVERLAY</constant></entry> | |
294 | <entry>0x0001</entry> | |
295 | <entry>The device is capable of non-destructive overlays. | |
296 | When the driver clears this flag, only destructive overlays are | |
297 | supported. There are no drivers yet which support both destructive and | |
0fb6ec6b HV |
298 | non-destructive overlays. Video Output Overlays are in practice always |
299 | non-destructive.</entry> | |
8e080c2e MCC |
300 | </row> |
301 | <row> | |
302 | <entry><constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> | |
303 | <entry>0x0002</entry> | |
304 | <entry>The device supports clipping by chroma-keying the | |
305 | images. That is, image pixels replace pixels in the VGA or video | |
306 | signal only where the latter assume a certain color. Chroma-keying | |
307 | makes no sense for destructive overlays.</entry> | |
308 | </row> | |
309 | <row> | |
310 | <entry><constant>V4L2_FBUF_CAP_LIST_CLIPPING</constant></entry> | |
311 | <entry>0x0004</entry> | |
312 | <entry>The device supports clipping using a list of clip | |
313 | rectangles.</entry> | |
314 | </row> | |
315 | <row> | |
316 | <entry><constant>V4L2_FBUF_CAP_BITMAP_CLIPPING</constant></entry> | |
317 | <entry>0x0008</entry> | |
318 | <entry>The device supports clipping using a bit mask.</entry> | |
319 | </row> | |
320 | <row> | |
321 | <entry><constant>V4L2_FBUF_CAP_LOCAL_ALPHA</constant></entry> | |
322 | <entry>0x0010</entry> | |
323 | <entry>The device supports clipping/blending using the | |
324 | alpha channel of the framebuffer or VGA signal. Alpha blending makes | |
325 | no sense for destructive overlays.</entry> | |
326 | </row> | |
327 | <row> | |
328 | <entry><constant>V4L2_FBUF_CAP_GLOBAL_ALPHA</constant></entry> | |
329 | <entry>0x0020</entry> | |
330 | <entry>The device supports alpha blending using a global | |
331 | alpha value. Alpha blending makes no sense for destructive overlays.</entry> | |
332 | </row> | |
333 | <row> | |
334 | <entry><constant>V4L2_FBUF_CAP_LOCAL_INV_ALPHA</constant></entry> | |
335 | <entry>0x0040</entry> | |
336 | <entry>The device supports clipping/blending using the | |
337 | inverted alpha channel of the framebuffer or VGA signal. Alpha | |
338 | blending makes no sense for destructive overlays.</entry> | |
339 | </row> | |
a4834cef VH |
340 | <row> |
341 | <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry> | |
342 | <entry>0x0080</entry> | |
b698c784 HV |
343 | <entry>The device supports Source Chroma-keying. Video pixels |
344 | with the chroma-key colors are replaced by framebuffer pixels, which is exactly opposite of | |
a4834cef VH |
345 | <constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> |
346 | </row> | |
8e080c2e MCC |
347 | </tbody> |
348 | </tgroup> | |
349 | </table> | |
350 | ||
351 | <table pgwide="1" frame="none" id="framebuffer-flags"> | |
352 | <title>Frame Buffer Flags</title> | |
353 | <tgroup cols="3"> | |
354 | &cs-def; | |
355 | <tbody valign="top"> | |
356 | <row> | |
357 | <entry><constant>V4L2_FBUF_FLAG_PRIMARY</constant></entry> | |
358 | <entry>0x0001</entry> | |
359 | <entry>The framebuffer is the primary graphics surface. | |
0fb6ec6b HV |
360 | In other words, the overlay is destructive. This flag is typically set by any |
361 | driver that doesn't have the <constant>V4L2_FBUF_CAP_EXTERNOVERLAY</constant> | |
362 | capability and it is cleared otherwise.</entry> | |
8e080c2e MCC |
363 | </row> |
364 | <row> | |
365 | <entry><constant>V4L2_FBUF_FLAG_OVERLAY</constant></entry> | |
366 | <entry>0x0002</entry> | |
05834fcf HV |
367 | <entry>If this flag is set for a video capture device, then the |
368 | driver will set the initial overlay size to cover the full framebuffer size, | |
369 | otherwise the existing overlay size (as set by &VIDIOC-S-FMT;) will be used. | |
370 | ||
371 | Only one video capture driver (bttv) supports this flag. The use of this flag | |
372 | for capture devices is deprecated. There is no way to detect which drivers | |
373 | support this flag, so the only reliable method of setting the overlay size is | |
374 | through &VIDIOC-S-FMT;. | |
375 | ||
376 | If this flag is set for a video output device, then the video output overlay | |
377 | window is relative to the top-left corner of the framebuffer and restricted | |
378 | to the size of the framebuffer. If it is cleared, then the video output | |
379 | overlay window is relative to the video output display. | |
380 | </entry> | |
8e080c2e MCC |
381 | </row> |
382 | <row> | |
383 | <entry><constant>V4L2_FBUF_FLAG_CHROMAKEY</constant></entry> | |
384 | <entry>0x0004</entry> | |
385 | <entry>Use chroma-keying. The chroma-key color is | |
386 | determined by the <structfield>chromakey</structfield> field of | |
387 | &v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref | |
388 | linkend="overlay" /> | |
389 | and | |
390 | <xref linkend="osd" />.</entry> | |
391 | </row> | |
392 | <row> | |
393 | <entry spanname="hspan">There are no flags to enable | |
394 | clipping using a list of clip rectangles or a bitmap. These methods | |
395 | are negotiated with the &VIDIOC-S-FMT; ioctl, see <xref | |
396 | linkend="overlay" /> and <xref linkend="osd" />.</entry> | |
397 | </row> | |
398 | <row> | |
399 | <entry><constant>V4L2_FBUF_FLAG_LOCAL_ALPHA</constant></entry> | |
400 | <entry>0x0008</entry> | |
401 | <entry>Use the alpha channel of the framebuffer to clip or | |
402 | blend framebuffer pixels with video images. The blend | |
403 | function is: output = framebuffer pixel * alpha + video pixel * (1 - | |
404 | alpha). The actual alpha depth depends on the framebuffer pixel | |
405 | format.</entry> | |
406 | </row> | |
407 | <row> | |
408 | <entry><constant>V4L2_FBUF_FLAG_GLOBAL_ALPHA</constant></entry> | |
409 | <entry>0x0010</entry> | |
410 | <entry>Use a global alpha value to blend the framebuffer | |
411 | with video images. The blend function is: output = (framebuffer pixel | |
412 | * alpha + video pixel * (255 - alpha)) / 255. The alpha value is | |
413 | determined by the <structfield>global_alpha</structfield> field of | |
414 | &v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref | |
415 | linkend="overlay" /> | |
416 | and <xref linkend="osd" />.</entry> | |
417 | </row> | |
418 | <row> | |
419 | <entry><constant>V4L2_FBUF_FLAG_LOCAL_INV_ALPHA</constant></entry> | |
420 | <entry>0x0020</entry> | |
421 | <entry>Like | |
422 | <constant>V4L2_FBUF_FLAG_LOCAL_ALPHA</constant>, use the alpha channel | |
423 | of the framebuffer to clip or blend framebuffer pixels with video | |
424 | images, but with an inverted alpha value. The blend function is: | |
425 | output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The | |
426 | actual alpha depth depends on the framebuffer pixel format.</entry> | |
427 | </row> | |
a4834cef VH |
428 | <row> |
429 | <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry> | |
430 | <entry>0x0040</entry> | |
431 | <entry>Use source chroma-keying. The source chroma-key color is | |
432 | determined by the <structfield>chromakey</structfield> field of | |
433 | &v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref | |
434 | linkend="overlay" /> and <xref linkend="osd" />. | |
435 | Both chroma-keying are mutual exclusive to each other, so same | |
436 | <structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry> | |
437 | </row> | |
8e080c2e MCC |
438 | </tbody> |
439 | </tgroup> | |
440 | </table> | |
441 | </refsect1> | |
442 | ||
443 | <refsect1> | |
444 | &return-value; | |
445 | ||
446 | <variablelist> | |
447 | <varlistentry> | |
448 | <term><errorcode>EPERM</errorcode></term> | |
449 | <listitem> | |
450 | <para><constant>VIDIOC_S_FBUF</constant> can only be called | |
451 | by a privileged user to negotiate the parameters for a destructive | |
452 | overlay.</para> | |
453 | </listitem> | |
454 | </varlistentry> | |
8e080c2e MCC |
455 | <varlistentry> |
456 | <term><errorcode>EINVAL</errorcode></term> | |
457 | <listitem> | |
43c1daa4 | 458 | <para>The <constant>VIDIOC_S_FBUF</constant> parameters are unsuitable.</para> |
8e080c2e MCC |
459 | </listitem> |
460 | </varlistentry> | |
461 | </variablelist> | |
462 | </refsect1> | |
463 | </refentry> |