Message-Id: <7a25beb8-6b81-4652-b509-b6410ae1dec1@app.fastmail.com>
Date: Fri, 26 Sep 2025 15:51:57 +0200
From: "Sebastian Wick" <sebastian@...astianwick.net>
To: "Daniel Stone" <daniel@...ishbar.org>,
 Nícolas F. R. A. Prado <nfraprado@...labora.com>
Cc: "Xaver Hugl" <xaver.hugl@...il.com>,
 "Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>,
 "Maxime Ripard" <mripard@...nel.org>,
 "Thomas Zimmermann" <tzimmermann@...e.de>,
 "David Airlie" <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>,
 "Chun-Kuang Hu" <chunkuang.hu@...nel.org>,
 "Philipp Zabel" <p.zabel@...gutronix.de>,
 "Matthias Brugger" <matthias.bgg@...il.com>,
 "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>,
 "Alex Hung" <alex.hung@....com>, wayland-devel@...ts.freedesktop.org,
 harry.wentland@....com, leo.liu@....com, ville.syrjala@...ux.intel.com,
 pekka.paalanen@...labora.com, mwen@...lia.com, jadahl@...hat.com,
 sebastian.wick@...hat.com, shashank.sharma@....com, agoins@...dia.com,
 joshua@...ggi.es, mdaenzer@...hat.com, aleixpol@....org,
 victoria@...tem76.com, uma.shankar@...el.com, quic_naseer@...cinc.com,
 quic_cbraga@...cinc.com, quic_abhinavk@...cinc.com, marcan@...can.st,
 Liviu.Dudau@....com, sashamcintosh@...gle.com,
 chaitanya.kumar.borah@...el.com, louis.chauvet@...tlin.com,
 mcanal@...lia.com, kernel@...labora.com, daniels@...labora.com,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 linux-mediatek@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 "Simona Vetter" <simona.vetter@...ll.ch>
Subject: Re: [PATCH RFC 1/5] drm: Support post-blend color pipeline API

(Sorry for re-sending; used a web mail client which send html)

On Mon, Sep 15, 2025, at 2:31 PM, Daniel Stone wrote:
> Hi Nícolas,
> 
> On Wed, 3 Sept 2025 at 19:43, Nícolas F. R. A. Prado
> <nfraprado@...labora.com> wrote:
> > On Tue, 2025-08-26 at 13:25 +0100, Daniel Stone wrote:
> > Based on this discussion, this is my understanding for the changes
> > desired on the series and their reasonings:
> >
> > 1. Add a driver cap, DRM_CAP_POST_BLEND_COLOR_PIPELINE, which drivers
> > will use to signal they support post-blend color pipelines.
> >   - Reason: Allow userspace to figure out that the driver doesn't
> > support post-blend color pipelines and choose to not set the client
> > cap, DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE, so it can use legacy
> > color management instead.
> > 2. Make it so setting the client cap,
> > DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE, fails if the driver cap,
> > DRM_CAP_POST_BLEND_COLOR_PIPELINE, isn't set
> >   - Reason: Prevent userspace from making color management unusable if
> > the driver doesn't support post-blend color pipelines, as the legacy
> > color-management properties (GAMMA_LUT, DEGAMMA_LUT, CTM) would be
> > unwriteable with the client cap set.
> 
> Definitely.
> 
> > 3. Make legacy color-management properties (GAMMA_LUT, DEGAMMA_LUT,
> > CTM) read-only if the client cap,
> > DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE, is set
> >   - Reason: Allow drm_info to print legacy color management
> > configuration while still enabling post-blend color pipelines through
> > the client cap. Also to allow smooth handover from pre-colorop
> > userspace client to colorop-ready userspace client, as the latter can
> > now replicate the legacy color configuration through the colorops.
> 
> I think yes, but I don't really feel strongly about this. If others
> involved have stronger opinions, I'm happy to yield.

So I'm going to argue that making the properties read-only or read-write is useless.

The only case where knowing the color pipeline of the previous user would be useful is if you want to re-use the framebuffer of said user. Otherwise, the color pipeline and the generated framebuffer have to somehow just match to produce the desired output and that does not require any previous state, making the legacy properties useless.

If we genuinely believe that this is something to be supported, then my question is why the new color pipeline should not be able to accurate reflect the state of the previous user, even if they used the legacy props?

The hardware was able to get into some state based on the legacy props, so it will be able to get into the same state with the color pipeline props; it's "just" a matter of exposing the right pipeline.

If we are not able to accurate reflect the previous state with the pipeline props, then use space will see inconsistent state between the legacy and color pipeline props. Which state is the right one? We cannot know. The previous user could have used either one. So having the legacy props does not help because we don't know if we should use them or the pipeline state.

So, I would argue that we should *remove* the legacy props if DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE is set. If the handover is relevant for a driver, they should ensure the legacy props state translates to the correct color pipeline state. 

> > Side note: Smooth handover back to pre-colorop userspace after tweaking
> > the colorops to something else would not be possible without making the
> > legacy properties writable too, so that the client could update them to
> > match the colorops setting before switching back. I don't imagine this
> > would be a common use case, and colorops are a superset of the legacy
> > properties so there are cases where it wouldn't even be possible to
> > replicate the colorop setting on the legacy properties, but thought I'd
> > mention this limitation for completeness' sake.
> 
> That's a totally acceptable tradeoff. We don't have a standard
> inter-client capability handshake, so if downgrading from a
> newer/more-capable to an older/less-capable client is a bit janky,
> that's OK. There's only so much we can do given the original design
> decision for the KMS core to not be opinionated about a 'golden state'
> that could be used as a reference for userspace to work from as a
> base.
> 
> > Also, as Xaver noted, this feedback also applies to pre-blend pipelines
> > and its legacy color-management properties (COLOR_ENCODING,
> > COLOR_RANGE), so the same changes would be desirable there for the same
> > reasons. So we should share this feedback on that series as well.
> 
> Yep.
> 
> Cheers,
> Daniel
> 

Powered by blists - more mailing lists