> > @@ -416,6 +417,24 @@ int drm_mode_object_get_properties(struct
> > drm_mode_object *obj, bool atomic,
> > continue;
> > }
> >
> > + if (post_blend_color_pipeline && obj->type ==
> > DRM_MODE_OBJECT_CRTC) {
> > + struct drm_crtc *crtc = obj_to_crtc(obj);
> > + struct drm_mode_config mode_config =
> > crtc->dev->mode_config;
> > +
> > + if (prop == mode_config.gamma_lut_property ||
> > + prop == mode_config.degamma_lut_property ||
> > + prop == mode_config.gamma_lut_size_property ||
> > + prop == mode_config.ctm_property)
> > + continue;
> > + }
> > +
> > + if (!post_blend_color_pipeline && obj->type ==
> > DRM_MODE_OBJECT_CRTC) {
> > + struct drm_crtc *crtc = obj_to_crtc(obj);
> > +
> > + if (prop == crtc->color_pipeline_property)
> > + continue;
> > + }
>
> Hmmm. One issue with this is that it makes things like drm_info
> harder: if drm_info opted into the client cap, it would no longer be
> able to see any GAMMA_LUT/etc programmed by the prior userspace. So I
> think allowing at least read-only access would be reasonable here.
FWIW the cap for per-plane pipelines also hides COLOR_RANGE and
COLOR_ENCODING properties from the client.
>From a compositor POV, I slightly prefer hiding the properties
entirely, but ignoring them on the compositor side when a color
pipeline is available would also be trivial.
> Having a client cap without a driver cap also puts userspace in a
> difficult position. If the driver doesn't support post-blend colorops,
> then enabling the client cap strictly removes support without a
> replacement. And without a driver cap, the client doesn't have a way
> to know which is better.
>
> Cheers,
> Daniel
