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!

Kind regards,
~Maarten Lankhorst

Reply via email to