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

[Qu Shengyu]

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 <harry.wentland at amd.com> 写道：
> 
> 
> 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.