mirror of
https://github.com/t2linux/kernel.git
synced 2026-04-30 13:48:59 -07:00
Merge branch 'patchwork' into v4l_for_linus
* patchwork: (404 commits) [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL [media] uvcvideo: fix cropcap v4l2-compliance failure [media] media: omap3isp: remove unused clkdev [media] coda: Add tracing support [media] coda: drop dma_sync_single_for_device in coda_bitstream_queue [media] coda: fix fill bitstream errors in nonstreaming case [media] coda: call SEQ_END when the first queue is stopped [media] coda: fail to start streaming if userspace set invalid formats [media] coda: remove duplicate error messages for buffer allocations [media] coda: move parameter buffer in together with context buffer allocation [media] coda: allocate bitstream buffer from REQBUFS, size depends on the format [media] coda: allocate per-context buffers from REQBUFS [media] coda: use strlcpy instead of snprintf [media] coda: bitstream payload is unsigned [media] coda: fix double call to debugfs_remove [media] coda: check kasprintf return value in coda_open [media] coda: bitrate can only be set in kbps steps [media] v4l2-mem2mem: no need to initialize b in v4l2_m2m_next_buf and v4l2_m2m_buf_remove [media] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init [media] coda: set allow_zero_bytesused flag for vb2_queue_init ...
This commit is contained in:
Mauro Carvalho Chehab
@@ -1,14 +1,13 @@
|
||||
<bibliography>
|
||||
<title>References</title>
|
||||
|
||||
<biblioentry id="eia608">
|
||||
<abbrev>EIA 608-B</abbrev>
|
||||
<biblioentry id="cea608">
|
||||
<abbrev>CEA 608-E</abbrev>
|
||||
<authorgroup>
|
||||
<corpauthor>Electronic Industries Alliance (<ulink
|
||||
url="http://www.eia.org">http://www.eia.org</ulink>)</corpauthor>
|
||||
<corpauthor>Consumer Electronics Association (<ulink
|
||||
url="http://www.ce.org">http://www.ce.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>EIA 608-B "Recommended Practice for Line 21 Data
|
||||
Service"</title>
|
||||
<title>CEA-608-E R-2014 "Line 21 Data Services"</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="en300294">
|
||||
|
||||
@@ -2491,7 +2491,7 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
|
||||
changes flag. See <xref linkend="changes-flags"/>.</para>
|
||||
changes flag. See <xref linkend="ctrl-changes-flags"/>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
@@ -254,7 +254,7 @@ ETS 300 231, lsb first transmitted.</entry>
|
||||
<row>
|
||||
<entry><constant>V4L2_SLICED_CAPTION_525</constant></entry>
|
||||
<entry>0x1000</entry>
|
||||
<entry><xref linkend="eia608" /></entry>
|
||||
<entry><xref linkend="cea608" /></entry>
|
||||
<entry>NTSC line 21, 284 (second field 21)</entry>
|
||||
<entry>Two bytes in transmission order, including parity
|
||||
bit, lsb first transmitted.</entry>
|
||||
|
||||
@@ -143,86 +143,28 @@
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>v4l</structfield></entry>
|
||||
<entry><structfield>dev</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for V4L sub-devices and nodes only.</entry>
|
||||
<entry>Valid for (sub-)devices that create a single device node.</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>
|
||||
<entry>Device node major number.</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>
|
||||
<entry>Device node minor number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw</structfield>[180]</entry>
|
||||
<entry><structfield>raw</structfield>[184]</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
@@ -253,8 +195,24 @@
|
||||
<entry>ALSA card</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry>
|
||||
<entry>DVB card</entry>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
|
||||
<entry>DVB frontend devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
|
||||
<entry>DVB demux devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
|
||||
<entry>DVB DVR devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
|
||||
<entry>DVB CAM devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
|
||||
<entry>DVB network devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
|
||||
@@ -282,6 +240,10 @@
|
||||
it in some digital video standard, with appropriate embedded timing
|
||||
signals.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
|
||||
<entry>TV and/or radio tuner</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
@@ -303,45 +303,6 @@ for a pixel lie next to each other in memory.</para>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR24">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
|
||||
<entry>'BGR3'</entry>
|
||||
@@ -404,6 +365,46 @@ for a pixel lie next to each other in memory.</para>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-ABGR32">
|
||||
<entry><constant>V4L2_PIX_FMT_ABGR32</constant></entry>
|
||||
<entry>'AR24'</entry>
|
||||
|
||||
@@ -38,10 +38,10 @@ columns and rows.</para>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 4:</entry>
|
||||
<entry>R<subscript>10</subscript></entry>
|
||||
<entry>B<subscript>11</subscript></entry>
|
||||
<entry>R<subscript>12</subscript></entry>
|
||||
<entry>B<subscript>13</subscript></entry>
|
||||
<entry>B<subscript>10</subscript></entry>
|
||||
<entry>G<subscript>11</subscript></entry>
|
||||
<entry>B<subscript>12</subscript></entry>
|
||||
<entry>G<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
@@ -52,10 +52,10 @@ columns and rows.</para>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 12:</entry>
|
||||
<entry>R<subscript>30</subscript></entry>
|
||||
<entry>B<subscript>31</subscript></entry>
|
||||
<entry>R<subscript>32</subscript></entry>
|
||||
<entry>B<subscript>33</subscript></entry>
|
||||
<entry>B<subscript>30</subscript></entry>
|
||||
<entry>G<subscript>31</subscript></entry>
|
||||
<entry>B<subscript>32</subscript></entry>
|
||||
<entry>G<subscript>33</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="topbot" colsep="1" rowsep="1">
|
||||
<tgroup cols="5" align="center" border="1">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
|
||||
@@ -29,12 +29,12 @@ 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
|
||||
<para><constant>V4L2_PIX_FMT_YUV420M</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 × 4
|
||||
<title><constant>V4L2_PIX_FMT_YUV420M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
|
||||
@@ -80,9 +80,9 @@ padding bytes after the last line of an image cross a system page
|
||||
boundary. Input devices may write padding bytes, the value is
|
||||
undefined. Output devices ignore the contents of padding
|
||||
bytes.</para><para>When the image format is planar the
|
||||
<structfield>bytesperline</structfield> value applies to the largest
|
||||
<structfield>bytesperline</structfield> value applies to the first
|
||||
plane and is divided by the same factor as the
|
||||
<structfield>width</structfield> field for any smaller planes. For
|
||||
<structfield>width</structfield> field for the other planes. For
|
||||
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
|
||||
padding bytes following each line as the Y plane. To avoid ambiguities
|
||||
drivers must return a <structfield>bytesperline</structfield> value
|
||||
@@ -182,14 +182,14 @@ see <xref linkend="colorspaces" />.</entry>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>bytesperline</structfield></entry>
|
||||
<entry>Distance in bytes between the leftmost pixels in two adjacent
|
||||
lines. See &v4l2-pix-format;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>reserved[7]</structfield></entry>
|
||||
<entry><structfield>reserved[6]</structfield></entry>
|
||||
<entry>Reserved for future extensions. Should be zeroed by the
|
||||
application.</entry>
|
||||
</row>
|
||||
@@ -483,8 +483,8 @@ is the Y'CbCr encoding identifier (&v4l2-ycbcr-encoding;) to specify non-standar
|
||||
Y'CbCr encodings and the third is the quantization identifier (&v4l2-quantization;)
|
||||
to specify non-standard quantization methods. Most of the time only the colorspace
|
||||
field of &v4l2-pix-format; or &v4l2-pix-format-mplane; needs to be filled in. Note
|
||||
that the default R'G'B' quantization is always full range for all colorspaces,
|
||||
so this won't be mentioned explicitly for each colorspace description.</para>
|
||||
that the default R'G'B' quantization is full range for all colorspaces except for
|
||||
BT.2020 which uses limited range R'G'B' quantization.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-colorspace">
|
||||
<title>V4L2 Colorspaces</title>
|
||||
@@ -598,7 +598,8 @@ so this won't be mentioned explicitly for each colorspace description.</para>
|
||||
<row>
|
||||
<entry><constant>V4L2_QUANTIZATION_DEFAULT</constant></entry>
|
||||
<entry>Use the default quantization encoding as defined by the colorspace.
|
||||
This is always full range for R'G'B' and usually limited range for Y'CbCr.</entry>
|
||||
This is always full range for R'G'B' (except for the BT.2020 colorspace) and usually
|
||||
limited range for Y'CbCr.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_QUANTIZATION_FULL_RANGE</constant></entry>
|
||||
@@ -620,8 +621,8 @@ is mapped to [16…235]. Cb and Cr are mapped from [-0.5…0.5] to [16
|
||||
|
||||
<section>
|
||||
<title>Detailed Colorspace Descriptions</title>
|
||||
<section>
|
||||
<title id="col-smpte-170m">Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
|
||||
<section id="col-smpte-170m">
|
||||
<title>Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
|
||||
<para>The <xref linkend="smpte170m" /> standard defines the colorspace used by NTSC and PAL and by SDTV
|
||||
in general. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
|
||||
@@ -666,8 +667,7 @@ as the SMPTE C set, so this colorspace is sometimes called SMPTE C as well.</par
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The transfer function defined for SMPTE 170M is the same as the
|
||||
one defined in Rec. 709. Normally L is in the range [0…1], but for the extended
|
||||
gamut xvYCC encoding values outside that range are allowed.</term>
|
||||
one defined in Rec. 709.</term>
|
||||
<listitem>
|
||||
<para>L' = -1.099(-L)<superscript>0.45</superscript> + 0.099 for L ≤ -0.018</para>
|
||||
<para>L' = 4.5L for -0.018 < L < 0.018</para>
|
||||
@@ -702,29 +702,10 @@ defined in the <xref linkend="itu601" /> standard and this colorspace is sometim
|
||||
though BT.601 does not mention any color primaries.</para>
|
||||
<para>The default quantization is limited range, but full range is possible although
|
||||
rarely seen.</para>
|
||||
<para>The <constant>V4L2_YCBCR_ENC_601</constant> encoding as described above is the
|
||||
default for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_709</constant>,
|
||||
in which case the Rec. 709 Y'CbCr encoding is used.</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
|
||||
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 255) * (0.299R' + 0.587G' + 0.114B') + (16 / 255)</para>
|
||||
<para>Cb = (224 / 255) * (-0.169R' - 0.331G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 255) * (0.5R' - 0.419G' - 0.081B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>Y' is clamped to the range [0…1] and Cb and Cr are clamped
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 709 encoding can also be used by selecting
|
||||
<constant>V4L2_YCBCR_ENC_XV709</constant>. The xvYCC encodings always use full range
|
||||
quantization.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-rec709">Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
|
||||
<section id="col-rec709">
|
||||
<title>Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
|
||||
<para>The <xref linkend="itu709" /> standard defines the colorspace used by HDTV in general. The default
|
||||
Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_709</constant>. The default Y'CbCr quantization is
|
||||
limited range. The chromaticities of the primary colors and the white reference are:</para>
|
||||
@@ -803,26 +784,39 @@ rarely seen.</para>
|
||||
<para>The <constant>V4L2_YCBCR_ENC_709</constant> encoding described above is the default
|
||||
for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_601</constant>, in which
|
||||
case the BT.601 Y'CbCr encoding is used.</para>
|
||||
<para>Two additional extended gamut Y'CbCr encodings are also possible with this colorspace:</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 709 encoding (<constant>V4L2_YCBCR_ENC_XV709</constant>, <xref linkend="xvycc" />)
|
||||
is similar to the Rec. 709 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 255) * (0.2126R' + 0.7152G' + 0.0722B') + (16 / 255)</para>
|
||||
<para>Cb = (224 / 255) * (-0.1146R' - 0.3854G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 255) * (0.5R' - 0.4542G' - 0.0458B')</para>
|
||||
<para>Y' = (219 / 256) * (0.2126R' + 0.7152G' + 0.0722B') + (16 / 256)</para>
|
||||
<para>Cb = (224 / 256) * (-0.1146R' - 0.3854G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 256) * (0.5R' - 0.4542G' - 0.0458B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
|
||||
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 256) * (0.299R' + 0.587G' + 0.114B') + (16 / 256)</para>
|
||||
<para>Cb = (224 / 256) * (-0.169R' - 0.331G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 256) * (0.5R' - 0.419G' - 0.081B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>Y' is clamped to the range [0…1] and Cb and Cr are clamped
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 601 encoding can also be used by
|
||||
selecting <constant>V4L2_YCBCR_ENC_XV601</constant>. The xvYCC encodings always use full
|
||||
range quantization.</para>
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 709 or xvYCC 601 encodings can be used by
|
||||
selecting <constant>V4L2_YCBCR_ENC_XV709</constant> or <constant>V4L2_YCBCR_ENC_XV601</constant>.
|
||||
The xvYCC encodings always use full range quantization.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-srgb">Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
|
||||
<section id="col-srgb">
|
||||
<title>Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
|
||||
<para>The <xref linkend="srgb" /> standard defines the colorspace used by most webcams and computer graphics. The
|
||||
default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SYCC</constant>. The default Y'CbCr quantization
|
||||
is full range. The chromaticities of the primary colors and the white reference are:</para>
|
||||
@@ -898,8 +892,8 @@ encoding, it is not. The <constant>V4L2_YCBCR_ENC_XV601</constant> scales and of
|
||||
values before quantization, but this encoding does not do that.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-adobergb">Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
|
||||
<section id="col-adobergb">
|
||||
<title>Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
|
||||
<para>The <xref linkend="adobergb" /> standard defines the colorspace used by computer graphics
|
||||
that use the AdobeRGB colorspace. This is also known as the <xref linkend="oprgb" /> standard.
|
||||
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr
|
||||
@@ -970,12 +964,12 @@ clamped to the range [-0.5…0.5]. This transform is identical to one defin
|
||||
SMPTE 170M/BT.601. The Y'CbCr quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-bt2020">Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
|
||||
<section id="col-bt2020">
|
||||
<title>Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
|
||||
<para>The <xref linkend="itu2020" /> standard defines the colorspace used by Ultra-high definition
|
||||
television (UHDTV). The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_BT2020</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
|
||||
the white reference are:</para>
|
||||
The default R'G'B' quantization is limited range (!), and so is the default Y'CbCr quantization.
|
||||
The chromaticities of the primary colors and the white reference are:</para>
|
||||
<table frame="none">
|
||||
<title>BT.2020 Chromaticities</title>
|
||||
<tgroup cols="3" align="left">
|
||||
@@ -1032,7 +1026,7 @@ the white reference are:</para>
|
||||
<term>The luminance (Y') and color difference (Cb and Cr) are obtained with the
|
||||
following <constant>V4L2_YCBCR_ENC_BT2020</constant> encoding:</term>
|
||||
<listitem>
|
||||
<para>Y' = 0.2627R' + 0.6789G' + 0.0593B'</para>
|
||||
<para>Y' = 0.2627R' + 0.6780G' + 0.0593B'</para>
|
||||
<para>Cb = -0.1396R' - 0.3604G' + 0.5B'</para>
|
||||
<para>Cr = 0.5R' - 0.4598G' - 0.0402B'</para>
|
||||
</listitem>
|
||||
@@ -1046,7 +1040,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
<varlistentry>
|
||||
<term>Luma:</term>
|
||||
<listitem>
|
||||
<para>Yc' = (0.2627R + 0.6789G + 0.0593B)'</para>
|
||||
<para>Yc' = (0.2627R + 0.6780G + 0.0593B)'</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@@ -1054,7 +1048,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
<varlistentry>
|
||||
<term>B' - Yc' ≤ 0:</term>
|
||||
<listitem>
|
||||
<para>Cbc = (B' - Y') / 1.9404</para>
|
||||
<para>Cbc = (B' - Yc') / 1.9404</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@@ -1062,7 +1056,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
<varlistentry>
|
||||
<term>B' - Yc' > 0:</term>
|
||||
<listitem>
|
||||
<para>Cbc = (B' - Y') / 1.5816</para>
|
||||
<para>Cbc = (B' - Yc') / 1.5816</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@@ -1086,8 +1080,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
clamped to the range [-0.5…0.5]. The Yc'CbcCrc quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-smpte-240m">Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
|
||||
<section id="col-smpte-240m">
|
||||
<title>Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
|
||||
<para>The <xref linkend="smpte240m" /> standard was an interim standard used during the early days of HDTV (1988-1998).
|
||||
It has been superseded by Rec. 709. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SMPTE240M</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and the
|
||||
@@ -1159,8 +1153,8 @@ following <constant>V4L2_YCBCR_ENC_SMPTE240M</constant> encoding:</term>
|
||||
clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-sysm">Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
|
||||
<section id="col-sysm">
|
||||
<title>Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
|
||||
<para>This standard defines the colorspace used by NTSC in 1953. In practice this
|
||||
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
|
||||
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
|
||||
@@ -1237,8 +1231,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-sysbg">Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
|
||||
<section id="col-sysbg">
|
||||
<title>Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
|
||||
<para>The <xref linkend="tech3213" /> standard defines the colorspace used by PAL/SECAM in 1975. In practice this
|
||||
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
|
||||
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
|
||||
@@ -1311,8 +1305,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
||||
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-jpeg">Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
|
||||
<section id="col-jpeg">
|
||||
<title>Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
|
||||
<para>This colorspace defines the colorspace used by most (Motion-)JPEG formats. The chromaticities
|
||||
of the primary colors and the white reference are identical to sRGB. The Y'CbCr encoding is
|
||||
<constant>V4L2_YCBCR_ENC_601</constant> with full range quantization where
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -136,6 +136,7 @@ Remote Controller chapter.</contrib>
|
||||
<year>2012</year>
|
||||
<year>2013</year>
|
||||
<year>2014</year>
|
||||
<year>2015</year>
|
||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
|
||||
Pawel Osciak</holder>
|
||||
@@ -151,6 +152,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.21</revnumber>
|
||||
<date>2015-02-13</date>
|
||||
<authorinitials>mcc</authorinitials>
|
||||
<revremark>Fix documentation for media controller device nodes and add support for DVB device nodes.
|
||||
Add support for Tuner sub-device.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>3.19</revnumber>
|
||||
<date>2014-12-05</date>
|
||||
|
||||
@@ -59,6 +59,11 @@ constant except when switching the video standard. Remember this
|
||||
switch can occur implicit when switching the video input or
|
||||
output.</para>
|
||||
|
||||
<para>Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
|
||||
and use <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>.</para>
|
||||
|
||||
<para>This ioctl must be implemented for video capture or output devices that
|
||||
support cropping and/or scaling and/or have non-square pixels, and for overlay devices.</para>
|
||||
|
||||
@@ -73,9 +78,7 @@ support cropping and/or scaling and/or have non-square pixels, and for overlay d
|
||||
<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> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
||||
@@ -64,7 +64,7 @@
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Type of the event.</entry>
|
||||
<entry>Type of the event, see <xref linkend="event-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
@@ -154,6 +154,113 @@
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="event-type">
|
||||
<title>Event Types</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_ALL</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>All events. V4L2_EVENT_ALL is valid only for
|
||||
VIDIOC_UNSUBSCRIBE_EVENT for unsubscribing all events at once.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_VSYNC</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>This event is triggered on the vertical sync.
|
||||
This event has a &v4l2-event-vsync; associated with it.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_EOS</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>This event is triggered when the end of a stream is reached.
|
||||
This is typically used with MPEG decoders to report to the application
|
||||
when the last of the MPEG stream has been decoded.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry><para>This event requires that the <structfield>id</structfield>
|
||||
matches the control ID from which you want to receive events.
|
||||
This event is triggered if the control's value changes, if a
|
||||
button control is pressed or if the control's flags change.
|
||||
This event has a &v4l2-event-ctrl; associated with it. This struct
|
||||
contains much of the same information as &v4l2-queryctrl; and
|
||||
&v4l2-control;.</para>
|
||||
|
||||
<para>If the event is generated due to a call to &VIDIOC-S-CTRL; or
|
||||
&VIDIOC-S-EXT-CTRLS;, then the event will <emphasis>not</emphasis> be sent to
|
||||
the file handle that called the ioctl function. This prevents
|
||||
nasty feedback loops. If you <emphasis>do</emphasis> want to get the
|
||||
event, then set the <constant>V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK</constant>
|
||||
flag.
|
||||
</para>
|
||||
|
||||
<para>This event type will ensure that no information is lost when
|
||||
more events are raised than there is room internally. In that
|
||||
case the &v4l2-event-ctrl; of the second-oldest event is kept,
|
||||
but the <structfield>changes</structfield> field of the
|
||||
second-oldest event is ORed with the <structfield>changes</structfield>
|
||||
field of the oldest event.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
|
||||
<entry>4</entry>
|
||||
<entry>
|
||||
<para>Triggered immediately when the reception of a
|
||||
frame has begun. This event has a
|
||||
&v4l2-event-frame-sync; associated with it.</para>
|
||||
|
||||
<para>If the hardware needs to be stopped in the case of a
|
||||
buffer underrun it might not be able to generate this event.
|
||||
In such cases the <structfield>frame_sequence</structfield>
|
||||
field in &v4l2-event-frame-sync; will not be incremented. This
|
||||
causes two consecutive frame sequence numbers to have n times
|
||||
frame interval in between them.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_SOURCE_CHANGE</constant></entry>
|
||||
<entry>5</entry>
|
||||
<entry>
|
||||
<para>This event is triggered when a source parameter change is
|
||||
detected during runtime by the video device. It can be a
|
||||
runtime resolution change triggered by a video decoder or the
|
||||
format change happening on an input connector.
|
||||
This event requires that the <structfield>id</structfield>
|
||||
matches the input index (when used with a video device node)
|
||||
or the pad index (when used with a subdevice node) from which
|
||||
you want to receive events.</para>
|
||||
|
||||
<para>This event has a &v4l2-event-src-change; associated
|
||||
with it. The <structfield>changes</structfield> bitfield denotes
|
||||
what has changed for the subscribed pad. If multiple events
|
||||
occurred before application could dequeue them, then the changes
|
||||
will have the ORed value of all the events generated.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_MOTION_DET</constant></entry>
|
||||
<entry>6</entry>
|
||||
<entry>
|
||||
<para>Triggered whenever the motion detection state for one or more of the regions
|
||||
changes. This event has a &v4l2-event-motion-det; associated with it.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
|
||||
<entry>0x08000000</entry>
|
||||
<entry>Base event number for driver-private events.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-vsync">
|
||||
<title>struct <structname>v4l2_event_vsync</structname></title>
|
||||
<tgroup cols="3">
|
||||
@@ -177,7 +284,7 @@
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>changes</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>A bitmask that tells what has changed. See <xref linkend="changes-flags" />.</entry>
|
||||
<entry>A bitmask that tells what has changed. See <xref linkend="ctrl-changes-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
@@ -309,8 +416,8 @@
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="changes-flags">
|
||||
<title>Changes</title>
|
||||
<table pgwide="1" frame="none" id="ctrl-changes-flags">
|
||||
<title>Control Changes</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
@@ -318,9 +425,9 @@
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_VALUE</constant></entry>
|
||||
<entry>0x0001</entry>
|
||||
<entry>This control event was triggered because the value of the control
|
||||
changed. Special case: if a button control is pressed, then this
|
||||
event is sent as well, even though there is not explicit value
|
||||
associated with a button control.</entry>
|
||||
changed. Special cases: Volatile controls do no generate this event;
|
||||
If a control has the <constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant>
|
||||
flag set, then this event is sent as well, regardless its value.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_FLAGS</constant></entry>
|
||||
|
||||
@@ -70,6 +70,11 @@ structure or returns the &EINVAL; if cropping is not supported.</para>
|
||||
<constant>VIDIOC_S_CROP</constant> ioctl with a pointer to this
|
||||
structure.</para>
|
||||
|
||||
<para>Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
|
||||
and use <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>.</para>
|
||||
|
||||
<para>The driver first adjusts the requested dimensions against
|
||||
hardware limits, &ie; the bounds given by the capture/output window,
|
||||
and it rounds to the closest possible values of horizontal and
|
||||
|
||||
@@ -318,10 +318,20 @@ can't generate such frequencies, then the flag will also be cleared.
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_DV_FL_HALF_LINE</entry>
|
||||
<entry>Specific to interlaced formats: if set, then field 1 (aka the odd field)
|
||||
is really one half-line longer and field 2 (aka the even field) is really one half-line
|
||||
shorter, so each field has exactly the same number of half-lines. Whether half-lines can be
|
||||
detected or used depends on the hardware.
|
||||
<entry>Specific to interlaced formats: if set, then the vertical frontporch
|
||||
of field 1 (aka the odd field) is really one half-line longer and the vertical backporch
|
||||
of field 2 (aka the even field) is really one half-line shorter, so each field has exactly
|
||||
the same number of half-lines. Whether half-lines can be detected or used depends on
|
||||
the hardware.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_DV_FL_IS_CE_VIDEO</entry>
|
||||
<entry>If set, then this is a Consumer Electronics (CE) video format.
|
||||
Such formats differ from other formats (commonly called IT formats) in that if
|
||||
R'G'B' encoding is used then by default the R'G'B' values use limited range
|
||||
(i.e. 16-235) as opposed to full range (i.e. 0-255). All formats defined in CEA-861
|
||||
except for the 640x480p59.94 format are CE formats.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
||||
@@ -240,9 +240,9 @@ where padding bytes after the last line of an image cross a system
|
||||
page boundary. Capture devices may write padding bytes, the value is
|
||||
undefined. Output devices ignore the contents of padding
|
||||
bytes.</para><para>When the image format is planar the
|
||||
<structfield>bytesperline</structfield> value applies to the largest
|
||||
<structfield>bytesperline</structfield> value applies to the first
|
||||
plane and is divided by the same factor as the
|
||||
<structfield>width</structfield> field for any smaller planes. For
|
||||
<structfield>width</structfield> field for the other planes. For
|
||||
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
|
||||
padding bytes following each line as the Y plane. To avoid ambiguities
|
||||
drivers must return a <structfield>bytesperline</structfield> value
|
||||
|
||||
@@ -60,8 +60,8 @@
|
||||
|
||||
<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
|
||||
Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and 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
|
||||
|
||||
@@ -205,7 +205,7 @@ ETS 300 231, lsb first transmitted.</entry>
|
||||
<row>
|
||||
<entry><constant>V4L2_SLICED_CAPTION_525</constant></entry>
|
||||
<entry>0x1000</entry>
|
||||
<entry><xref linkend="eia608" /></entry>
|
||||
<entry><xref linkend="cea608" /></entry>
|
||||
<entry>NTSC line 21, 284 (second field 21)</entry>
|
||||
<entry>Two bytes in transmission order, including parity
|
||||
bit, lsb first transmitted.</entry>
|
||||
|
||||
@@ -102,10 +102,10 @@ The bus_info must start with "PCI:" for PCI boards, "PCIe:" for PCI Express boar
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>version</structfield></entry>
|
||||
<entry><para>Version number of the driver.</para>
|
||||
<para>Starting on kernel 3.1, the version reported is provided per
|
||||
V4L2 subsystem, following the same Kernel numberation scheme. However, it
|
||||
should not always return the same version as the kernel, if, for example,
|
||||
an stable or distribution-modified kernel uses the V4L2 stack from a
|
||||
<para>Starting with kernel 3.1, the version reported is provided by the
|
||||
V4L2 subsystem following the kernel numbering scheme. However, it
|
||||
may not always return the same version as the kernel if, for example,
|
||||
a stable or distribution-modified kernel uses the V4L2 stack from a
|
||||
newer kernel.</para>
|
||||
<para>The version number is formatted using the
|
||||
<constant>KERNEL_VERSION()</constant> macro:</para></entry>
|
||||
|
||||
@@ -600,7 +600,9 @@ writing a value will cause the device to carry out a given action
|
||||
changes continuously. A typical example would be the current gain value if the device
|
||||
is in auto-gain mode. In such a case the hardware calculates the gain value based on
|
||||
the lighting conditions which can change over time. Note that setting a new value for
|
||||
a volatile control will have no effect. The new value will just be ignored.</entry>
|
||||
a volatile control will have no effect and no <constant>V4L2_EVENT_CTRL_CH_VALUE</constant>
|
||||
will be sent, unless the <constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant> flag
|
||||
(see below) is also set. Otherwise the new value will just be ignored.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant></entry>
|
||||
@@ -610,6 +612,14 @@ using one of the pointer fields of &v4l2-ext-control;. This flag is set for cont
|
||||
that are an array, string, or have a compound type. In all cases you have to set a
|
||||
pointer to memory containing the payload of the control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant></entry>
|
||||
<entry>0x0200</entry>
|
||||
<entry>The value provided to the control will be propagated to the driver
|
||||
even if remains constant. This is required when the control represents an action
|
||||
on the hardware. For example: clearing an error flag or triggering the flash. All the
|
||||
controls of the type <constant>V4L2_CTRL_TYPE_BUTTON</constant> have this flag set.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user