Documentation/userspace-api/media/v4l/ext-ctrls-dv.rst
Source file repositories/reference/linux-study-clean/Documentation/userspace-api/media/v4l/ext-ctrls-dv.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/userspace-api/media/v4l/ext-ctrls-dv.rst- Extension
.rst- Size
- 6974 bytes
- Lines
- 161
- 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.
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
.. _dv-controls:
*******************************
Digital Video Control Reference
*******************************
The Digital Video control class is intended to control receivers and
transmitters for `VGA <http://en.wikipedia.org/wiki/Vga>`__,
`DVI <http://en.wikipedia.org/wiki/Digital_Visual_Interface>`__
(Digital Visual Interface), HDMI (:ref:`hdmi`) and DisplayPort
(:ref:`dp`). These controls are generally expected to be private to
the receiver or transmitter subdevice that implements them, so they are
only exposed on the ``/dev/v4l-subdev*`` device node.
.. note::
Note that these devices can have multiple input or output pads which are
hooked up to e.g. HDMI connectors. Even though the subdevice will
receive or transmit video from/to only one of those pads, the other pads
can still be active when it comes to EDID (Extended Display
Identification Data, :ref:`vesaedid`) and HDCP (High-bandwidth Digital
Content Protection System, :ref:`hdcp`) processing, allowing the
device to do the fairly slow EDID/HDCP handling in advance. This allows
for quick switching between connectors.
These pads appear in several of the controls in this section as
bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad
1, etc. The maximum value of the control is the set of valid pads.
.. _dv-control-id:
Digital Video Control IDs
=========================
``V4L2_CID_DV_CLASS (class)``
The Digital Video class descriptor.
``V4L2_CID_DV_TX_HOTPLUG (bitmask)``
Many connectors have a hotplug pin which is high if EDID information
is available from the source. This control shows the state of the
hotplug pin as seen by the transmitter. Each bit corresponds to an
output pad on the transmitter. If an output pad does not have an
associated hotplug pin, then the bit for that pad will be 0. This
read-only control is applicable to DVI-D, HDMI and DisplayPort
connectors.
``V4L2_CID_DV_TX_RXSENSE (bitmask)``
Rx Sense is the detection of pull-ups on the TMDS clock lines. This
normally means that the sink has left/entered standby (i.e. the
transmitter can sense that the receiver is ready to receive video).
Each bit corresponds to an output pad on the transmitter. If an
output pad does not have an associated Rx Sense, then the bit for
that pad will be 0. This read-only control is applicable to DVI-D
and HDMI devices.
``V4L2_CID_DV_TX_EDID_PRESENT (bitmask)``
When the transmitter sees the hotplug signal from the receiver it
will attempt to read the EDID. If set, then the transmitter has read
at least the first block (= 128 bytes). Each bit corresponds to an
output pad on the transmitter. If an output pad does not support
EDIDs, then the bit for that pad will be 0. This read-only control
is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
``V4L2_CID_DV_TX_MODE``
(enum)
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.