linux-kernel - Re: [PATCH RFC v2 05/20] drm: Introduce DRM_CAP_POST_BLEND_COLOR

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: <7307e84f9e4b0a8c67b82f7234f90bf83f201037.camel@collabora.com>
Date: Mon, 29 Sep 2025 12:00:40 -0400
From: Nícolas "F. R. A. Prado" <nfraprado@...labora.com>
To: Harry Wentland <harry.wentland@....com>, Louis Chauvet	
 <louis.chauvet@...tlin.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>, Haneen Mohammed	
 <hamohammed.sa@...il.com>, Melissa Wen <melissa.srw@...il.com>
Cc: Alex Hung <alex.hung@....com>, wayland-devel@...ts.freedesktop.org, 
	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,
 mcanal@...lia.com, 	kernel@...labora.com, daniels@...labora.com,
 leandro.ribeiro@...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 v2 05/20] drm: Introduce
 DRM_CAP_POST_BLEND_COLOR_PIPELINE

On Mon, 2025-09-29 at 05:40 -0400, Harry Wentland wrote:
> 
> 
> On 2025-09-19 08:42, Louis Chauvet wrote:
> > 
> > 
> > Le 18/09/2025 à 02:43, Nícolas F. R. A. Prado a écrit :
> > > Add a new cap that drivers can set to signal they support post-
> > > blend
> > > color pipelines.
> > > 
> > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
> > 
> > Reviewed-by: Louis Chauvet <louis.chauvet@...tlin.com>
> > 
> > > ---
> > >   drivers/gpu/drm/drm_ioctl.c | 3 +++
> > >   include/drm/drm_drv.h       | 6 ++++++
> > >   include/uapi/drm/drm.h      | 6 ++++++
> > >   3 files changed, 15 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_ioctl.c
> > > b/drivers/gpu/drm/drm_ioctl.c
> > > index 
> > > ff193155129e7e863888d8958458978566b144f8..01592d10e3465ddceddef94
> > > bc417f98d3ec12087 100644
> > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > @@ -304,6 +304,9 @@ static int drm_getcap(struct drm_device *dev,
> > > void 
> > > *data, struct drm_file *file_
> > >           req->value = drm_core_check_feature(dev, DRIVER_ATOMIC)
> > > &&
> > >                    dev->mode_config.async_page_flip;
> > >           break;
> > > +    case DRM_CAP_POST_BLEND_COLOR_PIPELINE:
> > > +        req->value = drm_core_check_feature(dev, 
> > > DRIVER_POST_BLEND_COLOR_PIPELINE);
> > > +        break;
> > >       default:
> > >           return -EINVAL;
> > >       }
> > > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > > index 
> > > 42fc085f986dee9261f8b08c4fc7d93b8d6d9769..6b0f4904e69766232283d43
> > > 0c2540d30afef850f 100644
> > > --- a/include/drm/drm_drv.h
> > > +++ b/include/drm/drm_drv.h
> > > @@ -122,6 +122,12 @@ enum drm_driver_feature {
> > >        * the cursor planes to work correctly).
> > >        */
> > >       DRIVER_CURSOR_HOTSPOT           = BIT(9),
> > > +    /**
> > > +     * @DRIVER_POST_BLEND_COLOR_PIPELINE:
> > > +     *
> > > +     * Driver supports post-blend color pipeline.
> > > +     */
> > > +    DRIVER_POST_BLEND_COLOR_PIPELINE        = BIT(10),
> 
> Is this to let userspace know that the driver supports a
> post-blending color pipeline? Why couldn't userspace simply
> check whether crtc objects have "Color Pipeline" properties?

It is, and yes userspace could figure it out that way, though since the
property is only exposed after the client cap is set, it requires a
more involved setup: set the client cap, check for the property, if not
present unset the client cap.

With the driver cap introduced here, setting the client cap would fail
in the first place if the driver cap is not set, so in this case
userspace just tries to set the client cap, if it succeeds it knows it
can use color pipelines, if it fails it knows to use the legacy color
properties.

-- 
Thanks,

Nícolas

> 
> Harry
> 
> > >       /* IMPORTANT: Below are all the legacy flags, add new ones 
> > > above. */
> > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > index 
> > > 27cc159c1d275c7a7fe057840ef792f30a582bb7..c6c53e57958e951204154ce
> > > 41a69696a6876f0e8 100644
> > > --- a/include/uapi/drm/drm.h
> > > +++ b/include/uapi/drm/drm.h
> > > @@ -812,6 +812,12 @@ struct drm_gem_change_handle {
> > >    * commits.
> > >    */
> > >   #define DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP    0x15
> > > +/**
> > > + * DRM_CAP_POST_BLEND_COLOR_PIPELINE
> > > + *
> > > + * If set to 1, the driver supports post-blend color pipelines.
> > > + */
> > > +#define DRM_CAP_POST_BLEND_COLOR_PIPELINE    0x16
> > >   /* DRM_IOCTL_GET_CAP ioctl argument type */
> > >   struct drm_get_cap {
> > > 
> >