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.
Harry
> Kind regards,
> ~Maarten Lankhorst
