|  | <refentry id="vidioc-reqbufs"> | 
|  | <refmeta> | 
|  | <refentrytitle>ioctl VIDIOC_REQBUFS</refentrytitle> | 
|  | &manvol; | 
|  | </refmeta> | 
|  |  | 
|  | <refnamediv> | 
|  | <refname>VIDIOC_REQBUFS</refname> | 
|  | <refpurpose>Initiate Memory Mapping or User Pointer I/O</refpurpose> | 
|  | </refnamediv> | 
|  |  | 
|  | <refsynopsisdiv> | 
|  | <funcsynopsis> | 
|  | <funcprototype> | 
|  | <funcdef>int <function>ioctl</function></funcdef> | 
|  | <paramdef>int <parameter>fd</parameter></paramdef> | 
|  | <paramdef>int <parameter>request</parameter></paramdef> | 
|  | <paramdef>struct v4l2_requestbuffers *<parameter>argp</parameter></paramdef> | 
|  | </funcprototype> | 
|  | </funcsynopsis> | 
|  | </refsynopsisdiv> | 
|  |  | 
|  | <refsect1> | 
|  | <title>Arguments</title> | 
|  |  | 
|  | <variablelist> | 
|  | <varlistentry> | 
|  | <term><parameter>fd</parameter></term> | 
|  | <listitem> | 
|  | <para>&fd;</para> | 
|  | </listitem> | 
|  | </varlistentry> | 
|  | <varlistentry> | 
|  | <term><parameter>request</parameter></term> | 
|  | <listitem> | 
|  | <para>VIDIOC_REQBUFS</para> | 
|  | </listitem> | 
|  | </varlistentry> | 
|  | <varlistentry> | 
|  | <term><parameter>argp</parameter></term> | 
|  | <listitem> | 
|  | <para></para> | 
|  | </listitem> | 
|  | </varlistentry> | 
|  | </variablelist> | 
|  | </refsect1> | 
|  |  | 
|  | <refsect1> | 
|  | <title>Description</title> | 
|  |  | 
|  | <para>This ioctl is used to initiate <link linkend="mmap">memory | 
|  | mapped</link> or <link linkend="userp">user pointer</link> | 
|  | I/O. Memory mapped buffers are located in device memory and must be | 
|  | allocated with this ioctl before they can be mapped into the | 
|  | application's address space. User buffers are allocated by | 
|  | applications themselves, and this ioctl is merely used to switch the | 
|  | driver into user pointer I/O mode and to setup some internal structures.</para> | 
|  |  | 
|  | <para>To allocate device buffers applications initialize all | 
|  | fields of the <structname>v4l2_requestbuffers</structname> structure. | 
|  | They set the <structfield>type</structfield> field to the respective | 
|  | stream or buffer type, the <structfield>count</structfield> field to | 
|  | the desired number of buffers, <structfield>memory</structfield> | 
|  | must be set to the requested I/O method and the <structfield>reserved</structfield> array | 
|  | must be zeroed. When the ioctl | 
|  | is called with a pointer to this structure the driver will attempt to allocate | 
|  | the requested number of buffers and it stores the actual number | 
|  | allocated in the <structfield>count</structfield> field. It can be | 
|  | smaller than the number requested, even zero, when the driver runs out | 
|  | of free memory. A larger number is also possible when the driver requires | 
|  | more buffers to function correctly. For example video output requires at least two buffers, | 
|  | one displayed and one filled by the application.</para> | 
|  | <para>When the I/O method is not supported the ioctl | 
|  | returns an &EINVAL;.</para> | 
|  |  | 
|  | <para>Applications can call <constant>VIDIOC_REQBUFS</constant> | 
|  | again to change the number of buffers, however this cannot succeed | 
|  | when any buffers are still mapped. A <structfield>count</structfield> | 
|  | value of zero frees all buffers, after aborting or finishing any DMA | 
|  | in progress, an implicit &VIDIOC-STREAMOFF;. <!-- mhs: I see no | 
|  | reason why munmap()ping one or even all buffers must imply | 
|  | streamoff.--></para> | 
|  |  | 
|  | <table pgwide="1" frame="none" id="v4l2-requestbuffers"> | 
|  | <title>struct <structname>v4l2_requestbuffers</structname></title> | 
|  | <tgroup cols="3"> | 
|  | &cs-str; | 
|  | <tbody valign="top"> | 
|  | <row> | 
|  | <entry>__u32</entry> | 
|  | <entry><structfield>count</structfield></entry> | 
|  | <entry>The number of buffers requested or granted.</entry> | 
|  | </row> | 
|  | <row> | 
|  | <entry>&v4l2-buf-type;</entry> | 
|  | <entry><structfield>type</structfield></entry> | 
|  | <entry>Type of the stream or buffers, this is the same | 
|  | as the &v4l2-format; <structfield>type</structfield> field. See <xref | 
|  | linkend="v4l2-buf-type" /> for valid values.</entry> | 
|  | </row> | 
|  | <row> | 
|  | <entry>&v4l2-memory;</entry> | 
|  | <entry><structfield>memory</structfield></entry> | 
|  | <entry>Applications set this field to | 
|  | <constant>V4L2_MEMORY_MMAP</constant> or | 
|  | <constant>V4L2_MEMORY_USERPTR</constant>.</entry> | 
|  | </row> | 
|  | <row> | 
|  | <entry>__u32</entry> | 
|  | <entry><structfield>reserved</structfield>[2]</entry> | 
|  | <entry>A place holder for future extensions and custom | 
|  | (driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and | 
|  | higher. This array should be zeroed by applications.</entry> | 
|  | </row> | 
|  | </tbody> | 
|  | </tgroup> | 
|  | </table> | 
|  | </refsect1> | 
|  |  | 
|  | <refsect1> | 
|  | &return-value; | 
|  |  | 
|  | <variablelist> | 
|  | <varlistentry> | 
|  | <term><errorcode>EBUSY</errorcode></term> | 
|  | <listitem> | 
|  | <para>The driver supports multiple opens and I/O is already | 
|  | in progress, or reallocation of buffers was attempted although one or | 
|  | more are still mapped.</para> | 
|  | </listitem> | 
|  | </varlistentry> | 
|  | <varlistentry> | 
|  | <term><errorcode>EINVAL</errorcode></term> | 
|  | <listitem> | 
|  | <para>The buffer type (<structfield>type</structfield> field) or the | 
|  | requested I/O method (<structfield>memory</structfield>) is not | 
|  | supported.</para> | 
|  | </listitem> | 
|  | </varlistentry> | 
|  | </variablelist> | 
|  | </refsect1> | 
|  | </refentry> | 
|  |  | 
|  | <!-- | 
|  | Local Variables: | 
|  | mode: sgml | 
|  | sgml-parent-document: "v4l2.sgml" | 
|  | indent-tabs-mode: nil | 
|  | End: | 
|  | --> |