333c8b9778
Add a userspace API to get, set and enumerate the media format on a subdev pad. The format at the output of a subdev usually depends on the format at its input(s). The try format operation is thus not suitable for probing format at individual pads, as it can't modify the device state and thus can't remember the format tried at the input to compute the output format. To fix the problem, pass an extra argument to the get/set format operations to select the 'try' or 'active' format. The try format is used when probing the subdev. Setting the try format must not change the device configuration but can store data for later reuse. Data storage is provided at the file-handle level so applications probing the subdev concurently won't interfere with each other. The active format is used when configuring the subdev. It's identical to the format handled by the usual get/set operations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
116 lines
3.6 KiB
XML
116 lines
3.6 KiB
XML
<refentry id="vidioc-streamon">
|
|
<refmeta>
|
|
<refentrytitle>ioctl VIDIOC_STREAMON, VIDIOC_STREAMOFF</refentrytitle>
|
|
&manvol;
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>VIDIOC_STREAMON</refname>
|
|
<refname>VIDIOC_STREAMOFF</refname>
|
|
<refpurpose>Start or stop streaming 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>const int *<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_STREAMON, VIDIOC_STREAMOFF</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><parameter>argp</parameter></term>
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>The <constant>VIDIOC_STREAMON</constant> and
|
|
<constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture
|
|
or output process during streaming (<link linkend="mmap">memory
|
|
mapping</link> or <link linkend="userp">user pointer</link>) I/O.</para>
|
|
|
|
<para>Specifically the capture hardware is disabled and no input
|
|
buffers are filled (if there are any empty buffers in the incoming
|
|
queue) until <constant>VIDIOC_STREAMON</constant> has been called.
|
|
Accordingly the output hardware is disabled, no video signal is
|
|
produced until <constant>VIDIOC_STREAMON</constant> has been called.
|
|
The ioctl will succeed only when at least one output buffer is in the
|
|
incoming queue.</para>
|
|
|
|
<para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of
|
|
aborting or finishing any DMA in progress, unlocks any user pointer
|
|
buffers locked in physical memory, and it removes all buffers from the
|
|
incoming and outgoing queues. That means all images captured but not
|
|
dequeued yet will be lost, likewise all images enqueued for output but
|
|
not transmitted yet. I/O returns to the same state as after calling
|
|
&VIDIOC-REQBUFS; and can be restarted accordingly.</para>
|
|
|
|
<para>Both ioctls take a pointer to an integer, the desired buffer or
|
|
stream type. This is the same as &v4l2-requestbuffers;
|
|
<structfield>type</structfield>.</para>
|
|
|
|
<para>Note applications can be preempted for unknown periods right
|
|
before or after the <constant>VIDIOC_STREAMON</constant> or
|
|
<constant>VIDIOC_STREAMOFF</constant> calls, there is no notion of
|
|
starting or stopping "now". Buffer timestamps can be used to
|
|
synchronize with other events.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
&return-value;
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><errorcode>EINVAL</errorcode></term>
|
|
<listitem>
|
|
<para>Streaming I/O is not supported, the buffer
|
|
<structfield>type</structfield> is not supported, or no buffers have
|
|
been allocated (memory mapping) or enqueued (output) yet.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><errorcode>EPIPE</errorcode></term>
|
|
<listitem>
|
|
<para>The driver implements <link
|
|
linkend="pad-level-formats">pad-level format configuration</link> and
|
|
the pipeline configuration is invalid.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
</refentry>
|
|
|
|
<!--
|
|
Local Variables:
|
|
mode: sgml
|
|
sgml-parent-document: "v4l2.sgml"
|
|
indent-tabs-mode: nil
|
|
End:
|
|
-->
|