Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
On 3/31/25 12:53, Xaver Hugl wrote: Cursor plane has no color pipeline and thus it has no colorop either. It inherits color processing from its parent plane. Just to be sure: That means amdgpu will reject atomic commits that try to set a color pipeline on the primary plane while showing the cursor plane on top of it? Just like with scaling? In theory that should be the case, and I will investigate and confirm it. Is this a beavhiour expected by a compositor?
[ANNOUNCE] libei 1.4.1
libei 1.4.1 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/ libei 1.4.1 fixes two issues with the 1.4.0 release: - the ei_touchscreen version listed in the protocol didn't get bumped to version 2, fixed now - meson dependency overrides didn't use the correct suffix for the library, also fixed now Many thanks To Corentin and Ian for the fixes. Corentin Noël (1): meson.build: Use the correct name for the libraries overrides Ian Douglas Scott (1): proto: Fix `version` for `ei_touchscreen` Peter Hutterer (3): scanner: convert the 'version' and 'since' arguments to int scanner: ensure 'since' doesn't exceed the interface version libei 1.4.1 signature.asc Description: PGP signature
Re: [PATCH V8 03/43] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On 3/31/25 10:24, Shengyu Qu wrote: 在 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 dest
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
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);
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
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);
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
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);
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
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);
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
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. Again it is up to compositors or apps to determine how color pipeline and colorops are used (or not). For example, both primary plane and overlay plane have the same color pipeline, HDR can be enabled only on overlay but not on primary. 在 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. Cursor plane has no color pipeline and thus it has no colorop either. It inherits color processing from its parent plane. You can create a color pipeline for cursor plane for your hardware. If none of existing colorop matches your need, new colorop can be defined. 在 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);
Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane
> Cursor plane has no color pipeline and thus it has no colorop either. It > inherits color processing from its parent plane. Just to be sure: That means amdgpu will reject atomic commits that try to set a color pipeline on the primary plane while showing the cursor plane on top of it? Just like with scaling?
