|
@@ -60,9 +60,19 @@ input</refpurpose>
|
|
automatically, similar to sensing the video standard. To do so, applications
|
|
automatically, similar to sensing the video standard. To do so, applications
|
|
call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a
|
|
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
|
|
&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
|
|
<errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but
|
|
it was unstable and the receiver could not lock to the signal, then
|
|
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,
|
|
<errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal,
|