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] [day] [month] [year] [list]

Message-ID: <CAFZQkGwotQ6cxVCSgp-BhUi5DaZ7MyVvbnrDJW11Z7ztzqy58g@mail.gmail.com>
Date: Mon, 25 Aug 2025 20:45:27 +0200
From: Xaver Hugl <xaver.hugl@...il.com>
To: Daniel Stone <daniel@...ishbar.org>
Cc: Nícolas F. R. A. Prado <nfraprado@...labora.com>, 
	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, 
	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

> > @@ -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