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