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 | ||
b7e67f6c | 18 | .. cpp:function:: int ioctl( int fd, int request, struct v4l2_dv_timings *argp ) |
5377d91f | 19 | |
586027ce | 20 | |
15e7d615 | 21 | Arguments |
5377d91f MH |
22 | ========= |
23 | ||
24 | ``fd`` | |
25 | File descriptor returned by :ref:`open() <func-open>`. | |
26 | ||
27 | ``request`` | |
28 | VIDIOC_QUERY_DV_TIMINGS, VIDIOC_SUBDEV_QUERY_DV_TIMINGS | |
29 | ||
30 | ``argp`` | |
31 | ||
32 | ||
15e7d615 | 33 | Description |
5377d91f MH |
34 | =========== |
35 | ||
36 | The hardware may be able to detect the current DV timings automatically, | |
37 | similar to sensing the video standard. To do so, applications call | |
2212ff25 | 38 | :ref:`VIDIOC_QUERY_DV_TIMINGS` with a pointer to a struct |
5377d91f MH |
39 | :ref:`v4l2_dv_timings <v4l2-dv-timings>`. Once the hardware detects |
40 | the timings, it will fill in the timings structure. | |
41 | ||
706f8a99 MCC |
42 | .. note:: Drivers shall *not* switch timings automatically if new |
43 | timings are detected. Instead, drivers should send the | |
44 | ``V4L2_EVENT_SOURCE_CHANGE`` event (if they support this) and expect | |
45 | that userspace will take action by calling :ref:`VIDIOC_QUERY_DV_TIMINGS`. | |
46 | The reason is that new timings usually mean different buffer sizes as | |
47 | well, and you cannot change buffer sizes on the fly. In general, | |
48 | applications that receive the Source Change event will have to call | |
49 | :ref:`VIDIOC_QUERY_DV_TIMINGS`, and if the detected timings are valid they | |
50 | will have to stop streaming, set the new timings, allocate new buffers | |
51 | and start streaming again. | |
5377d91f MH |
52 | |
53 | If the timings could not be detected because there was no signal, then | |
54 | ENOLINK is returned. If a signal was detected, but it was unstable and | |
cdb4af0f | 55 | the receiver could not lock to the signal, then ``ENOLCK`` is returned. If |
5377d91f MH |
56 | the receiver could lock to the signal, but the format is unsupported |
57 | (e.g. because the pixelclock is out of range of the hardware | |
58 | capabilities), then the driver fills in whatever timings it could find | |
cdb4af0f | 59 | and returns ``ERANGE``. In that case the application can call |
7347081e | 60 | :ref:`VIDIOC_DV_TIMINGS_CAP` to compare the |
5377d91f MH |
61 | found timings with the hardware's capabilities in order to give more |
62 | precise feedback to the user. | |
63 | ||
64 | ||
15e7d615 | 65 | Return Value |
5377d91f MH |
66 | ============ |
67 | ||
68 | On success 0 is returned, on error -1 and the ``errno`` variable is set | |
69 | appropriately. The generic error codes are described at the | |
70 | :ref:`Generic Error Codes <gen-errors>` chapter. | |
71 | ||
72 | ENODATA | |
73 | Digital video timings are not supported for this input or output. | |
74 | ||
75 | ENOLINK | |
76 | No timings could be detected because no signal was found. | |
77 | ||
78 | ENOLCK | |
79 | The signal was unstable and the hardware could not lock on to it. | |
80 | ||
81 | ERANGE | |
82 | Timings were found, but they are out of range of the hardware | |
83 | capabilities. |