mozilla-central/third_party/drm/drm/include/libdrm
Name Description Size
drm.h Header for the Direct Rendering Manager Author: Rickard E. (Rik) Faith <faith@valinux.com> Acknowledgments: Dec 1999, Richard Henderson <rth@twiddle.net>, move to generic cmpxchg. 36567
drm_fourcc.h DOC: overview In the DRM subsystem, framebuffer pixel formats are described using the fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to the fourcc code, a Format Modifier may optionally be provided, in order to further describe the buffer's format - for example tiling or compression. Format Modifiers ---------------- Format modifiers are used in conjunction with a fourcc code, forming a unique fourcc:modifier pair. This format:modifier pair must fully define the format and data layout of the buffer, and should be the only way to describe that particular buffer. Having multiple fourcc:modifier pairs which describe the same layout should be avoided, as such aliases run the risk of different drivers exposing different names for the same data format, forcing userspace to understand that they are aliases. Format modifiers may change any property of the buffer, including the number of planes and/or the required allocation size. Format modifiers are vendor-namespaced, and as such the relationship between a fourcc code and a modifier is specific to the modifer being used. For example, some modifiers may preserve meaning - such as number of planes - from the fourcc code, whereas others may not. Modifiers must uniquely encode buffer layout. In other words, a buffer must match only a single modifier. A modifier must not be a subset of layouts of another modifier. For instance, it's incorrect to encode pitch alignment in a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel aligned modifier. That said, modifiers can have implicit minimal requirements. For modifiers where the combination of fourcc code and modifier can alias, a canonical pair needs to be defined and used by all drivers. Preferred combinations are also encouraged where all combinations might lead to confusion and unnecessarily reduced interoperability. An example for the latter is AFBC, where the ABGR layouts are preferred over ARGB layouts. There are two kinds of modifier users: - Kernel and user-space drivers: for drivers it's important that modifiers don't alias, otherwise two drivers might support the same format but use different aliases, preventing them from sharing buffers in an efficient format. - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these users see modifiers as opaque tokens they can check for equality and intersect. These users musn't need to know to reason about the modifier value (i.e. they are not expected to extract information out of the modifier). Vendors should document their modifier usage in as much detail as possible, to ensure maximum compatibility across devices, drivers and applications. The authoritative list of format modifier codes is found in `include/uapi/drm/drm_fourcc.h` 66036
drm_mode.h DOC: overview DRM exposes many UAPI and structure definition to have a consistent and standardized interface with user. Userspace can refer to these structure definitions and UAPI formats to communicate to driver 32695