DE/compositor development notes - DRM pixel formats and modifiers
Display controller needs to know how data in framebuffer is laid out to know how to interpret
it. This is indicated by pixel format and optional modifier. There are lots of formats and
modifiers specified in
drm/drm_fourcc.h. Formats are four-letter codes, modifiers are 32-bit
Pixel formats typically specify how one pixel is laid out: single-planar/multi-planar layout, order of components within a pixel, width and interpretation of every component.
Pixel formats can be classified as single-plane and multi-plane. Single-plane store all information for a pixel in one place, multi-plane formats store components of the pixel separately, with every plane (chunk of memory) laying out components of pixels in the same order.
DRM_FORMAT_ABGR1555 is defined as
[15:0] B:G:R:x 5:5:5:1 little endian:
single-planar, RGB, one pixel occupies 16 bits, 5 bits of blue, green, red components
and 1 bit of alpha.
Some formats are more cryptic:
non-subsampled Cr (1) and Cb (2) planes:
YCbCr, 3 planes, 8 bit Y plane, 8 bit Cr plane, 8 bit Cb plane.
Pixel format modifiers typically specify how multiple pixels are laid out in memory: there
DRM_FORMAT_MOD_LINEAR to force linear layout (pixels are laid out in memory one after
another, left-to-right, top-to-bottom, with a possible padding between rows), and a number
of modifiers to specify various tiling layouts (clumps of nearby pixels are stored
in memory together) and framebuffer compression algorithms.
Every DRM plane exposes supported formats, so it’s up to userspace to pick one for best performance. Some DRM planes are specifically created to speedup frequent operations: it is common to see overlay planes that support YUV pixel formats for video playback: many video formats encode picture in YUV, so it allows decoding video directly into a framebuffer and skipping YUV->RGB conversion.