DRM fourcc <-> VideoPixelFormat, and the PipeWire SPA formats. More...
Detailed Description
DRM fourcc <-> VideoPixelFormat, and the PipeWire SPA formats.
A DRM fourcc names the component order of a little-endian machine word, so DRM_ARGB8888 is B,G,R,A in memory – the reverse of how the name reads. That inversion is the single most common source of red/blue swaps on the dma-buf path, so the mapping states the memory order in each comment.
A DRM format modifier (tiling, compression) is deliberately absent. It is not part of a pixel format: the same fourcc can arrive linear or tiled, and folding one into the other would be the same category error as baking a stride alignment into a format descriptor. Callers pass modifiers alongside.
PipeWire's SPA video formats live here too, since they are defined in DRM terms and reached the rest of score through DRM already.
Deliberately header-free of libdrm and libspa: the fourccs are computed from their characters, so this builds and is tested everywhere.
Go to the source code of this file.
Namespaces | |
| namespace | score |
| Base toolkit upon which the software is built. | |
| namespace | score::gfx |
| Graphics rendering pipeline for ossia score. | |
Functions | |
| constexpr uint32_t | score::gfx::interop::drmPixelFourcc (char a, char b, char c, char d) noexcept |
| Build a DRM fourcc from its characters, least-significant byte first. | |
| VideoPixelFormat | score::gfx::interop::fromDrmFourcc (uint32_t fourcc) noexcept |
| The layout behind a DRM fourcc, or Unknown when score has no row for it. | |
| uint32_t | score::gfx::interop::toDrmFourcc (VideoPixelFormat f) noexcept |
Function Documentation
◆ toDrmFourcc()
|
noexcept |
The DRM fourcc a layout should be exported as, or 0 when DRM has none. Not a strict inverse: several fourccs can share a layout, and this returns the canonical one.