Documentation/userspace-api/media/v4l/vidioc-query-dv-timings.rst
Source file repositories/reference/linux-study-clean/Documentation/userspace-api/media/v4l/vidioc-query-dv-timings.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/userspace-api/media/v4l/vidioc-query-dv-timings.rst- Extension
.rst- Size
- 2881 bytes
- Lines
- 87
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: V4L
.. _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:macro:: VIDIOC_QUERY_DV_TIMINGS
``int ioctl(int fd, VIDIOC_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp)``
.. c:macro:: VIDIOC_SUBDEV_QUERY_DV_TIMINGS
``int ioctl(int fd, VIDIOC_SUBDEV_QUERY_DV_TIMINGS, struct v4l2_dv_timings *argp)``
Arguments
=========
``fd``
File descriptor returned by :c:func:`open()`.
``argp``
Pointer to struct :c:type:`v4l2_dv_timings`.
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
============
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.