Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
Source file repositories/reference/linux-study-clean/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/userspace-api/media/v4l/metafmt-d4xx.rst- Extension
.rst- Size
- 7468 bytes
- Lines
- 254
- 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
.. _v4l2-meta-fmt-d4xx:
*******************************
V4L2_META_FMT_D4XX ('D4XX')
*******************************
Intel D4xx UVC Cameras Metadata
Description
===========
Intel D4xx (D435, D455 and others) cameras include per-frame metadata in their UVC
payload headers, following the Microsoft(R) UVC extension proposal [1_]. That
means, that the private D4XX metadata, following the standard UVC header, is
organised in blocks. D4XX cameras implement several standard block types,
proposed by Microsoft, and several proprietary ones. Supported standard metadata
types are MetadataId_CaptureStats (ID 3), MetadataId_CameraExtrinsics (ID 4),
and MetadataId_CameraIntrinsics (ID 5). For their description see [1_]. This
document describes proprietary metadata types, used by D4xx cameras.
V4L2_META_FMT_D4XX buffers follow the metadata buffer layout of
V4L2_META_FMT_UVC with the only difference, that it also includes proprietary
payload header data. D4xx cameras use bulk transfers and only send one payload
per frame, therefore their headers cannot be larger than 255 bytes.
This document implements Intel Configuration version 3 [9_].
Below are proprietary Microsoft style metadata types, used by D4xx cameras,
where all fields are in little endian order:
.. tabularcolumns:: |p{5.0cm}|p{12.5cm}|
.. flat-table:: D4xx metadata
:widths: 1 2
:header-rows: 1
:stub-columns: 0
* - **Field**
- **Description**
* - :cspan:`1` *Depth Control*
* - __u32 ID
- 0x80000000
* - __u32 Size
- Size in bytes, include ID (all protocol versions: 60)
* - __u32 Version
- Version of this structure. The documentation herein covers versions 1,
2 and 3. The version number will be incremented when new fields are
added.
* - __u32 Flags
- A bitmask of flags: see [2_] below
* - __u32 Gain
- Gain value in internal units, same as the V4L2_CID_GAIN control, used to
capture the frame
* - __u32 Exposure
- Exposure time (in microseconds) used to capture the frame
* - __u32 Laser power
- Power of the laser LED 0-360, used for depth measurement
* - __u32 AE mode
- 0: manual; 1: automatic exposure
* - __u32 Exposure priority
- Exposure priority value: 0 - constant frame rate
* - __u32 AE ROI left
- Left border of the AE Region of Interest (all ROI values are in pixels
and lie between 0 and maximum width or height respectively)
* - __u32 AE ROI right
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.