Commit 76d21c56 authored by Linus Torvalds's avatar Linus Torvalds

Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (442 commits)
  [media] videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t
  [media] sh_mobile_ceu_camera: Do not call vb2's mem_ops directly
  [media] V4L: soc-camera: explicitly require V4L2_BUF_TYPE_VIDEO_CAPTURE
  [media] v4l: soc-camera: Store negotiated buffer settings
  [media] rc: interim support for 32-bit NEC-ish scancodes
  [media] mceusb: topseed 0x0011 needs gen3 init for tx to work
  [media] lirc_zilog: error out if buffer read bytes != chunk size
  [media] lirc: silence some compile warnings
  [media] hdpvr: use same polling interval as other OS
  [media] ir-kbd-i2c: pass device code w/key in hauppauge case
  [media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap
  [media] remove the old RC_MAP_HAUPPAUGE_NEW RC map
  [media] rc/keymaps: Rename Hauppauge table as rc-hauppauge
  [media] rc-rc5-hauppauge-new: Fix Hauppauge Grey mapping
  [media] rc-rc5-hauppauge-new: Add support for the old Black RC
  [media] rc-rc5-hauppauge-new: Add the old control to the table
  [media] rc-winfast: Fix the keycode tables
  [media] a800: Fix a few wrong IR key assignments
  [media] opera1: Use multimedia keys instead of an app-specific mapping
  [media] dw2102: Use multimedia keys instead of an app-specific mapping
  ...

Fix up trivial conflicts (remove/modify and some real conflicts) in:
	arch/arm/mach-omap2/devices.c
	drivers/staging/Kconfig
	drivers/staging/Makefile
	drivers/staging/dabusb/dabusb.c
	drivers/staging/dabusb/dabusb.h
	drivers/staging/easycap/easycap_ioctl.c
	drivers/staging/usbvideo/usbvideo.c
	drivers/staging/usbvideo/vicam.c
parents 6e50e9f9 472af2b0
What: /sys/bus/media/devices/.../model
Date: January 2011
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
linux-media@vger.kernel.org
Description: Contains the device model name in UTF-8. The device version is
is not be appended to the model name.
......@@ -53,7 +53,10 @@ MAN := $(patsubst %.xml, %.9, $(BOOKS))
mandocs: $(MAN)
build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \
cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(objtree)/Documentation/DocBook/media/
cp $(srctree)/Documentation/DocBook/dvb/*.png \
$(srctree)/Documentation/DocBook/v4l/*.gif \
$(srctree)/Documentation/DocBook/v4l/*.png \
$(objtree)/Documentation/DocBook/media/
xmldoclinks:
ifneq ($(objtree),$(srctree))
......
This diff is collapsed.
......@@ -106,6 +106,9 @@ Foundation. A copy of the license is included in the chapter entitled
&sub-remote_controllers;
</chapter>
</part>
<part id="media_common">
&sub-media-controller;
</part>
&sub-fdl-appendix;
......
......@@ -846,6 +846,8 @@ conversion routine or library for integration into applications.</para>
</section>
</section>
&sub-planar-apis;
<section id="crop">
<title>Image Cropping, Insertion and Scaling</title>
......
......@@ -1711,8 +1711,8 @@ ioctl would enumerate the available audio inputs. An ioctl to
determine the current audio input, if more than one combines with the
current video input, did not exist. So
<constant>VIDIOC_G_AUDIO</constant> was renamed to
<constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl will be removed in
the future. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
<constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl was removed on
Kernel 2.6.39. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio
input.</para>
<para>The same changes were made to &VIDIOC-G-AUDOUT; and
......@@ -1726,7 +1726,7 @@ must be updated to successfully compile again.</para>
<para>The &VIDIOC-OVERLAY; ioctl was incorrectly defined with
write-read parameter. It was changed to write-only, while the write-read
version was renamed to <constant>VIDIOC_OVERLAY_OLD</constant>. The old
ioctl will be removed in the future. Until further the "videodev"
ioctl was removed on Kernel 2.6.39. Until further the "videodev"
kernel module will automatically translate to the new version, so drivers
must be recompiled, but not applications.</para>
</listitem>
......@@ -1744,7 +1744,7 @@ surface can be seen.</para>
defined with write-only parameter, inconsistent with other ioctls
modifying their argument. They were changed to write-read, while a
<constant>_OLD</constant> suffix was added to the write-only versions.
The old ioctls will be removed in the future. Drivers and
The old ioctls were removed on Kernel 2.6.39. Drivers and
applications assuming a constant parameter need an update.</para>
</listitem>
</orderedlist>
......@@ -1815,8 +1815,8 @@ yet to be addressed, for details see <xref
<para>The &VIDIOC-CROPCAP; ioctl was incorrectly defined
with read-only parameter. It is now defined as write-read ioctl, while
the read-only version was renamed to
<constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl will be removed
in the future.</para>
<constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl was removed
on Kernel 2.6.39.</para>
</listitem>
</orderedlist>
</section>
......@@ -2353,6 +2353,20 @@ that used it. It was originally scheduled for removal in 2.6.35.
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 2.6.39</title>
<orderedlist>
<listitem>
<para>The old VIDIOC_*_OLD symbols and V4L1 support were removed.</para>
</listitem>
<listitem>
<para>Multi-planar API added. Does not affect the compatibility of
current drivers and applications. See
<link linkend="planar-apis">multi-planar API</link>
for details.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
......
......@@ -18,7 +18,8 @@ files are used for video output devices.</para>
<title>Querying Capabilities</title>
<para>Devices supporting the video capture interface set the
<constant>V4L2_CAP_VIDEO_CAPTURE</constant> flag in the
<constant>V4L2_CAP_VIDEO_CAPTURE</constant> or
<constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions
they may also support the <link linkend="overlay">video overlay</link>
......@@ -64,9 +65,11 @@ linkend="crop" />.</para>
<para>To query the current image format applications set the
<structfield>type</structfield> field of a &v4l2-format; to
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> and call the
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and call the
&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
the &v4l2-pix-format; <structfield>pix</structfield> member of the
the &v4l2-pix-format; <structfield>pix</structfield> or the
&v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
<structfield>fmt</structfield> union.</para>
<para>To request different parameters applications set the
......@@ -84,8 +87,8 @@ adjust the parameters and finally return the actual parameters as
without disabling I/O or possibly time consuming hardware
preparations.</para>
<para>The contents of &v4l2-pix-format; are discussed in <xref
linkend="pixfmt" />. See also the specification of the
<para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
are discussed in <xref linkend="pixfmt" />. See also the specification of the
<constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant>
and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video
capture devices must implement both the
......
......@@ -17,7 +17,8 @@ files are used for video capture devices.</para>
<title>Querying Capabilities</title>
<para>Devices supporting the video output interface set the
<constant>V4L2_CAP_VIDEO_OUTPUT</constant> flag in the
<constant>V4L2_CAP_VIDEO_OUTPUT</constant> or
<constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions
they may also support the <link linkend="raw-vbi">raw VBI
......@@ -60,9 +61,11 @@ linkend="crop" />.</para>
<para>To query the current image format applications set the
<structfield>type</structfield> field of a &v4l2-format; to
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and call the
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and call the
&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
the &v4l2-pix-format; <structfield>pix</structfield> member of the
the &v4l2-pix-format; <structfield>pix</structfield> or the
&v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
<structfield>fmt</structfield> union.</para>
<para>To request different parameters applications set the
......@@ -80,8 +83,8 @@ adjust the parameters and finally return the actual parameters as
without disabling I/O or possibly time consuming hardware
preparations.</para>
<para>The contents of &v4l2-pix-format; are discussed in <xref
linkend="pixfmt" />. See also the specification of the
<para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
are discussed in <xref linkend="pixfmt" />. See also the specification of the
<constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant>
and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video
output devices must implement both the
......
This diff is collapsed.
......@@ -45,7 +45,10 @@ just specify a <constant>NULL</constant> pointer here.</para>
<listitem>
<para>Length of the memory area to map. This must be the
same value as returned by the driver in the &v4l2-buffer;
<structfield>length</structfield> field.</para>
<structfield>length</structfield> field for the
single-planar API, and the same value as returned by the driver
in the &v4l2-plane; <structfield>length</structfield> field for the
multi-planar API.</para>
</listitem>
</varlistentry>
<varlistentry>
......@@ -106,7 +109,10 @@ flag.</para>
<listitem>
<para>Offset of the buffer in device memory. This must be the
same value as returned by the driver in the &v4l2-buffer;
<structfield>m</structfield> union <structfield>offset</structfield> field.</para>
<structfield>m</structfield> union <structfield>offset</structfield> field for
the single-planar API, and the same value as returned by the driver
in the &v4l2-plane; <structfield>m</structfield> union
<structfield>mem_offset</structfield> field for the multi-planar API.</para>
</listitem>
</varlistentry>
</variablelist>
......
......@@ -37,7 +37,8 @@
<para>Length of the mapped buffer. This must be the same
value as given to <function>mmap()</function> and returned by the
driver in the &v4l2-buffer; <structfield>length</structfield>
field.</para>
field for the single-planar API and in the &v4l2-plane;
<structfield>length</structfield> field for the multi-planar API.</para>
</listitem>
</varlistentry>
</variablelist>
......
This diff is collapsed.
......@@ -45,7 +45,7 @@ describing an IR signal are read from the chardev.</para>
<para>The data written to the chardev is a pulse/space sequence of integer
values. Pulses and spaces are only marked implicitly by their position. The
data must start and end with a pulse, therefore, the data must always include
an unevent number of samples. The write function must block until the data has
an uneven number of samples. The write function must block until the data has
been transmitted by the hardware.</para>
</section>
......
<partinfo>
<authorgroup>
<author>
<firstname>Laurent</firstname>
<surname>Pinchart</surname>
<affiliation><address><email>laurent.pinchart@ideasonboard.com</email></address></affiliation>
<contrib>Initial version.</contrib>
</author>
</authorgroup>
<copyright>
<year>2010</year>
<holder>Laurent Pinchart</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>1.0.0</revnumber>
<date>2010-11-10</date>
<authorinitials>lp</authorinitials>
<revremark>Initial revision</revremark>
</revision>
</revhistory>
</partinfo>
<title>Media Controller API</title>
<chapter id="media_controller">
<title>Media Controller</title>
<section id="media-controller-intro">
<title>Introduction</title>
<para>Media devices increasingly handle multiple related functions. Many USB
cameras include microphones, video capture hardware can also output video,
or SoC camera interfaces also perform memory-to-memory operations similar to
video codecs.</para>
<para>Independent functions, even when implemented in the same hardware, can
be modelled as separate devices. A USB camera with a microphone will be
presented to userspace applications as V4L2 and ALSA capture devices. The
devices' relationships (when using a webcam, end-users shouldn't have to
manually select the associated USB microphone), while not made available
directly to applications by the drivers, can usually be retrieved from
sysfs.</para>
<para>With more and more advanced SoC devices being introduced, the current
approach will not scale. Device topologies are getting increasingly complex
and can't always be represented by a tree structure. Hardware blocks are
shared between different functions, creating dependencies between seemingly
unrelated devices.</para>
<para>Kernel abstraction APIs such as V4L2 and ALSA provide means for
applications to access hardware parameters. As newer hardware expose an
increasingly high number of those parameters, drivers need to guess what
applications really require based on limited information, thereby
implementing policies that belong to userspace.</para>
<para>The media controller API aims at solving those problems.</para>
</section>
<section id="media-controller-model">
<title>Media device model</title>
<para>Discovering a device internal topology, and configuring it at runtime,
is one of the goals of the media controller API. To achieve this, hardware
devices are modelled as an oriented graph of building blocks called entities
connected through pads.</para>
<para>An entity is a basic media hardware or software building block. It can
correspond to a large variety of logical blocks such as physical hardware
devices (CMOS sensor for instance), logical hardware devices (a building
block in a System-on-Chip image processing pipeline), DMA channels or
physical connectors.</para>
<para>A pad is a connection endpoint through which an entity can interact
with other entities. Data (not restricted to video) produced by an entity
flows from the entity's output to one or more entity inputs. Pads should not
be confused with physical pins at chip boundaries.</para>
<para>A link is a point-to-point oriented connection between two pads,
either on the same entity or on different entities. Data flows from a source
pad to a sink pad.</para>
</section>
</chapter>
<appendix id="media-user-func">
<title>Function Reference</title>
<!-- Keep this alphabetically sorted. -->
&sub-media-open;
&sub-media-close;
&sub-media-ioctl;
<!-- All ioctls go here. -->
&sub-media-ioc-device-info;
&sub-media-ioc-enum-entities;
&sub-media-ioc-enum-links;
&sub-media-ioc-setup-link;
</appendix>
<refentry id="media-func-close">
<refmeta>
<refentrytitle>media close()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>media-close</refname>
<refpurpose>Close a media device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;unistd.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>close</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Closes the media device. Resources associated with the file descriptor
are freed. The device configuration remain unchanged.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>close</function> returns 0 on success. On error, -1 is
returned, and <varname>errno</varname> is set appropriately. Possible error
codes are:</para>
<variablelist>
<varlistentry>
<term><errorcode>EBADF</errorcode></term>
<listitem>
<para><parameter>fd</parameter> is not a valid open file descriptor.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="media-func-ioctl">
<refmeta>
<refentrytitle>media ioctl()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>media-ioctl</refname>
<refpurpose>Control a media device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;sys/ioctl.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>void *<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>Media ioctl request code as defined in the media.h header file,
for example MEDIA_IOC_SETUP_LINK.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para>Pointer to a request-specific structure.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <function>ioctl()</function> function manipulates media device
parameters. The argument <parameter>fd</parameter> must be an open file
descriptor.</para>
<para>The ioctl <parameter>request</parameter> code specifies the media
function to be called. It has encoded in it whether the argument is an
input, output or read/write parameter, and the size of the argument
<parameter>argp</parameter> in bytes.</para>
<para>Macros and structures definitions specifying media ioctl requests and
their parameters are located in the media.h header file. All media ioctl
requests, their respective function and parameters are specified in
<xref linkend="media-user-func" />.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>ioctl()</function> returns <returnvalue>0</returnvalue> on
success. On failure, <returnvalue>-1</returnvalue> is returned, and the
<varname>errno</varname> variable is set appropriately. Generic error codes
are listed below, and request-specific error codes are listed in the
individual requests descriptions.</para>
<para>When an ioctl that takes an output or read/write parameter fails,
the parameter remains unmodified.</para>
<variablelist>
<varlistentry>
<term><errorcode>EBADF</errorcode></term>
<listitem>
<para><parameter>fd</parameter> is not a valid open file descriptor.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EFAULT</errorcode></term>
<listitem>
<para><parameter>argp</parameter> references an inaccessible memory
area.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <parameter>request</parameter> or the data pointed to by
<parameter>argp</parameter> is not valid. This is a very common error
code, see the individual ioctl requests listed in
<xref linkend="media-user-func" /> for actual causes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOMEM</errorcode></term>
<listitem>
<para>Insufficient kernel memory was available to complete the
request.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOTTY</errorcode></term>
<listitem>
<para><parameter>fd</parameter> is not associated with a character
special device.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="media-func-open">
<refmeta>
<refentrytitle>media open()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>media-open</refname>
<refpurpose>Open a media device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;fcntl.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>open</function></funcdef>
<paramdef>const char *<parameter>device_name</parameter></paramdef>
<paramdef>int <parameter>flags</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>device_name</parameter></term>
<listitem>
<para>Device to be opened.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>flags</parameter></term>
<listitem>
<para>Open flags. Access mode must be either <constant>O_RDONLY</constant>
or <constant>O_RDWR</constant>. Other flags have no effect.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To open a media device applications call <function>open()</function>
with the desired device name. The function has no side effects; the device
configuration remain unchanged.</para>
<para>When the device is opened in read-only mode, attemps to modify its
configuration will result in an error, and <varname>errno</varname> will be
set to <errorcode>EBADF</errorcode>.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>open</function> returns the new file descriptor on success.
On error, -1 is returned, and <varname>errno</varname> is set appropriately.
Possible error codes are:</para>
<variablelist>
<varlistentry>
<term><errorcode>EACCES</errorcode></term>
<listitem>
<para>The requested access to the file is not allowed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EMFILE</errorcode></term>
<listitem>
<para>The process already has the maximum number of files open.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENFILE</errorcode></term>
<listitem>
<para>The system limit on the total number of open files has been
reached.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOMEM</errorcode></term>
<listitem>
<para>Insufficient kernel memory was available.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENXIO</errorcode></term>
<listitem>
<para>No device corresponding to this device special file exists.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="media-ioc-device-info">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_DEVICE_INFO</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_DEVICE_INFO</refname>
<refpurpose>Query device information</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 media_device_info *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_DEVICE_INFO</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>All media devices must support the <constant>MEDIA_IOC_DEVICE_INFO</constant>
ioctl. To query device information, applications call the ioctl with a
pointer to a &media-device-info;. The driver fills the structure and returns
the information to the application.
The ioctl never fails.</para>
<table pgwide="1" frame="none" id="media-device-info">
<title>struct <structname>media_device_info</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>char</entry>
<entry><structfield>driver</structfield>[16]</entry>
<entry><para>Name of the driver implementing the media API as a
NUL-terminated ASCII string. The driver version is stored in the
<structfield>driver_version</structfield> field.</para>
<para>Driver specific applications can use this information to
verify the driver identity. It is also useful to work around
known bugs, or to identify drivers in error reports.</para></entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>model</structfield>[32]</entry>
<entry>Device model name as a NUL-terminated UTF-8 string. The
device version is stored in the <structfield>device_version</structfield>
field and is not be appended to the model name.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>serial</structfield>[40]</entry>
<entry>Serial number as a NUL-terminated ASCII string.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>bus_info</structfield>[32]</entry>
<entry>Location of the device in the system as a NUL-terminated
ASCII string. This includes the bus type name (PCI, USB, ...) and a
bus-specific identifier.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>media_version</structfield></entry>
<entry>Media API version, formatted with the
<constant>KERNEL_VERSION()</constant> macro.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>hw_revision</structfield></entry>
<entry>Hardware device revision in a driver-specific format.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>media_version</structfield></entry>
<entry>Media device driver version, formatted with the
<constant>KERNEL_VERSION()</constant> macro. Together with the
<structfield>driver</structfield> field this identifies a particular
driver.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[31]</entry>
<entry>Reserved for future extensions. Drivers and applications must
set this array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>The <structfield>serial</structfield> and <structfield>bus_info</structfield>
fields can be used to distinguish between multiple instances of otherwise
identical hardware. The serial number takes precedence when provided and can
be assumed to be unique. If the serial number is an empty string, the
<structfield>bus_info</structfield> field can be used instead. The
<structfield>bus_info</structfield> field is guaranteed to be unique, but
can vary across reboots or device unplug/replug.</para>
</refsect1>
<refsect1>
<title>Return value</title>
<para>This function doesn't return specific error codes.</para>
</refsect1>
</refentry>
<refentry id="media-ioc-enum-entities">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_ENUM_ENTITIES</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_ENUM_ENTITIES</refname>
<refpurpose>Enumerate entities and their properties</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 media_entity_desc *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_ENTITIES</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To query the attributes of an entity, applications set the id field
of a &media-entity-desc; structure and call the MEDIA_IOC_ENUM_ENTITIES
ioctl with a pointer to this structure. The driver fills the rest of the
structure or returns an &EINVAL; when the id is invalid.</para>
<para>Entities can be enumerated by or'ing the id with the
<constant>MEDIA_ENT_ID_FLAG_NEXT</constant> flag. The driver will return
information about the entity with the smallest id strictly larger than the
requested one ('next entity'), or the &EINVAL; if there is none.</para>
<para>Entity IDs can be non-contiguous. Applications must
<emphasis>not</emphasis> try to enumerate entities by calling
MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error.</para>
<para>Two or more entities that share a common non-zero
<structfield>group_id</structfield> value are considered as logically
grouped. Groups are used to report
<itemizedlist>
<listitem><para>ALSA, VBI and video nodes that carry the same media
stream</para></listitem>
<listitem><para>lens and flash controllers associated with a sensor</para></listitem>
</itemizedlist>
</para>
<table pgwide="1" frame="none" id="media-entity-desc">
<title>struct <structname>media_entity_desc</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity id, set by the application. When the id is or'ed with
<constant>MEDIA_ENT_ID_FLAG_NEXT</constant>, the driver clears the
flag and returns the first entity with a larger id.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>name</structfield>[32]</entry>
<entry></entry>
<entry></entry>
<entry>Entity name as an UTF-8 NULL-terminated string.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity type, see <xref linkend="media-entity-type" /> for details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>revision</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity revision in a driver/hardware specific format.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity flags, see <xref linkend="media-entity-flag" /> for details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>group_id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity group ID</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>pads</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Number of pads</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>links</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Total number of outbound links. Inbound links are not counted
in this field.</entry>
</row>
<row>
<entry>union</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>v4l</structfield></entry>
<entry></entry>
<entry>Valid for V4L sub-devices and nodes only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>major</structfield></entry>
<entry>V4L device node major number. For V4L sub-devices with no
device node, set by the driver to 0.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>minor</structfield></entry>
<entry>V4L device node minor number. For V4L sub-devices with no
device node, set by the driver to 0.</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>fb</structfield></entry>
<entry></entry>
<entry>Valid for frame buffer nodes only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>major</structfield></entry>
<entry>Frame buffer device node major number.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>minor</structfield></entry>
<entry>Frame buffer device node minor number.</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>alsa</structfield></entry>
<entry></entry>
<entry>Valid for ALSA devices only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>card</structfield></entry>
<entry>ALSA card number</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>device</structfield></entry>
<entry>ALSA device number</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>subdevice</structfield></entry>
<entry>ALSA sub-device number</entry>
</row>
<row>
<entry></entry>
<entry>int</entry>
<entry><structfield>dvb</structfield></entry>
<entry></entry>
<entry>DVB card number</entry>
</row>
<row>
<entry></entry>
<entry>__u8</entry>
<entry><structfield>raw</structfield>[180]</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-entity-type">
<title>Media entity types</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE</constant></entry>
<entry>Unknown device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry>
<entry>V4L video, radio or vbi device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_FB</constant></entry>
<entry>Frame buffer device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_ALSA</constant></entry>
<entry>ALSA card</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry>
<entry>DVB card</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
<entry>Unknown V4L sub-device</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
<entry>Video sensor</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
<entry>Flash controller</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
<entry>Lens controller</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-entity-flag">
<title>Media entity flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry>
<entry>Default entity for its type. Used to discover the default
audio, VBI and video devices, the default camera sensor, ...</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &media-entity-desc; <structfield>id</structfield> references
a non-existing entity.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="media-ioc-enum-links">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_ENUM_LINKS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_ENUM_LINKS</refname>
<refpurpose>Enumerate all pads and links for a given entity</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 media_links_enum *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_LINKS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To enumerate pads and/or links for a given entity, applications set
the entity field of a &media-links-enum; structure and initialize the
&media-pad-desc; and &media-link-desc; structure arrays pointed by the
<structfield>pads</structfield> and <structfield>links</structfield> fields.
They then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this
structure.</para>
<para>If the <structfield>pads</structfield> field is not NULL, the driver
fills the <structfield>pads</structfield> array with information about the
entity's pads. The array must have enough room to store all the entity's
pads. The number of pads can be retrieved with the &MEDIA-IOC-ENUM-ENTITIES;
ioctl.</para>
<para>If the <structfield>links</structfield> field is not NULL, the driver
fills the <structfield>links</structfield> array with information about the
entity's outbound links. The array must have enough room to store all the
entity's outbound links. The number of outbound links can be retrieved with
the &MEDIA-IOC-ENUM-ENTITIES; ioctl.</para>
<para>Only forward links that originate at one of the entity's source pads
are returned during the enumeration process.</para>
<table pgwide="1" frame="none" id="media-links-enum">
<title>struct <structname>media_links_enum</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>entity</structfield></entry>
<entry>Entity id, set by the application.</entry>
</row>
<row>
<entry>struct &media-pad-desc;</entry>
<entry>*<structfield>pads</structfield></entry>
<entry>Pointer to a pads array allocated by the application. Ignored
if NULL.</entry>
</row>
<row>
<entry>struct &media-link-desc;</entry>
<entry>*<structfield>links</structfield></entry>
<entry>Pointer to a links array allocated by the application. Ignored
if NULL.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-pad-desc">
<title>struct <structname>media_pad_desc</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>entity</structfield></entry>
<entry>ID of the entity this pad belongs to.</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>index</structfield></entry>
<entry>0-based pad index.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Pad flags, see <xref linkend="media-pad-flag" /> for more details.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-pad-flag">
<title>Media pad flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_PAD_FL_SINK</constant></entry>
<entry>Input pad, relative to the entity. Input pads sink data and
are targets of links.</entry>
</row>
<row>
<entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry>
<entry>Output pad, relative to the entity. Output pads source data
and are origins of links.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-link-desc">
<title>struct <structname>media_links_desc</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>struct &media-pad-desc;</entry>
<entry><structfield>source</structfield></entry>
<entry>Pad at the origin of this link.</entry>
</row>
<row>
<entry>struct &media-pad-desc;</entry>
<entry><structfield>sink</structfield></entry>
<entry>Pad at the target of this link.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Link flags, see <xref linkend="media-link-flag" /> for more details.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-link-flag">
<title>Media link flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry>
<entry>The link is enabled and can be used to transfer media data.
When two or more links target a sink pad, only one of them can be
enabled at a time.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry>
<entry>The link enabled state can't be modified at runtime. An
immutable link is always enabled.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry>
<entry>The link enabled state can be modified during streaming. This
flag is set by drivers and is read-only for applications.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and
<constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &media-links-enum; <structfield>id</structfield> references
a non-existing entity.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="media-ioc-setup-link">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_SETUP_LINK</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_SETUP_LINK</refname>
<refpurpose>Modify the properties of a link</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 media_link_desc *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_LINKS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To change link properties applications fill a &media-link-desc; with
link identification information (source and sink pad) and the new requested
link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to
that structure.</para>
<para>The only configurable property is the <constant>ENABLED</constant>
link flag to enable/disable a link. Links marked with the
<constant>IMMUTABLE</constant> link flag can not be enabled or disabled.
</para>
<para>Link configuration has no side effect on other links. If an enabled
link at the sink pad prevents the link from being enabled, the driver
returns with an &EBUSY;.</para>
<para>Only links marked with the <constant>DYNAMIC</constant> link flag can
be enabled/disabled while streaming media data. Attempting to enable or
disable a streaming non-dynamic link will return an &EBUSY;.</para>
<para>If the specified link can't be found the driver returns with an
&EINVAL;.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The link properties can't be changed because the link is
currently busy. This can be caused, for instance, by an active media
stream (audio or video) on the link. The ioctl shouldn't be retried if
no other action is performed before to fix the problem.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &media-link-desc; references a non-existing link, or the
link is immutable and an attempt to modify its configuration was made.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="V4L2-PIX-FMT-NV12M">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV12M ('NV12M')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar, two-plane version of the YUV 4:2:0 format.
The three components are separated into two sub-images or planes.
<constant>V4L2_PIX_FMT_NV12M</constant> differs from <constant>V4L2_PIX_FMT_NV12
</constant> in that the two planes are non-contiguous in memory, i.e. the chroma
plane do not necessarily immediately follows the luma plane.
The luminance data occupies the first plane. The Y plane has one byte per pixel.
In the second plane there is a chrominance data with alternating chroma samples.
The CbCr plane is the same width, in bytes, as the Y plane (and of the image),
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example,
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para>
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<para>If the Y plane has pad bytes after each row, then the
CbCr plane has as many pad bytes after its rows.</para>
<example>
<title><constant>V4L2_PIX_FMT_NV12M</constant> 4 &times; 4 pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV12MT ('TM12')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-NV12MT"><constant>V4L2_PIX_FMT_NV12MT
</constant></refname>
<refpurpose>Formats with &frac12; horizontal and vertical
chroma resolution. This format has two planes - one for luminance and one for
chrominance. Chroma samples are interleaved. The difference to
<constant>V4L2_PIX_FMT_NV12</constant> is the memory layout. Pixels are
grouped in macroblocks of 64x32 size. The order of macroblocks in memory is
also not standard.
</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is the two-plane versions of the YUV 4:2:0 format where data
is grouped into 64x32 macroblocks. The three components are separated into two
sub-images or planes. The Y plane has one byte per pixel and pixels are grouped
into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y
plane (and the image), but is half as tall in pixels. The chroma plane is also
grouped into 64x32 macroblocks.</para>
<para>Width of the buffer has to be aligned to the multiple of 128, and
height alignment is 32. Every four adjactent buffers - two horizontally and two
vertically are grouped together and are located in memory in Z or flipped Z
order. </para>
<para>Layout of macroblocks in memory is presented in the following
figure.</para>
<para><figure id="nv12mt">
<title><constant>V4L2_PIX_FMT_NV12MT</constant> macroblock Z shape
memory layout</title>
<mediaobject>
<imageobject>
<imagedata fileref="nv12mt.gif" format="GIF" />
</imageobject>
</mediaobject>
</figure>
The requirement that width is multiple of 128 is implemented because,
the Z shape cannot be cut in half horizontally. In case the vertical resolution
of macroblocks is odd then the last row of macroblocks is arranged in a linear
order. </para>
<para>In case of chroma the layout is identical. Cb and Cr samples are
interleaved. Height of the buffer is aligned to 32.
</para>
<example>
<title>Memory layout of macroblocks in <constant>V4L2_PIX_FMT_NV12
</constant> format pixel image - extreme case</title>
<para>
<figure id="nv12mt_ex">
<title>Example <constant>V4L2_PIX_FMT_NV12MT</constant> memory
layout of macroblocks</title>
<mediaobject>
<imageobject>
<imagedata fileref="nv12mt_example.gif" format="GIF" />
</imageobject>
</mediaobject>
</figure>
Memory layout of macroblocks of <constant>V4L2_PIX_FMT_NV12MT
</constant> format in most extreme case.
</para>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_SRGGB12 ('RG12'),
V4L2_PIX_FMT_SGRBG12 ('BA12'),
V4L2_PIX_FMT_SGBRG12 ('GB12'),
V4L2_PIX_FMT_SBGGR12 ('BG12'),
</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-SRGGB12"><constant>V4L2_PIX_FMT_SRGGB12</constant></refname>
<refname id="V4L2-PIX-FMT-SGRBG12"><constant>V4L2_PIX_FMT_SGRBG12</constant></refname>
<refname id="V4L2-PIX-FMT-SGBRG12"><constant>V4L2_PIX_FMT_SGBRG12</constant></refname>
<refname id="V4L2-PIX-FMT-SBGGR12"><constant>V4L2_PIX_FMT_SBGGR12</constant></refname>
<refpurpose>12-bit Bayer formats expanded to 16 bits</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer formats with
12 bits per colour. Each colour component is stored in a 16-bit word, with 6
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
stored in memory in little endian order. They are conventionally described
as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
formats</para>
<example>
<title><constant>V4L2_PIX_FMT_SBGGR12</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte, high 6 bits in high bytes are 0.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>B<subscript>00low</subscript></entry>
<entry>B<subscript>00high</subscript></entry>
<entry>G<subscript>01low</subscript></entry>
<entry>G<subscript>01high</subscript></entry>
<entry>B<subscript>02low</subscript></entry>
<entry>B<subscript>02high</subscript></entry>
<entry>G<subscript>03low</subscript></entry>
<entry>G<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>G<subscript>10low</subscript></entry>
<entry>G<subscript>10high</subscript></entry>
<entry>R<subscript>11low</subscript></entry>
<entry>R<subscript>11high</subscript></entry>
<entry>G<subscript>12low</subscript></entry>
<entry>G<subscript>12high</subscript></entry>
<entry>R<subscript>13low</subscript></entry>
<entry>R<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>B<subscript>20low</subscript></entry>
<entry>B<subscript>20high</subscript></entry>
<entry>G<subscript>21low</subscript></entry>
<entry>G<subscript>21high</subscript></entry>
<entry>B<subscript>22low</subscript></entry>
<entry>B<subscript>22high</subscript></entry>
<entry>G<subscript>23low</subscript></entry>
<entry>G<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>G<subscript>30low</subscript></entry>
<entry>G<subscript>30high</subscript></entry>
<entry>R<subscript>31low</subscript></entry>
<entry>R<subscript>31high</subscript></entry>
<entry>G<subscript>32low</subscript></entry>
<entry>G<subscript>32high</subscript></entry>
<entry>R<subscript>33low</subscript></entry>
<entry>R<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<refentry id="V4L2-PIX-FMT-YUV420M">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YU12M')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
with planes non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub- images or planes.
The Y plane is first. The Y plane has one byte per pixel. The Cb data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cb belongs to four
pixels, a two-by-two square of the image. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->
......@@ -2,12 +2,16 @@
<para>The V4L2 API was primarily designed for devices exchanging
image data with applications. The
<structname>v4l2_pix_format</structname> structure defines the format
and layout of an image in memory. Image formats are negotiated with
the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video
<structname>v4l2_pix_format</structname> and <structname>v4l2_pix_format_mplane
</structname> structures define the format and layout of an image in memory.
The former is used with the single-planar API, while the latter is used with the
multi-planar version (see <xref linkend="planar-apis"/>). Image formats are
negotiated with the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video
capturing and output, for overlay frame buffer formats see also
&VIDIOC-G-FBUF;.)</para>
<section>
<title>Single-planar format structure</title>
<table pgwide="1" frame="none" id="v4l2-pix-format">
<title>struct <structname>v4l2_pix_format</structname></title>
<tgroup cols="3">
......@@ -106,6 +110,98 @@ set this field to zero.</entry>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>Multi-planar format structures</title>
<para>The <structname>v4l2_plane_pix_format</structname> structures define
size and layout for each of the planes in a multi-planar format.
The <structname>v4l2_pix_format_mplane</structname> structure contains
information common to all planes (such as image width and height) and
an array of <structname>v4l2_plane_pix_format</structname> structures,
describing all planes of that format.</para>
<table pgwide="1" frame="none" id="v4l2-plane-pix-format">
<title>struct <structname>vl42_plane_pix_format</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>sizeimage</structfield></entry>
<entry>Maximum size in bytes required for image data in this plane.
</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>bytesperline</structfield></entry>
<entry>Distance in bytes between the leftmost pixels in two adjacent
lines.</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>reserved[7]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the
application.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-pix-format-mplane">
<title>struct <structname>v4l2_pix_format_mplane</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Image width in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Image height in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>pixelformat</structfield></entry>
<entry>The pixel format. Both single- and multi-planar four character
codes can be used.</entry>
</row>
<row>
<entry>&v4l2-field;</entry>
<entry><structfield>field</structfield></entry>
<entry>See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>&v4l2-colorspace;</entry>
<entry><structfield>colorspace</structfield></entry>
<entry>See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>&v4l2-plane-pix-format;</entry>
<entry><structfield>plane_fmt[VIDEO_MAX_PLANES]</structfield></entry>
<entry>An array of structures describing format of each plane this
pixel format consists of. The number of valid entries in this array
has to be put in the <structfield>num_planes</structfield>
field.</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>num_planes</structfield></entry>
<entry>Number of planes (i.e. separate memory buffers) for this format
and the number of valid entries in the
<structfield>plane_fmt</structfield> array.</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>reserved[11]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the
application.</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>Standard Image Formats</title>
......@@ -142,11 +238,19 @@ leftmost pixel of the second row from the top, and so on. The last row
has just as many pad bytes after it as the other rows.</para>
<para>In V4L2 each format has an identifier which looks like
<constant>PIX_FMT_XXX</constant>, defined in the <filename>videodev2.h</filename>
header file. These identifiers
represent <link linkend="v4l2-fourcc">four character codes</link>
<constant>PIX_FMT_XXX</constant>, defined in the <link
linkend="videodev">videodev.h</link> header file. These identifiers
represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link>
which are also listed below, however they are not the same as those
used in the Windows world.</para>
<para>For some formats, data is stored in separate, discontiguous
memory buffers. Those formats are identified by a separate set of FourCC codes
and are referred to as "multi-planar formats". For example, a YUV422 frame is
normally stored in one memory buffer, but it can also be placed in two or three
separate buffers, with Y component in one buffer and CbCr components in another
in the 2-planar version or with each component in its own buffer in the
3-planar case. Those sub-buffers are referred to as "planes".</para>
</section>
<section id="colorspaces">
......@@ -599,10 +703,13 @@ information.</para>
&sub-vyuy;
&sub-y41p;
&sub-yuv420;
&sub-yuv420m;
&sub-yuv410;
&sub-yuv422p;
&sub-yuv411p;
&sub-nv12;
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
</section>
......
<section id="planar-apis">
<title>Single- and multi-planar APIs</title>
<para>Some devices require data for each input or output video frame
to be placed in discontiguous memory buffers. In such cases, one
video frame has to be addressed using more than one memory address, i.e. one
pointer per "plane". A plane is a sub-buffer of the current frame. For
examples of such formats see <xref linkend="pixfmt" />.</para>
<para>Initially, V4L2 API did not support multi-planar buffers and a set of
extensions has been introduced to handle them. Those extensions constitute
what is being referred to as the "multi-planar API".</para>
<para>Some of the V4L2 API calls and structures are interpreted differently,
depending on whether single- or multi-planar API is being used. An application
can choose whether to use one or the other by passing a corresponding buffer
type to its ioctl calls. Multi-planar versions of buffer types are suffixed
with an `_MPLANE' string. For a list of available multi-planar buffer types
see &v4l2-buf-type;.
</para>
<section>
<title>Multi-planar formats</title>
<para>Multi-planar API introduces new multi-planar formats. Those formats
use a separate set of FourCC codes. It is important to distinguish between
the multi-planar API and a multi-planar format. Multi-planar API calls can
handle all single-planar formats as well (as long as they are passed in
multi-planar API structures), while the single-planar API cannot
handle multi-planar formats.</para>
</section>
<section>
<title>Calls that distinguish between single and multi-planar APIs</title>
<variablelist>
<varlistentry>
<term>&VIDIOC-QUERYCAP;</term>
<listitem><para>Two additional multi-planar capabilities are added. They can
be set together with non-multi-planar ones for devices that handle
both single- and multi-planar formats.</para></listitem>
</varlistentry>
<varlistentry>
<term>&VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT;</term>
<listitem><para>New structures for describing multi-planar formats are added:
&v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may
define new multi-planar formats, which have distinct FourCC codes from
the existing single-planar ones.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF;</term>
<listitem><para>A new &v4l2-plane; structure for describing planes is added.
Arrays of this structure are passed in the new
<structfield>m.planes</structfield> field of &v4l2-buffer;.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&VIDIOC-REQBUFS;</term>
<listitem><para>Will allocate multi-planar buffers as requested.</para></listitem>
</varlistentry>
</variablelist>
</section>
</section>
This diff is collapsed.
......@@ -85,6 +85,17 @@ Remote Controller chapter.</contrib>
</address>
</affiliation>
</author>
<author>
<firstname>Pawel</firstname>
<surname>Osciak</surname>
<contrib>Designed and documented the multi-planar API.</contrib>
<affiliation>
<address>
<email>pawel AT osciak.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
......@@ -102,7 +113,8 @@ Remote Controller chapter.</contrib>
<year>2010</year>
<year>2011</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
Pawel Osciak</holder>
</copyright>
<legalnotice>
<para>Except when explicitly stated as GPL, programming examples within
......@@ -115,6 +127,13 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>2.6.39</revnumber>
<date>2011-03-01</date>
<authorinitials>mcc, po</authorinitials>
<revremark>Removed VIDIOC_*_OLD from videodev2.h header and update it to reflect latest changes. Added the <link linkend="planar-apis">multi-planar API</link>.</revremark>
</revision>
<revision>
<revnumber>2.6.37</revnumber>
<date>2010-08-06</date>
......@@ -382,7 +401,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 2.6.38</subtitle>
<subtitle>Revision 2.6.39</subtitle>
<chapter id="common">
&sub-common;
......@@ -411,6 +430,7 @@ and discussions on the V4L mailing list.</revremark>
<section id="radio"> &sub-dev-radio; </section>
<section id="rds"> &sub-dev-rds; </section>
<section id="event"> &sub-dev-event; </section>
<section id="subdev"> &sub-dev-subdev; </section>
</chapter>
<chapter id="driver">
......@@ -478,6 +498,12 @@ and discussions on the V4L mailing list.</revremark>
&sub-reqbufs;
&sub-s-hw-freq-seek;
&sub-streamon;
&sub-subdev-enum-frame-interval;
&sub-subdev-enum-frame-size;
&sub-subdev-enum-mbus-code;
&sub-subdev-g-crop;
&sub-subdev-g-fmt;
&sub-subdev-g-frame-interval;
&sub-subscribe-event;
<!-- End of ioctls. -->
&sub-mmap;
......
This diff is collapsed.
......@@ -76,7 +76,9 @@ pixelformat</structfield> field.</entry>
<entry>Type of the data stream, set by the application.
Only these types are valid here:
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
and higher.</entry>
......
......@@ -60,11 +60,13 @@ application.</para>
<structfield>type</structfield> field of a struct
<structname>v4l2_format</structname> to the respective buffer (stream)
type. For example video capture devices use
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>. When the application
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. When the application
calls the <constant>VIDIOC_G_FMT</constant> ioctl with a pointer to
this structure the driver fills the respective member of the
<structfield>fmt</structfield> union. In case of video capture devices
that is the &v4l2-pix-format; <structfield>pix</structfield> member.
that is either the &v4l2-pix-format; <structfield>pix</structfield> or
the &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member.
When the requested buffer type is not supported drivers return an
&EINVAL;.</para>
......@@ -131,6 +133,15 @@ this ioctl.</para>
<entry>Definition of an image format, see <xref
linkend="pixfmt" />, used by video capture and output
devices.</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-pix-format-mplane;</entry>
<entry><structfield>pix_mp</structfield></entry>
<entry>Definition of an image format, see <xref
linkend="pixfmt" />, used by video capture and output
devices that support the <link linkend="planar-apis">multi-planar
version of the API</link>.</entry>
</row>
<row>
<entry></entry>
......
......@@ -64,7 +64,8 @@ zero to the number of buffers allocated with &VIDIOC-REQBUFS;
contents of the struct <structname>v4l2_buffer</structname> returned
by a &VIDIOC-QUERYBUF; ioctl will do as well. When the buffer is
intended for output (<structfield>type</structfield> is
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>, or
<constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>) applications must also
initialize the <structfield>bytesused</structfield>,
<structfield>field</structfield> and
......@@ -75,7 +76,11 @@ supports capturing from specific video inputs and you want to specify a video
input, then <structfield>flags</structfield> should be set to
<constant>V4L2_BUF_FLAG_INPUT</constant> and the field
<structfield>input</structfield> must be initialized to the desired input.
The <structfield>reserved</structfield> field must be set to 0.
The <structfield>reserved</structfield> field must be set to 0. When using
the <link linkend="planar-apis">multi-planar API</link>, the
<structfield>m.planes</structfield> field must contain a userspace pointer
to a filled-in array of &v4l2-plane; and the <structfield>length</structfield>
field must be set to the number of elements in that array.
</para>
<para>To enqueue a <link linkend="mmap">memory mapped</link>
......@@ -93,10 +98,13 @@ structure the driver sets the
buffer applications set the <structfield>memory</structfield>
field to <constant>V4L2_MEMORY_USERPTR</constant>, the
<structfield>m.userptr</structfield> field to the address of the
buffer and <structfield>length</structfield> to its size.
When <constant>VIDIOC_QBUF</constant> is called with a pointer to this
structure the driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant>
flag and clears the <constant>V4L2_BUF_FLAG_MAPPED</constant> and
buffer and <structfield>length</structfield> to its size. When the multi-planar
API is used, <structfield>m.userptr</structfield> and
<structfield>length</structfield> members of the passed array of &v4l2-plane;
have to be used instead. When <constant>VIDIOC_QBUF</constant> is called with
a pointer to this structure the driver sets the
<constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the
<constant>V4L2_BUF_FLAG_MAPPED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flags in the
<structfield>flags</structfield> field, or it returns an error code.
This ioctl locks the memory pages of the buffer in physical memory,
......@@ -115,7 +123,9 @@ remaining fields or returns an error code. The driver may also set
<constant>V4L2_BUF_FLAG_ERROR</constant> in the <structfield>flags</structfield>
field. It indicates a non-critical (recoverable) streaming error. In such case
the application may continue as normal, but should be aware that data in the
dequeued buffer might be corrupted.</para>
dequeued buffer might be corrupted. When using the multi-planar API, the
planes array does not have to be passed; the <structfield>m.planes</structfield>
member must be set to NULL in that case.</para>
<para>By default <constant>VIDIOC_DQBUF</constant> blocks when no
buffer is in the outgoing queue. When the
......
......@@ -61,6 +61,10 @@ buffer at any time after buffers have been allocated with the
to the number of buffers allocated with &VIDIOC-REQBUFS;
(&v4l2-requestbuffers; <structfield>count</structfield>) minus one.
The <structfield>reserved</structfield> field should to set to 0.
When using the <link linkend="planar-apis">multi-planar API</link>, the
<structfield>m.planes</structfield> field must contain a userspace pointer to an
array of &v4l2-plane; and the <structfield>length</structfield> field has
to be set to the number of elements in that array.
After calling <constant>VIDIOC_QUERYBUF</constant> with a pointer to
this structure drivers return an error code or fill the rest of
the structure.</para>
......@@ -70,11 +74,13 @@ the structure.</para>
<constant>V4L2_BUF_FLAG_QUEUED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The
<structfield>memory</structfield> field will be set to the current
I/O method, the <structfield>m.offset</structfield>
I/O method. For the single-planar API, the <structfield>m.offset</structfield>
contains the offset of the buffer from the start of the device memory,
the <structfield>length</structfield> field its size. The driver may
or may not set the remaining fields and flags, they are meaningless in
this context.</para>
the <structfield>length</structfield> field its size. For the multi-planar API,
fields <structfield>m.mem_offset</structfield> and
<structfield>length</structfield> in the <structfield>m.planes</structfield>
array elements will be used instead. The driver may or may not set the remaining
fields and flags, they are meaningless in this context.</para>
<para>The <structname>v4l2_buffer</structname> structure is
specified in <xref linkend="buffer" />.</para>
......
......@@ -142,15 +142,29 @@ this array to zero.</entry>
<row>
<entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry>
<entry>0x00000001</entry>
<entry>The device supports the <link
<entry>The device supports the single-planar API through the <link
linkend="capture">Video Capture</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant></entry>
<entry>0x00001000</entry>
<entry>The device supports the
<link linkend="planar-apis">multi-planar API</link> through the
<link linkend="capture">Video Capture</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OUTPUT</constant></entry>
<entry>0x00000002</entry>
<entry>The device supports the <link
<entry>The device supports the single-planar API through the <link
linkend="output">Video Output</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant></entry>
<entry>0x00002000</entry>
<entry>The device supports the
<link linkend="planar-apis">multi-planar API</link> through the
<link linkend="output">Video Output</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>
<entry>0x00000004</entry>
......
......@@ -93,6 +93,15 @@ synchronize with other events.</para>
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>
......
<refentry id="vidioc-subdev-enum-frame-interval">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refname>
<refpurpose>Enumerate frame intervals</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_subdev_frame_interval_enum *
<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_SUBDEV_ENUM_FRAME_INTERVAL</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>This ioctl lets applications enumerate available frame intervals on a
given sub-device pad. Frame intervals only makes sense for sub-devices that
can control the frame period on their own. This includes, for instance,
image sensors and TV tuners.</para>
<para>For the common use case of image sensors, the frame intervals
available on the sub-device output pad depend on the frame format and size
on the same pad. Applications must thus specify the desired format and size
when enumerating frame intervals.</para>
<para>To enumerate frame intervals applications initialize the
<structfield>index</structfield>, <structfield>pad</structfield>,
<structfield>code</structfield>, <structfield>width</structfield> and
<structfield>height</structfield> fields of
&v4l2-subdev-frame-interval-enum; and call the
<constant>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</constant> ioctl with a pointer
to this structure. Drivers fill the rest of the structure or return
an &EINVAL; if one of the input fields is invalid. All frame intervals are
enumerable by beginning at index zero and incrementing by one until
<errorcode>EINVAL</errorcode> is returned.</para>
<para>Available frame intervals may depend on the current 'try' formats
at other pads of the sub-device, as well as on the current active links. See
&VIDIOC-SUBDEV-G-FMT; for more information about the try formats.</para>
<para>Sub-devices that support the frame interval enumeration ioctl should
implemented it on a single pad only. Its behaviour when supported on
multiple pads of the same sub-device is not defined.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-frame-interval-enum">
<title>struct <structname>v4l2_subdev_frame_interval_enum</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the format in the enumeration, set by the
application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media controller API.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>code</structfield></entry>
<entry>The media bus format code, as defined in
<xref linkend="v4l2-mbus-format" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Frame width, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Frame height, in pixels.</entry>
</row>
<row>
<entry>&v4l2-fract;</entry>
<entry><structfield>interval</structfield></entry>
<entry>Period, in seconds, between consecutive video frames.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-frame-interval-enum;
<structfield>pad</structfield> references a non-existing pad, one of
the <structfield>code</structfield>, <structfield>width</structfield>
or <structfield>height</structfield> fields are invalid for the given
pad or the <structfield>index</structfield> field is out of bounds.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="vidioc-subdev-enum-frame-size">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refname>
<refpurpose>Enumerate media bus frame sizes</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_subdev_frame_size_enum *
<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_SUBDEV_ENUM_FRAME_SIZE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>This ioctl allows applications to enumerate all frame sizes
supported by a sub-device on the given pad for the given media bus format.
Supported formats can be retrieved with the &VIDIOC-SUBDEV-ENUM-MBUS-CODE;
ioctl.</para>
<para>To enumerate frame sizes applications initialize the
<structfield>pad</structfield>, <structfield>code</structfield> and
<structfield>index</structfield> fields of the
&v4l2-subdev-mbus-code-enum; and call the
<constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant> ioctl with a pointer to
the structure. Drivers fill the minimum and maximum frame sizes or return
an &EINVAL; if one of the input parameters is invalid.</para>
<para>Sub-devices that only support discrete frame sizes (such as most
sensors) will return one or more frame sizes with identical minimum and
maximum values.</para>
<para>Not all possible sizes in given [minimum, maximum] ranges need to be
supported. For instance, a scaler that uses a fixed-point scaling ratio
might not be able to produce every frame size between the minimum and
maximum values. Applications must use the &VIDIOC-SUBDEV-S-FMT; ioctl to
try the sub-device for an exact supported frame size.</para>
<para>Available frame sizes may depend on the current 'try' formats at other
pads of the sub-device, as well as on the current active links and the
current values of V4L2 controls. See &VIDIOC-SUBDEV-G-FMT; for more
information about try formats.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-frame-size-enum">
<title>struct <structname>v4l2_subdev_frame_size_enum</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the format in the enumeration, set by the
application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media controller API.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>code</structfield></entry>
<entry>The media bus format code, as defined in
<xref linkend="v4l2-mbus-format" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>min_width</structfield></entry>
<entry>Minimum frame width, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>max_width</structfield></entry>
<entry>Maximum frame width, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>min_height</structfield></entry>
<entry>Minimum frame height, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>max_height</structfield></entry>
<entry>Maximum frame height, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-frame-size-enum; <structfield>pad</structfield>
references a non-existing pad, the <structfield>code</structfield> is
invalid for the given pad or the <structfield>index</structfield>
field is out of bounds.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="vidioc-subdev-enum-mbus-code">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_MBUS_CODE</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_ENUM_MBUS_CODE</refname>
<refpurpose>Enumerate media bus formats</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_subdev_mbus_code_enum *
<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_SUBDEV_ENUM_MBUS_CODE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>To enumerate media bus formats available at a given sub-device pad
applications initialize the <structfield>pad</structfield> and
<structfield>index</structfield> fields of &v4l2-subdev-mbus-code-enum; and
call the <constant>VIDIOC_SUBDEV_ENUM_MBUS_CODE</constant> ioctl with a
pointer to this structure. Drivers fill the rest of the structure or return
an &EINVAL; if either the <structfield>pad</structfield> or
<structfield>index</structfield> are invalid. All media bus formats are
enumerable by beginning at index zero and incrementing by one until
<errorcode>EINVAL</errorcode> is returned.</para>
<para>Available media bus formats may depend on the current 'try' formats
at other pads of the sub-device, as well as on the current active links. See
&VIDIOC-SUBDEV-G-FMT; for more information about the try formats.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-mbus-code-enum">
<title>struct <structname>v4l2_subdev_mbus_code_enum</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media controller API.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the format in the enumeration, set by the
application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>code</structfield></entry>
<entry>The media bus format code, as defined in
<xref linkend="v4l2-mbus-format" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-mbus-code-enum; <structfield>pad</structfield>
references a non-existing pad, or the <structfield>index</structfield>
field is out of bounds.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="vidioc-subdev-g-crop">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_G_CROP</refname>
<refname>VIDIOC_SUBDEV_S_CROP</refname>
<refpurpose>Get or set the crop rectangle on a subdev pad</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_subdev_crop *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>const struct v4l2_subdev_crop *<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_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>To retrieve the current crop rectangle applications set the
<structfield>pad</structfield> field of a &v4l2-subdev-crop; to the
desired pad number as reported by the media API and the
<structfield>which</structfield> field to
<constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. They then call the
<constant>VIDIOC_SUBDEV_G_CROP</constant> ioctl with a pointer to this
structure. The driver fills the members of the <structfield>rect</structfield>
field or returns &EINVAL; if the input arguments are invalid, or if cropping
is not supported on the given pad.</para>
<para>To change the current crop rectangle applications set both the
<structfield>pad</structfield> and <structfield>which</structfield> fields
and all members of the <structfield>rect</structfield> field. They then call
the <constant>VIDIOC_SUBDEV_S_CROP</constant> ioctl with a pointer to this
structure. The driver verifies the requested crop rectangle, adjusts it
based on the hardware capabilities and configures the device. Upon return
the &v4l2-subdev-crop; contains the current format as would be returned
by a <constant>VIDIOC_SUBDEV_G_CROP</constant> call.</para>
<para>Applications can query the device capabilities by setting the
<structfield>which</structfield> to
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. When set, 'try' crop
rectangles are not applied to the device by the driver, but are mangled
exactly as active crop rectangles and stored in the sub-device file handle.
Two applications querying the same sub-device would thus not interact with
each other.</para>
<para>Drivers must not return an error solely because the requested crop
rectangle doesn't match the device capabilities. They must instead modify
the rectangle to match what the hardware can provide. The modified format
should be as close as possible to the original request.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-crop">
<title>struct <structname>v4l2_subdev_crop</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media framework.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>which</structfield></entry>
<entry>Crop rectangle to get or set, from
&v4l2-subdev-format-whence;.</entry>
</row>
<row>
<entry>&v4l2-rect;</entry>
<entry><structfield>rect</structfield></entry>
<entry>Crop rectangle boundaries, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[8]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The crop rectangle can't be changed because the pad is currently
busy. This can be caused, for instance, by an active video stream on
the pad. The ioctl must not be retried without performing another
action to fix the problem first. Only returned by
<constant>VIDIOC_SUBDEV_S_CROP</constant></para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-crop; <structfield>pad</structfield>
references a non-existing pad, the <structfield>which</structfield>
field references a non-existing format, or cropping is not supported
on the given subdev pad.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="vidioc-subdev-g-fmt">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_G_FMT</refname>
<refname>VIDIOC_SUBDEV_S_FMT</refname>
<refpurpose>Get or set the data format on a subdev pad</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_subdev_format *<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_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>These ioctls are used to negotiate the frame format at specific
subdev pads in the image pipeline.</para>
<para>To retrieve the current format applications set the
<structfield>pad</structfield> field of a &v4l2-subdev-format; to the
desired pad number as reported by the media API and the
<structfield>which</structfield> field to
<constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. When they call the
<constant>VIDIOC_SUBDEV_G_FMT</constant> ioctl with a pointer to this
structure the driver fills the members of the <structfield>format</structfield>
field.</para>
<para>To change the current format applications set both the
<structfield>pad</structfield> and <structfield>which</structfield> fields
and all members of the <structfield>format</structfield> field. When they
call the <constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl with a pointer to this
structure the driver verifies the requested format, adjusts it based on the
hardware capabilities and configures the device. Upon return the
&v4l2-subdev-format; contains the current format as would be returned by a
<constant>VIDIOC_SUBDEV_G_FMT</constant> call.</para>
<para>Applications can query the device capabilities by setting the
<structfield>which</structfield> to
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. When set, 'try' formats are not
applied to the device by the driver, but are changed exactly as active
formats and stored in the sub-device file handle. Two applications querying
the same sub-device would thus not interact with each other.</para>
<para>For instance, to try a format at the output pad of a sub-device,
applications would first set the try format at the sub-device input with the
<constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl. They would then either
retrieve the default format at the output pad with the
<constant>VIDIOC_SUBDEV_G_FMT</constant> ioctl, or set the desired output
pad format with the <constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl and check
the returned value.</para>
<para>Try formats do not depend on active formats, but can depend on the
current links configuration or sub-device controls value. For instance, a
low-pass noise filter might crop pixels at the frame boundaries, modifying
its output frame size.</para>
<para>Drivers must not return an error solely because the requested format
doesn't match the device capabilities. They must instead modify the format
to match what the hardware can provide. The modified format should be as
close as possible to the original request.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-format">
<title>struct <structname>v4l2_subdev_format</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media controller API.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>which</structfield></entry>
<entry>Format to modified, from &v4l2-subdev-format-whence;.</entry>
</row>
<row>
<entry>&v4l2-mbus-framefmt;</entry>
<entry><structfield>format</structfield></entry>
<entry>Definition of an image format, see <xref
linkend="v4l2-mbus-framefmt" /> for details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[8]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-subdev-format-whence">
<title>enum <structname>v4l2_subdev_format_whence</structname></title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry>V4L2_SUBDEV_FORMAT_TRY</entry>
<entry>0</entry>
<entry>Try formats, used for querying device capabilities.</entry>
</row>
<row>
<entry>V4L2_SUBDEV_FORMAT_ACTIVE</entry>
<entry>1</entry>
<entry>Active formats, applied to the hardware.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The format can't be changed because the pad is currently busy.
This can be caused, for instance, by an active video stream on the
pad. The ioctl must not be retried without performing another action
to fix the problem first. Only returned by
<constant>VIDIOC_SUBDEV_S_FMT</constant></para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-format; <structfield>pad</structfield>
references a non-existing pad, or the <structfield>which</structfield>
field references a non-existing format.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="vidioc-subdev-g-frame-interval">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_G_FRAME_INTERVAL</refname>
<refname>VIDIOC_SUBDEV_S_FRAME_INTERVAL</refname>
<refpurpose>Get or set the frame interval on a subdev pad</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_subdev_frame_interval *<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_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>These ioctls are used to get and set the frame interval at specific
subdev pads in the image pipeline. The frame interval only makes sense for
sub-devices that can control the frame period on their own. This includes,
for instance, image sensors and TV tuners. Sub-devices that don't support
frame intervals must not implement these ioctls.</para>
<para>To retrieve the current frame interval applications set the
<structfield>pad</structfield> field of a &v4l2-subdev-frame-interval; to
the desired pad number as reported by the media controller API. When they
call the <constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant> ioctl with a
pointer to this structure the driver fills the members of the
<structfield>interval</structfield> field.</para>
<para>To change the current frame interval applications set both the
<structfield>pad</structfield> field and all members of the
<structfield>interval</structfield> field. When they call the
<constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant> ioctl with a pointer to
this structure the driver verifies the requested interval, adjusts it based
on the hardware capabilities and configures the device. Upon return the
&v4l2-subdev-frame-interval; contains the current frame interval as would be
returned by a <constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant> call.
</para>
<para>Drivers must not return an error solely because the requested interval
doesn't match the device capabilities. They must instead modify the interval
to match what the hardware can provide. The modified interval should be as
close as possible to the original request.</para>
<para>Sub-devices that support the frame interval ioctls should implement
them on a single pad only. Their behaviour when supported on multiple pads
of the same sub-device is not defined.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-frame-interval">
<title>struct <structname>v4l2_subdev_frame_interval</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media controller API.</entry>
</row>
<row>
<entry>&v4l2-fract;</entry>
<entry><structfield>interval</structfield></entry>
<entry>Period, in seconds, between consecutive video frames.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The frame interval can't be changed because the pad is currently
busy. This can be caused, for instance, by an active video stream on
the pad. The ioctl must not be retried without performing another
action to fix the problem first. Only returned by
<constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant></para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-frame-interval; <structfield>pad</structfield>
references a non-existing pad, or the pad doesn't support frame
intervals.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
......@@ -556,6 +556,9 @@ sub ngene {
my $hash1 = "d798d5a757121174f0dbc5f2833c0c85";
my $file2 = "ngene_17.fw";
my $hash2 = "26b687136e127b8ac24b81e0eeafc20b";
my $url2 = "http://l4m-daten.de/downloads/firmware/dvb-s2/linux/all/";
my $file3 = "ngene_18.fw";
my $hash3 = "ebce3ea769a53e3e0b0197c3b3f127e3";
checkstandard();
......@@ -565,7 +568,10 @@ sub ngene {
wgetfile($file2, $url . $file2);
verify($file2, $hash2);
"$file1, $file2";
wgetfile($file3, $url2 . $file3);
verify($file3, $hash3);
"$file1, $file2, $file3";
}
sub az6027{
......
......@@ -4,7 +4,7 @@ following file(s) to this directory.
for DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
-------------------------------------------
The Sharp 7395 driver can be found in windows/system32/driver
The Sharp 7395 driver can be found in windows/system32/drivers
US2A0D.sys (dated 17 Mar 2009)
......@@ -44,7 +44,7 @@ and run
Other LG firmware can be extracted manually from US280D.sys
only found in windows/system32/driver.
only found in windows/system32/drivers
dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw
......@@ -55,4 +55,16 @@ dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw
---------------------------------------------------------------------
The Sharp 0194 tuner driver can be found in windows/system32/drivers
US290D.sys (dated 09 Apr 2009)
For LME2510
dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw
For LME2510C
dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw
Copy the firmware file(s) to /lib/firmware
......@@ -108,42 +108,6 @@ Who: Pavel Machek <pavel@ucw.cz>
---------------------------
What: Video4Linux obsolete drivers using V4L1 API
When: kernel 2.6.39
Files: drivers/staging/se401/* drivers/staging/usbvideo/*
Check: drivers/staging/se401/se401.c drivers/staging/usbvideo/usbvideo.c
Why: There are some drivers still using V4L1 API, despite all efforts we've done
to migrate. Those drivers are for obsolete hardware that the old maintainer
didn't care (or not have the hardware anymore), and that no other developer
could find any hardware to buy. They probably have no practical usage today,
and people with such old hardware could probably keep using an older version
of the kernel. Those drivers will be moved to staging on 2.6.38 and, if nobody
cares enough to port and test them with V4L2 API, they'll be removed on 2.6.39.
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: Video4Linux: Remove obsolete ioctl's
When: kernel 2.6.39
Files: include/media/videodev2.h
Why: Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong
type of R/W arguments. They were fixed, but the old ioctl names are
still there, maintained to avoid breaking binary compatibility:
#define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int)
#define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm)
#define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control)
#define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio)
#define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout)
#define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap)
There's no sense on preserving those forever, as it is very doubtful
that someone would try to use a such old binary with a modern kernel.
Removing them will allow us to remove some magic done at the V4L ioctl
handler.
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: sys_sysctl
When: September 2010
Option: CONFIG_SYSCTL_SYSCALL
......
......@@ -273,6 +273,7 @@ Code Seq#(hex) Include File Comments
'z' 40-7F CAN bus card conflict!
<mailto:oe@port.de>
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
'|' 00-7F linux/media.h
0x80 00-1F linux/fb.h
0x89 00-06 arch/x86/include/asm/sockios.h
0x89 0B-DF linux/sockios.h
......
This diff is collapsed.
......@@ -36,8 +36,7 @@ Additional features for the PVR-350 (CX23415 based):
* Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the
video signal)
* Provides a framebuffer (allowing X applications to appear on the video
device) (this framebuffer is not yet part of the kernel. In the meantime it
is available from www.ivtvdriver.org).
device)
* Supports raw YUV output.
IMPORTANT: In case of problems first read this page:
......
......@@ -103,6 +103,7 @@ spca561 046d:092d Logitech QC Elch2
spca561 046d:092e Logitech QC Elch2
spca561 046d:092f Logitech QuickCam Express Plus
sunplus 046d:0960 Logitech ClickSmart 420
nw80x 046d:d001 Logitech QuickCam Pro (dark focus ring)
sunplus 0471:0322 Philips DMVC1300K
zc3xx 0471:0325 Philips SPC 200 NC
zc3xx 0471:0326 Philips SPC 300 NC
......@@ -150,10 +151,12 @@ sunplus 04fc:5330 Digitrex 2110
sunplus 04fc:5360 Sunplus Generic
spca500 04fc:7333 PalmPixDC85
sunplus 04fc:ffff Pure DigitalDakota
nw80x 0502:d001 DVC V6
spca501 0506:00df 3Com HomeConnect Lite
sunplus 052b:1507 Megapixel 5 Pretec DC-1007
sunplus 052b:1513 Megapix V4
sunplus 052b:1803 MegaImage VI
nw80x 052b:d001 EZCam Pro p35u
tv8532 0545:808b Veo Stingray
tv8532 0545:8333 Veo Stingray
sunplus 0546:3155 Polaroid PDC3070
......@@ -177,6 +180,7 @@ sunplus 055f:c530 Mustek Gsmart LCD 3
sunplus 055f:c540 Gsmart D30
sunplus 055f:c630 Mustek MDC4000
sunplus 055f:c650 Mustek MDC5500Z
nw80x 055f:d001 Mustek Wcam 300 mini
zc3xx 055f:d003 Mustek WCam300A
zc3xx 055f:d004 Mustek WCam300 AN
conex 0572:0041 Creative Notebook cx11646
......@@ -195,14 +199,20 @@ gl860 05e3:0503 Genesys Logic PC Camera
gl860 05e3:f191 Genesys Logic PC Camera
spca561 060b:a001 Maxell Compact Pc PM3
zc3xx 0698:2003 CTX M730V built in
nw80x 06a5:0000 Typhoon Webcam 100 USB
nw80x 06a5:d001 Divio based webcams
nw80x 06a5:d800 Divio Chicony TwinkleCam, Trust SpaceCam
spca500 06bd:0404 Agfa CL20
spca500 06be:0800 Optimedia
nw80x 06be:d001 EZCam Pro p35u
sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom
spca506 06e1:a190 ADS Instant VCD
ov534 06f8:3002 Hercules Blog Webcam
ov534_9 06f8:3003 Hercules Dualpix HD Weblog
sonixj 06f8:3004 Hercules Classic Silver
sonixj 06f8:3008 Hercules Deluxe Optical Glass
pac7302 06f8:3009 Hercules Classic Link
nw80x 0728:d001 AVerMedia Camguard
spca508 0733:0110 ViewQuest VQ110
spca501 0733:0401 Intel Create and Share
spca501 0733:0402 ViewQuest M318B
......
This diff is collapsed.
......@@ -4582,6 +4582,12 @@ L: linux-omap@vger.kernel.org
S: Maintained
F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c
OMAP IMAGE SIGNAL PROCESSOR (ISP)
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/video/omap3isp/*
OMAP USB SUPPORT
M: Felipe Balbi <balbi@ti.com>
M: David Brownell <dbrownell@users.sourceforge.net>
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -40,6 +40,7 @@ struct xc5000_config {
#define XC5000_RADIO_NOT_CONFIGURED 0
#define XC5000_RADIO_FM1 1
#define XC5000_RADIO_FM2 2
#define XC5000_RADIO_FM1_MONO 3
/* For each bridge framework, when it attaches either analog or digital,
* it has to store a reference back to its _core equivalent structure,
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment