linux-kernel - Re: [PATCH RFC 1/5] drm: Support post-blend color pipeline API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPj87rPAoD2D99zTdsvJ=9K8+G17mTS2jDYHMPYmXNtUyp2L_Q@mail.gmail.com>
Date: Mon, 25 Aug 2025 14:34:48 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Nícolas F. R. A. Prado <nfraprado@...labora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Chun-Kuang Hu <chunkuang.hu@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>, 
	Matthias Brugger <matthias.bgg@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Alex Hung <alex.hung@....com>, 
	wayland-devel@...ts.freedesktop.org, harry.wentland@....com, leo.liu@....com, 
	ville.syrjala@...ux.intel.com, pekka.paalanen@...labora.com, 
	contact@...rsion.fr, mwen@...lia.com, jadahl@...hat.com, 
	sebastian.wick@...hat.com, shashank.sharma@....com, agoins@...dia.com, 
	joshua@...ggi.es, mdaenzer@...hat.com, aleixpol@....org, xaver.hugl@...il.com, 
	victoria@...tem76.com, uma.shankar@...el.com, quic_naseer@...cinc.com, 
	quic_cbraga@...cinc.com, quic_abhinavk@...cinc.com, marcan@...can.st, 
	Liviu.Dudau@....com, sashamcintosh@...gle.com, 
	chaitanya.kumar.borah@...el.com, louis.chauvet@...tlin.com, mcanal@...lia.com, 
	kernel@...labora.com, daniels@...labora.com, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org, 
	linux-arm-kernel@...ts.infradead.org, Simona Vetter <simona.vetter@...ll.ch>
Subject: Re: [PATCH RFC 1/5] drm: Support post-blend color pipeline API

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
<nfraprado@...labora.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