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@collabora.com>
> >
> > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.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 {
> > >
> >