mirror of
https://github.com/torvalds/linux.git
synced 2024-12-13 22:53:20 +00:00
e8be7e97e6
instead of declaring the uAPI structs using usual refs, e. g.: .. _foo-struct: Use the C domain way: .. c:type:: foo_struct This way, the kAPI documentation can use cross-references to point to the uAPI symbols. That solves about ~100 undefined warnings like: WARNING: c:type reference target not found: foo_struct Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
87 lines
2.8 KiB
ReStructuredText
87 lines
2.8 KiB
ReStructuredText
.. -*- coding: utf-8; mode: rst -*-
|
|
|
|
.. _VIDIOC_QUERY_DV_TIMINGS:
|
|
|
|
*****************************
|
|
ioctl VIDIOC_QUERY_DV_TIMINGS
|
|
*****************************
|
|
|
|
Name
|
|
====
|
|
|
|
VIDIOC_QUERY_DV_TIMINGS - VIDIOC_SUBDEV_QUERY_DV_TIMINGS - Sense the DV preset received by the current input
|
|
|
|
|
|
Synopsis
|
|
========
|
|
|
|
.. c:function:: int ioctl( int fd, VIDIOC_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp )
|
|
:name: VIDIOC_QUERY_DV_TIMINGS
|
|
|
|
.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp )
|
|
:name: VIDIOC_SUBDEV_QUERY_DV_TIMINGS
|
|
|
|
|
|
Arguments
|
|
=========
|
|
|
|
``fd``
|
|
File descriptor returned by :ref:`open() <func-open>`.
|
|
|
|
``argp``
|
|
|
|
|
|
Description
|
|
===========
|
|
|
|
The hardware may be able to detect the current DV timings automatically,
|
|
similar to sensing the video standard. To do so, applications call
|
|
:ref:`VIDIOC_QUERY_DV_TIMINGS` with a pointer to a struct
|
|
:c:type:`v4l2_dv_timings`. Once the hardware detects
|
|
the timings, it will fill in the timings structure.
|
|
|
|
.. note::
|
|
|
|
Drivers shall *not* switch timings automatically if new
|
|
timings are detected. Instead, drivers should send the
|
|
``V4L2_EVENT_SOURCE_CHANGE`` event (if they support this) and expect
|
|
that userspace will take action by calling :ref:`VIDIOC_QUERY_DV_TIMINGS`.
|
|
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
|
|
:ref:`VIDIOC_QUERY_DV_TIMINGS`, and if the detected timings are valid they
|
|
will have to stop streaming, set the new timings, allocate new buffers
|
|
and start streaming again.
|
|
|
|
If the timings could not be detected because there was no signal, then
|
|
ENOLINK is returned. If a signal was detected, but it was unstable and
|
|
the receiver could not lock to the signal, then ``ENOLCK`` is returned. If
|
|
the receiver could lock to the signal, but the format is unsupported
|
|
(e.g. because the pixelclock is out of range of the hardware
|
|
capabilities), then the driver fills in whatever timings it could find
|
|
and returns ``ERANGE``. In that case the application can call
|
|
:ref:`VIDIOC_DV_TIMINGS_CAP` to compare the
|
|
found timings with the hardware's capabilities in order to give more
|
|
precise feedback to the user.
|
|
|
|
|
|
Return Value
|
|
============
|
|
|
|
On success 0 is returned, on error -1 and the ``errno`` variable is set
|
|
appropriately. The generic error codes are described at the
|
|
:ref:`Generic Error Codes <gen-errors>` chapter.
|
|
|
|
ENODATA
|
|
Digital video timings are not supported for this input or output.
|
|
|
|
ENOLINK
|
|
No timings could be detected because no signal was found.
|
|
|
|
ENOLCK
|
|
The signal was unstable and the hardware could not lock on to it.
|
|
|
|
ERANGE
|
|
Timings were found, but they are out of range of the hardware
|
|
capabilities.
|