Commit | Line | Data |
---|---|---|
5377d91f MH |
1 | .. -*- coding: utf-8; mode: rst -*- |
2 | ||
af4a4d0d | 3 | .. _VIDIOC_QUERY_DV_TIMINGS: |
5377d91f MH |
4 | |
5 | ***************************** | |
6 | ioctl VIDIOC_QUERY_DV_TIMINGS | |
7 | ***************************** | |
8 | ||
15e7d615 | 9 | Name |
586027ce | 10 | ==== |
5377d91f | 11 | |
586027ce | 12 | VIDIOC_QUERY_DV_TIMINGS - VIDIOC_SUBDEV_QUERY_DV_TIMINGS - Sense the DV preset received by the current input |
5377d91f | 13 | |
15e7d615 MCC |
14 | |
15 | Synopsis | |
5377d91f MH |
16 | ======== |
17 | ||
41d80465 MCC |
18 | .. c:function:: int ioctl( int fd, VIDIOC_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp ) |
19 | :name: VIDIOC_QUERY_DV_TIMINGS | |
20 | ||
21 | .. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp ) | |
22 | :name: VIDIOC_SUBDEV_QUERY_DV_TIMINGS | |
5377d91f | 23 | |
586027ce | 24 | |
15e7d615 | 25 | Arguments |
5377d91f MH |
26 | ========= |
27 | ||
28 | ``fd`` | |
29 | File descriptor returned by :ref:`open() <func-open>`. | |
30 | ||
5377d91f MH |
31 | ``argp`` |
32 | ||
33 | ||
15e7d615 | 34 | Description |
5377d91f MH |
35 | =========== |
36 | ||
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 | |
2212ff25 | 39 | :ref:`VIDIOC_QUERY_DV_TIMINGS` with a pointer to a struct |
e8be7e97 | 40 | :c:type:`v4l2_dv_timings`. Once the hardware detects |
5377d91f MH |
41 | the timings, it will fill in the timings structure. |
42 | ||
b6b6e678 MCC |
43 | .. note:: |
44 | ||
45 | Drivers shall *not* switch timings automatically if new | |
706f8a99 MCC |
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. | |
5377d91f MH |
55 | |
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 | |
cdb4af0f | 58 | the receiver could not lock to the signal, then ``ENOLCK`` is returned. If |
5377d91f MH |
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 | |
cdb4af0f | 62 | and returns ``ERANGE``. In that case the application can call |
7347081e | 63 | :ref:`VIDIOC_DV_TIMINGS_CAP` to compare the |
5377d91f MH |
64 | found timings with the hardware's capabilities in order to give more |
65 | precise feedback to the user. | |
66 | ||
67 | ||
15e7d615 | 68 | Return Value |
5377d91f MH |
69 | ============ |
70 | ||
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. | |
74 | ||
75 | ENODATA | |
76 | Digital video timings are not supported for this input or output. | |
77 | ||
78 | ENOLINK | |
79 | No timings could be detected because no signal was found. | |
80 | ||
81 | ENOLCK | |
82 | The signal was unstable and the hardware could not lock on to it. | |
83 | ||
84 | ERANGE | |
85 | Timings were found, but they are out of range of the hardware | |
86 | capabilities. |