Re: [PATCH RFC 1/5] drm: Support post-blend color pipeline API

[Pekka Paalanen <pekka.paalanen@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 3673 bytes --]

On Tue, 30 Sep 2025 14:20:09 +0200
Daniel Stone <daniel@fooishbar.org> wrote:

> Hi,
> 
> On Fri, 26 Sept 2025 at 15:45, Sebastian Wick
> <sebastian@sebastianwick.net> wrote:
> > 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.  
> 
> I don't think it's useless; if nothing else, drm_info is a thing and
> having it work is nice.

I think that the properties of the chosen API flavor should be
readable, and properties of the not-chosen API should be hidden.

> > 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?  
> 
> That's reasonable. My hunch was that it would be too much code in the
> kernel to essentially just do format reinterpretation on userspace's
> behalf.

I agree with Sebastian here. For userspace like drm_info or a
compositor to inspect the current state of KMS, it must first pick the
API to use: either legacy or colorops pipelines. There is no indication
which one was programmed, and since properties always have some value,
both APIs will return something. Which one is right is unknown.

Given that colorop pipelines can and should be able to represent
everything the legacy APIs can, but the opposite is not true, it is a
safe bet to always choose colorops pipelines API. Hence, legacy API
state should always be translated to colorops pipelines API by the
kernel.

Colorops pipelines API is even safe for switching from more capable to
less capable KMS client: the less capable client can see colorops it
does not understand being used, so it will be aware that it cannot
understand the full pipeline. This can trigger a fallback, e.g. do not
animate the switch between clients.

> > 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.  
> 
> FWIW, the usecase I can see in mind would be doing a fade-style
> transition between the old and new clients. But I don't really care
> too strongly about it to be honest; I mostly care about having
> drm_info work because it's a super-useful tool.

drm_info can be reliable, if it always uses colorops pipelines API when
available, and in that case ignores the legacy color operation
properties.

If necessary, one of the pipelines could be explicitly a model of the
old color operation properties.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]