From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Robert Mader <robert.mader@collabora.com>,
"Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com>,
dri-devel@lists.freedesktop.org
Cc: Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org,
Harry Wentland <harry.wentland@amd.com>,
Daniel Stone <daniels@collabora.com>,
Uma Shankar <uma.shankar@intel.com>,
Louis Chauvet <louis.chauvet@bootlin.com>,
Melissa Wen <mwen@igalia.com>, Simon Ser <contact@emersion.fr>,
Pekka Paalanen <pekka.paalanen@collabora.com>,
Leandro Ribeiro <leandro.ribeiro@collabora.com>
Subject: Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
Date: Thu, 9 Jul 2026 13:49:59 +0200 [thread overview]
Message-ID: <a7887776-c26c-4f6d-a662-2d8ef005ff4c@linux.intel.com> (raw)
In-Reply-To: <361dfc91-94e8-4289-9b3e-5280803d9257@collabora.com>
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/20260623164812.81110-1-harry.wentland@amd.com/ so the initial implementations for AMD and VKMS directly do so?
That would be great!
Kind regards,
~Maarten Lankhorst
next prev parent reply other threads:[~2026-07-09 11:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 7:32 [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE Robert Mader
2026-07-03 8:38 ` ✓ i915.CI.BAT: success for drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (rev2) Patchwork
2026-07-03 11:11 ` [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE Melissa Wen
2026-07-04 1:34 ` ✗ i915.CI.Full: failure for drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (rev2) Patchwork
2026-07-07 8:03 ` [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE Borah, Chaitanya Kumar
2026-07-07 13:01 ` Maarten Lankhorst
2026-07-07 13:15 ` Robert Mader
2026-07-07 14:17 ` Maarten Lankhorst
2026-07-09 6:44 ` Borah, Chaitanya Kumar
2026-07-09 10:02 ` Maarten Lankhorst
2026-07-09 11:14 ` Robert Mader
2026-07-09 11:49 ` Maarten Lankhorst [this message]
2026-07-13 20:05 ` Harry Wentland
2026-07-07 8:26 ` Maarten Lankhorst
2026-07-07 8:31 ` Robert Mader
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7887776-c26c-4f6d-a662-2d8ef005ff4c@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--cc=airlied@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=chaitanya.kumar.borah@intel.com \
--cc=contact@emersion.fr \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=leandro.ribeiro@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.chauvet@bootlin.com \
--cc=mripard@kernel.org \
--cc=mwen@igalia.com \
--cc=pekka.paalanen@collabora.com \
--cc=robert.mader@collabora.com \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=uma.shankar@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.