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.wentl...@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.
