[PATCH] drm/rockchip: dw_hdmi_qp: attach the HDMI Colorspace connector property

[PATCH] drm/rockchip: dw_hdmi_qp: attach the HDMI Colorspace connector property

[Igor Paunovic]

The HDMI connector framework already consumes conn_state->colorspace
when generating the AVI infoframe (drm_hdmi_avi_infoframe_colorimetry()
in drm_hdmi_state_helper.c), and drmm_connector_hdmi_init() attaches
HDR_OUTPUT_METADATA and max bpc for this connector. The Colorspace
property itself, however, is never created, so userspace has no way to
request BT.2020 colorimetry and wide-gamut/HDR output stays effectively
unavailable on RK3588 even though the rest of the plumbing is in place.

Compositors gate HDR on this: KWin (Plasma 6.x) requires the Colorspace
property alongside HDR_OUTPUT_METADATA and max bpc before it reports an
output as HDR/wide-gamut capable, so the HDR toggle never appears.

Create and attach the standard HDMI colorspace property right after the
bridge connector is initialised. Passing 0 selects the full HDMI
colorspace set defined by the DRM core.

Tested on an Orange Pi 5 Plus (RK3588) with Plasma 6.6 on the Collabora
rockchip-v7.0 tree, which carries the same gap: with the property
attached, kscreen-doctor reports both HDMI outputs as HDR and
wide-color-gamut capable, KWin exposes the HDR toggle, the property
switches to BT2020_RGB at 10 bpc when enabled (verified with modetest),
and browsers report an HDR display so streaming services serve native
smpte2084/bt2020 content.

Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
---
--- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
@@ -603,6 +603,20 @@
 		return dev_err_probe(hdmi->dev, PTR_ERR(connector),
 				     "Failed to init bridge connector\n");
 
+	/*
+	 * Attach the HDMI Colorspace property. The HDMI connector framework
+	 * already consumes conn_state->colorspace for the AVI infoframe
+	 * (drm_hdmi_avi_infoframe_colorimetry()), and HDR_OUTPUT_METADATA and
+	 * max bpc are attached by drmm_connector_hdmi_init(), but without the
+	 * Colorspace property userspace cannot request BT.2020 signalling,
+	 * which keeps wide-gamut/HDR output unavailable. Passing 0 selects
+	 * the full HDMI colorspace set defined by the core.
+	 */
+	ret = drm_mode_create_hdmi_colorspace_property(connector, 0);
+	if (ret)
+		return ret;
+	drm_connector_attach_colorspace_property(connector);
+
 	return 0;
 }
 

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] drm/rockchip: dw_hdmi_qp: attach the HDMI Colorspace connector property

[Royal Net]

> [Severity: High] This is a pre-existing issue, but by adding this
> error path, the patch exposes it further. Does returning an error
> here without cancelling hdmi->hpd_work risk a use-after-free?

Thanks for taking a look.

The window you describe does exist, but it is not introduced or
widened by this patch: hdmi->hpd_work is initialized and the HPD
interrupt requested early in dw_hdmi_qp_rockchip_bind(), and the
function already has several error returns after the interrupt is
live -- encoder init, dw_hdmi_qp_bind() and drm_bridge_connector_init()
-- none of which cancel the delayed work. This patch adds one more
return immediately after the last of those, following the function's
existing error-handling pattern.
Since the cancellation gap is common to all of bind()'s error paths,
I think the right fix is a separate patch addressing all of them at
once (e.g. switching to devm_delayed_work_autocancel() or a devres
action) rather than special-casing the new return. I'm happy to send
that as a follow-up.

Igor


On Tue, Jul 14, 2026 at 10:40 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Returning an error from `dw_hdmi_qp_rockchip_bind()` without cancelling `hdmi->hpd_work` leads to a Use-After-Free when the delayed work or HPD interrupt fires.
> --
>
> --- Patch [1]: [PATCH] drm/rockchip: dw_hdmi_qp: attach the HDMI Colorspace connector property ---
> commit 77d2f0e8bc60d50755aec22dee119ad08bb92b3c
> Author: Igor Paunovic <royalnet026@gmail.com>
>
> drm/rockchip: dw_hdmi_qp: attach the HDMI Colorspace connector property
>
> This commit creates and attaches the standard HDMI colorspace property
> after the bridge connector is initialised. This allows userspace to request
> BT.2020 colorimetry and enables wide-gamut/HDR output on RK3588.
>
> > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> > --- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> [ ... ]
> > @@ -695,6 +695,20 @@ static int dw_hdmi_qp_rockchip_bind(struct device *dev, struct device *master,
> >               return dev_err_probe(hdmi->dev, PTR_ERR(connector),
> >                                    "Failed to init bridge connector\n");
> >
> > +     /*
> > +      * Attach the HDMI Colorspace property. The HDMI connector framework
> > +      * already consumes conn_state->colorspace for the AVI infoframe
> > +      * (drm_hdmi_avi_infoframe_colorimetry()), and HDR_OUTPUT_METADATA and
> > +      * max bpc are attached by drmm_connector_hdmi_init(), but without the
> > +      * Colorspace property userspace cannot request BT.2020 signalling,
> > +      * which keeps wide-gamut/HDR output unavailable. Passing 0 selects
> > +      * the full HDMI colorspace set defined by the core.
> > +      */
> > +     ret = drm_mode_create_hdmi_colorspace_property(connector, 0);
> > +     if (ret)
> > +             return ret;
>
> [Severity: High]
> This is a pre-existing issue, but by adding this error path, the patch
> exposes it further. Does returning an error here without cancelling
> hdmi->hpd_work risk a use-after-free?
>
> If a hardware HPD interrupt fires right before the devres cleanup
> unregisters the IRQ, hdmi->hpd_work can get queued. The DRM master
> teardown then frees hdmi (which was allocated via drmm_kzalloc),
> leaving the delayed work to execute later with a dangling pointer:
>
> drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c:dw_hdmi_qp_rk3588_hpd_work() {
>         struct rockchip_hdmi_qp *hdmi = container_of(work,
>                                                      struct rockchip_hdmi_qp,
>                                                      hpd_work.work);
>         struct drm_device *drm = hdmi->encoder.encoder.dev;
>         ...
> }
>
> Could we ensure that the delayed work is properly cancelled before
> returning errors from dw_hdmi_qp_rockchip_bind()?
>
> > +     drm_connector_attach_colorspace_property(connector);
> >
> >       return 0;
> >  }
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260714202850.40999-1-royalnet026@gmail.com?part=1

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip