brintos

brintos / linux-shallow public Read only

0
0
Text · 2.8 KiB · 5afdc4b Raw
87 lines · plain
1.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later2.. c:namespace:: V4L3 4.. _VIDIOC_QUERY_DV_TIMINGS:5 6*****************************7ioctl VIDIOC_QUERY_DV_TIMINGS8*****************************9 10Name11====12 13VIDIOC_QUERY_DV_TIMINGS - VIDIOC_SUBDEV_QUERY_DV_TIMINGS - Sense the DV preset received by the current input14 15Synopsis16========17 18.. c:macro:: VIDIOC_QUERY_DV_TIMINGS19 20``int ioctl(int fd, VIDIOC_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp)``21 22.. c:macro:: VIDIOC_SUBDEV_QUERY_DV_TIMINGS23 24``int ioctl(int fd, VIDIOC_SUBDEV_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp)``25 26Arguments27=========28 29``fd``30    File descriptor returned by :c:func:`open()`.31 32``argp``33    Pointer to struct :c:type:`v4l2_dv_timings`.34 35Description36===========37 38The hardware may be able to detect the current DV timings automatically,39similar to sensing the video standard. To do so, applications call40:ref:`VIDIOC_QUERY_DV_TIMINGS` with a pointer to a struct41:c:type:`v4l2_dv_timings`. Once the hardware detects42the timings, it will fill in the timings structure.43 44.. note::45 46   Drivers shall *not* switch timings automatically if new47   timings are detected. Instead, drivers should send the48   ``V4L2_EVENT_SOURCE_CHANGE`` event (if they support this) and expect49   that userspace will take action by calling :ref:`VIDIOC_QUERY_DV_TIMINGS`.50   The reason is that new timings usually mean different buffer sizes as51   well, and you cannot change buffer sizes on the fly. In general,52   applications that receive the Source Change event will have to call53   :ref:`VIDIOC_QUERY_DV_TIMINGS`, and if the detected timings are valid they54   will have to stop streaming, set the new timings, allocate new buffers55   and start streaming again.56 57If the timings could not be detected because there was no signal, then58ENOLINK is returned. If a signal was detected, but it was unstable and59the receiver could not lock to the signal, then ``ENOLCK`` is returned. If60the receiver could lock to the signal, but the format is unsupported61(e.g. because the pixelclock is out of range of the hardware62capabilities), then the driver fills in whatever timings it could find63and returns ``ERANGE``. In that case the application can call64:ref:`VIDIOC_DV_TIMINGS_CAP` to compare the65found timings with the hardware's capabilities in order to give more66precise feedback to the user.67 68Return Value69============70 71On success 0 is returned, on error -1 and the ``errno`` variable is set72appropriately. The generic error codes are described at the73:ref:`Generic Error Codes <gen-errors>` chapter.74 75ENODATA76    Digital video timings are not supported for this input or output.77 78ENOLINK79    No timings could be detected because no signal was found.80 81ENOLCK82    The signal was unstable and the hardware could not lock on to it.83 84ERANGE85    Timings were found, but they are out of range of the hardware86    capabilities.87