| <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: | |
| --> |