On 2026-07-13 16:05, Harry Wentland wrote:
>
>
> On 2026-07-09 07:49, Maarten Lankhorst wrote:
>> Hey,
>>
>> On 7/9/26 13:14, Robert Mader wrote:
>>> Hi,
>>>
>>> On 09.07.26 12:02, Maarten Lankhorst wrote:
>>>> Hey,
>>>>
>>>> On 7/9/26 08:44, Borah, Chaitanya Kumar wrote:
>>>>>
>>>>> On 7/7/2026 6:31 PM, Maarten Lankhorst wrote:
>>>>>> Hey,
>>>>>>
>>>>>> On 7/7/26 10:03, Borah, Chaitanya Kumar wrote:
>>>>>>> On 7/3/2026 1:02 PM, Robert Mader wrote:
>>>>>>>> The client cap is currently advertised unconditionally, even for
>>>>>>>> drivers
>>>>>>>> that do not support plane color pipelines. If clients supporting the
>>>>>>>> later,
>>>>>>> s/later/latter
>>>>>>>
>>>>>>>> like Wayland compositors or tools like drm_info, enable the client cap
>>>>>>>> on
>>>>>>>> such drivers they will be left without both color pipeline and the
>>>>>>>> legacy
>>>>>>>> properties COLOR_ENCODING and COLOR_RANGE, effectively breaking
>>>>>>>> YUV->RGB
>>>>>>>> conversion support.
>>>>>>>>
>>>>>>>> Prevent that by only marking the cap supported if there are actually
>>>>>>>> planes
>>>>>>>> with color pipelines.
>>>>>>>>
>>>>>>>> Note: while the color pipeline replacement for the legacy properties is
>>>>>>>> still under review (1), we can assume that it will work as a drop-in
>>>>>>>> replacement.
>>>>>>> This change will but a driver can also choose to export colorops like
>>>>>>> programmable CTM_3x4 to achieve the same.
>>>>>>>
>>>>>>> We should also perhaps document this somewhere that if a driver
>>>>>>> supports LEGACY properties, it is imperative to implement some version
>>>>>>> of it with the color pipeline line property.
>>>>>> Would this be doable inside drm core? Implement the color pipeline
>>>>>> properties, get the fixed pipeline for free?
>>>>> Right now, the Bypass(default) pipeline is automatically created when we
>>>>> call drm_plane_create_color_pipeline_property(), we could come up with a
>>>>> similar helper that could also create a pipeline that replaces the legacy
>>>>> properties.
>>>>>
>>>>> But this can't replace the existing helper entirely because some HW
>>>>> (though unlikely) might not support YUV buffers.
>>>> No need to do this for free, but a cheaper way for drivers to implement
>>>> legacy
>>>> properties by only implementing the pipeline would be nice, similar to how
>>>> atomic also implements legacy modesetting and universal planes.
>>>
>>> I really like this idea - should we take it to the corresponding series,
>>> https://lore.kernel.org/dri-devel/[email protected]/
>>> so the initial implementations for AMD and VKMS directly do so?
>>
>> That would be great!
>>
>
> If I understand you correctly you suggest to map legacy COLOR_RANGE and
> COLOR_ENCODING to the new FIXED_MATRIX colorop in a generic way, instead of
> having drivers advertise them separately. Do I have that right?
>
> It's probably a good idea. It should be easy to make that change after
> merging the Fixed Matrix series with YUV support.
>
I sketched this out but both VKMS and amdgpu have HW generations
or configs where no color pipeline is created. For that we still
need the current way of COLOR_RANGE and COLOR_ENCODING handling.
Because of this the code to create COLOR_RANGE and COLOR_ENCODING
based on the color pipeline is not really simplifying things, but
merely adding more code.
At this point I am not convinced adding helpers to create COLOR_RANGE
and COLOR_ENCODING based on the color pipeline is a net positive.
Maybe in the future that equation changes.
If anyone is interested I'm still happy to share the code. Just
let me know.
Harry
> Harry
>
>> Kind regards,
>> ~Maarten Lankhorst
>
