Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
[linux/fpc-iii.git] / Documentation / media / uapi / v4l / vidioc-query-dv-timings.rst
blob0d16853b1b5170af347d6c3d24cc7c553f14b14a
1 .. -*- coding: utf-8; mode: rst -*-
3 .. _VIDIOC_QUERY_DV_TIMINGS:
5 *****************************
6 ioctl VIDIOC_QUERY_DV_TIMINGS
7 *****************************
9 Name
10 ====
12 VIDIOC_QUERY_DV_TIMINGS - VIDIOC_SUBDEV_QUERY_DV_TIMINGS - Sense the DV preset received by the current input
15 Synopsis
16 ========
18 .. c:function:: int ioctl( int fd, VIDIOC_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp )
19     :name: VIDIOC_QUERY_DV_TIMINGS
21 .. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp )
22     :name: VIDIOC_SUBDEV_QUERY_DV_TIMINGS
25 Arguments
26 =========
28 ``fd``
29     File descriptor returned by :ref:`open() <func-open>`.
31 ``argp``
34 Description
35 ===========
37 The hardware may be able to detect the current DV timings automatically,
38 similar to sensing the video standard. To do so, applications call
39 :ref:`VIDIOC_QUERY_DV_TIMINGS` with a pointer to a struct
40 :c:type:`v4l2_dv_timings`. Once the hardware detects
41 the timings, it will fill in the timings structure.
43 .. note::
45    Drivers shall *not* switch timings automatically if new
46    timings are detected. Instead, drivers should send the
47    ``V4L2_EVENT_SOURCE_CHANGE`` event (if they support this) and expect
48    that userspace will take action by calling :ref:`VIDIOC_QUERY_DV_TIMINGS`.
49    The reason is that new timings usually mean different buffer sizes as
50    well, and you cannot change buffer sizes on the fly. In general,
51    applications that receive the Source Change event will have to call
52    :ref:`VIDIOC_QUERY_DV_TIMINGS`, and if the detected timings are valid they
53    will have to stop streaming, set the new timings, allocate new buffers
54    and start streaming again.
56 If the timings could not be detected because there was no signal, then
57 ENOLINK is returned. If a signal was detected, but it was unstable and
58 the receiver could not lock to the signal, then ``ENOLCK`` is returned. If
59 the receiver could lock to the signal, but the format is unsupported
60 (e.g. because the pixelclock is out of range of the hardware
61 capabilities), then the driver fills in whatever timings it could find
62 and returns ``ERANGE``. In that case the application can call
63 :ref:`VIDIOC_DV_TIMINGS_CAP` to compare the
64 found timings with the hardware's capabilities in order to give more
65 precise feedback to the user.
68 Return Value
69 ============
71 On success 0 is returned, on error -1 and the ``errno`` variable is set
72 appropriately. The generic error codes are described at the
73 :ref:`Generic Error Codes <gen-errors>` chapter.
75 ENODATA
76     Digital video timings are not supported for this input or output.
78 ENOLINK
79     No timings could be detected because no signal was found.
81 ENOLCK
82     The signal was unstable and the hardware could not lock on to it.
84 ERANGE
85     Timings were found, but they are out of range of the hardware
86     capabilities.