xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'linuxtv/vsp1' into HEAD

Browse Source
This commit is contained in:
Laurent Pinchart
2016-02-20 02:58:43 +02:00
parent d2eaa59000 18922936dc
commit 4c4400504f
319 changed files with 9337 additions and 3448 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
Documentation/DocBook/device-drivers.tmpl
View File

@@ -229,6 +229,7 @@ X!Isound/sound_firmware.c
!Iinclude/media/v4l2-dv-timings.h
!Iinclude/media/v4l2-event.h
!Iinclude/media/v4l2-flash-led-class.h
!Iinclude/media/v4l2-mc.h
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h

58
Documentation/DocBook/media/v4l/controls.xml
View File

@@ -2329,6 +2329,14 @@ to search and match for the present Macroblock (MB) in the reference picture. Th
vertical search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-force-key-frame">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME</constant>&nbsp;</entry>
<entry>button</entry>
</row><row><entry spanname="descr">Force a key frame for the next queued buffer. Applicable to encoders.
This is a general, codec-agnostic keyframe control.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
@@ -5069,6 +5077,46 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant></entry>
<entry id="v4l2-dv-content-type">enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Configures the IT Content Type
of the transmitted video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. The
enum&nbsp;v4l2_dv_it_content_type defines the possible content types:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GRAPHICS</constant>&nbsp;</entry>
<entry>Graphics content. Pixel data should be passed unfiltered and without
analog reconstruction.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_PHOTO</constant>&nbsp;</entry>
<entry>Photo content. The content is derived from digital still pictures.
The content should be passed through with minimal scaling and picture
enhancements.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_CINEMA</constant>&nbsp;</entry>
<entry>Cinema content.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant>&nbsp;</entry>
<entry>Game content. Audio and video latency should be minimized.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant>&nbsp;</entry>
<entry>No IT Content information is available and the ITC bit in the AVI
InfoFrame is set to 0.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
<entry>bitmask</entry>
@@ -5098,6 +5146,16 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_IT_CONTENT_TYPE</constant></entry>
<entry>enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Reads the IT Content Type
of the received video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. See
<constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant> for the available content types.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>

3
Documentation/DocBook/media/v4l/media-ioc-g-topology.xml
View File

@@ -48,9 +48,6 @@
<refsect1>
<title>Description</title>
<para><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para>
<para>The typical usage of this ioctl is to call it twice.
On the first call, the structure defined at &media-v2-topology; should
be zeroed. At return, if no errors happen, this ioctl will return the

33
Documentation/DocBook/media/v4l/media-types.xml
View File

@@ -56,10 +56,6 @@
<entry><constant>MEDIA_ENT_F_CONN_COMPOSITE</constant></entry>
<entry>Connector for a RGB composite signal.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_CONN_TEST</constant></entry>
<entry>Connector for a test generator.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_CAM_SENSOR</constant></entry>
<entry>Camera video sensor entity.</entry>
@@ -84,7 +80,34 @@
</row>
<row>
<entry><constant>MEDIA_ENT_F_TUNER</constant></entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner.</entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner,
with consists on a PLL tuning stage that converts radio
frequency (RF) signal into an Intermediate Frequency (IF).
Modern tuners have internally IF-PLL decoders for audio
and video, but older models have those stages implemented
on separate entities.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_VID_DECODER</constant></entry>
<entry>IF-PLL video decoder. It receives the IF from a PLL
and decodes the analog TV video signal. This is commonly
found on some very old analog tuners, like Philips MK3
designs. They all contain a tda9887 (or some software
compatible similar chip, like tda9885). Those devices
use a different I2C address than the tuner PLL.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_AUD_DECODER</constant></entry>
<entry>IF-PLL sound decoder. It receives the IF from a PLL
and decodes the analog TV audio signal. This is commonly
found on some very old analog hardware, like Micronas
msp3400, Philips tda9840, tda985x, etc. Those devices
use a different I2C address than the tuner PLL and
should be controlled together with the IF-PLL video
decoder.
</entry>
</row>
</tbody>
</tgroup>

26
Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml
View File

