1<html><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968"><title>ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="index.html" title="LINUX MEDIA INFRASTRUCTURE API"><link rel="up" href="user-func.html" title="Appendix A. Function Reference"><link rel="prev" href="vidioc-g-ext-ctrls.html" title="ioctl VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, VIDIOC_TRY_EXT_CTRLS"><link rel="next" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="vidioc-g-ext-ctrls.html">Prev</a> </td><th width="60%" align="center">Appendix A. Function Reference</th><td width="20%" align="right"> <a accesskey="n" href="vidioc-g-fmt.html">Next</a></td></tr></table><hr></div><div class="refentry"><a name="vidioc-g-fbuf"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>VIDIOC_G_FBUF, VIDIOC_S_FBUF — Get or set frame buffer overlay parameters</p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="funcsynopsis"><table border="0" class="funcprototype-table" summary="Function synopsis" style="cellspacing: 0; cellpadding: 0;"><tr><td><code class="funcdef">int <b class="fsfunc">ioctl</b>(</code></td><td>int <var class="pdparam">fd</var>, </td></tr><tr><td> </td><td>int <var class="pdparam">request</var>, </td></tr><tr><td> </td><td>struct v4l2_framebuffer *<var class="pdparam">argp</var><code>)</code>;</td></tr></table><div class="funcprototype-spacer"> </div></div><div class="funcsynopsis"><table border="0" class="funcprototype-table" summary="Function synopsis" style="cellspacing: 0; cellpadding: 0;"><tr><td><code class="funcdef">int <b class="fsfunc">ioctl</b>(</code></td><td>int <var class="pdparam">fd</var>, </td></tr><tr><td> </td><td>int <var class="pdparam">request</var>, </td></tr><tr><td> </td><td>const struct v4l2_framebuffer *<var class="pdparam">argp</var><code>)</code>;</td></tr></table><div class="funcprototype-spacer"> </div></div></div><div class="refsect1"><a name="idp1114342788"></a><h2>Arguments</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><em class="parameter"><code>fd</code></em></span></dt><dd><p>File descriptor returned by <a class="link" href="func-open.html" title="V4L2 open()"><code class="function">open()</code></a>.</p></dd><dt><span class="term"><em class="parameter"><code>request</code></em></span></dt><dd><p>VIDIOC_G_FBUF, VIDIOC_S_FBUF</p></dd><dt><span class="term"><em class="parameter"><code>argp</code></em></span></dt><dd><p></p></dd></dl></div></div><div class="refsect1"><a name="idp1114346892"></a><h2>Description</h2><p>Applications can use the <code class="constant">VIDIOC_G_FBUF</code> and 2<code class="constant">VIDIOC_S_FBUF</code> ioctl to get and set the 3framebuffer parameters for a <a class="link" href="overlay.html" title="Video Overlay Interface">Video 4Overlay</a> or <a class="link" href="osd.html" title="Video Output Overlay Interface">Video Output Overlay</a> 5(OSD). The type of overlay is implied by the device type (capture or 6output device) and can be determined with the <a class="link" href="vidioc-querycap.html" title="ioctl VIDIOC_QUERYCAP"><code class="constant">VIDIOC_QUERYCAP</code></a> ioctl. 7One <code class="filename">/dev/videoN</code> device must not support both 8kinds of overlay.</p><p>The V4L2 API distinguishes destructive and non-destructive 9overlays. A destructive overlay copies captured video images into the 10video memory of a graphics card. A non-destructive overlay blends 11video images into a VGA signal or graphics into a video signal. 12<em class="wordasword">Video Output Overlays</em> are always 13non-destructive.</p><p>To get the current parameters applications call the 14<code class="constant">VIDIOC_G_FBUF</code> ioctl with a pointer to a 15<span class="structname">v4l2_framebuffer</span> structure. The driver fills 16all fields of the structure or returns an <span class="errorcode">EINVAL</span> error code when overlays are 17not supported.</p><p>To set the parameters for a <em class="wordasword">Video Output 18Overlay</em>, applications must initialize the 19<em class="structfield"><code>flags</code></em> field of a struct 20<span class="structname">v4l2_framebuffer</span>. Since the framebuffer is 21implemented on the TV card all other parameters are determined by the 22driver. When an application calls <code class="constant">VIDIOC_S_FBUF</code> 23with a pointer to this structure, the driver prepares for the overlay 24and returns the framebuffer parameters as 25<code class="constant">VIDIOC_G_FBUF</code> does, or it returns an error 26code.</p><p>To set the parameters for a <em class="wordasword">non-destructive 27Video Overlay</em>, applications must initialize the 28<em class="structfield"><code>flags</code></em> field, the 29<em class="structfield"><code>fmt</code></em> substructure, and call 30<code class="constant">VIDIOC_S_FBUF</code>. Again the driver prepares for the 31overlay and returns the framebuffer parameters as 32<code class="constant">VIDIOC_G_FBUF</code> does, or it returns an error 33code.</p><p>For a <em class="wordasword">destructive Video Overlay</em> 34applications must additionally provide a 35<em class="structfield"><code>base</code></em> address. Setting up a DMA to a 36random memory location can jeopardize the system security, its 37stability or even damage the hardware, therefore only the superuser 38can set the parameters for a destructive video overlay.</p><div class="table"><a name="v4l2-framebuffer"></a><p class="title"><b>Table A.69. struct <span class="structname">v4l2_framebuffer</span></b></p><div class="table-contents"><table summary="struct v4l2_framebuffer" width="100%" border="0"><colgroup><col class="c1"><col class="c2"><col class="c3"><col class="c4"></colgroup><tbody valign="top"><tr><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>capability</code></em></td><td valign="top"> </td><td valign="top">Overlay capability flags set by the driver, see 39<a class="xref" href="vidioc-g-fbuf.html#framebuffer-cap" title="Table A.70. Frame Buffer Capability Flags">Table A.70, “Frame Buffer Capability Flags”</a>.</td></tr><tr><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>flags</code></em></td><td valign="top"> </td><td valign="top">Overlay control flags set by application and 40driver, see <a class="xref" href="vidioc-g-fbuf.html#framebuffer-flags" title="Table A.71. Frame Buffer Flags">Table A.71, “Frame Buffer Flags”</a></td></tr><tr><td valign="top">void *</td><td valign="top"><em class="structfield"><code>base</code></em></td><td valign="top"> </td><td valign="top">Physical base address of the framebuffer, 41that is the address of the pixel in the top left corner of the 42framebuffer.<a href="#ftn.idp1114363188" class="footnote" name="idp1114363188"><sup class="footnote">[a]</sup></a></td></tr><tr><td valign="top"> </td><td valign="top"> </td><td valign="top"> </td><td valign="top">This field is irrelevant to 43<em class="wordasword">non-destructive Video Overlays</em>. For 44<em class="wordasword">destructive Video Overlays</em> applications must 45provide a base address. The driver may accept only base addresses 46which are a multiple of two, four or eight bytes. For 47<em class="wordasword">Video Output Overlays</em> the driver must return 48a valid base address, so applications can find the corresponding Linux 49framebuffer device (see <a class="xref" href="osd.html" title="Video Output Overlay Interface">the section called “Video Output Overlay Interface”</a>).</td></tr><tr><td valign="top">struct</td><td valign="top"><em class="structfield"><code>fmt</code></em></td><td valign="top"> </td><td valign="top">Layout of the frame buffer.</td></tr><tr><td valign="top"> </td><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>width</code></em></td><td valign="top">Width of the frame buffer in pixels.</td></tr><tr><td valign="top"> </td><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>height</code></em></td><td valign="top">Height of the frame buffer in pixels.</td></tr><tr><td valign="top"> </td><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>pixelformat</code></em></td><td valign="top">The pixel format of the 50framebuffer.</td></tr><tr><td valign="top"> </td><td valign="top"> </td><td valign="top"> </td><td valign="top">For <em class="wordasword">non-destructive Video 51Overlays</em> this field only defines a format for the 52struct <a class="link" href="overlay.html#v4l2-window" title="Table 4.1. struct v4l2_window">v4l2_window</a> <em class="structfield"><code>chromakey</code></em> field.</td></tr><tr><td valign="top"> </td><td valign="top"> </td><td valign="top"> </td><td valign="top">For <em class="wordasword">destructive Video 53Overlays</em> applications must initialize this field. For 54<em class="wordasword">Video Output Overlays</em> the driver must return 55a valid format.</td></tr><tr><td valign="top"> </td><td valign="top"> </td><td valign="top"> </td><td valign="top">Usually this is an RGB format (for example 56<a class="link" href="packed-rgb.html#V4L2-PIX-FMT-RGB565"><code class="constant">V4L2_PIX_FMT_RGB565</code></a>) 57but YUV formats (only packed YUV formats when chroma keying is used, 58not including <code class="constant">V4L2_PIX_FMT_YUYV</code> and 59<code class="constant">V4L2_PIX_FMT_UYVY</code>) and the 60<code class="constant">V4L2_PIX_FMT_PAL8</code> format are also permitted. The 61behavior of the driver when an application requests a compressed 62format is undefined. See <a class="xref" href="pixfmt.html" title="Chapter 2. Image Formats">Chapter 2, <i>Image Formats</i></a> for information on 63pixel formats.</td></tr><tr><td valign="top"> </td><td valign="top">enum <a class="link" href="field-order.html#v4l2-field" title="Table 3.9. enum v4l2_field">v4l2_field</a></td><td valign="top"><em class="structfield"><code>field</code></em></td><td valign="top">Drivers and applications shall ignore this field. 64If applicable, the field order is selected with the <a class="link" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"><code class="constant">VIDIOC_S_FMT</code></a> 65ioctl, using the <em class="structfield"><code>field</code></em> field of 66struct <a class="link" href="overlay.html#v4l2-window" title="Table 4.1. struct v4l2_window">v4l2_window</a>.</td></tr><tr><td valign="top"> </td><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>bytesperline</code></em></td><td valign="top">Distance in bytes between the leftmost pixels in 67two adjacent lines.</td></tr><tr><td colspan="4" valign="top"><p>This field is irrelevant to 68<em class="wordasword">non-destructive Video 69Overlays</em>.</p><p>For <em class="wordasword">destructive Video 70Overlays</em> both applications and drivers can set this field 71to request padding bytes at the end of each line. Drivers however may 72ignore the requested value, returning <em class="structfield"><code>width</code></em> 73times bytes-per-pixel or a larger value required by the hardware. That 74implies applications can just set this field to zero to get a 75reasonable default.</p><p>For <em class="wordasword">Video Output 76Overlays</em> the driver must return a valid 77value.</p><p>Video hardware may access padding bytes, therefore 78they must reside in accessible memory. Consider for example the case 79where padding bytes after the last line of an image cross a system 80page boundary. Capture devices may write padding bytes, the value is 81undefined. Output devices ignore the contents of padding 82bytes.</p><p>When the image format is planar the 83<em class="structfield"><code>bytesperline</code></em> value applies to the first 84plane and is divided by the same factor as the 85<em class="structfield"><code>width</code></em> field for the other planes. For 86example the Cb and Cr planes of a YUV 4:2:0 image have half as many 87padding bytes following each line as the Y plane. To avoid ambiguities 88drivers must return a <em class="structfield"><code>bytesperline</code></em> value 89rounded up to a multiple of the scale factor.</p></td></tr><tr><td valign="top"> </td><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>sizeimage</code></em></td><td valign="top"><p>This field is irrelevant to 90<em class="wordasword">non-destructive Video Overlays</em>. For 91<em class="wordasword">destructive Video Overlays</em> applications must 92initialize this field. For <em class="wordasword">Video Output 93Overlays</em> the driver must return a valid 94format.</p><p>Together with <em class="structfield"><code>base</code></em> it 95defines the framebuffer memory accessible by the 96driver.</p></td></tr><tr><td valign="top"> </td><td valign="top">enum <a class="link" href="ch02s05.html#v4l2-colorspace" title="Table 2.4. V4L2 Colorspaces">v4l2_colorspace</a></td><td valign="top"><em class="structfield"><code>colorspace</code></em></td><td valign="top">This information supplements the 97<em class="structfield"><code>pixelformat</code></em> and must be set by the driver, 98see <a class="xref" href="colorspaces.html" title="Colorspaces">the section called “Colorspaces”</a>.</td></tr><tr><td valign="top"> </td><td valign="top">__u32</td><td valign="top"><em class="structfield"><code>priv</code></em></td><td valign="top">Reserved. Drivers and applications must set this field to 99zero.</td></tr></tbody><tbody class="footnotes"><tr><td colspan="4"><div id="ftn.idp1114363188" class="footnote"><p><a href="#idp1114363188" class="para"><sup class="para">[a] </sup></a>A physical base address may not suit all 100platforms. GK notes in theory we should pass something like PCI device 101+ memory region + offset instead. If you encounter problems please 102discuss on the linux-media mailing list: <a class="ulink" href="http://www.linuxtv.org/lists.php" target="_top">http://www.linuxtv.org/lists.php</a>.</p></div></td></tr></tbody></table></div></div><br class="table-break"><div class="table"><a name="framebuffer-cap"></a><p class="title"><b>Table A.70. Frame Buffer Capability Flags</b></p><div class="table-contents"><table summary="Frame Buffer Capability Flags" width="100%" border="0"><colgroup><col class="c1"><col class="c2"><col class="c3"></colgroup><tbody valign="top"><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_EXTERNOVERLAY</code></td><td valign="top">0x0001</td><td valign="top">The device is capable of non-destructive overlays. 103When the driver clears this flag, only destructive overlays are 104supported. There are no drivers yet which support both destructive and 105non-destructive overlays. Video Output Overlays are in practice always 106non-destructive.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_CHROMAKEY</code></td><td valign="top">0x0002</td><td valign="top">The device supports clipping by chroma-keying the 107images. That is, image pixels replace pixels in the VGA or video 108signal only where the latter assume a certain color. Chroma-keying 109makes no sense for destructive overlays.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_LIST_CLIPPING</code></td><td valign="top">0x0004</td><td valign="top">The device supports clipping using a list of clip 110rectangles.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_BITMAP_CLIPPING</code></td><td valign="top">0x0008</td><td valign="top">The device supports clipping using a bit mask.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_LOCAL_ALPHA</code></td><td valign="top">0x0010</td><td valign="top">The device supports clipping/blending using the 111alpha channel of the framebuffer or VGA signal. Alpha blending makes 112no sense for destructive overlays.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_GLOBAL_ALPHA</code></td><td valign="top">0x0020</td><td valign="top">The device supports alpha blending using a global 113alpha value. Alpha blending makes no sense for destructive overlays.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_LOCAL_INV_ALPHA</code></td><td valign="top">0x0040</td><td valign="top">The device supports clipping/blending using the 114inverted alpha channel of the framebuffer or VGA signal. Alpha 115blending makes no sense for destructive overlays.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_CAP_SRC_CHROMAKEY</code></td><td valign="top">0x0080</td><td valign="top">The device supports Source Chroma-keying. Video pixels 116with the chroma-key colors are replaced by framebuffer pixels, which is exactly opposite of 117<code class="constant">V4L2_FBUF_CAP_CHROMAKEY</code></td></tr></tbody></table></div></div><br class="table-break"><div class="table"><a name="framebuffer-flags"></a><p class="title"><b>Table A.71. Frame Buffer Flags</b></p><div class="table-contents"><table summary="Frame Buffer Flags" width="100%" border="0"><colgroup><col class="c1"><col class="c2"><col class="c3"></colgroup><tbody valign="top"><tr><td valign="top"><code class="constant">V4L2_FBUF_FLAG_PRIMARY</code></td><td valign="top">0x0001</td><td valign="top">The framebuffer is the primary graphics surface. 118In other words, the overlay is destructive. This flag is typically set by any 119driver that doesn't have the <code class="constant">V4L2_FBUF_CAP_EXTERNOVERLAY</code> 120capability and it is cleared otherwise.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_FLAG_OVERLAY</code></td><td valign="top">0x0002</td><td valign="top">If this flag is set for a video capture device, then the 121driver will set the initial overlay size to cover the full framebuffer size, 122otherwise the existing overlay size (as set by <a class="link" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"><code class="constant">VIDIOC_S_FMT</code></a>) will be used. 123 124Only one video capture driver (bttv) supports this flag. The use of this flag 125for capture devices is deprecated. There is no way to detect which drivers 126support this flag, so the only reliable method of setting the overlay size is 127through <a class="link" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"><code class="constant">VIDIOC_S_FMT</code></a>. 128 129If this flag is set for a video output device, then the video output overlay 130window is relative to the top-left corner of the framebuffer and restricted 131to the size of the framebuffer. If it is cleared, then the video output 132overlay window is relative to the video output display. 133 </td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_FLAG_CHROMAKEY</code></td><td valign="top">0x0004</td><td valign="top">Use chroma-keying. The chroma-key color is 134determined by the <em class="structfield"><code>chromakey</code></em> field of 135struct <a class="link" href="overlay.html#v4l2-window" title="Table 4.1. struct v4l2_window">v4l2_window</a> and negotiated with the <a class="link" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"><code class="constant">VIDIOC_S_FMT</code></a> ioctl, see <a class="xref" href="overlay.html" title="Video Overlay Interface">the section called “Video Overlay Interface”</a> 136and 137 <a class="xref" href="osd.html" title="Video Output Overlay Interface">the section called “Video Output Overlay Interface”</a>.</td></tr><tr><td colspan="3" valign="top">There are no flags to enable 138clipping using a list of clip rectangles or a bitmap. These methods 139are negotiated with the <a class="link" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"><code class="constant">VIDIOC_S_FMT</code></a> ioctl, see <a class="xref" href="overlay.html" title="Video Overlay Interface">the section called “Video Overlay Interface”</a> and <a class="xref" href="osd.html" title="Video Output Overlay Interface">the section called “Video Output Overlay Interface”</a>.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_FLAG_LOCAL_ALPHA</code></td><td valign="top">0x0008</td><td valign="top">Use the alpha channel of the framebuffer to clip or 140blend framebuffer pixels with video images. The blend 141function is: output = framebuffer pixel * alpha + video pixel * (1 - 142alpha). The actual alpha depth depends on the framebuffer pixel 143format.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_FLAG_GLOBAL_ALPHA</code></td><td valign="top">0x0010</td><td valign="top">Use a global alpha value to blend the framebuffer 144with video images. The blend function is: output = (framebuffer pixel 145* alpha + video pixel * (255 - alpha)) / 255. The alpha value is 146determined by the <em class="structfield"><code>global_alpha</code></em> field of 147struct <a class="link" href="overlay.html#v4l2-window" title="Table 4.1. struct v4l2_window">v4l2_window</a> and negotiated with the <a class="link" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"><code class="constant">VIDIOC_S_FMT</code></a> ioctl, see <a class="xref" href="overlay.html" title="Video Overlay Interface">the section called “Video Overlay Interface”</a> 148and <a class="xref" href="osd.html" title="Video Output Overlay Interface">the section called “Video Output Overlay Interface”</a>.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_FLAG_LOCAL_INV_ALPHA</code></td><td valign="top">0x0020</td><td valign="top">Like 149<code class="constant">V4L2_FBUF_FLAG_LOCAL_ALPHA</code>, use the alpha channel 150of the framebuffer to clip or blend framebuffer pixels with video 151images, but with an inverted alpha value. The blend function is: 152output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The 153actual alpha depth depends on the framebuffer pixel format.</td></tr><tr><td valign="top"><code class="constant">V4L2_FBUF_FLAG_SRC_CHROMAKEY</code></td><td valign="top">0x0040</td><td valign="top">Use source chroma-keying. The source chroma-key color is 154determined by the <em class="structfield"><code>chromakey</code></em> field of 155struct <a class="link" href="overlay.html#v4l2-window" title="Table 4.1. struct v4l2_window">v4l2_window</a> and negotiated with the <a class="link" href="vidioc-g-fmt.html" title="ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT"><code class="constant">VIDIOC_S_FMT</code></a> ioctl, see <a class="xref" href="overlay.html" title="Video Overlay Interface">the section called “Video Overlay Interface”</a> and <a class="xref" href="osd.html" title="Video Output Overlay Interface">the section called “Video Output Overlay Interface”</a>. 156Both chroma-keying are mutual exclusive to each other, so same 157<em class="structfield"><code>chromakey</code></em> field of struct <a class="link" href="overlay.html#v4l2-window" title="Table 4.1. struct v4l2_window">v4l2_window</a> is being used.</td></tr></tbody></table></div></div><br class="table-break"></div><div class="refsect1"><a name="idp1114420276"></a><h2>Return Value</h2><p>On success <span class="returnvalue">0</span> is returned, on error <span class="returnvalue">-1</span> and the <code class="varname">errno</code> variable is set appropriately. The generic error codes are described at the <a class="link" href="gen_errors.html#gen-errors" title="Table 19.1. Generic error codes">Generic Error Codes</a> chapter.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><span class="errorcode">EPERM</span></span></dt><dd><p><code class="constant">VIDIOC_S_FBUF</code> can only be called 158by a privileged user to negotiate the parameters for a destructive 159overlay.</p></dd><dt><span class="term"><span class="errorcode">EINVAL</span></span></dt><dd><p>The <code class="constant">VIDIOC_S_FBUF</code> parameters are unsuitable.</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="vidioc-g-ext-ctrls.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="user-func.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="vidioc-g-fmt.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">ioctl VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, 160VIDIOC_TRY_EXT_CTRLS </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, 161VIDIOC_TRY_FMT</td></tr></table></div></body></html> 162