kernel/linux.git/include/uapi/drm/drm_mode.h, branch v6.19.11

drm/colorop: Add 3D LUT support to color pipeline

2025-11-26T22:09:42+00:00

It is to be used to enable HDR by allowing userpace to create and pass 3D LUTs to kernel and hardware. new drm_colorop_type: DRM_COLOROP_3D_LUT. Reviewed-by: Simon Ser Signed-off-by: Alex Hung Reviewed-by: Daniel Stone Reviewed-by: Melissa Wen Reviewed-by: Sebastian Wick Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-46-alex.hung@amd.com

drm/colorop: Define LUT_1D interpolation

2025-11-26T22:09:14+00:00

We want to make sure userspace is aware of the 1D LUT interpolation. While linear interpolation is common it might not be supported on all HW. Give driver implementers a way to specify their interpolation. Reviewed-by: Simon Ser Signed-off-by: Alex Hung Signed-off-by: Harry Wentland Reviewed-by: Daniel Stone Reviewed-by: Melissa Wen Reviewed-by: Sebastian Wick Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-44-alex.hung@amd.com

drm/colorop: Add multiplier type

2025-11-26T22:03:35+00:00

This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER. It's a simple multiplier to all pixel values. The value is specified via a S31.32 fixed point provided via the "MULTIPLIER" property. Reviewed-by: Simon Ser Signed-off-by: Alex Hung Reviewed-by: Daniel Stone Reviewed-by: Melissa Wen Reviewed-by: Sebastian Wick Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-41-alex.hung@amd.com

drm/colorop: Add 1D Curve Custom LUT type

2025-11-26T22:03:35+00:00

We've previously introduced DRM_COLOROP_1D_CURVE for pre-defined 1D curves. But we also have HW that supports custom curves and userspace needs the ability to pass custom curves, aka LUTs. This patch introduces a new colorop type, called DRM_COLOROP_1D_LUT that provides a SIZE property which is used by a driver to advertise the supported SIZE of the LUT, as well as a DATA property which userspace uses to set the LUT. DATA and size function in the same way as current drm_crtc GAMMA and DEGAMMA LUTs. Reviewed-by: Simon Ser Signed-off-by: Alex Hung Co-developed-by: Harry Wentland Signed-off-by: Harry Wentland Reviewed-by: Daniel Stone Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-38-alex.hung@amd.com

drm: Add Enhanced LUT precision structure

2025-11-26T22:03:35+00:00

Existing LUT precision structure drm_color_lut has only 16 bit precision. This is not enough for upcoming enhanced hardwares and advance usecases like HDR processing. Hence added a new structure with 32 bit precision values. Signed-off-by: Alex Hung Signed-off-by: Uma Shankar Signed-off-by: Chaitanya Kumar Borah Reviewed-by: Sebastian Wick Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-36-alex.hung@amd.com

drm/colorop: Add 3x4 CTM type

2025-11-26T22:03:33+00:00

This type is used to support a 3x4 matrix in colorops. A 3x4 matrix uses the last column as a "bias" column. Some HW exposes support for 3x4. The calculation looks like: out matrix in |R| |0 1 2 3 | | R | |G| = |4 5 6 7 | x | G | |B| |8 9 10 11| | B | |1.0| This is also the first colorop where we need a blob property to program the property. For that we'll introduce a new DATA property that can be used by all colorop TYPEs requiring a blob. The way a DATA blob is read depends on the TYPE of the colorop. We only create the DATA property for property types that need it. Reviewed-by: Simon Ser Reviewed-by: Louis Chauvet Signed-off-by: Alex Hung Signed-off-by: Harry Wentland Reviewed-by: Daniel Stone Reviewed-by: Melissa Wen Reviewed-by: Sebastian Wick Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-19-alex.hung@amd.com

drm/colorop: Add TYPE property

2025-11-26T22:03:31+00:00

Add a read-only TYPE property. The TYPE specifies the colorop type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT, etc. For now we're only introducing an enumerated 1D LUT type to illustrate the concept. Reviewed-by: Simon Ser Reviewed-by: Louis Chauvet Signed-off-by: Alex Hung Signed-off-by: Harry Wentland Reviewed-by: Daniel Stone Reviewed-by: Melissa Wen Reviewed-by: Sebastian Wick Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-6-alex.hung@amd.com

drm/colorop: Introduce new drm_colorop mode object

2025-11-26T22:03:30+00:00

This patches introduces a new drm_colorop mode object. This object represents color transformations and can be used to define color pipelines. We also introduce the drm_colorop_state here, as well as various helpers and state tracking bits. Reviewed-by: Simon Ser Signed-off-by: Alex Hung Signed-off-by: Harry Wentland Reviewed-by: Daniel Stone Reviewed-by: Melissa Wen Reviewed-by: Sebastian Wick Signed-off-by: Simon Ser Link: https://patch.msgid.link/20251115000237.3561250-5-alex.hung@amd.com

drm/dumb-buffers: Provide helper to set pitch and size

2025-09-29T11:57:43+00:00

Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer scanline pitch and allocation size. Implementations of struct drm_driver.dumb_create can call the new helper for their size computations. There is currently quite a bit of code duplication among DRM's memory managers. Each calculates scanline pitch and buffer size from the given arguments, but the implementations are inconsistent in how they treat alignment and format support. Later patches will unify this code on top of drm_mode_size_dumb() as much as possible. drm_mode_size_dumb() uses existing 4CC format helpers to interpret the given color mode. This makes the dumb-buffer interface behave similar the kernel's video= parameter. Current per-driver implementations again likely have subtle differences or bugs in how they support color modes. The dumb-buffer UAPI is only specified for known color modes. These values describe linear, single-plane RGB color formats or legacy index formats. Other values should not be specified. But some user space still does. So for unknown color modes, there are a number of known exceptions for which drm_mode_size_dumb() calculates the pitch from the bpp value, as before. All other values work the same but print an error. v6: - document additional use cases for DUMB_CREATE2 in TODO list (Tomi) - fix typos in documentation (Tomi) v5: - check for overflows with check_mul_overflow() (Tomi) v4: - use %u conversion specifier (Geert) - list DRM_FORMAT_Dn in UAPI docs (Geert) - avoid dmesg spamming with drm_warn_once() (Sima) - add more information about bpp special case (Sima) - clarify parameters for hardware alignment - add a TODO item for DUMB_CREATE2 v3: - document the UAPI semantics - compute scanline pitch from for unknown color modes (Andy, Tomi) Signed-off-by: Thomas Zimmermann Reviewed-by: Tomi Valkeinen Reviewed-by: Tomi Valkeinen Link: https://lore.kernel.org/r/20250821081918.79786-3-tzimmermann@suse.de

drm: document DRM_MODE_PAGE_FLIP_EVENT interactions with atomic

2025-07-17T16:35:28+00:00

It's not obvious off-hand which CRTCs will get a page-flip event when using this flag in an atomic commit, because it's all implicitly implied based on the contents of the atomic commit. Document requirements for using this flag and how to request an event for a CRTC. Note, because prepare_signaling() runs right after drm_atomic_set_property() calls, page-flip events are not delivered for CRTCs pulled in later by DRM core (e.g. on modeset by drm_atomic_helper_check_modeset()) or the driver (e.g. other CRTCs sharing a DP-MST connector). v2: fix cut off sentence in commit message (Pekka) Signed-off-by: Simon Ser Reviewed-by: Simona Vetter Cc: Ville Syrjälä Cc: Pekka Paalanen Cc: David Turner Cc: Daniel Stone Link: https://lore.kernel.org/r/20250501112945.6448-1-contact@emersion.fr