Hi Nícolas, On Wed, 3 Sept 2025 at 19:43, Nícolas F. R. A. Prado <nfrapr...@collabora.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. > 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
