[PATCH V8 09/43] drm/colorop: Add atomic state print for drm_colorop
From: Harry Wentland
Print atomic state for drm_colorop in debugfs
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
v8:
- Add switch statement to print colorop type (Simon Ser)
v7:
- Add a commit messages
- Squash "drm/colorop: Add NEXT to colorop state print" (Simon Ser)
drivers/gpu/drm/drm_atomic.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 12c313d43e56..97a30d6a68a1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -777,6 +777,29 @@ static int drm_atomic_plane_check(const struct
drm_plane_state *old_plane_state,
return 0;
}
+
+
+static void drm_atomic_colorop_print_state(struct drm_printer *p,
+ const struct drm_colorop_state *state)
+{
+ struct drm_colorop *colorop = state->colorop;
+
+ drm_printf(p, "colorop[%u]:\n", colorop->base.id);
+ drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
+ drm_printf(p, "\tbypass=%u\n", state->bypass);
+
+ switch (colorop->type) {
+ case DRM_COLOROP_1D_CURVE:
+ drm_printf(p, "\tcurve_1d_type=%s\n",
+
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+ break;
+ default:
+ break;
+ }
+
+ drm_printf(p, "\tnext=%d\n", colorop->next ? colorop->next->base.id :
0);
+}
+
static void drm_atomic_plane_print_state(struct drm_printer *p,
const struct drm_plane_state *state)
{
@@ -798,7 +821,8 @@ static void drm_atomic_plane_print_state(struct drm_printer
*p,
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
-
+ drm_printf(p, "\tcolor-pipeline=%d\n",
+ state->color_pipeline ? state->color_pipeline->base.id : 0);
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
}
@@ -1844,6 +1868,7 @@ static void __drm_state_dump(struct drm_device *dev,
struct drm_printer *p,
bool take_locks)
{
struct drm_mode_config *config = &dev->mode_config;
+ struct drm_colorop *colorop;
struct drm_plane *plane;
struct drm_crtc *crtc;
struct drm_connector *connector;
@@ -1853,6 +1878,14 @@ static void __drm_state_dump(struct drm_device *dev,
struct drm_printer *p,
if (!drm_drv_uses_atomic_modeset(dev))
return;
+ list_for_each_entry(colorop, &config->colorop_list, head) {
+ if (take_locks)
+ drm_modeset_lock(&colorop->plane->mutex, NULL);
+ drm_atomic_colorop_print_state(p, colorop->state);
+ if (take_locks)
+ drm_modeset_unlock(&colorop->plane->mutex);
+ }
+
list_for_each_entry(plane, &config->plane_list, head) {
if (take_locks)
drm_modeset_lock(&plane->mutex, NULL);
--
2.43.0
[PATCH V8 31/43] drm/amd/display: Add support for BT.709 and BT.2020 TFs
From: Harry Wentland
This adds support for the BT.709/BT.2020 transfer functions
on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this change the following IGT subtests pass:
kms_colorop --run plane-XR30-XR30-bt2020_inv_oetf
kms_colorop --run plane-XR30-XR30-bt2020_oetf
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
v8:
- Move BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) in amdgpu_dm_supported_blnd_tfs
to "drm/amd/display: Enable support for PQ 125 EOTF and Inverse" (Leo Li)
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 11 ---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 9 ++---
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 63044e0296cb..1765402bc122 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -676,6 +676,9 @@ amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type
tf)
case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
return TRANSFER_FUNCTION_SRGB;
+ case DRM_COLOROP_1D_CURVE_BT2020_INV_OETF:
+ case DRM_COLOROP_1D_CURVE_BT2020_OETF:
+ return TRANSFER_FUNCTION_BT709;
case DRM_COLOROP_1D_CURVE_PQ_125_EOTF:
case DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF:
return TRANSFER_FUNCTION_PQ;
@@ -1284,8 +1287,10 @@ __set_colorop_1d_curve_blend_tf_lut(struct
dc_plane_state *dc_plane_state,
const struct drm_color_lut *blend_lut;
uint32_t blend_size = 0;
- if (colorop->type != DRM_COLOROP_1D_CURVE &&
- colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+ if (colorop->type != DRM_COLOROP_1D_CURVE)
+ return -EINVAL;
+
+ if (!(BIT(colorop_state->curve_1d_type) & amdgpu_dm_supported_blnd_tfs))
return -EINVAL;
if (colorop_state->bypass) {
@@ -1321,7 +1326,7 @@ __set_dm_plane_colorop_blend(struct drm_plane_state
*plane_state,
/* 3nd op: 1d curve - blend */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
- new_colorop_state->curve_1d_type ==
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+ (BIT(new_colorop_state->curve_1d_type) &
amdgpu_dm_supported_blnd_tfs)) {
colorop_state = new_colorop_state;
break;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 581f41907c79..ff5828a1e8cd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -33,15 +33,18 @@
const u64 amdgpu_dm_supported_degam_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
- BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF);
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF);
const u64 amdgpu_dm_supported_shaper_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
- BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF);
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_BT2020_OETF);
const u64 amdgpu_dm_supported_blnd_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
- BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF);
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF);
#define MAX_COLOR_PIPELINE_OPS 10
--
2.43.0
Re: [PATCH V8 03/43] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On Tuesday, April 1st, 2025 at 02:10, Alex Hung wrote: > On 3/29/25 09:26, Simon Ser wrote: > > > I would also highlight that we need to seamlessly switch between HW > > fixed-function blocks and shaders/CPU with no visible difference. Depending > > on > > the content being displayed we might need to fallback to shaders/CPU at any > > time. (A classic example would be a new notification popup preventing us > > from > > leveraging KMS planes.) > > Yes that would be the goal. > > Is there any part of the docs that still need revising to clarify this? I haven't seen this point mentioned in the current docs.
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
Hi, Thanks for reply. It solves my question. Seems it’s not clearly described in the document. Maybe you can add more information to documentation in next version of patch? > 在 2025年4月2日，03:45，Harry Wentland 写道： > > > On 2025-04-01 11:45, Shengyu Qu wrote: >> >> >> 在 2025/4/1 22:11, Michel Dänzer 写道: >>> On 2025-04-01 14:32, Shengyu Qu wrote: 在 2025/4/1 17:56, Michel Dänzer 写道: > On 2025-03-31 19:42, Alex Hung wrote: >> On 3/31/25 11:04, Shengyu Qu wrote: >>> Or we can add some kind of "linked with" info to plane's COLOR_PIPELINE >>> property, to let userspace know that cursor plane and background plane >>> share the same colorop config. So that userspace could do extra >>> conversion on cursor image data to avoid display wrong cursor color. >> That's over-complicate and makes little sense for both device drivers >> and userspace applications. >> If any planes share same colorop config, a device driver exposes the >> same color pipeline with the same colorops. >> If a plane does not support color pipeline or a driver doesn't want to >> support it, there is no color pipeline and no color objects. > I suspect using the cursor plane is generally higher priority for Wayland > compositors than using overlay planes, because the former is critical for > a responsive user experience. > This requires that the amdgpu DC driver backs the cursor plane with a > dedicated HW plane though (as it's already doing in some cases), to > either fully support color pipelines for the cursor plane, or at least > provide proper "no color pipeline" behaviour for it. Letting the > effective behaviour be determined by the other planes which happen to be > behind the cursor plane isn't usable for Wayland compositors. Current behavior is just disable colorop for both background plane and cursor plane. >>> Are you saying the color pipeline is implicitly disabled for any KMS planes >>> which happen to be overlapped by the cursor plane? >> According to this mail, I think so(unless I mistook about the meaning again): >> https://lists.freedesktop.org/archives/amd-gfx/2025-April/122257.html > > No, that's not what this is saying. > > What this says is that when a compositor tries to enable > an color pipeline on a plane on AMD HW and a cursor on > top of that plane the driver will reject that commit. > > A compositor can then either not set a color pipeline, > or not set the cursor plane. > > There's no "implicit disabling" going on. Everything is > explicit. > > I'm having a hard time trying to understand where your > questions are coming from. Are you implementing a compositor? > Are you trying to build a power-efficient system using AMD > HW? Something else? If you could expand on that it might help > us answer them better. The question basically comes from I hope that all planes(including cursor’s parent plane)could use hw colorop to reduce power consumption. But current code implementation won’t support applying colorop to cursor’s parent plane. That “linked with” I mentioned in previous email is a try to come up with a solution for this issue. Best regards, Shengyu > > Harry > >>> That sounds like a no go. I'm not sure how much planes does the hardware support, but if there are too less planes to use, maybe we still need to make use of the cursor background plane in the compositor. >>> If the HW has too few planes to allow both the cursor & overlay planes to >>> work correctly (regardless of their dimensions), the driver should not >>> allow enabling both kinds of planes at the same time.
[ANNOUNCE] libinput 1.28.1
libinput 1.28.1 is now available. This release fixes two regressions: - After unplugging and re-plugging a tablet device, proximity events toggled the tip on/off due to an uninitialized (== zero) pressure range. Repeatedly unplugging also eventually triggered an bug notification. - libinput debug-events failed to print pinch angle and rotation And because the commits were already sitting on the branch, also included is fixed handling of the tablet pad mode toggle buttons. Instead of the previous heuristics we now let this be handled by libwacom 2.15 (if available). Only three tablet devices have those buttons and they're all getting old, so this is unlikely to affect a lot of users. libinput debug-events --help and libinput debug-gui --help now print all available configuration options too. As usual, the git shortlog is below. Peter Hutterer (12): test: add a helper call to mark the end of boilerplate in a test util: provide better alignment for the function name/line no in trace test: fix the tablet tool_ref test tablet: fix an indentation issue tools/debug-events: print all available options pad: fix handling of direct mode switch buttons test: add no-tool testing to one of the tablet tests util: fix a memleak printing a tablet tip event tablet: always initialize the pressure thresholds tablet: delete the tablet's pressure range from the tool pressure ranges tools/debug-events: print pinch angle and rotation again libinput 1.28.1 signature.asc Description: PGP signature
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
Or we can add some kind of "linked with" info to plane's COLOR_PIPELINE property, to let userspace know that cursor plane and background plane share the same colorop config. So that userspace could do extra conversion on cursor image data to avoid display wrong cursor color. 在 2025/4/1 0:50, Shengyu Qu 写道: Thanks, I mistook about the MPO document. Maybe we should also disable colorop on the background plane of the cursor plane? So that compositors would do sw color convertion on both cursor plane and background plane, which should keep cursor display correctly. 在 2025/4/1 0:34, Alex Hung 写道: On 3/31/25 10:31, Shengyu Qu wrote: Sorry for vague expression. I mean that I think we shouldn't register DRM_PLANE_TYPE_CURSOR in the driver, as we don't have actual hardware support. This is not true. AMD has hardware cursor support. 在 2025/4/1 0:26, Alex Hung 写道: On 3/31/25 10:12, Shengyu Qu wrote: So currently we have to hope the compositor won't use DRM_PLANE_TYPE_CURSOR planes at all Why do we still register DRM_PLANE_TYPE_CURSOR in the driver? I am not sure what your question is. A compositor can choose or skip any hardware features, but this discussion is out of the scope. 在 2025/4/1 0:06, Alex Hung 写道: On 3/31/25 09:43, Shengyu Qu wrote: Hi, Thanks for reply. So currently we have to apply color conversion on the background plane of the cursor to do some color space conversion. What would happen if cursor and background plane needs different conversion config? Or we just give the cursor a dedicated plane? This scenario is not supported on AMD hardware, but software cursors on other plane types won't be affected. Best regards, Shengyu 在 2025/3/31 22:28, Alex Hung 写道: On 3/30/25 06:59, Shengyu Qu wrote: Hi, Do we really need to disable cursor plane color pipeline support? I don't think we need to disable that if it is supported, since there might be some user-defined colored cursor icon. This patch applies to AMD hardware only: https:// elixir.bootlin.com/ linux/v6.13/source/Documentation/gpu/amdgpu/ display/mpo- overview.rst#L101 Best regards, Shengyu For some unknown reason, seems my mail is not shown in the mail list archive, so I resent it. 在 2025/3/27 7:47, Alex Hung 写道: cursor plane does not need to have color pipeline. Signed-off-by: Alex Hung --- v7: - Add a commit messages drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/ amdgpu_dm_plane.c b/drivers/gpu/drm/amd/display/amdgpu_dm/ amdgpu_dm_plane.c index 9632b8b73e7e..b5b9b0b5da63 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c @@ -1792,6 +1792,9 @@ dm_plane_init_colorops(struct drm_plane *plane) struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES]; int len = 0; + if (plane->type == DRM_PLANE_TYPE_CURSOR) + return 0; + /* Create COLOR_PIPELINE property and attach */ drm_plane_create_color_pipeline_property(plane, pipelines, len); OpenPGP_0xE3520CC91929C8E7.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH V8 03/43] drm/doc/rfc: Describe why prescriptive color pipeline is needed
在 2025/3/27 7:46, Alex Hung 写道: From: Harry Wentland Add documentation for color pipeline API. Signed-off-by: Alex Hung Signed-off-by: Harry Wentland --- v8: - Fix typo "definint" -> "defining" v7: - Add a commit messages v5: - Don't require BYPASS to succeed (Sebastian) - use DATA for 1D and 3D LUT types (Sebastian) - update 3DLUT ops to use 3DLUT_MODES and 3DLUT_MODE_INDEX - Add section on drm_colorop extensibility - Add color_pipeline.rst to RFC toc tree v4: - Drop IOCTL docs since we dropped the IOCTLs (Pekka) - Clarify reading and setting of COLOR_PIPELINE prop (Pekka) - Add blurb about not requiring to reject a pipeline due to incompatible ops, as long as op can be bypassed (Pekka) - Dropped informational strings (such as input CSC) as they're not actually intended to be advertised (Pekka) v3: - Describe DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (Sebastian) - Ask for clear documentation of colorop behavior (Sebastian) v2: - Update colorop visualizations to match reality (Sebastian, Alex Hung) - Updated wording (Pekka) - Change BYPASS wording to make it non-mandatory (Sebastian) - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property section (Pekka) - Use PQ EOTF instead of its inverse in Pipeline Programming example (Melissa) - Add "Driver Implementer's Guide" section (Pekka) - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka) Documentation/gpu/rfc/color_pipeline.rst | 378 +++ Documentation/gpu/rfc/index.rst | 3 + 2 files changed, 381 insertions(+) create mode 100644 Documentation/gpu/rfc/color_pipeline.rst diff --git a/Documentation/gpu/rfc/color_pipeline.rst b/Documentation/gpu/rfc/color_pipeline.rst new file mode 100644 index ..58bcc2a5ffd8 --- /dev/null +++ b/Documentation/gpu/rfc/color_pipeline.rst @@ -0,0 +1,378 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +Linux Color Pipeline API + + +What problem are we solving? + + +We would like to support pre-, and post-blending complex color +transformations in display controller hardware in order to allow for +HW-supported HDR use-cases, as well as to provide support to +color-managed applications, such as video or image editors. + +It is possible to support an HDR output on HW supporting the Colorspace +and HDR Metadata drm_connector properties, but that requires the +compositor or application to render and compose the content into one +final buffer intended for display. Doing so is costly. + +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other +operations to support color transformations. These operations are often +implemented in fixed-function HW and therefore much more power efficient than +performing similar operations via shaders or CPU. + +We would like to make use of this HW functionality to support complex color +transformations with no, or minimal CPU or shader load. + + +How are other OSes solving this problem? + + +The most widely supported use-cases regard HDR content, whether video or +gaming. + +Most OSes will specify the source content format (color gamut, encoding transfer +function, and other metadata, such as max and average light levels) to a driver. +Drivers will then program their fixed-function HW accordingly to map from a +source content buffer's space to a display's space. + +When fixed-function HW is not available the compositor will assemble a shader to +ask the GPU to perform the transformation from the source content format to the +display's format. + +A compositor's mapping function and a driver's mapping function are usually +entirely separate concepts. On OSes where a HW vendor has no insight into +closed-source compositor code such a vendor will tune their color management +code to visually match the compositor's. On other OSes, where both mapping +functions are open to an implementer they will ensure both mappings match. + +This results in mapping algorithm lock-in, meaning that no-one alone can +experiment with or introduce new mapping algorithms and achieve +consistent results regardless of which implementation path is taken. + +Why is Linux different? +=== + +Unlike other OSes, where there is one compositor for one or more drivers, on +Linux we have a many-to-many relationship. Many compositors; many drivers. +In addition each compositor vendor or community has their own view of how +color management should be done. This is what makes Linux so beautiful. + +This means that a HW vendor can now no longer tune their driver to one +compositor, as tuning it to one could make it look fairly different from +another compositor's color mapping. + +We need a better solution. + + +Descriptive API +=== + +An API that describes the source and destination colorspaces is a descriptive +API. It describes the input
