Hey, On Wed, 27 Aug 2025 at 12:17, Sebastian Wick <sebastian.w...@redhat.com> wrote: > On Fri Aug 22, 2025 at 8:36 PM CEST, Nícolas F. R. A. Prado wrote: > > Introduce support for a post-blend color pipeline API analogous to the > > pre-blend color pipeline API. While the pre-blend color pipeline was > > configured through a COLOR_PIPELINE property attached to a drm_plane, > > the post-blend color pipeline is configured through a COLOR_PIPELINE > > property on the drm_crtc. > > > > Since colorops can now be attached to either a drm_plane or a drm_crtc, > > rework the helpers to account for both cases. > > > > Also introduce a new cap, DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE, to > > enable support for post-blend color pipelines, and prevent the now > > legacy GAMMA_LUT, DEGAMMA_LUT, GAMMA_LUT_SIZE and CTM properties from > > being exposed. > > Please note that you'll also have to deprecate the semi-standard > Broadcast RGB property. It serves two purposes at once: it changes the > values between the color range (similar to COLOR_RANGE but at the other > end) and informats the sink of the range as well. > > So the post blending color pipeline will need something like an inverse > COLOR_RANGE op. > > We will also need a new connector property where user space can select > the color range, which does not change the pixel values, and only > exposes options that can be achieved (default sink behavior, full range > infoframe, limited range infoframe).
As a note to others, the follow-up is on the 'pixel_encoding' property thread here: https://lore.kernel.org/all/dcd5vifrkfb9.1khizi3asi...@redhat.com/ I think we should keep discussion of those properties there. :) Also strongly related is the proposal to add range/encoding properties to writeback connectors; analagous to the inbound properties: https://lore.kernel.org/all/20250813170542.331206-1-robert.ma...@collabora.com/ I've talked myself around into thinking that the writeback-connector property is better than trying to use colorops to do the transform. On the hardware I've seen, whilst the CRTC output pipeline does have colour-transform properties, the final yard of the encoding (YUV/RGB, full/limited range, primaries, etc) is in fact a per-connector property, so I think it makes more sense there, as that allows usecases like RGB display output whilst streaming to YUV writeback so you can push it directly into an encoder without an intermediate RGB->YUV conversion step. But again, I think conversation about that would be better on that thread rather than here. Thanks! Cheers, Daniel
