On 2025-09-26 09:51, Sebastian Wick wrote:
(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
<[email protected]> 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.
I tend to agree. The DRM driver cap seems to complicate the handling for
userspace and drivers, which makes the whole mechanism more fragile, all
to work around a commonly known short-coming of DRM/KMS, which is the
default state problem when transitioning between userspace clients.
Harry
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
