Hi Nicolas,
Thanks for doing this! It's great to see.
On Fri, 22 Aug 2025 at 19:36, Nícolas F. R. A. Prado
<nfrapr...@collabora.com> wrote:
> -/**
> - * drm_plane_colorop_curve_1d_lut_init - Initialize a DRM_COLOROP_1D_LUT
> - *
> - * @dev: DRM device
> - * @colorop: The drm_colorop object to initialize
> - * @plane: The associated drm_plane
> - * @lut_size: LUT size supported by driver
> - * @lut1d_interpolation: 1D LUT interpolation type
> - * @flags: bitmask of misc, see DRM_COLOROP_FLAG_* defines.
> - * @return zero on success, -E value on failure
> - */
> -int drm_plane_colorop_curve_1d_lut_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> - struct drm_plane *plane, uint32_t
> lut_size,
> - enum
> drm_colorop_lut1d_interpolation_type lut1d_interpolation,
> - uint32_t flags)
> +static int
> +drm_common_colorop_curve_1d_lut_init(struct drm_device *dev,
> + struct drm_colorop *colorop,
> + uint32_t lut_size,
> + enum
> drm_colorop_lut1d_interpolation_type lut1d_interpolation,
> + uint32_t flags)
I think these would be better in a prior commit which only moved the
plane init around.
> @@ -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.
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
