You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - removal of sn9c102. This device driver was replaced a long time ago by gspca - solo6x10 and go7007 webcam drivers moved from staging into mainstream. They were waiting for an API to allow setting the image detection matrix - SDR drivers moved from staging into mainstream: sdr-msi3101 (renamed as msi2500) and rtl2832 - added SDR driver for airspy - added demux driver: si2165 - rework at several RC subsystem, making the code for RC-5 SZ variant to be added at the standard RC5 decoder - added decoder for the XMP IR protocol - tuner driver moved from staging into mainstream: msi3101 (renamed as msi001) - added documentation for some additional SDR pixfmt - some device tree bindings documented - added support for exynos3250 at s5p-jpeg - remove the obsolete, unmaintained and broken mx1_camera driver - added support for remote controllers at au0828 driver - added a RC driver: sunxi-cir - several driver fixes, enhancements and cleanups. * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (455 commits) [media] cx23885: fix UNSET/TUNER_ABSENT confusion [media] coda: fix build error by making reset control optional [media] radio-miropcm20: fix sparse NULL pointer warning [media] MAINTAINERS: Update go7007 pattern [media] MAINTAINERS: Update solo6x10 patterns [media] media: atmel-isi: add primary DT support [media] media: atmel-isi: convert the pdata from pointer to structure [media] media: atmel-isi: add v4l2 async probe support [media] rcar_vin: add devicetree support [media] media: pxa_camera device-tree support [media] media: mt9m111: add device-tree suppport [media] soc_camera: add support for dt binding soc_camera drivers [media] media: soc_camera: pxa_camera documentation device-tree support [media] media: mt9m111: add device-tree documentation [media] s5p-mfc: remove unnecessary calling to function video_devdata() [media] s5p-jpeg: add chroma subsampling adjustment for Exynos3250 [media] s5p-jpeg: Prevent erroneous downscaling for Exynos3250 SoC [media] s5p-jpeg: Assure proper crop rectangle initialization [media] s5p-jpeg: fix g_selection op [media] s5p-jpeg: Adjust jpeg_bound_align_image to Exynos3250 needs ...
This commit is contained in:
Linus Torvalds
@@ -174,7 +174,7 @@ FILENAME = \
|
||||
DOCUMENTED = \
|
||||
-e "s/\(enum *\)v4l2_mpeg_cx2341x_video_\([a-z]*_spatial_filter_type\)/\1<link linkend=\"\2\">v4l2_mpeg_cx2341x_video_\2<\/link>/g" \
|
||||
-e "s/\(\(enum\|struct\) *\)\(v4l2_[a-zA-Z0-9_]*\)/\1<link linkend=\"\3\">\3<\/link>/g" \
|
||||
-e "s/\(V4L2_PIX_FMT_[A-Z0-9_]\+\) /<link linkend=\"\1\">\1<\/link> /g" \
|
||||
-e "s/\(V4L2_PIX_FMT_[A-Z0-9_]\+\)\(\s\+v4l2_fourcc\)/<link linkend=\"\1\">\1<\/link>\2/g" \
|
||||
-e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \
|
||||
-e "s/v4l2\-mpeg\-vbi\-ITV0/v4l2-mpeg-vbi-itv0-1/g"
|
||||
|
||||
|
||||
@@ -555,10 +555,46 @@ typedef enum fe_delivery_system {
|
||||
</section>
|
||||
<section id="DTV-ISDBT-LAYER-TIME-INTERLEAVING">
|
||||
<title><constant>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</constant></title>
|
||||
<para>Possible values: 0, 1, 2, 3, -1 (AUTO)</para>
|
||||
<para>Note: The real inter-leaver depth-names depend on the mode (fft-size); the values
|
||||
here are referring to what can be found in the TMCC-structure -
|
||||
independent of the mode.</para>
|
||||
<para>Valid values: 0, 1, 2, 4, -1 (AUTO)</para>
|
||||
<para>when DTV_ISDBT_SOUND_BROADCASTING is active, value 8 is also valid.</para>
|
||||
<para>Note: The real time interleaving length depends on the mode (fft-size). The values
|
||||
here are referring to what can be found in the TMCC-structure, as shown in the table below.</para>
|
||||
<informaltable id="isdbt-layer-interleaving-table">
|
||||
<tgroup cols="4" align="center">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</entry>
|
||||
<entry>Mode 1 (2K FFT)</entry>
|
||||
<entry>Mode 2 (4K FFT)</entry>
|
||||
<entry>Mode 3 (8K FFT)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1</entry>
|
||||
<entry>4</entry>
|
||||
<entry>2</entry>
|
||||
<entry>1</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>8</entry>
|
||||
<entry>4</entry>
|
||||
<entry>2</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>4</entry>
|
||||
<entry>16</entry>
|
||||
<entry>8</entry>
|
||||
<entry>4</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</section>
|
||||
<section id="DTV-ATSCMH-FIC-VER">
|
||||
<title><constant>DTV_ATSCMH_FIC_VER</constant></title>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -150,9 +150,15 @@ signal. Drivers shall not convert the sample format by software.</para></entry>
|
||||
<entry>This is the scanning system line number
|
||||
associated with the first line of the VBI image, of the first and the
|
||||
second field respectively. See <xref linkend="vbi-525" /> and
|
||||
<xref linkend="vbi-625" /> for valid values. VBI input drivers can
|
||||
return start values 0 if the hardware cannot reliable identify
|
||||
scanning lines, VBI acquisition may not require this
|
||||
<xref linkend="vbi-625" /> for valid values.
|
||||
The <constant>V4L2_VBI_ITU_525_F1_START</constant>,
|
||||
<constant>V4L2_VBI_ITU_525_F2_START</constant>,
|
||||
<constant>V4L2_VBI_ITU_625_F1_START</constant> and
|
||||
<constant>V4L2_VBI_ITU_625_F2_START</constant> defines give the start line
|
||||
numbers for each field for each 525 or 625 line format as a convenience.
|
||||
Don't forget that ITU line numbering starts at 1, not 0.
|
||||
VBI input drivers can return start values 0 if the hardware cannot
|
||||
reliable identify scanning lines, VBI acquisition may not require this
|
||||
information.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
||||
@@ -72,9 +72,12 @@ To use the <link linkend="format">format</link> ioctls applications set the
|
||||
<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format;
|
||||
<structfield>sdr</structfield> member of the <structfield>fmt</structfield>
|
||||
union as needed per the desired operation.
|
||||
Currently only the <structfield>pixelformat</structfield> field of
|
||||
&v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code
|
||||
of the data format.
|
||||
Currently there is two fields, <structfield>pixelformat</structfield> and
|
||||
<structfield>buffersize</structfield>, of struct &v4l2-sdr-format; which are
|
||||
used. Content of the <structfield>pixelformat</structfield> is V4L2 FourCC
|
||||
code of the data format. The <structfield>buffersize</structfield> field is
|
||||
maximum buffer size in bytes required for data transfer, set by the driver in
|
||||
order to inform application.
|
||||
</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-sdr-format">
|
||||
@@ -91,9 +94,16 @@ little endian <link linkend="v4l2-fourcc">four character code</link>.
|
||||
V4L2 defines SDR formats in <xref linkend="sdr-formats" />.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>buffersize</structfield></entry>
|
||||
<entry>
|
||||
Maximum size in bytes required for data. Value is set by the driver.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>reserved[28]</structfield></entry>
|
||||
<entry><structfield>reserved[24]</structfield></entry>
|
||||
<entry>This array is reserved for future extensions.
|
||||
Drivers and applications must set it to zero.</entry>
|
||||
</row>
|
||||
|
||||
@@ -185,7 +185,14 @@ tables, sigh. --></para></entry>
|
||||
<entry></entry>
|
||||
<entry spanname="hspan">Drivers must set
|
||||
<structfield>service_lines</structfield>[0][0] and
|
||||
<structfield>service_lines</structfield>[1][0] to zero.</entry>
|
||||
<structfield>service_lines</structfield>[1][0] to zero.
|
||||
The <constant>V4L2_VBI_ITU_525_F1_START</constant>,
|
||||
<constant>V4L2_VBI_ITU_525_F2_START</constant>,
|
||||
<constant>V4L2_VBI_ITU_625_F1_START</constant> and
|
||||
<constant>V4L2_VBI_ITU_625_F2_START</constant> defines give the start
|
||||
line numbers for each field for each 525 or 625 line format as a
|
||||
convenience. Don't forget that ITU line numbering starts at 1, not 0.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
||||
@@ -870,7 +870,8 @@ should set this to 0.</entry>
|
||||
If the application sets this to 0 for an output stream, then
|
||||
<structfield>bytesused</structfield> will be set to the size of the
|
||||
plane (see the <structfield>length</structfield> field of this struct)
|
||||
by the driver.</entry>
|
||||
by the driver. Note that the actual image data starts at
|
||||
<structfield>data_offset</structfield> which may not be 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
@@ -919,6 +920,10 @@ should set this to 0.</entry>
|
||||
<entry>Offset in bytes to video data in the plane.
|
||||
Drivers must set this field when <structfield>type</structfield>
|
||||
refers to an input stream, applications when it refers to an output stream.
|
||||
Note that data_offset is included in <structfield>bytesused</structfield>.
|
||||
So the size of the image in the plane is
|
||||
<structfield>bytesused</structfield>-<structfield>data_offset</structfield> at
|
||||
offset <structfield>data_offset</structfield> from the start of the plane.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@@ -1066,7 +1071,7 @@ state, in the application domain so to say.</entry>
|
||||
<entry>Drivers set or clear this flag when calling the
|
||||
<constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video
|
||||
capture devices when the buffer contains a compressed image which is a
|
||||
key frame (or field), &ie; can be decompressed on its own. Also know as
|
||||
key frame (or field), &ie; can be decompressed on its own. Also known as
|
||||
an I-frame. Applications can set this bit when <structfield>type</structfield>
|
||||
refers to an output stream.</entry>
|
||||
</row>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,44 @@
|
||||
<refentry id="V4L2-SDR-FMT-CS08">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_SDR_FMT_CS8 ('CS08')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname>
|
||||
<constant>V4L2_SDR_FMT_CS8</constant>
|
||||
</refname>
|
||||
<refpurpose>Complex signed 8-bit IQ sample</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>
|
||||
This format contains sequence of complex number samples. Each complex number
|
||||
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
|
||||
represented as a 8 bit signed number. I value comes first and Q value after
|
||||
that.
|
||||
</para>
|
||||
<example>
|
||||
<title><constant>V4L2_SDR_FMT_CS8</constant> 1 sample</title>
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>I'<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 1:</entry>
|
||||
<entry>Q'<subscript>0</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -0,0 +1,47 @@
|
||||
<refentry id="V4L2-SDR-FMT-CS14LE">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_SDR_FMT_CS14LE ('CS14')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname>
|
||||
<constant>V4L2_SDR_FMT_CS14LE</constant>
|
||||
</refname>
|
||||
<refpurpose>Complex signed 14-bit little endian IQ sample</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>
|
||||
This format contains sequence of complex number samples. Each complex number
|
||||
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
|
||||
represented as a 14 bit signed little endian number. I value comes first
|
||||
and Q value after that. 14 bit value is stored in 16 bit space with unused
|
||||
high bits padded with 0.
|
||||
</para>
|
||||
<example>
|
||||
<title><constant>V4L2_SDR_FMT_CS14LE</constant> 1 sample</title>
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="3" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>I'<subscript>0[7:0]</subscript></entry>
|
||||
<entry>I'<subscript>0[13:8]</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 2:</entry>
|
||||
<entry>Q'<subscript>0[7:0]</subscript></entry>
|
||||
<entry>Q'<subscript>0[13:8]</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -0,0 +1,40 @@
|
||||
<refentry id="V4L2-SDR-FMT-RU12LE">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_SDR_FMT_RU12LE ('RU12')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname>
|
||||
<constant>V4L2_SDR_FMT_RU12LE</constant>
|
||||
</refname>
|
||||
<refpurpose>Real unsigned 12-bit little endian sample</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>
|
||||
This format contains sequence of real number samples. Each sample is
|
||||
represented as a 12 bit unsigned little endian number. Sample is stored
|
||||
in 16 bit space with unused high bits padded with 0.
|
||||
</para>
|
||||
<example>
|
||||
<title><constant>V4L2_SDR_FMT_RU12LE</constant> 1 sample</title>
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="3" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>I'<subscript>0[7:0]</subscript></entry>
|
||||
<entry>I'<subscript>0[11:8]</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -18,7 +18,7 @@
|
||||
<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
|
||||
12 bits per colour. Each colour component is stored in a 16-bit word, with 4
|
||||
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
|
||||
|
||||
@@ -112,9 +112,34 @@ see <xref linkend="colorspaces" />.</entry>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>priv</structfield></entry>
|
||||
<entry>Reserved for custom (driver defined) additional
|
||||
information about formats. When not used drivers and applications must
|
||||
set this field to zero.</entry>
|
||||
<entry><para>This field indicates whether the remaining fields of the
|
||||
<structname>v4l2_pix_format</structname> structure, also called the extended
|
||||
fields, are valid. When set to <constant>V4L2_PIX_FMT_PRIV_MAGIC</constant>, it
|
||||
indicates that the extended fields have been correctly initialized. When set to
|
||||
any other value it indicates that the extended fields contain undefined values.
|
||||
</para>
|
||||
<para>Applications that wish to use the pixel format extended fields must first
|
||||
ensure that the feature is supported by querying the device for the
|
||||
<link linkend="querycap"><constant>V4L2_CAP_EXT_PIX_FORMAT</constant></link>
|
||||
capability. If the capability isn't set the pixel format extended fields are not
|
||||
supported and using the extended fields will lead to undefined results.</para>
|
||||
<para>To use the extended fields, applications must set the
|
||||
<structfield>priv</structfield> field to
|
||||
<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant>, initialize all the extended fields
|
||||
and zero the unused bytes of the <structname>v4l2_format</structname>
|
||||
<structfield>raw_data</structfield> field.</para>
|
||||
<para>When the <structfield>priv</structfield> field isn't set to
|
||||
<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant> drivers must act as if all the
|
||||
extended fields were set to zero. On return drivers must set the
|
||||
<structfield>priv</structfield> field to
|
||||
<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant> and all the extended fields to
|
||||
applicable values.</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Flags set by the application or driver, see <xref
|
||||
linkend="format-flags" />.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@@ -201,9 +226,15 @@ codes can be used.</entry>
|
||||
and the number of valid entries in the
|
||||
<structfield>plane_fmt</structfield> array.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Flags set by the application or driver, see <xref
|
||||
linkend="format-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>reserved[11]</structfield></entry>
|
||||
<entry><structfield>reserved[10]</structfield></entry>
|
||||
<entry>Reserved for future extensions. Should be zeroed by the
|
||||
application.</entry>
|
||||
</row>
|
||||
@@ -248,7 +279,7 @@ 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 <link
|
||||
linkend="videodev">videodev.h</link> header file. These identifiers
|
||||
linkend="videodev">videodev2.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>
|
||||
@@ -828,6 +859,9 @@ interface only.</para>
|
||||
|
||||
&sub-sdr-cu08;
|
||||
&sub-sdr-cu16le;
|
||||
&sub-sdr-cs08;
|
||||
&sub-sdr-cs14le;
|
||||
&sub-sdr-ru12le;
|
||||
|
||||
</section>
|
||||
|
||||
@@ -1060,4 +1094,21 @@ concatenated to form the JPEG stream. </para>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="format-flags">
|
||||
<title>Format Flags</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_PIX_FMT_FLAG_PREMUL_ALPHA</constant></entry>
|
||||
<entry>0x00000001</entry>
|
||||
<entry>The color values are premultiplied by the alpha channel
|
||||
value. For example, if a light blue pixel with 50% transparency was described by
|
||||
RGBA values (128, 192, 255, 128), the same pixel described with premultiplied
|
||||
colors would be described by RGBA values (64, 96, 128, 128) </entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
@@ -86,47 +86,47 @@ selection targets available for a video capture device. It is recommended to
|
||||
configure the cropping targets before to the composing targets.</para>
|
||||
|
||||
<para>The range of coordinates of the top left corner, width and height of
|
||||
areas that can be sampled is given by the <constant> V4L2_SEL_TGT_CROP_BOUNDS
|
||||
</constant> target. It is recommended for the driver developers to put the
|
||||
top/left corner at position <constant> (0,0) </constant>. The rectangle's
|
||||
areas that can be sampled is given by the <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>
|
||||
target. It is recommended for the driver developers to put the
|
||||
top/left corner at position <constant>(0,0)</constant>. The rectangle's
|
||||
coordinates are expressed in pixels.</para>
|
||||
|
||||
<para>The top left corner, width and height of the source rectangle, that is
|
||||
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP
|
||||
</constant> target. It uses the same coordinate system as <constant>
|
||||
V4L2_SEL_TGT_CROP_BOUNDS </constant>. The active cropping area must lie
|
||||
completely inside the capture boundaries. The driver may further adjust the
|
||||
requested size and/or position according to hardware limitations.</para>
|
||||
the area actually sampled, is given by the <constant>V4L2_SEL_TGT_CROP</constant>
|
||||
target. It uses the same coordinate system as <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>.
|
||||
The active cropping area must lie completely inside the capture boundaries. The
|
||||
driver may further adjust the requested size and/or position according to hardware
|
||||
limitations.</para>
|
||||
|
||||
<para>Each capture device has a default source rectangle, given by the
|
||||
<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant> target. This rectangle shall
|
||||
<constant>V4L2_SEL_TGT_CROP_DEFAULT</constant> target. This rectangle shall
|
||||
over what the driver writer considers the complete picture. Drivers shall set
|
||||
the active crop rectangle to the default when the driver is first loaded, but
|
||||
not later.</para>
|
||||
|
||||
<para>The composing targets refer to a memory buffer. The limits of composing
|
||||
coordinates are obtained using <constant> V4L2_SEL_TGT_COMPOSE_BOUNDS
|
||||
</constant>. All coordinates are expressed in pixels. The rectangle's top/left
|
||||
corner must be located at position <constant> (0,0) </constant>. The width and
|
||||
height are equal to the image size set by <constant> VIDIOC_S_FMT </constant>.
|
||||
coordinates are obtained using <constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant>.
|
||||
All coordinates are expressed in pixels. The rectangle's top/left
|
||||
corner must be located at position <constant>(0,0)</constant>. The width and
|
||||
height are equal to the image size set by <constant>VIDIOC_S_FMT</constant>.
|
||||
</para>
|
||||
|
||||
<para>The part of a buffer into which the image is inserted by the hardware is
|
||||
controlled by the <constant> V4L2_SEL_TGT_COMPOSE </constant> target.
|
||||
controlled by the <constant>V4L2_SEL_TGT_COMPOSE</constant> target.
|
||||
The rectangle's coordinates are also expressed in the same coordinate system as
|
||||
the bounds rectangle. The composing rectangle must lie completely inside bounds
|
||||
rectangle. The driver must adjust the composing rectangle to fit to the
|
||||
bounding limits. Moreover, the driver can perform other adjustments according
|
||||
to hardware limitations. The application can control rounding behaviour using
|
||||
<link linkend="v4l2-selection-flags"> constraint flags </link>.</para>
|
||||
<link linkend="v4l2-selection-flags"> constraint flags</link>.</para>
|
||||
|
||||
<para>For capture devices the default composing rectangle is queried using
|
||||
<constant> V4L2_SEL_TGT_COMPOSE_DEFAULT </constant>. It is usually equal to the
|
||||
<constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant>. It is usually equal to the
|
||||
bounding rectangle.</para>
|
||||
|
||||
<para>The part of a buffer that is modified by the hardware is given by
|
||||
<constant> V4L2_SEL_TGT_COMPOSE_PADDED </constant>. It contains all pixels
|
||||
defined using <constant> V4L2_SEL_TGT_COMPOSE </constant> plus all
|
||||
<constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant>. It contains all pixels
|
||||
defined using <constant>V4L2_SEL_TGT_COMPOSE</constant> plus all
|
||||
padding data modified by hardware during insertion process. All pixels outside
|
||||
this rectangle <emphasis>must not</emphasis> be changed by the hardware. The
|
||||
content of pixels that lie inside the padded area but outside active area is
|
||||
@@ -140,52 +140,51 @@ where the rubbish pixels are located and remove them if needed.</para>
|
||||
<title>Configuration of video output</title>
|
||||
|
||||
<para>For output devices targets and ioctls are used similarly to the video
|
||||
capture case. The <emphasis> composing </emphasis> rectangle refers to the
|
||||
capture case. The <emphasis>composing</emphasis> rectangle refers to the
|
||||
insertion of an image into a video signal. The cropping rectangles refer to a
|
||||
memory buffer. It is recommended to configure the composing targets before to
|
||||
the cropping targets.</para>
|
||||
|
||||
<para>The cropping targets refer to the memory buffer that contains an image to
|
||||
be inserted into a video signal or graphical screen. The limits of cropping
|
||||
coordinates are obtained using <constant> V4L2_SEL_TGT_CROP_BOUNDS </constant>.
|
||||
coordinates are obtained using <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>.
|
||||
All coordinates are expressed in pixels. The top/left corner is always point
|
||||
<constant> (0,0) </constant>. The width and height is equal to the image size
|
||||
specified using <constant> VIDIOC_S_FMT </constant> ioctl.</para>
|
||||
<constant>(0,0)</constant>. The width and height is equal to the image size
|
||||
specified using <constant>VIDIOC_S_FMT</constant> ioctl.</para>
|
||||
|
||||
<para>The top left corner, width and height of the source rectangle, that is
|
||||
the area from which image date are processed by the hardware, is given by the
|
||||
<constant> V4L2_SEL_TGT_CROP </constant>. Its coordinates are expressed
|
||||
<constant>V4L2_SEL_TGT_CROP</constant>. Its coordinates are expressed
|
||||
in in the same coordinate system as the bounds rectangle. The active cropping
|
||||
area must lie completely inside the crop boundaries and the driver may further
|
||||
adjust the requested size and/or position according to hardware
|
||||
limitations.</para>
|
||||
|
||||
<para>For output devices the default cropping rectangle is queried using
|
||||
<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant>. It is usually equal to the
|
||||
<constant>V4L2_SEL_TGT_CROP_DEFAULT</constant>. It is usually equal to the
|
||||
bounding rectangle.</para>
|
||||
|
||||
<para>The part of a video signal or graphics display where the image is
|
||||
inserted by the hardware is controlled by <constant>
|
||||
V4L2_SEL_TGT_COMPOSE </constant> target. The rectangle's coordinates
|
||||
are expressed in pixels. The composing rectangle must lie completely inside the
|
||||
bounds rectangle. The driver must adjust the area to fit to the bounding
|
||||
limits. Moreover, the driver can perform other adjustments according to
|
||||
hardware limitations. </para>
|
||||
inserted by the hardware is controlled by <constant>V4L2_SEL_TGT_COMPOSE</constant>
|
||||
target. The rectangle's coordinates are expressed in pixels. The composing
|
||||
rectangle must lie completely inside the bounds rectangle. The driver must
|
||||
adjust the area to fit to the bounding limits. Moreover, the driver can
|
||||
perform other adjustments according to hardware limitations.</para>
|
||||
|
||||
<para>The device has a default composing rectangle, given by the <constant>
|
||||
V4L2_SEL_TGT_COMPOSE_DEFAULT </constant> target. This rectangle shall cover what
|
||||
<para>The device has a default composing rectangle, given by the
|
||||
<constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant> target. This rectangle shall cover what
|
||||
the driver writer considers the complete picture. It is recommended for the
|
||||
driver developers to put the top/left corner at position <constant> (0,0)
|
||||
</constant>. Drivers shall set the active composing rectangle to the default
|
||||
driver developers to put the top/left corner at position <constant>(0,0)</constant>.
|
||||
Drivers shall set the active composing rectangle to the default
|
||||
one when the driver is first loaded.</para>
|
||||
|
||||
<para>The devices may introduce additional content to video signal other than
|
||||
an image from memory buffers. It includes borders around an image. However,
|
||||
such a padded area is driver-dependent feature not covered by this document.
|
||||
Driver developers are encouraged to keep padded rectangle equal to active one.
|
||||
The padded target is accessed by the <constant> V4L2_SEL_TGT_COMPOSE_PADDED
|
||||
</constant> identifier. It must contain all pixels from the <constant>
|
||||
V4L2_SEL_TGT_COMPOSE </constant> target.</para>
|
||||
The padded target is accessed by the <constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant>
|
||||
identifier. It must contain all pixels from the <constant>V4L2_SEL_TGT_COMPOSE</constant>
|
||||
target.</para>
|
||||
|
||||
</section>
|
||||
|
||||
@@ -194,8 +193,8 @@ V4L2_SEL_TGT_COMPOSE </constant> target.</para>
|
||||
<title>Scaling control</title>
|
||||
|
||||
<para>An application can detect if scaling is performed by comparing the width
|
||||
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP
|
||||
</constant> and <constant> V4L2_SEL_TGT_COMPOSE </constant> targets. If
|
||||
and the height of rectangles obtained using <constant>V4L2_SEL_TGT_CROP</constant>
|
||||
and <constant>V4L2_SEL_TGT_COMPOSE</constant> targets. If
|
||||
these are not equal then the scaling is applied. The application can compute
|
||||
the scaling ratios using these values.</para>
|
||||
|
||||
@@ -208,7 +207,7 @@ the scaling ratios using these values.</para>
|
||||
<title>Comparison with old cropping API</title>
|
||||
|
||||
<para>The selection API was introduced to cope with deficiencies of previous
|
||||
<link linkend="crop"> API </link>, that was designed to control simple capture
|
||||
<link linkend="crop"> API</link>, that was designed to control simple capture
|
||||
devices. Later the cropping API was adopted by video output drivers. The ioctls
|
||||
are used to select a part of the display were the video signal is inserted. It
|
||||
should be considered as an API abuse because the described operation is
|
||||
@@ -220,7 +219,7 @@ part of an image by abusing V4L2 API. Cropping a smaller image from a larger
|
||||
one is achieved by setting the field
|
||||
&v4l2-pix-format;<structfield>::bytesperline</structfield>. Introducing an image offsets
|
||||
could be done by modifying field &v4l2-buffer;<structfield>::m_userptr</structfield>
|
||||
before calling <constant> VIDIOC_QBUF </constant>. Those
|
||||
before calling <constant>VIDIOC_QBUF</constant>. Those
|
||||
operations should be avoided because they are not portable (endianness), and do
|
||||
not work for macroblock and Bayer formats and mmap buffers. The selection API
|
||||
deals with configuration of buffer cropping/composing in a clear, intuitive and
|
||||
@@ -229,7 +228,7 @@ and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap;
|
||||
have no reserved fields. Therefore there is no way to extend their functionality.
|
||||
The new &v4l2-selection; provides a lot of place for future
|
||||
extensions. Driver developers are encouraged to implement only selection API.
|
||||
The former cropping API would be simulated using the new one. </para>
|
||||
The former cropping API would be simulated using the new one.</para>
|
||||
|
||||
</section>
|
||||
|
||||
@@ -238,9 +237,9 @@ The former cropping API would be simulated using the new one. </para>
|
||||
<example>
|
||||
<title>Resetting the cropping parameters</title>
|
||||
|
||||
<para>(A video capture device is assumed; change <constant>
|
||||
V4L2_BUF_TYPE_VIDEO_CAPTURE </constant> for other devices; change target to
|
||||
<constant> V4L2_SEL_TGT_COMPOSE_* </constant> family to configure composing
|
||||
<para>(A video capture device is assumed; change
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> for other devices; change target to
|
||||
<constant>V4L2_SEL_TGT_COMPOSE_*</constant> family to configure composing
|
||||
area)</para>
|
||||
|
||||
<programlisting>
|
||||
@@ -292,8 +291,8 @@ area)</para>
|
||||
|
||||
<example>
|
||||
<title>Querying for scaling factors</title>
|
||||
<para>A video output device is assumed; change <constant>
|
||||
V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> for other devices</para>
|
||||
<para>A video output device is assumed; change
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> for other devices</para>
|
||||
<programlisting>
|
||||
|
||||
&v4l2-selection; compose = {
|
||||
|
||||
@@ -151,6 +151,14 @@ 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>3.16</revnumber>
|
||||
<date>2014-05-27</date>
|
||||
<authorinitials>lp</authorinitials>
|
||||
<revremark>Extended &v4l2-pix-format;. Added format flags.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.15</revnumber>
|
||||
<date>2014-02-03</date>
|
||||
|
||||
@@ -92,6 +92,18 @@
|
||||
<entry><structfield>frame_sync</structfield></entry>
|
||||
<entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>&v4l2-event-motion-det;</entry>
|
||||
<entry><structfield>motion_det</structfield></entry>
|
||||
<entry>Event data for event V4L2_EVENT_MOTION_DET.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>&v4l2-event-src-change;</entry>
|
||||
<entry><structfield>src_change</structfield></entry>
|
||||
<entry>Event data for event V4L2_EVENT_SOURCE_CHANGE.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
@@ -258,6 +270,44 @@
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-motion-det">
|
||||
<title>struct <structname>v4l2_event_motion_det</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>
|
||||
Currently only one flag is available: if <constant>V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ</constant>
|
||||
is set, then the <structfield>frame_sequence</structfield> field is valid,
|
||||
otherwise that field should be ignored.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>frame_sequence</structfield></entry>
|
||||
<entry>
|
||||
The sequence number of the frame being received. Only valid if the
|
||||
<constant>V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ</constant> flag was set.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>region_mask</structfield></entry>
|
||||
<entry>
|
||||
The bitmask of the regions that reported motion. There is at least one
|
||||
region. If this field is 0, then no motion was detected at all.
|
||||
If there is no <constant>V4L2_CID_DETECT_MD_REGION_GRID</constant> control
|
||||
(see <xref linkend="detect-controls" />) to assign a different region
|
||||
to each cell in the motion detection grid, then that all cells
|
||||
are automatically assigned to the default region 0.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="changes-flags">
|
||||
<title>Changes</title>
|
||||
<tgroup cols="3">
|
||||
|
||||
@@ -72,23 +72,30 @@ initialize the <structfield>id</structfield>,
|
||||
<structfield>size</structfield> and <structfield>reserved2</structfield> fields
|
||||
of each &v4l2-ext-control; and call the
|
||||
<constant>VIDIOC_G_EXT_CTRLS</constant> ioctl. String controls controls
|
||||
must also set the <structfield>string</structfield> field.</para>
|
||||
must also set the <structfield>string</structfield> field. Controls
|
||||
of compound types (<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set)
|
||||
must set the <structfield>ptr</structfield> field.</para>
|
||||
|
||||
<para>If the <structfield>size</structfield> is too small to
|
||||
receive the control result (only relevant for pointer-type controls
|
||||
like strings), then the driver will set <structfield>size</structfield>
|
||||
to a valid value and return an &ENOSPC;. You should re-allocate the
|
||||
string memory to this new size and try again. It is possible that the
|
||||
same issue occurs again if the string has grown in the meantime. It is
|
||||
memory to this new size and try again. For the string type it is possible that
|
||||
the same issue occurs again if the string has grown in the meantime. It is
|
||||
recommended to call &VIDIOC-QUERYCTRL; first and use
|
||||
<structfield>maximum</structfield>+1 as the new <structfield>size</structfield>
|
||||
value. It is guaranteed that that is sufficient memory.
|
||||
</para>
|
||||
|
||||
<para>N-dimensional arrays are set and retrieved row-by-row. You cannot set a partial
|
||||
array, all elements have to be set or retrieved. The total size is calculated
|
||||
as <structfield>elems</structfield> * <structfield>elem_size</structfield>.
|
||||
These values can be obtained by calling &VIDIOC-QUERY-EXT-CTRL;.</para>
|
||||
|
||||
<para>To change the value of a set of controls applications
|
||||
initialize the <structfield>id</structfield>, <structfield>size</structfield>,
|
||||
<structfield>reserved2</structfield> and
|
||||
<structfield>value/string</structfield> fields of each &v4l2-ext-control; and
|
||||
<structfield>value/value64/string/ptr</structfield> fields of each &v4l2-ext-control; and
|
||||
call the <constant>VIDIOC_S_EXT_CTRLS</constant> ioctl. The controls
|
||||
will only be set if <emphasis>all</emphasis> control values are
|
||||
valid.</para>
|
||||
@@ -96,7 +103,7 @@ valid.</para>
|
||||
<para>To check if a set of controls have correct values applications
|
||||
initialize the <structfield>id</structfield>, <structfield>size</structfield>,
|
||||
<structfield>reserved2</structfield> and
|
||||
<structfield>value/string</structfield> fields of each &v4l2-ext-control; and
|
||||
<structfield>value/value64/string/ptr</structfield> fields of each &v4l2-ext-control; and
|
||||
call the <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctl. It is up to
|
||||
the driver whether wrong values are automatically adjusted to a valid
|
||||
value or if an error is returned.</para>
|
||||
@@ -158,19 +165,47 @@ applications must set the array to zero.</entry>
|
||||
<entry></entry>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>value</structfield></entry>
|
||||
<entry>New value or current value.</entry>
|
||||
<entry>New value or current value. Valid if this control is not of
|
||||
type <constant>V4L2_CTRL_TYPE_INTEGER64</constant> and
|
||||
<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is not set.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__s64</entry>
|
||||
<entry><structfield>value64</structfield></entry>
|
||||
<entry>New value or current value.</entry>
|
||||
<entry>New value or current value. Valid if this control is of
|
||||
type <constant>V4L2_CTRL_TYPE_INTEGER64</constant> and
|
||||
<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is not set.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>char *</entry>
|
||||
<entry><structfield>string</structfield></entry>
|
||||
<entry>A pointer to a string.</entry>
|
||||
<entry>A pointer to a string. Valid if this control is of
|
||||
type <constant>V4L2_CTRL_TYPE_STRING</constant>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u8 *</entry>
|
||||
<entry><structfield>p_u8</structfield></entry>
|
||||
<entry>A pointer to a matrix control of unsigned 8-bit values.
|
||||
Valid if this control is of type <constant>V4L2_CTRL_TYPE_U8</constant>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u16 *</entry>
|
||||
<entry><structfield>p_u16</structfield></entry>
|
||||
<entry>A pointer to a matrix control of unsigned 16-bit values.
|
||||
Valid if this control is of type <constant>V4L2_CTRL_TYPE_U16</constant>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>void *</entry>
|
||||
<entry><structfield>ptr</structfield></entry>
|
||||
<entry>A pointer to a compound type which can be an N-dimensional array and/or a
|
||||
compound type (the control's type is >= <constant>V4L2_CTRL_COMPOUND_TYPES</constant>).
|
||||
Valid if <constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set for this control.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
||||
@@ -152,13 +152,10 @@ a valid base address, so applications can find the corresponding Linux
|
||||
framebuffer device (see <xref linkend="osd" />).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-pix-format;</entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>fmt</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Layout of the frame buffer. The
|
||||
<structname>v4l2_pix_format</structname> structure is defined in <xref
|
||||
linkend="pixfmt" />, for clarification the fields and acceptable values
|
||||
are listed below:</entry>
|
||||
<entry>Layout of the frame buffer.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
@@ -276,9 +273,8 @@ see <xref linkend="colorspaces" />.</entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>priv</structfield></entry>
|
||||
<entry>Reserved for additional information about custom
|
||||
(driver defined) formats. When not used drivers and applications must
|
||||
set this field to zero.</entry>
|
||||
<entry>Reserved. Drivers and applications must set this field to
|
||||
zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
||||
@@ -58,17 +58,16 @@
|
||||
|
||||
<para>The ioctls are used to query and configure selection rectangles.</para>
|
||||
|
||||
<para> To query the cropping (composing) rectangle set &v4l2-selection;
|
||||
<para>To query the cropping (composing) rectangle set &v4l2-selection;
|
||||
<structfield> type </structfield> field to the respective buffer type.
|
||||
Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
|
||||
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
|
||||
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
|
||||
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
|
||||
Do not use multiplanar buffers. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. Use
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>. The next step is
|
||||
setting the value of &v4l2-selection; <structfield>target</structfield> field
|
||||
to <constant> V4L2_SEL_TGT_CROP </constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
|
||||
targets. The <structfield>flags</structfield> and <structfield>reserved
|
||||
to <constant>V4L2_SEL_TGT_CROP</constant> (<constant>V4L2_SEL_TGT_COMPOSE</constant>).
|
||||
Please refer to table <xref linkend="v4l2-selections-common" /> or <xref linkend="selection-api" />
|
||||
for additional targets. The <structfield>flags</structfield> and <structfield>reserved
|
||||
</structfield> fields of &v4l2-selection; are ignored and they must be filled
|
||||
with zeros. The driver fills the rest of the structure or
|
||||
returns &EINVAL; if incorrect buffer type or target was used. If cropping
|
||||
@@ -77,19 +76,18 @@ always equal to the bounds rectangle. Finally, the &v4l2-rect;
|
||||
<structfield>r</structfield> rectangle is filled with the current cropping
|
||||
(composing) coordinates. The coordinates are expressed in driver-dependent
|
||||
units. The only exception are rectangles for images in raw formats, whose
|
||||
coordinates are always expressed in pixels. </para>
|
||||
coordinates are always expressed in pixels.</para>
|
||||
|
||||
<para> To change the cropping (composing) rectangle set the &v4l2-selection;
|
||||
<para>To change the cropping (composing) rectangle set the &v4l2-selection;
|
||||
<structfield>type</structfield> field to the respective buffer type. Do not
|
||||
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
|
||||
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
|
||||
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
|
||||
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
|
||||
use multiplanar buffers. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. Use
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>. The next step is
|
||||
setting the value of &v4l2-selection; <structfield>target</structfield> to
|
||||
<constant>V4L2_SEL_TGT_CROP</constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
|
||||
targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
|
||||
<constant>V4L2_SEL_TGT_CROP</constant> (<constant>V4L2_SEL_TGT_COMPOSE</constant>).
|
||||
Please refer to table <xref linkend="v4l2-selections-common" /> or <xref linkend="selection-api" />
|
||||
for additional targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
|
||||
set to the desired active area. Field &v4l2-selection; <structfield> reserved
|
||||
</structfield> is ignored and must be filled with zeros. The driver may adjust
|
||||
coordinates of the requested rectangle. An application may
|
||||
@@ -149,8 +147,8 @@ On success the &v4l2-rect; <structfield>r</structfield> field contains
|
||||
the adjusted rectangle. When the parameters are unsuitable the application may
|
||||
modify the cropping (composing) or image parameters and repeat the cycle until
|
||||
satisfactory parameters have been negotiated. If constraints flags have to be
|
||||
violated at then ERANGE is returned. The error indicates that <emphasis> there
|
||||
exist no rectangle </emphasis> that satisfies the constraints.</para>
|
||||
violated at then ERANGE is returned. The error indicates that <emphasis>there
|
||||
exist no rectangle</emphasis> that satisfies the constraints.</para>
|
||||
|
||||
<para>Selection targets and flags are documented in <xref
|
||||
linkend="v4l2-selections-common"/>.</para>
|
||||
|
||||
@@ -300,6 +300,12 @@ modulator programming see
|
||||
<entry>0x00100000</entry>
|
||||
<entry>The device supports the
|
||||
<link linkend="sdr">SDR Capture</link> interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_EXT_PIX_FORMAT</constant></entry>
|
||||
<entry>0x00200000</entry>
|
||||
<entry>The device supports the &v4l2-pix-format; extended
|
||||
fields.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_READWRITE</constant></entry>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user