Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane

[Shengyu Qu]

在 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?

Forget about my previous mail. Background plane means the parent plane of cursor plane, which is described here:

https://docs.kernel.org/next/gpu/amdgpu/display/mpo-overview.html

Not mean the plane that is overlapped by cursor plane, since only one plane is affected by cursor plane.

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.

OpenPGP_0xE3520CC91929C8E7.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature