[PATCH v5 0/3] Add "link bpc" DRM property

[PATCH v5 0/3] Add "link bpc" DRM property

[Nicolas Frattaroli]

This series adds a new "link bpc" DRM property. It reflects the display
link's actual achieved output bits per component, considering any
degradation of the bit depth done by drivers for bandwidth or other
reasons. The property's value is updated during an atomic commit, which
is also when it fires an uevent if it changed to let userspace know.

There's a weston implementation at [1] which makes use of this new
property to warn when a user's requested bpc could not be reached.

[1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850

---
Changes in v5:
- Split "drm/connector: hdmi: Add a 'link bpc' property" into two
  patches; one adding the property, the other making use for it in the
  HDMI helpers (Maxime)
- Apply Maxime's Ack to the two split patches as per the review
- Link to v4: https://lore.kernel.org/r/20260311-link-bpc-v4-0-51775e964720@collabora.com

Changes in v4:
- Throw out the workqueue and delayed work item
- Remove the drm_connector_update_link_bpc_state function
- Reimplement it by updating the property and firing the uevent in
  commit_tail
- Check that the provided max_bpc value in attach_link_bpc_property is
  within the expected range
- Clamp the connector state's link_bpc value between 8 and max_bpc so
  that no value outside the declared range is ever written to the drm
  property
- Update and reword doc strings
- Add an amdgpu implementation
- Link to v3: https://lore.kernel.org/r/20251022162843.1759-1-marius.vlad@collabora.com/T/

Changes in v3:
- remove VRR mention from commit description (Ville)
- add DRM_MODE_PROP_IMMUTABLE to flags (Ville)
- provide helpers functions for drivers to use (can be used by other
  types of connectors, not just HDMI)
- send uevent informating userspace when 'link bpc' connector state
  changed (Daniel @ https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850)
- added missing doc entry
- Link to v2: https://lore.kernel.org/r/20251006083043.3115-1-marius.vlad@collabora.com/T/

Changes in v2:
- replace return with EBUSY if connector already exists (Dmitry)
- add i-g-t test and an implementation for Weston (Dmitry)
- re-wording patch description (Jani)
- Link to v1: https://lore.kernel.org/r/20250801101750.1726-1-marius.vlad@collabora.com/T/

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

---
Nicolas Frattaroli (3):
      drm/connector: Add a 'link bpc' property
      drm/connector: hdmi: Add support for 'link bpc' property
      drm/amd/display: Add support for 'link bpc' property

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++-
 drivers/gpu/drm/display/drm_hdmi_state_helper.c   |  2 +
 drivers/gpu/drm/drm_atomic_helper.c               |  9 +++
 drivers/gpu/drm/drm_atomic_uapi.c                 |  2 +
 drivers/gpu/drm/drm_connector.c                   | 86 +++++++++++++++++++++++
 include/drm/drm_connector.h                       | 16 +++++
 6 files changed, 129 insertions(+), 1 deletion(-)
---
base-commit: f4482de2c06e19b0c337b774e485755378990614
change-id: 20260309-link-bpc-d0afc475ac49

Best regards,
-- 
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

[PATCH v5 1/3] drm/connector: Add a 'link bpc' property

[Nicolas Frattaroli]

Display drivers may degrade from higher bit depths to lower bit depths
for reasons such as bandwidth constraints. Userspace applications, such
as compositors, may wish to know that this has occurred transparently,
instead of assuming that the "max bpc" they requested could be reached.

Introduce a new immutable DRM property called "link bpc" that reflects
the current display link's bits-per-component. An uevent is fired when
the link bpc value changes on an atomic commit.

Acked-by: Maxime Ripard <mripard@kernel.org>
Co-developed-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Co-developed-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/gpu/drm/drm_atomic_helper.c |  9 ++++
 drivers/gpu/drm/drm_atomic_uapi.c   |  2 +
 drivers/gpu/drm/drm_connector.c     | 82 +++++++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h         | 16 ++++++++
 4 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 26953ed6b53e..4a932f543ac7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2033,9 +2033,11 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
 
 static void commit_tail(struct drm_atomic_state *state)
 {
+	struct drm_connector_state *old_conn_state, *new_conn_state;
 	struct drm_device *dev = state->dev;
 	const struct drm_mode_config_helper_funcs *funcs;
 	struct drm_crtc_state *new_crtc_state;
+	struct drm_connector *connector;
 	struct drm_crtc *crtc;
 	ktime_t start;
 	s64 commit_time_ms;
@@ -2059,6 +2061,13 @@ static void commit_tail(struct drm_atomic_state *state)
 
 	drm_atomic_helper_wait_for_dependencies(state);
 
+	for_each_oldnew_connector_in_state(state, connector, old_conn_state,
+					   new_conn_state, i) {
+		if (old_conn_state->link_bpc != new_conn_state->link_bpc)
+			drm_connector_update_link_bpc_property(connector,
+							       new_conn_state);
+	}
+
 	/*
 	 * We cannot safely access new_crtc_state after
 	 * drm_atomic_helper_commit_hw_done() so figure out which crtc's have
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 5bd5bf6661df..12e7a5ab2299 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1020,6 +1020,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = state->privacy_screen_sw_state;
 	} else if (property == connector->broadcast_rgb_property) {
 		*val = state->hdmi.broadcast_rgb;
+	} else if (property == connector->link_bpc_property) {
+		*val = state->link_bpc;
 	} else if (connector->funcs->atomic_get_property) {
 		return connector->funcs->atomic_get_property(connector,
 				state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e70699c59c43..878e9db2c895 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -542,6 +542,75 @@ int drmm_connector_init(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drmm_connector_init);
 
+/**
+ * drm_connector_attach_link_bpc_property - create and attach 'link bpc' property
+ * @connector: drm connector
+ * @max_bpc: specify the upper limit, matching  that of 'max bpc' property
+ *
+ * Create and attach the 'link bpc' DRM property on @connector with an upper
+ * limit of @max_bpc.
+ *
+ * Returns:
+ * 0 on success, negative errno on failure.
+ */
+int
+drm_connector_attach_link_bpc_property(struct drm_connector *connector,
+				       unsigned int max_bpc)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if (connector->link_bpc_property)
+		return -EBUSY;
+
+	if (max_bpc < 8 || max_bpc > U8_MAX)
+		return -EINVAL;
+
+	prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+					 "link bpc", 8, max_bpc);
+	if (!prop)
+		return -ENOMEM;
+
+	connector->link_bpc_property = prop;
+
+	drm_object_attach_property(&connector->base, prop, max_bpc);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_link_bpc_property);
+
+/**
+ * drm_connector_update_link_bpc_property - update the 'link bpc' property of a
+ *                                          connector and fire uevent
+ * @connector: pointer to the &struct drm_connector
+ * @state: pointer to the &struct drm_connector_state with the new value
+ *
+ * Update the 'link bpc' property of the given @connector to the
+ * &drm_connector_state.link_bpc member's value of @state and fire a uevent.
+ */
+void
+drm_connector_update_link_bpc_property(struct drm_connector *connector,
+				       struct drm_connector_state *state)
+{
+	u8 bpc = clamp(state->link_bpc, 8, state->max_bpc);
+
+	if (!connector->link_bpc_property)
+		return;
+
+	if (bpc != state->link_bpc)
+		drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] Clamping link bpc from %u to %u\n",
+			    connector->base.id, connector->name, state->link_bpc, bpc);
+
+	drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] Setting state link bpc %u\n",
+				     connector->base.id, connector->name, bpc);
+	drm_object_property_set_value(&connector->base, connector->link_bpc_property,
+				      bpc);
+
+	drm_sysfs_connector_property_event(connector,
+					   connector->link_bpc_property);
+}
+EXPORT_SYMBOL(drm_connector_update_link_bpc_property);
+
 /**
  * drmm_connector_hdmi_init - Init a preallocated HDMI connector
  * @dev: DRM device
@@ -1713,6 +1782,19 @@ EXPORT_SYMBOL(drm_hdmi_connector_get_output_format_name);
  *	drm_connector_attach_max_bpc_property() to create and attach the
  *	property to the connector during initialization.
  *
+ * link bpc:
+ *	This immutable range property can be used by userspace to determine the
+ *	current display link's bit depth. Drivers can use
+ *	drm_connector_attach_link_bpc_property() to create and attach the
+ *	property to the connector during initialization. They can then set the
+ *	&drm_connector_state.link_bpc member to the actual output bit depth
+ *	after any degradation. The drm property will be updated to this member's
+ *	value on the next atomic commit, and if it changed, a uevent will be
+ *	fired.
+ *	Userspace can listen to the uevent to be notified of link bpc changes,
+ *	and compare the property's value to what userspace requested to
+ *	determine whether colour depth has been degraded.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index c18be8c19de0..3c339a9840c9 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1132,6 +1132,11 @@ struct drm_connector_state {
 	 */
 	u8 max_bpc;
 
+	/**
+	 * @link_bpc: Current display link's bits-per-component.
+	 */
+	u8 link_bpc;
+
 	/**
 	 * @privacy_screen_sw_state: See :ref:`Standard Connector
 	 * Properties<standard_connector_properties>`
@@ -2124,6 +2129,12 @@ struct drm_connector {
 	 */
 	struct drm_property *max_bpc_property;
 
+	/**
+	 * @link_bpc_property: Connector property that reflects the current
+	 * output bits per component.
+	 */
+	struct drm_property *link_bpc_property;
+
 	/** @privacy_screen: drm_privacy_screen for this connector, or NULL. */
 	struct drm_privacy_screen *privacy_screen;
 
@@ -2534,6 +2545,11 @@ void drm_connector_attach_privacy_screen_provider(
 	struct drm_connector *connector, struct drm_privacy_screen *priv);
 void drm_connector_update_privacy_screen(const struct drm_connector_state *connector_state);
 
+int drm_connector_attach_link_bpc_property(struct drm_connector *connector,
+					   unsigned int max_bpc);
+void drm_connector_update_link_bpc_property(struct drm_connector *connector,
+					    struct drm_connector_state *state);
+
 /**
  * struct drm_tile_group - Tile group metadata
  * @refcount: reference count

-- 
2.53.0

[PATCH v5 2/3] drm/connector: hdmi: Add support for 'link bpc' property

[Nicolas Frattaroli]

Create and attach the 'link bpc' DRM property for every HDMI connector
that's created through drmm_connector_hdmi_init.

Then, set the connector state's link_bpc member in the HDMI atomic check
state helper to the connector state's HDMI output bpc.

Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/gpu/drm/display/drm_hdmi_state_helper.c | 2 ++
 drivers/gpu/drm/drm_connector.c                 | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index a1d16762ac7a..40648574f5e5 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -865,6 +865,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 		struct drm_crtc *crtc = new_conn_state->crtc;
 		struct drm_crtc_state *crtc_state;
 
+		new_conn_state->link_bpc = new_conn_state->hdmi.output_bpc;
+
 		crtc_state = drm_atomic_get_crtc_state(state, crtc);
 		if (IS_ERR(crtc_state))
 			return PTR_ERR(crtc_state);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 878e9db2c895..572894dad4bf 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -693,6 +693,10 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 	drm_connector_attach_max_bpc_property(connector, 8, max_bpc);
 	connector->max_bpc = max_bpc;
 
+	ret = drm_connector_attach_link_bpc_property(connector, max_bpc);
+	if (ret)
+		return ret;
+
 	if (max_bpc > 8)
 		drm_connector_attach_hdr_output_metadata_property(connector);
 

-- 
2.53.0

[PATCH v5 3/3] drm/amd/display: Add support for 'link bpc' property

[Nicolas Frattaroli]

The 'link bpc' DRM property exposes the connector's current display link
bits per component value. This allows userspace to discover whether a
link has degraded from a higher bit depth to a lower one.

Add support for it in amdgpu.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 65b256a7b6c4..467821cab009 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7186,6 +7186,14 @@ static void apply_dsc_policy_for_stream(struct amdgpu_dm_connector *aconnector,
 }
 #endif
 
+static void amdgpu_dm_update_link_bpc(struct drm_connector_state *conn_state,
+				      enum dc_color_depth depth)
+{
+	/* 6 bpc is an experimental internal format only, use 8 as minimum */
+	conn_state->link_bpc = clamp(convert_dc_color_depth_into_bpc(depth), 8,
+				     conn_state->max_bpc);
+}
+
 static struct dc_stream_state *
 create_stream_for_sink(struct drm_connector *connector,
 		       const struct drm_display_mode *drm_mode,
@@ -8983,8 +8991,10 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 				adev->mode_info.underscan_vborder_property,
 				0);
 
-	if (!aconnector->mst_root)
+	if (!aconnector->mst_root) {
 		drm_connector_attach_max_bpc_property(&aconnector->base, 8, 16);
+		drm_connector_attach_link_bpc_property(&aconnector->base, 16);
+	}
 
 	aconnector->base.state->max_bpc = 16;
 	aconnector->base.state->max_requested_bpc = aconnector->base.state->max_bpc;
@@ -11427,6 +11437,9 @@ static int dm_update_crtc_state(struct amdgpu_display_manager *dm,
 			goto fail;
 		}
 
+		amdgpu_dm_update_link_bpc(drm_new_conn_state,
+					  new_stream->timing.display_color_depth);
+
 		/*
 		 * TODO: Check VSDB bits to decide whether this should
 		 * be enabled or not.

-- 
2.53.0

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Michel Dänzer]

On 3/19/26 13:28, Nicolas Frattaroli wrote:
> This series adds a new "link bpc" DRM property. It reflects the display
> link's actual achieved output bits per component, considering any
> degradation of the bit depth done by drivers for bandwidth or other
> reasons. The property's value is updated during an atomic commit, which
> is also when it fires an uevent if it changed to let userspace know.
> 
> There's a weston implementation at [1] which makes use of this new
> property to warn when a user's requested bpc could not be reached.
> 
> [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850

I see no description of a real-world use case, either in this series or in the weston MR, beyond logging a message when the "link bpc" & "max bpc" property values don't match. They are not expected to match in general, so I have a hard time seeing the usefulness of that.

Moreover, there's no description of what exactly the "link bpc" property value means, e.g. vs things like DSC or dithering, or how a compositor / user would determine which value they need / want under given circumstances.

In summary, I'm skeptical that this will be useful in practice in the current form. I do see potential for spurious bug reports based on the "link bpc" property having the "wrong" value though.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Nicolas Frattaroli]

On Friday, 20 March 2026 15:32:37 Central European Standard Time Michel Dänzer wrote:
> On 3/19/26 13:28, Nicolas Frattaroli wrote:
> > This series adds a new "link bpc" DRM property. It reflects the display
> > link's actual achieved output bits per component, considering any
> > degradation of the bit depth done by drivers for bandwidth or other
> > reasons. The property's value is updated during an atomic commit, which
> > is also when it fires an uevent if it changed to let userspace know.
> > 
> > There's a weston implementation at [1] which makes use of this new
> > property to warn when a user's requested bpc could not be reached.
> > 
> > [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850
> 
> I see no description of a real-world use case, either in this series
> or in the weston MR, beyond logging a message when the "link bpc" &
> "max bpc" property values don't match. They are not expected to match
> in general, so I have a hard time seeing the usefulness of that.

Hello,

these are valid concerns. The problem being addressed is related to
userspace being able to detect whether the link has degraded due to,
say, a sketchy cable.

This patch started out as a method of forcing the output link's BPC
value to a certain value, but this is not desirable. The max bpc
property is already used to restrict the link's bpc due to sketchy
hardware that advertises a higher max bpc than it can actually
achieve.

This adds the other side of the equation, where userspace isn't
necessarily keen on blindly accepting the combination of output
link parameters the kernel degraded to. This allows userspace to
detect that an explicitly chosen value it tried did not work, and
try again with a different color format/VRR/bpc/etc.

A particular real-world use case is for playback of video content.
When playing back YUV 4:2:0 10-bit video content in a full-screen
setting, having RGB 10-bit degrade to YUV 4:2:0 10-bit rather than
RGB 8-bit is more desirable. However, this is a tradeoff only
userspace knows to make; the kernel doesn't necessarily know that
the framebuffer it has been handed as RGB 10-bit is secretly just
a video player's playback of YUV 4:2:0 10-bit content. As for
the property that let's userspace actually set the output color
format, that's a separate series of mine.

I agree that the weston implementation isn't a great showcase,
but it's actually supposed to compare link bpc with an explicitly
set max bpc config value, not the property value. The config value
exists to request a certain bpc.

> Moreover, there's no description of what exactly the "link bpc" property
> value means, e.g. vs things like DSC or dithering, or how a compositor / 
> user would determine which value they need / want under given circumstances.

I agree that I should've expanded on this after splitting it out of the
HDMI patch. It's the output BPC as HDMI understands it. That means DSC is not
a factor. I don't know if any display protocols do dithering at the
protocol level, I only know some monitors dither internally, which isn't
something that can be detected.

> In summary, I'm skeptical that this will be useful in practice in the
> current form. I do see potential for spurious bug reports based on the
> "link bpc" property having the "wrong" value though.

Kind regards,
Nicolas Frattaroli

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Michel Dänzer]

On 3/20/26 19:02, Nicolas Frattaroli wrote:
> On Friday, 20 March 2026 15:32:37 Central European Standard Time Michel Dänzer wrote:
>> On 3/19/26 13:28, Nicolas Frattaroli wrote:
>>> This series adds a new "link bpc" DRM property. It reflects the display
>>> link's actual achieved output bits per component, considering any
>>> degradation of the bit depth done by drivers for bandwidth or other
>>> reasons. The property's value is updated during an atomic commit, which
>>> is also when it fires an uevent if it changed to let userspace know.
>>>
>>> There's a weston implementation at [1] which makes use of this new
>>> property to warn when a user's requested bpc could not be reached.
>>>
>>> [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850
>>
>> I see no description of a real-world use case, either in this series
>> or in the weston MR, beyond logging a message when the "link bpc" &
>> "max bpc" property values don't match. They are not expected to match
>> in general, so I have a hard time seeing the usefulness of that.
> 
> Hello,
> 
> these are valid concerns. The problem being addressed is related to
> userspace being able to detect whether the link has degraded due to,
> say, a sketchy cable.
> 
> This patch started out as a method of forcing the output link's BPC
> value to a certain value, but this is not desirable. The max bpc
> property is already used to restrict the link's bpc due to sketchy
> hardware that advertises a higher max bpc than it can actually
> achieve.

Not really.

The "max bpc" property is simply an upper limit for the effective bpc that can be used by the driver; nothing more or less. The driver is free to use any lower bpc value though, that doesn't mean anything's wrong.

It doesn't imply that the "max bpc" value can actually be achieved under any circumstances.

The practical purpose is mainly to restrict bpc in cases where higher bpc would prevent e.g. higher refresh rate.


> I agree that the weston implementation isn't a great showcase,
> but it's actually supposed to compare link bpc with an explicitly
> set max bpc config value, not the property value. The config value
> exists to request a certain bpc.

Per above, the "max bpc" property isn't really useful for that.


>> Moreover, there's no description of what exactly the "link bpc" property
>> value means, e.g. vs things like DSC or dithering, or how a compositor / 
>> user would determine which value they need / want under given circumstances.
> 
> I agree that I should've expanded on this after splitting it out of the
> HDMI patch. It's the output BPC as HDMI understands it. That means DSC is not
> a factor. I don't know if any display protocols do dithering at the
> protocol level, I only know some monitors dither internally, which isn't
> something that can be detected.

I know AMD GPUs can do at least temporal dithering of the data they send over the link, I suspect non-temporal as well.

Either way, the user may be able to distinguish more information than the "link bpc" property value implies.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Nicolas Frattaroli]

On Monday, 23 March 2026 11:55:34 Central European Standard Time Michel Dänzer wrote:
> On 3/20/26 19:02, Nicolas Frattaroli wrote:
> > On Friday, 20 March 2026 15:32:37 Central European Standard Time Michel Dänzer wrote:
> >> On 3/19/26 13:28, Nicolas Frattaroli wrote:
> >>> This series adds a new "link bpc" DRM property. It reflects the display
> >>> link's actual achieved output bits per component, considering any
> >>> degradation of the bit depth done by drivers for bandwidth or other
> >>> reasons. The property's value is updated during an atomic commit, which
> >>> is also when it fires an uevent if it changed to let userspace know.
> >>>
> >>> There's a weston implementation at [1] which makes use of this new
> >>> property to warn when a user's requested bpc could not be reached.
> >>>
> >>> [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850
> >>
> >> I see no description of a real-world use case, either in this series
> >> or in the weston MR, beyond logging a message when the "link bpc" &
> >> "max bpc" property values don't match. They are not expected to match
> >> in general, so I have a hard time seeing the usefulness of that.
> > 
> > Hello,
> > 
> > these are valid concerns. The problem being addressed is related to
> > userspace being able to detect whether the link has degraded due to,
> > say, a sketchy cable.
> > 
> > This patch started out as a method of forcing the output link's BPC
> > value to a certain value, but this is not desirable. The max bpc
> > property is already used to restrict the link's bpc due to sketchy
> > hardware that advertises a higher max bpc than it can actually
> > achieve.
> 
> Not really.
> 
> The "max bpc" property is simply an upper limit for the effective bpc that can be used by the driver; nothing more or less. The driver is free to use any lower bpc value though, that doesn't mean anything's wrong.
> 
> It doesn't imply that the "max bpc" value can actually be achieved under any circumstances.
> 
> The practical purpose is mainly to restrict bpc in cases where higher bpc would prevent e.g. higher refresh rate.

The max bpc property's upper limit is an arbitrary driver-set value as
you stated, but that's not what I'm talking about here. Please look at
the code in drm_atomic_uapi.c.

> 
> 
> > I agree that the weston implementation isn't a great showcase,
> > but it's actually supposed to compare link bpc with an explicitly
> > set max bpc config value, not the property value. The config value
> > exists to request a certain bpc.
> 
> Per above, the "max bpc" property isn't really useful for that.

This is straight up false. Setting a max bpc value in weston's config
sets the max bpc DRM property to that value, which in turn sets
max_requested_bpc. On atomic_check, the minimum of state->max_bpc
and state->max_requested_bpc is taken for the new value of
state->max_bpc, i.e. what is set through the property does constrain
the max bpc.

> 
> 
> >> Moreover, there's no description of what exactly the "link bpc" property
> >> value means, e.g. vs things like DSC or dithering, or how a compositor / 
> >> user would determine which value they need / want under given circumstances.
> > 
> > I agree that I should've expanded on this after splitting it out of the
> > HDMI patch. It's the output BPC as HDMI understands it. That means DSC is not
> > a factor. I don't know if any display protocols do dithering at the
> > protocol level, I only know some monitors dither internally, which isn't
> > something that can be detected.
> 
> I know AMD GPUs can do at least temporal dithering of the data they send over the link, I suspect non-temporal as well.
> 
> Either way, the user may be able to distinguish more information than the "link bpc" property value implies.
> 
> 
> 

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Michel Dänzer]

On 3/23/26 13:05, Nicolas Frattaroli wrote:
> On Monday, 23 March 2026 11:55:34 Central European Standard Time Michel Dänzer wrote:
>> On 3/20/26 19:02, Nicolas Frattaroli wrote:
>>> On Friday, 20 March 2026 15:32:37 Central European Standard Time Michel Dänzer wrote:
>>>> On 3/19/26 13:28, Nicolas Frattaroli wrote:
>>>>> This series adds a new "link bpc" DRM property. It reflects the display
>>>>> link's actual achieved output bits per component, considering any
>>>>> degradation of the bit depth done by drivers for bandwidth or other
>>>>> reasons. The property's value is updated during an atomic commit, which
>>>>> is also when it fires an uevent if it changed to let userspace know.
>>>>>
>>>>> There's a weston implementation at [1] which makes use of this new
>>>>> property to warn when a user's requested bpc could not be reached.
>>>>>
>>>>> [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850
>>>>
>>>> I see no description of a real-world use case, either in this series
>>>> or in the weston MR, beyond logging a message when the "link bpc" &
>>>> "max bpc" property values don't match. They are not expected to match
>>>> in general, so I have a hard time seeing the usefulness of that.
>>>
>>> Hello,
>>>
>>> these are valid concerns. The problem being addressed is related to
>>> userspace being able to detect whether the link has degraded due to,
>>> say, a sketchy cable.
>>>
>>> This patch started out as a method of forcing the output link's BPC
>>> value to a certain value, but this is not desirable. The max bpc
>>> property is already used to restrict the link's bpc due to sketchy
>>> hardware that advertises a higher max bpc than it can actually
>>> achieve.
>>
>> Not really.
>>
>> The "max bpc" property is simply an upper limit for the effective bpc that can be used by the driver; nothing more or less. The driver is free to use any lower bpc value though, that doesn't mean anything's wrong.
>>
>> It doesn't imply that the "max bpc" value can actually be achieved under any circumstances.
>>
>> The practical purpose is mainly to restrict bpc in cases where higher bpc would prevent e.g. higher refresh rate.
> 
> The max bpc property's upper limit is an arbitrary driver-set value as
> you stated, but that's not what I'm talking about here.

I'm not talking about the maximum value of the property itself either.

The value of the "max bpc" property, which can be modified by user space, defines the upper limit for the effective bpc used by the driver.


>>> I agree that the weston implementation isn't a great showcase,
>>> but it's actually supposed to compare link bpc with an explicitly
>>> set max bpc config value, not the property value. The config value
>>> exists to request a certain bpc.
>>
>> Per above, the "max bpc" property isn't really useful for that.
> 
> This is straight up false. Setting a max bpc value in weston's config
> sets the max bpc DRM property to that value, which in turn sets
> max_requested_bpc. On atomic_check, the minimum of state->max_bpc
> and state->max_requested_bpc is taken for the new value of
> state->max_bpc, i.e. what is set through the property does constrain
> the max bpc.

What I mean is that the "max bpc" property isn't useful for the purpose of "request a certain bpc". It only affects the upper limit, not the effective value, which can legitimately be lower. Logging a message in that case may be a false positive which may result in a spurious issue report.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Nicolas Frattaroli]

On Monday, 23 March 2026 15:38:58 Central European Standard Time Michel Dänzer wrote:
> On 3/23/26 13:05, Nicolas Frattaroli wrote:
> > On Monday, 23 March 2026 11:55:34 Central European Standard Time Michel Dänzer wrote:
> >> On 3/20/26 19:02, Nicolas Frattaroli wrote:
> >>> On Friday, 20 March 2026 15:32:37 Central European Standard Time Michel Dänzer wrote:
> >>>> On 3/19/26 13:28, Nicolas Frattaroli wrote:
> >>>>> This series adds a new "link bpc" DRM property. It reflects the display
> >>>>> link's actual achieved output bits per component, considering any
> >>>>> degradation of the bit depth done by drivers for bandwidth or other
> >>>>> reasons. The property's value is updated during an atomic commit, which
> >>>>> is also when it fires an uevent if it changed to let userspace know.
> >>>>>
> >>>>> There's a weston implementation at [1] which makes use of this new
> >>>>> property to warn when a user's requested bpc could not be reached.
> >>>>>
> >>>>> [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850
> >>>>
> >>>> I see no description of a real-world use case, either in this series
> >>>> or in the weston MR, beyond logging a message when the "link bpc" &
> >>>> "max bpc" property values don't match. They are not expected to match
> >>>> in general, so I have a hard time seeing the usefulness of that.
> >>>
> >>> Hello,
> >>>
> >>> these are valid concerns. The problem being addressed is related to
> >>> userspace being able to detect whether the link has degraded due to,
> >>> say, a sketchy cable.
> >>>
> >>> This patch started out as a method of forcing the output link's BPC
> >>> value to a certain value, but this is not desirable. The max bpc
> >>> property is already used to restrict the link's bpc due to sketchy
> >>> hardware that advertises a higher max bpc than it can actually
> >>> achieve.
> >>
> >> Not really.
> >>
> >> The "max bpc" property is simply an upper limit for the effective bpc that can be used by the driver; nothing more or less. The driver is free to use any lower bpc value though, that doesn't mean anything's wrong.
> >>
> >> It doesn't imply that the "max bpc" value can actually be achieved under any circumstances.
> >>
> >> The practical purpose is mainly to restrict bpc in cases where higher bpc would prevent e.g. higher refresh rate.
> > 
> > The max bpc property's upper limit is an arbitrary driver-set value as
> > you stated, but that's not what I'm talking about here.
> 
> I'm not talking about the maximum value of the property itself either.
> 
> The value of the "max bpc" property, which can be modified by user space, defines the upper limit for the effective bpc used by the driver.

Yes, I know what the max bpc property does. I do not think it defines
a fixed bpc the driver was required to use, as if it did, the link bpc
property would be useless.

> >>> I agree that the weston implementation isn't a great showcase,
> >>> but it's actually supposed to compare link bpc with an explicitly
> >>> set max bpc config value, not the property value. The config value
> >>> exists to request a certain bpc.
> >>
> >> Per above, the "max bpc" property isn't really useful for that.
> > 
> > This is straight up false. Setting a max bpc value in weston's config
> > sets the max bpc DRM property to that value, which in turn sets
> > max_requested_bpc. On atomic_check, the minimum of state->max_bpc
> > and state->max_requested_bpc is taken for the new value of
> > state->max_bpc, i.e. what is set through the property does constrain
> > the max bpc.
> 
> What I mean is that the "max bpc" property isn't useful for the purpose of "request a certain bpc".

Yes it is? It requests an upper limit for BPC and every driver
will try to pick the highest that's practically possible.

> It only affects the upper limit, not the effective value, which can legitimately be lower.

I am aware, that is why the link bpc property is added, to evaluate
what the driver ended up picking. See "practically possible" above.

> Logging a message in that case may be a false positive which may result in a spurious issue report.

That is not what any of this is used for. In the MR, it acts on the weston
option of the name max-bpc, which incidentally sets the max bpc
property, but is an explicit request by a user made through a config
file. The use here is just a basic userspace use of it, the point is
not to create a new warning out of nothing for the fun of it.

The whole point of this property is to close the feedback loop
between requesting a new bpc with max-bpc and seeing what comes out
the other end with link-bpc. This answers all questions you should
have about the definition of what bits per component is (same as
with max bpc), and why this property should exist. "Someone might
not understand its purpose" is, in my eyes, not a valid reason to
not have this property, as this argument applies to every property.

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Michel Dänzer]

On 3/23/26 17:55, Nicolas Frattaroli wrote:
>
> "Someone might not understand its purpose" is, in my eyes, not a valid reason to
> not have this property, [...]
Per my previous posts, that's not my concern.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Nicolas Frattaroli]

On Monday, 23 March 2026 18:27:41 Central European Standard Time Michel Dänzer wrote:
> On 3/23/26 17:55, Nicolas Frattaroli wrote:
> >
> > "Someone might not understand its purpose" is, in my eyes, not a valid reason to
> > not have this property, [...]
> Per my previous posts, that's not my concern.
> 
> 
> 

Then what is your concern? That the link-bpc property does not
consider DSC and dithering? Two things which the max-bpc property
also does not consider?

Please clearly state where your problem with this property is (and
not with how your understanding of the Weston MR uses it) so that
I can make forward progress here. If all you want is a clearer
description of the property in the comment that accompanies it,
then I can do that, and I said I agree with this point. But you
seem to be arguing from a position of not wanting the property to
exist at all, which is not something I can address. Userspace needs
a way to close the feedback loop here, or it won't be able to make
the right content-specific trade-offs.

Kind regards,
Nicolas Frattaroli

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Michel Dänzer]

On 3/24/26 16:25, Nicolas Frattaroli wrote:
> On Monday, 23 March 2026 18:27:41 Central European Standard Time Michel Dänzer wrote:
>> On 3/23/26 17:55, Nicolas Frattaroli wrote:
>>>
>>> "Someone might not understand its purpose" is, in my eyes, not a valid reason to
>>> not have this property, [...]
>> Per my previous posts, that's not my concern.
> 
> Then what is your concern?

Per my previous posts, my concerns are:

* The meaning of the "link bpc" property value isn't defined well enough vs things like dithering or DSC, which will likely result in compositors / users overestimating what value they need / want, resulting in compositors spuriously rejecting configurations which would work perfectly fine, and/or spurious issue reports.

With my compositor developer hat on, what I'd want to know is something like: "How many bits of information can be passed over the link, allowing the display to present it in a way which can be perceived by the user?" With dithering or DSC, that would be a higher value than the physical link bpc.


* There's no clear use case.

This is generally a requirement for new KMS UAPI.

The practical usefulness of the corresponding weston MR is dubious per the concern above.


> That the link-bpc property does not consider DSC and dithering?
> Two things which the max-bpc property also does not consider?

It's not (as much of) an issue with the "max bpc" property because it's just an upper limit, the driver is free to use a lower effective bpc.


> If all you want is a clearer description of the property in the comment that
> accompanies it, then I can do that, and I said I agree with this point.

Patch 3 would need to take dithering & DSC into account as well.


> But you seem to be arguing from a position of not wanting the property to
> exist at all, [...]

I'm not. However, per the first concern above, a not-well-defined property could be worse than none.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Nicolas Frattaroli]

On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote:
> On 3/24/26 16:25, Nicolas Frattaroli wrote:
> > On Monday, 23 March 2026 18:27:41 Central European Standard Time Michel Dänzer wrote:
> >> On 3/23/26 17:55, Nicolas Frattaroli wrote:
> >>>
> >>> "Someone might not understand its purpose" is, in my eyes, not a valid reason to
> >>> not have this property, [...]
> >> Per my previous posts, that's not my concern.
> > 
> > Then what is your concern?
> 
> Per my previous posts, my concerns are:
> 
> * The meaning of the "link bpc" property value isn't defined well
> enough vs things like dithering or DSC, which will likely result in
> compositors / users overestimating what value they need / want,
> resulting in compositors spuriously rejecting configurations which 
> would work perfectly fine, and/or spurious issue reports.

Dithering and DSC are supposed to be transparent, no? Or else why is
amdgpu forcing DSC on for everyone? This doesn't make sense. If a
link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits.
No compositor would care about the compressed-to actual bit depth on
the wire being 9 bits on the intake of a DSC decoder, it's not relevant
for their use case, they're not decoding DSC.

Making it consider DSC as part of the link bpc would lead to what you
describe, since now compositors would need to know the compression
algorithms of every single display protocol to correctly determine
whether unintended degradation has happened. Ignoring DSC, which is
what I am doing, would not do that.
 
> With my compositor developer hat on, what I'd want to know is something
> like: "How many bits of information can be passed over the link, allowing
> the display to present it in a way which can be perceived by the user?"
> With dithering or DSC, that would be a higher value than the physical
> link bpc.

You're assuming link-bpc isn't precisely that. It is precisely that. It's
not the wire format. Nobody cares about how many bits are on the wire, they
care about the bit depth on the protocol level, that is, whether 10->8 bit
degradation has happened, not whether 10 bits have DSC applied to be actually
9 bits on the wire but it's not the same as uncompressed 9 bits would be
because compression doesn't work like that.

> * There's no clear use case.
> 
> This is generally a requirement for new KMS UAPI.
> 
> The practical usefulness of the corresponding weston MR is dubious
> per the concern above.

As per my previous responses, I outlined you the use case. However, you
seem to be obsessed with the weston MR that adds a warning. This is not
the use case. I will copy-paste my explanation of the use case again, for
your benefit:

A particular real-world use case is for playback of video content.
When playing back YUV 4:2:0 10-bit video content in a full-screen
setting, having RGB 10-bit degrade to YUV 4:2:0 10-bit rather than
RGB 8-bit is more desirable. However, this is a tradeoff only
userspace knows to make; the kernel doesn't necessarily know that
the framebuffer it has been handed as RGB 10-bit is secretly just
a video player's playback of YUV 4:2:0 10-bit content. As for
the property that let's userspace actually set the output color
format, that's a separate series of mine.

> > That the link-bpc property does not consider DSC and dithering?
> > Two things which the max-bpc property also does not consider?
> 
> It's not (as much of) an issue with the "max bpc" property because
> it's just an upper limit, the driver is free to use a lower effective bpc. 

Yes it is. If I request 10 bpc but I'm somehow convinced that this means
"whatever bpc compresses to 10bpc with DSC" then it's not working as this
flawed interpretation would convince me. However, thankfully, nobody thinks
this.

> > If all you want is a clearer description of the property in the comment that
> > accompanies it, then I can do that, and I said I agree with this point.
> 
> Patch 3 would need to take dithering & DSC into account as well.

There is no patch 3, and I will not break the feedback loop semantics of this
property to please you. It ruins the actual intended use case, so I won't do it.

> > But you seem to be arguing from a position of not wanting the property to
> > exist at all, [...]
> 
> I'm not. However, per the first concern above, a not-well-defined
> property could be worse than none.

So should I remove max-bpc as well? It's not well defined after all.

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]

Hi Michel,

I have some opinions as well.

On Tue, 24 Mar 2026 17:44:21 +0100
Michel Dänzer <michel.daenzer@mailbox.org> wrote:

> Per my previous posts, my concerns are:
> 
> * The meaning of the "link bpc" property value isn't defined well
> enough vs things like dithering or DSC, which will likely result in
> compositors / users overestimating what value they need / want,
> resulting in compositors spuriously rejecting configurations which
> would work perfectly fine, and/or spurious issue reports.

That is ok. Compositors need to understand what the numbers mean, how
reliable they are, and act accordingly. Knowing the lower bound for
link precision is already useful as it guarantees a minimum precision.
It is up to the compositors to decide how they communicate this.

Or course, assuming lossy compression is not too lossy. Maybe
lossy compression should be forbidden by default unless explicitly
enabled by userspace?

> With my compositor developer hat on, what I'd want to know is
> something like: "How many bits of information can be passed over the
> link, allowing the display to present it in a way which can be
> perceived by the user?" With dithering or DSC, that would be a higher
> value than the physical link bpc.

Sure, but this is not that. This is only a part of that. You would
also want to know what the monitor does with the signal, the depth of
the data path to the panel, and so on. I'm sure those are completely
off-topic for a KMS property.

The kernel driver won't know how acceptable temporal dithering, spatial
dithering or lossy compression are, so I don't think it should be
deciding how many bits of precision they add or subtract. Exactly this
makes the link bpc property a well-defined fact rather than an estimate.

The documentation of 'link bpc' could be more explicit about this.

> 
> * There's no clear use case.
> 
> This is generally a requirement for new KMS UAPI.
> 
> The practical usefulness of the corresponding weston MR is dubious
> per the concern above.

I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc rather
than RGB 8 bpc is an excellent use case. I had another use case in
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686

Mario Kleiner had excellent cases as well.

Maybe these just need to be spelled more clearly in the commit message.

> > That the link-bpc property does not consider DSC and dithering?
> > Two things which the max-bpc property also does not consider?  
> 
> It's not (as much of) an issue with the "max bpc" property because
> it's just an upper limit, the driver is free to use a lower effective
> bpc.

FWIW, 'max bpc' is a workaround for faulty sink devices that claim to
handle a depth but silently misbehave. This is also why I called for a
"desired bpc" setting in the Weston MR, to not confuse with the "max
bpc" setting.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Michel Dänzer]

On 3/21/26 03:33, Mario Kleiner wrote:
> As somebody who writes software for neuroscience research, I would find this new property very useful.
> 
> Even if the 'link bpc' is not the perfectly accurate answer in presence of dithering or display stream compression, I think it could provide an idea about the minimum precision available, so a DRM client can at least make sure its minimum requirements are met. E.g., a 'link bpc' of 10 would at least guarantee 10 bpc, and effectively a bit more if spatial dithering is applied in addition.

There's a problem in the opposite direction: With dithering, the "link bpc" property implies that the display link can transmit less information than it actually can.


> That said, I don't have practical experience with the effects of DSC, I don't have any
> suitable hardware. Afaik it is not truly lossless, but only (supposed to be, usually)
> perceptually lossless. It would be great to have some property that informs clients if DSC
> is active or not, or allow some control over that.

FWIW, I mentioned DSC not because it's potentially lossy, but because it allows transmitting a larger "real" (albeit potentially lossy) bpc over a smaller physical bpc. If the "link bpc" property reported the latter, it would again imply the link can transfer less information than it actually can.


> Also as somebody who has spent many hours of his life hunting down some sysfs or debugfs files for reporting such numbers, the files usually being differently named, at different paths, with different formats, or not existing at all, depending on kernel version and gpu configuration. I'd like to do less of that in the future.

No doubt that generic KMS properties would be better than that, I'm just skeptical that this specific property (alone) as currently defined is really useful.


> In the scenarios used by my app, the app often knows what an optimal setting for 'max bpc' or reported value from such a 'link bpc' would be,

How can it know that vs dithering?


> But I could imagine regular desktop use cases, where a Wayland compositor can somewhat know what good minimum values for 'link bpc' would be, and maybe adapt, or give the user a hint about potentially degraded quality, and what to do about it ("Check your cables", "Reduce video resolution or refresh rate", "Run with less displays",...).

I see potential for false positives resulting in spurious issue reports.


> - A HDR-10 display mode on a true HDR sink implies one really wants a 'link bpc' of at least 10 bpc, especially given the large nonlinearity of EOTF's like Perceptual Quantizer, or things will look poor.

Even with dithering? (Same question about the other scenarios you mentioned)


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast