pub struct DrmFormat {
pub fourcc: u32,
pub modifiers: u64,
}
Expand description
In the Linux DRM+KMS system (i.e. kernel-side GPU drivers), a “DRM format” is an image format (i.e. a specific byte-level encoding of texel data) that framebuffers (or more generally “surfaces” / “images”) could use, provided that all the GPUs involved support the specific format used.
See also https://docs.kernel.org/gpu/drm-kms.html#drm-format-handling.
Fields§
§fourcc: u32
FourCC code for a “DRM format”, i.e. one of the DRM_FORMAT_*
values
defined in drm/drm_fourcc.h
, and the main aspect of a “DRM format”
that userspace needs to care about (e.g. RGB vs YUV, bit width, etc.).
For example, non-HDR RGBA surfaces will almost always use the format
DRM_FORMAT_ABGR8888
(with FourCC "AB24"
, i.e. 0x34324241
), and:
- “A” can be replaced with “X” (disabling the alpha channel)
- “AB” can be reversed, to get “BA” (ABGR -> BGRA)
- “B” can be replaced with “R” (ABGR -> ARGB)
- “AR” can be reversed, to get “RA” (ARGB -> RGBA)
- “24” can be replaced with “30” or “48” (increasing bits per channel)
Some formats also require multiple “planes” (i.e. independent buffers), and while that’s commonly for YUV formats, planar RGBA also exists.
modifiers: u64
Each “DRM format” may be further “modified” with additional features, describing how memory is accessed by GPU texture units (e.g. “tiling”), and optionally requiring additional “planes” for compression purposes.
To userspace, the modifiers are almost always opaque and merely need to be passed from an image exporter to an image importer, to correctly interpret the GPU memory in the same way on both sides.