@@ -1,35 +1,43 @@
<refentry id="V4L2-PIX-FMT-YUV420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV420M"><constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU420M"><constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> and
<constant>V4L2_PIX_FMT_YVU420</constant> with planes non contiguous
in memory.</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub- images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cb data
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV420M</constant> the Cb data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cb belongs to four
pixels, a two-by-two square of the image. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
in the third plane.</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV420M</constant> and
<constant>V4L2_PIX_FMT_YVU420M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>

114
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml → Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml
View File

@@ -1,40 +1,45 @@
<refentry id="V4L2-PIX-FMT-YVU420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV422M"><constant>V4L2_PIX_FMT_YUV422M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU422M"><constant>V4L2_PIX_FMT_YVU422M</constant></refname>
<refpurpose>Planar formats with &frac12; horizontal resolution, also
known as YUV and YVU 4:2:2</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cr data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cr belongs to four
pixels, a two-by-two square of the image. For example,
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
the third plane. </para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV422M</constant> the Cb data
constitutes the second plane which is half the width of the Y plane (and of the
image). Each Cb belongs to two pixels. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cr
and Cb planes have half as many pad bytes after their rows. In other
<para><constant>V4L2_PIX_FMT_YVU422M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV422M</constant> and
<constant>V4L2_PIX_FMT_YVU422M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
<title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 &times; 4
pixel image</title>
<formalpara>
@@ -75,25 +80,45 @@ pixel image</title>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;6:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;6:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
@@ -113,36 +138,23 @@ pixel image</title>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
</tbody>
</tgroup>

177
Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml Normal file
View File

@@ -0,0 +1,177 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-YUV444M"><constant>V4L2_PIX_FMT_YUV444M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU444M"><constant>V4L2_PIX_FMT_YVU444M</constant></refname>
<refpurpose>Planar formats with full horizontal resolution, also
known as YUV and YVU 4:4:4</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.</para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV444M</constant> the Cb data
constitutes the second plane which is the same width and height as the Y plane
(and as the image). The Cr data, just like the Cb plane, is in the third plane.
</para>
<para><constant>V4L2_PIX_FMT_YVU444M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have the same number of pad bytes after their rows.</para>
<para><constant>V4L2_PIX_FMT_YUV444M</constant> and
<constant>V4L2_PIX_FMT_YUV444M</constant> are 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_YUV444M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cb<subscript>03</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cb<subscript>13</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cb<subscript>23</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cb<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
<entry>Cr<subscript>03</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
<entry>Cr<subscript>13</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;8:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
<entry>Cr<subscript>23</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;12:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
<entry>Cr<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>1</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>2</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>3</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

3
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@@ -1628,7 +1628,8 @@ information.</para>
&sub-y41p;
&sub-yuv420;
&sub-yuv420m;
&sub-yvu420m;
&sub-yuv422m;
&sub-yuv444m;
&sub-yuv410;
&sub-yuv422p;
&sub-yuv411p;

14
Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml
View File

@@ -60,9 +60,19 @@ input</refpurpose>
automatically, similar to sensing the video standard. To do so, applications
call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a
&v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the
timings structure.
timings structure.</para>
If the timings could not be detected because there was no signal, then
<para>Please note that drivers shall <emphasis>not</emphasis> switch timings automatically
if new timings are detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERY_DV_TIMINGS</constant>.
The reason is that new timings usually mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERY_DV_TIMINGS</constant>,
and if the detected timings are valid they will have to stop streaming, set the new
timings, allocate new buffers and start streaming again.</para>
<para>If the timings could not be detected because there was no signal, then
<errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but
it was unstable and the receiver could not lock to the signal, then
<errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal,

10
Documentation/DocBook/media/v4l/vidioc-querystd.xml
View File

@@ -59,6 +59,16 @@ then the driver will return V4L2_STD_UNKNOWN. When detection is not
possible or fails, the set must contain all standards supported by the
current video input or output.</para>
<para>Please note that drivers shall <emphasis>not</emphasis> switch the video standard
automatically if a new video standard is detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERYSTD</constant>.
The reason is that a new video standard can mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERYSTD</constant>,
and if the detected video standard is valid they will have to stop streaming, set the new
standard, allocate new buffers and start streaming again.</para>
</refsect1>
<refsect1>