[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

[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

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/26/26 13:17, Nicolas Frattaroli wrote:
> 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?

Not really, no. They achieve higher "effective" (as perceived by the user) bpc using a lower physical bpc.


> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits.

If DSC encodes user-perceived 10 bpc at a lower physical bpc, and the "link bpc" property reports 10, that would satisfy my concern for DSC.

Are you sure that's the case though?

I would be quite surprised if this was correspondingly the case for dithering.

Either way, the "link bpc" semantics regarding these should be explicitly documented.


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

Sounds like you misunderstood my concern.


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

I'm not assuming, I'm asking for this to be clarified.


> [...], you seem to be obsessed [...]

Not sure why you keep attacking me personally. I'm not trying to shoot down your proposal, I'm trying to prevent potential flaws I see with it. A bit more cooperative attitude would be nice.


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

The start of this thread is the cover letter of a 3-patch series.


> and I will not break the feedback loop semantics of this property to please you.

More ad hominem.


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

This isn't a good-faith argument either. Nobody asked for that.


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

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

[Harry Wentland]

On 2026-03-30 12:57, Michel Dänzer wrote:
> On 3/26/26 13:17, Nicolas Frattaroli wrote:
>> 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?
> 
> Not really, no. They achieve higher "effective" (as perceived by the user) bpc using a lower physical bpc.
> 
> 
>> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits.
> 
> If DSC encodes user-perceived 10 bpc at a lower physical bpc, and the "link bpc" property reports 10, that would satisfy my concern for DSC.
> 

Conceptually I would understand DSC to not effect the reported bpc, so
a 10bpc output bpc would be reported as 10bpc via the property, but
DSC would compress that down to a lower value on the wire.

Dithering wouldn't do that. An 8bpc output would be reported as 8bpc
even if dithering makes it perceptually look like 10bpc.

I can understand the challenge of how to intelligently use it to
report anything back to users. I could see some compositors being happy
to use the bpc alone, while others might want to know dithering and/or
DSC state (compression ratio?) as well.

Harry

> Are you sure that's the case though?
> 
> I would be quite surprised if this was correspondingly the case for dithering.
> 
> Either way, the "link bpc" semantics regarding these should be explicitly documented.
> 
> 
>> 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.
> 
> Sounds like you misunderstood my concern.
> 
> 
>>> 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.
> 
> I'm not assuming, I'm asking for this to be clarified.
> 
> 
>> [...], you seem to be obsessed [...]
> 
> Not sure why you keep attacking me personally. I'm not trying to shoot down your proposal, I'm trying to prevent potential flaws I see with it. A bit more cooperative attitude would be nice.
> 
> 
>>>> 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,
> 
> The start of this thread is the cover letter of a 3-patch series.
> 
> 
>> and I will not break the feedback loop semantics of this property to please you.
> 
> More ad hominem.
> 
> 
>>>> 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.
> 
> This isn't a good-faith argument either. Nobody asked for that.
> 
> 

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

[Harry Wentland]

On 2026-03-26 09:53, Pekka Paalanen wrote:
> 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?
> 

I disagree. While technically lossy, DSC is perceptually lossless, at
least according to the designers of DSC. If I'm not mistaken this is
all based on extensive studies.

The decision to enable DSC or not has an impact on the power consumption
of the HW, in ways that are often nuanced. Userspace has no way to know
or understand these nuances. This should be in control of the driver.

At most I could see a "never do DSC or dither" toggle, if one is really
concerned about this, but I don't realistically see use-cases where this
would improve user experience, even for users that care about color work
and correctness.

The YCbCr420 case is different. We probably want a way for userspace to
understand that half 3/4 of chroma values are being tossed out. This
would be significant for RGB content but insignificant for YCbCr420
content.

Harry

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

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

[Michel Dänzer]

On 3/26/26 14:53, Pekka Paalanen wrote:
> 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.

I don't disagree, this needs to be made clear in the documentation though, if not reflected in the property name itself.


>> * 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.

This series and the corresponding Weston MR aren't enough to address that use case though, are they? All they achieve is logging a potentially misleading warning.

It might make sense to combine this series and the Weston MR with whatever else is needed for that use case.


> I had another use case in
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686

That would need to take dithering into account as well?


> Mario Kleiner had excellent cases as well.

I raised unanswered questions on those.


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

That's not the only use case (in fact I'm not sure I'd heard of this before). E.g. it can also be used in cases where some HW bottleneck prevents using maximum refresh rate at maximum bpc for all displays, to explicitly choose which display(s) to limit bpc for, allowing max bpc for the rest.


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

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

[Pekka Paalanen]

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

On Mon, 30 Mar 2026 15:01:33 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2026-03-26 09:53, Pekka Paalanen wrote:
> > 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?
> >   
> 
> I disagree. While technically lossy, DSC is perceptually lossless, at
> least according to the designers of DSC. If I'm not mistaken this is
> all based on extensive studies.
> 
> The decision to enable DSC or not has an impact on the power consumption
> of the HW, in ways that are often nuanced. Userspace has no way to know
> or understand these nuances. This should be in control of the driver.

I guess time will tell.

Are you saying that enabling DSC might have disadvantages aside from
image quality?

> At most I could see a "never do DSC or dither" toggle, if one is really
> concerned about this, but I don't realistically see use-cases where this
> would improve user experience, even for users that care about color work
> and correctness.

I'm not familiar with DSC, so I cannot criticise it. Dithering OTOH
seems to be obviously suspect though.

Temporal dithering - what if your refresh rate is 30 Hz for some movie
playback?

Spatial dithering - what if you have a low-resolution screen?

I would not assume that dithering is always ok, and always achieves its
theoretical results.

> The YCbCr420 case is different. We probably want a way for userspace to
> understand that half 3/4 of chroma values are being tossed out. This
> would be significant for RGB content but insignificant for YCbCr420
> content.

Do you mean full resolution vs. chroma sub-sampled to 2x2 blocks? I
would again not assume "insignificant", because it depends on the
picture content and angular pixel density (can you see individual
pixels at your viewing distance). Gray-scale text will be fine, but
colored text is another question.

I'm fine with proceeding with these assumptions, as long as it is
acknowledged that these assumptions might turn out false later and have
a contingency plan.


Thanks,
pq

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

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

[Pekka Paalanen]

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

On Tue, 31 Mar 2026 10:01:59 +0200
Michel Dänzer <michel.daenzer@mailbox.org> wrote:

> On 3/26/26 14:53, Pekka Paalanen wrote:
> > 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.  
> 
> I don't disagree, this needs to be made clear in the documentation
> though, if not reflected in the property name itself.
> 
> 
> >> * 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.  
> 
> This series and the corresponding Weston MR aren't enough to address
> that use case though, are they? All they achieve is logging a
> potentially misleading warning.
> 
> It might make sense to combine this series and the Weston MR with
> whatever else is needed for that use case.

What do you believe is missing?

Informing the user that the display quality may not be as expected is
the point. Weston does not have any other kind of UI atm. than printing
to the log.

> > I had another use case in
> > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686  
> 
> That would need to take dithering into account as well?

Yes, dithering could be an adverse effect or not sufficient. Hence the
'link bpc' property should not consider any kind of dithering, to be on
the safe side. I fully expect dithering to become explicitly
controllable, as policy belongs in userspace.

The point of dithering is to adjust the stimuli on screen, that is, to
make a visible difference on dithered vs. not. Maintaining a display
profile valid requires keeping the stimuli response as it was during
profiling. Therefore turning dithering on or off would invalidate the
profile in cases where dithering is useful.

> > Mario Kleiner had excellent cases as well.  
> 
> I raised unanswered questions on those.
> 
> 
> >>> 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.  
> 
> That's not the only use case (in fact I'm not sure I'd heard of this
> before). E.g. it can also be used in cases where some HW bottleneck
> prevents using maximum refresh rate at maximum bpc for all displays,
> to explicitly choose which display(s) to limit bpc for, allowing max
> bpc for the rest.

That was what I came to understand when some years I dug into the
history to figure out why 'max bpc' was added initially. What you say
is another good use case considering the state of the UAPI which offers
no direct control.


Thanks,
pq

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

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

[Pekka Paalanen]

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

On Mon, 30 Mar 2026 14:52:23 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2026-03-30 12:57, Michel Dänzer wrote:
> > On 3/26/26 13:17, Nicolas Frattaroli wrote:  
> >> 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?  
> > 
> > Not really, no. They achieve higher "effective" (as perceived by
> > the user) bpc using a lower physical bpc.
> > 
> >   
> >> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's
> >> still 10 bits.  
> > 
> > If DSC encodes user-perceived 10 bpc at a lower physical bpc, and
> > the "link bpc" property reports 10, that would satisfy my concern
> > for DSC. 
> 
> Conceptually I would understand DSC to not effect the reported bpc, so
> a 10bpc output bpc would be reported as 10bpc via the property, but
> DSC would compress that down to a lower value on the wire.
> 
> Dithering wouldn't do that. An 8bpc output would be reported as 8bpc
> even if dithering makes it perceptually look like 10bpc.

That seems quite arbitrary, but ok, that could work.

> I can understand the challenge of how to intelligently use it to
> report anything back to users. I could see some compositors being happy
> to use the bpc alone, while others might want to know dithering and/or
> DSC state (compression ratio?) as well.

People who care about the picture quality down to these levels will
likely want to know and learn about these techniques. They may also
want to explicitly control them.

In time, when these have been used enough in the wild, compositor
developers will learn what makes a difference and what does not, so
they will adjust their reporting to end users. The most important thing
for the kernel is it offer an unambiguous and stable UAPI for these.

Policy belongs in userspace.


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/31/26 14:38, Pekka Paalanen wrote:
> On Tue, 31 Mar 2026 10:01:59 +0200
> Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>> On 3/26/26 14:53, Pekka Paalanen wrote:
>>> On Tue, 24 Mar 2026 17:44:21 +0100
>>> Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>>>   
>>>> * 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.  
>>
>> This series and the corresponding Weston MR aren't enough to address
>> that use case though, are they? All they achieve is logging a
>> potentially misleading warning.
>>
>> It might make sense to combine this series and the Weston MR with
>> whatever else is needed for that use case.
> 
> What do you believe is missing?

For the stated use case, e.g. a mechanism to control RGB vs YCbCr?


> Informing the user that the display quality may not be as expected is
> the point.

The warning implies that the "link bpc" value is expected to match the "max bpc" value, which generally isn't the case.


>>> I had another use case in
>>> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686  
>>
>> That would need to take dithering into account as well?
> 
> Yes, dithering could be an adverse effect or not sufficient. Hence the
> 'link bpc' property should not consider any kind of dithering, to be on
> the safe side. I fully expect dithering to become explicitly
> controllable, as policy belongs in userspace.

I agree that would be ideal, alas it's not current reality.


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

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

[Pekka Paalanen]

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

On Tue, 31 Mar 2026 14:56:22 +0200
Michel Dänzer <michel.daenzer@mailbox.org> wrote:

> On 3/31/26 14:38, Pekka Paalanen wrote:
> > On Tue, 31 Mar 2026 10:01:59 +0200
> > Michel Dänzer <michel.daenzer@mailbox.org> wrote:  
> >> On 3/26/26 14:53, Pekka Paalanen wrote:  
> >>> On Tue, 24 Mar 2026 17:44:21 +0100
> >>> Michel Dänzer <michel.daenzer@mailbox.org> wrote:
> >>>     
> >>>> * 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.    
> >>
> >> This series and the corresponding Weston MR aren't enough to address
> >> that use case though, are they? All they achieve is logging a
> >> potentially misleading warning.
> >>
> >> It might make sense to combine this series and the Weston MR with
> >> whatever else is needed for that use case.  
> > 
> > What do you believe is missing?  
> 
> For the stated use case, e.g. a mechanism to control RGB vs YCbCr?

There is no need for that. Currently the driver chooses the color model
and depth on its own. We just want to make sure it's not too low.

This will remain useful when userspace can explicitly control more
things. I think all stream parameters should have an "auto" value and a
feedback property, plus a property to explicitly set something. That
allows userspace to light up anything any way possible, but also to try
and make decisions about what it exactly wants.

A consistent naming scheme for stream for setter vs. feedback
properties would be nice, though I'm not sure if that boat already
sailed.

> > Informing the user that the display quality may not be as expected
> > is the point.  
> 
> The warning implies that the "link bpc" value is expected to match
> the "max bpc" value, which generally isn't the case.

Yes, that's why I wrote
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686

> >>> I had another use case in
> >>> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686    
> >>
> >> That would need to take dithering into account as well?  
> > 
> > Yes, dithering could be an adverse effect or not sufficient. Hence the
> > 'link bpc' property should not consider any kind of dithering, to be on
> > the safe side. I fully expect dithering to become explicitly
> > controllable, as policy belongs in userspace.  
> 
> I agree that would be ideal, alas it's not current reality.

One step at a time, eyes on the prize.


Thanks,
pq


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

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

[Harry Wentland]

On 2026-03-31 06:28, Pekka Paalanen wrote:
> On Mon, 30 Mar 2026 15:01:33 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> On 2026-03-26 09:53, Pekka Paalanen wrote:
>>> 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?
>>>   
>>
>> I disagree. While technically lossy, DSC is perceptually lossless, at
>> least according to the designers of DSC. If I'm not mistaken this is
>> all based on extensive studies.
>>
>> The decision to enable DSC or not has an impact on the power consumption
>> of the HW, in ways that are often nuanced. Userspace has no way to know
>> or understand these nuances. This should be in control of the driver.
> 
> I guess time will tell.
> 
> Are you saying that enabling DSC might have disadvantages aside from
> image quality?
> 

The opposite; enabling DSC might have advantages, in particular in power
efficiency. And image quality impacts are negligible or (perceptually)
non-existant, from my understanding. Afaik, Apple, which prides itself
on image quality and being a platform for content producers, enables DSC
by default on their systems.

>> At most I could see a "never do DSC or dither" toggle, if one is really
>> concerned about this, but I don't realistically see use-cases where this
>> would improve user experience, even for users that care about color work
>> and correctness.
> 
> I'm not familiar with DSC, so I cannot criticise it. Dithering OTOH
> seems to be obviously suspect though.
> 
> Temporal dithering - what if your refresh rate is 30 Hz for some movie
> playback?
> 
> Spatial dithering - what if you have a low-resolution screen?
> 
> I would not assume that dithering is always ok, and always achieves its
> theoretical results.
> 

Quite possibly, but we haven't really seen complaints about dither other
than in scenarios where people explictly test that input pixels equal
output pixels exactly.

>> The YCbCr420 case is different. We probably want a way for userspace to
>> understand that half 3/4 of chroma values are being tossed out. This
>> would be significant for RGB content but insignificant for YCbCr420
>> content.
> 
> Do you mean full resolution vs. chroma sub-sampled to 2x2 blocks? I
> would again not assume "insignificant", because it depends on the
> picture content and angular pixel density (can you see individual
> pixels at your viewing distance). Gray-scale text will be fine, but
> colored text is another question.
> 

Yes. I think downgrading an output to YCbCr420 (chroma sub-sampled to
2x2 blocks) is a significant image quality impact.

> I'm fine with proceeding with these assumptions, as long as it is
> acknowledged that these assumptions might turn out false later and have
> a contingency plan.
> 

I guess that goes to Michel's question about what's expected of
compositors here and whether there is clarity... I'm not sure
I really have an answer on that other than documenting our
expectations.

Harry

> 
> Thanks,
> pq

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

[Harry Wentland]

On 2026-03-31 08:50, Pekka Paalanen wrote:
> On Mon, 30 Mar 2026 14:52:23 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> On 2026-03-30 12:57, Michel Dänzer wrote:
>>> On 3/26/26 13:17, Nicolas Frattaroli wrote:  
>>>> 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?  
>>>
>>> Not really, no. They achieve higher "effective" (as perceived by
>>> the user) bpc using a lower physical bpc.
>>>
>>>   
>>>> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's
>>>> still 10 bits.  
>>>
>>> If DSC encodes user-perceived 10 bpc at a lower physical bpc, and
>>> the "link bpc" property reports 10, that would satisfy my concern
>>> for DSC. 
>>
>> Conceptually I would understand DSC to not effect the reported bpc, so
>> a 10bpc output bpc would be reported as 10bpc via the property, but
>> DSC would compress that down to a lower value on the wire.
>>
>> Dithering wouldn't do that. An 8bpc output would be reported as 8bpc
>> even if dithering makes it perceptually look like 10bpc.
> 
> That seems quite arbitrary, but ok, that could work.
> 
>> I can understand the challenge of how to intelligently use it to
>> report anything back to users. I could see some compositors being happy
>> to use the bpc alone, while others might want to know dithering and/or
>> DSC state (compression ratio?) as well.
> 
> People who care about the picture quality down to these levels will
> likely want to know and learn about these techniques. They may also
> want to explicitly control them.
> 
> In time, when these have been used enough in the wild, compositor
> developers will learn what makes a difference and what does not, so
> they will adjust their reporting to end users. The most important thing
> for the kernel is it offer an unambiguous and stable UAPI for these.
> 
> Policy belongs in userspace.
> 

I don't like this as a blanket statement. There is a lot of policy that
intersects with HW nuances, whether it comes to power or otherwise.
Taking away driver vendor's abilities to optimize will hurt the Linux
ecosystem in the long run.

IMO this needs to be evaluated on a case by case basis. There are
many places where it does make sense to give userspace a greater
say on policy, but we don't want to push driver (HW specific) logic
up into userspace.

Harry

> 
> Thanks,
> pq

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

[Michel Dänzer]

On 3/31/26 16:21, Pekka Paalanen wrote:
> On Tue, 31 Mar 2026 14:56:22 +0200
> Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>> On 3/31/26 14:38, Pekka Paalanen wrote:
>>> On Tue, 31 Mar 2026 10:01:59 +0200
>>> Michel Dänzer <michel.daenzer@mailbox.org> wrote:  
>>>> On 3/26/26 14:53, Pekka Paalanen wrote:  
>>>>> On Tue, 24 Mar 2026 17:44:21 +0100
>>>>> Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>>>>>     
>>>>>> * 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.    
>>>>
>>>> This series and the corresponding Weston MR aren't enough to address
>>>> that use case though, are they? All they achieve is logging a
>>>> potentially misleading warning.
>>>>
>>>> It might make sense to combine this series and the Weston MR with
>>>> whatever else is needed for that use case.  
>>>
>>> What do you believe is missing?  
>>
>> For the stated use case, e.g. a mechanism to control RGB vs YCbCr?
> 
> There is no need for that. Currently the driver chooses the color model
> and depth on its own. We just want to make sure it's not too low.

What can be done when it's too low though? The only thing I can see is setting a higher "max bpc" value. If that's acceptable and helps though, why was the lower value set in the first place? (Otherwise the weston MR doesn't log the warning)


I feel like I'm still missing a piece of the picture for the practical use.


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

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

[Daniel Stone]

Hi Harry,

On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote:
> On 2026-03-31 08:50, Pekka Paalanen wrote:
> > People who care about the picture quality down to these levels will
> > likely want to know and learn about these techniques. They may also
> > want to explicitly control them.
> >
> > In time, when these have been used enough in the wild, compositor
> > developers will learn what makes a difference and what does not, so
> > they will adjust their reporting to end users. The most important thing
> > for the kernel is it offer an unambiguous and stable UAPI for these.
> >
> > Policy belongs in userspace.
>
> I don't like this as a blanket statement. There is a lot of policy that
> intersects with HW nuances, whether it comes to power or otherwise.
> Taking away driver vendor's abilities to optimize will hurt the Linux
> ecosystem in the long run.
>
> IMO this needs to be evaluated on a case by case basis. There are
> many places where it does make sense to give userspace a greater
> say on policy, but we don't want to push driver (HW specific) logic
> up into userspace.

It's not something that's _just_ specific to a particular
display-controller manufacturer or a particular IP generation though.
It very much depends on the usecase.

If you have a laptop and you're trying to give a presentation,
applying dithering and/or DSC makes a lot of sense: you don't want
your battery to die, and the projector's probably going to obliterate
half the colour anyway, so might as well as go for the most efficient
thing.

If your laptop is plugged into your big display at home to write code,
applying DSC to cram the highest possible resolution + refresh in
would make sense. But if dithering only results in a marginal power
saving, and your laptop is charging anyway - why bother degrading
visual acuity?

If you're a media player, then you're in a good position to know what
would be good to go over the wire, because you know (& are possibly in
control of) the format over what comes in in the first place.

But everyone's tradeoffs are different, which is why sometimes the
best choice is to ultimately leave it up to the user. If you dig into
any media playback device (STBs running Android TV, Apple TV, Fire TV,
et al), you'll see that all of them ultimately allow overrides for bpc
/ colour model / subsampling / etc. Those aren't just there for fun,
but because they are usable to real people, and it's not possible for
Amlogic or MediaTek or Rockchip or whoever to statically decide that a
certain configuration is going to be best everywhere.

Right now we have drivers making magic per-vendor/SKU decisions,
without even so much as a feedback mechanism to userspace (unless you
count debugfs, maybe) so it can even figure out what's going on, let
alone control it. To properly support some of those usecases,
userspace needs to be able to control what goes out on the wire, but
as a first step, it just wants to be informed of what the driver even
did with the properties we gave it.

The end game of this isn't Weston logging something to stdout, it's to
surface things to userspace so it can guide the kernel into making a
good decision for usecases that may not be ones the silicon vendor
decided was 'probably the best thing' however many years ago.

Cheers,
Daniel

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

[Ville Syrjälä]

On Wed, Apr 01, 2026 at 09:40:15AM +0100, Daniel Stone wrote:
> Hi Harry,
> 
> On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote:
> > On 2026-03-31 08:50, Pekka Paalanen wrote:
> > > People who care about the picture quality down to these levels will
> > > likely want to know and learn about these techniques. They may also
> > > want to explicitly control them.
> > >
> > > In time, when these have been used enough in the wild, compositor
> > > developers will learn what makes a difference and what does not, so
> > > they will adjust their reporting to end users. The most important thing
> > > for the kernel is it offer an unambiguous and stable UAPI for these.
> > >
> > > Policy belongs in userspace.
> >
> > I don't like this as a blanket statement. There is a lot of policy that
> > intersects with HW nuances, whether it comes to power or otherwise.
> > Taking away driver vendor's abilities to optimize will hurt the Linux
> > ecosystem in the long run.
> >
> > IMO this needs to be evaluated on a case by case basis. There are
> > many places where it does make sense to give userspace a greater
> > say on policy, but we don't want to push driver (HW specific) logic
> > up into userspace.
> 
> It's not something that's _just_ specific to a particular
> display-controller manufacturer or a particular IP generation though.
> It very much depends on the usecase.
> 
> If you have a laptop and you're trying to give a presentation,
> applying dithering and/or DSC makes a lot of sense: you don't want
> your battery to die, and the projector's probably going to obliterate
> half the colour anyway, so might as well as go for the most efficient
> thing.
> 
> If your laptop is plugged into your big display at home to write code,
> applying DSC to cram the highest possible resolution + refresh in
> would make sense. But if dithering only results in a marginal power
> saving, and your laptop is charging anyway - why bother degrading
> visual acuity?
> 
> If you're a media player, then you're in a good position to know what
> would be good to go over the wire, because you know (& are possibly in
> control of) the format over what comes in in the first place.
> 
> But everyone's tradeoffs are different, which is why sometimes the
> best choice is to ultimately leave it up to the user. If you dig into
> any media playback device (STBs running Android TV, Apple TV, Fire TV,
> et al), you'll see that all of them ultimately allow overrides for bpc
> / colour model / subsampling / etc. Those aren't just there for fun,
> but because they are usable to real people, and it's not possible for
> Amlogic or MediaTek or Rockchip or whoever to statically decide that a
> certain configuration is going to be best everywhere.
> 
> Right now we have drivers making magic per-vendor/SKU decisions,
> without even so much as a feedback mechanism to userspace (unless you
> count debugfs, maybe) so it can even figure out what's going on, let
> alone control it. To properly support some of those usecases,
> userspace needs to be able to control what goes out on the wire, but
> as a first step, it just wants to be informed of what the driver even
> did with the properties we gave it.
> 
> The end game of this isn't Weston logging something to stdout, it's to
> surface things to userspace so it can guide the kernel into making a
> good decision for usecases that may not be ones the silicon vendor
> decided was 'probably the best thing' however many years ago.

I think the problem here is that no one even tried to make a
real userspace implementation. So it's very hard to judge if this
new property is actually usable in the end, or if it will just end
up as historical baggage that we have to carry around forever.

IMO just having userspace log what the kernel said does not fulfill
the "userspace implementation must be ready before new drm uapi is
merged" requirement. 

-- 
Ville Syrjälä
Intel

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

[Daniel Stone]

Hi,

On Wed, 1 Apr 2026 at 12:10, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Wed, Apr 01, 2026 at 09:40:15AM +0100, Daniel Stone wrote:
> > The end game of this isn't Weston logging something to stdout, it's to
> > surface things to userspace so it can guide the kernel into making a
> > good decision for usecases that may not be ones the silicon vendor
> > decided was 'probably the best thing' however many years ago.
>
> I think the problem here is that no one even tried to make a
> real userspace implementation. So it's very hard to judge if this
> new property is actually usable in the end, or if it will just end
> up as historical baggage that we have to carry around forever.
>
> IMO just having userspace log what the kernel said does not fulfill
> the "userspace implementation must be ready before new drm uapi is
> merged" requirement.

Sure. To be honest it seemed pretty obviously reflective of 'max bpc'.
Derek is working on a Weston implementation which uses 'link bpc' as
part of a control loop with 'max bpc' now, which should hopefully
satisfy that.

Cheers,
Daniel

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

[Xaver Hugl]

Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli
<nicolas.frattaroli@collabora.com>:
>
> 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.

Hi,
I think it's a really good idea to have a property for knowing the
actual bpc of the link... however, I do have one big concern with this
API specifically: It only gives me this information after a modeset.

With this limitation, I can at most show the user which bpc was chosen
after the apply display settings and have the end user manually test
and figure things out, but I cannot show in the UI which bpc will be
chosen with some configuration before they apply it, and I cannot do
atomic tests to find a desired tradeoff automatically on the
compositor side.

As a side note, for future patches relevant for compositors, please cc
wayland-devel. It really shouldn't be up to chance whether or not
compositor developers that would later use the API find out about it
before it's merged, and keeping track of all of dri-devel is way too
much to ask from userspace developers.

- Xaver

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

[Ville Syrjälä]

On Wed, Apr 01, 2026 at 01:57:08PM +0200, Xaver Hugl wrote:
> Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com>:
> >
> > 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.
> 
> Hi,
> I think it's a really good idea to have a property for knowing the
> actual bpc of the link... however, I do have one big concern with this
> API specifically: It only gives me this information after a modeset.
> 
> With this limitation, I can at most show the user which bpc was chosen
> after the apply display settings and have the end user manually test
> and figure things out, but I cannot show in the UI which bpc will be
> chosen with some configuration before they apply it, and I cannot do
> atomic tests to find a desired tradeoff automatically on the
> compositor side.

I think the idea of some kind of feedback properties in the atomic
commit has come up before, but no one has ever tried to implement them.

> 
> As a side note, for future patches relevant for compositors, please cc
> wayland-devel. It really shouldn't be up to chance whether or not
> compositor developers that would later use the API find out about it
> before it's merged, and keeping track of all of dri-devel is way too
> much to ask from userspace developers.
> 
> - Xaver

-- 
Ville Syrjälä
Intel

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

[Nicolas Frattaroli]

On Wednesday, 1 April 2026 13:57:08 Central European Summer Time Xaver Hugl wrote:
> Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com>:
> >
> > 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.
> 
> Hi,
> I think it's a really good idea to have a property for knowing the
> actual bpc of the link... however, I do have one big concern with this
> API specifically: It only gives me this information after a modeset.
> 
> With this limitation, I can at most show the user which bpc was chosen
> after the apply display settings and have the end user manually test
> and figure things out, but I cannot show in the UI which bpc will be
> chosen with some configuration before they apply it, and I cannot do
> atomic tests to find a desired tradeoff automatically on the
> compositor side.

To do this I'd need to see if there's some feedback mechanism for
the output configuration chosen by the atomic check phase, so that
userspace can then run a DRM_MODE_ATOMIC_TEST_ONLY and get the value
back somehow.

The current implementation wouldn't be able to do this since it
updates the property on commit_tail. I'll need to look into whether
drivers already have everything figured out with regards to link bpc
in the check phase, and how that would best be communicated to
userspace.

> As a side note, for future patches relevant for compositors, please cc
> wayland-devel. It really shouldn't be up to chance whether or not
> compositor developers that would later use the API find out about it
> before it's merged, and keeping track of all of dri-devel is way too
> much to ask from userspace developers.

I'll do that, but consider using lei[1] to have saved searches on lore
delivered to a local Mailbox, a suitable query here may be

    dfb:drm_property

which will return all e-mails with diffs matching added lines with
"drm_property" in them, from which lei can then fetch the full
threads.

> 
> - Xaver
> 

Kind regards,
Nicolas Frattaroli

https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started [1]

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

[Daniel Stone]

On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> I think the idea of some kind of feedback properties in the atomic
> commit has come up before, but no one has ever tried to implement them.

Yeah, if you're looking for context on these, the last place I
remember it coming up was wanting to know which other objects would
potentially be dragged into a commit. For example, on ye olde (?)
Intel platforms, if programming a different mode is actually
stop-the-world where all other CRTCs get affected by a CDCLK change,
being able to know that those other CRTCs would be affected before it
happens, rather than random -EBUSY after the fact.

Cheers,
Daniel

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

[Nicolas Frattaroli]

Chiming in here to basically agree with Daniel and underline his point with
some evidence.

On Wednesday, 1 April 2026 10:40:15 Central European Summer Time Daniel Stone wrote:
> Hi Harry,
> 
> On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote:
> > On 2026-03-31 08:50, Pekka Paalanen wrote:
> > > People who care about the picture quality down to these levels will
> > > likely want to know and learn about these techniques. They may also
> > > want to explicitly control them.
> > >
> > > In time, when these have been used enough in the wild, compositor
> > > developers will learn what makes a difference and what does not, so
> > > they will adjust their reporting to end users. The most important thing
> > > for the kernel is it offer an unambiguous and stable UAPI for these.
> > >
> > > Policy belongs in userspace.
> >
> > I don't like this as a blanket statement. There is a lot of policy that
> > intersects with HW nuances, whether it comes to power or otherwise.
> > Taking away driver vendor's abilities to optimize will hurt the Linux
> > ecosystem in the long run.
> >
> > IMO this needs to be evaluated on a case by case basis. There are
> > many places where it does make sense to give userspace a greater
> > say on policy, but we don't want to push driver (HW specific) logic
> > up into userspace.
> 
> It's not something that's _just_ specific to a particular
> display-controller manufacturer or a particular IP generation though.
> It very much depends on the usecase.
> 
> If you have a laptop and you're trying to give a presentation,
> applying dithering and/or DSC makes a lot of sense: you don't want
> your battery to die, and the projector's probably going to obliterate
> half the colour anyway, so might as well as go for the most efficient
> thing.
> 
> If your laptop is plugged into your big display at home to write code,
> applying DSC to cram the highest possible resolution + refresh in
> would make sense. But if dithering only results in a marginal power
> saving, and your laptop is charging anyway - why bother degrading
> visual acuity?

This kind of encourages me to say that the meaning of "bpc" here should
either be reduced by all compression (of which I see dithering as a
primitive variant of) or left at the uncompressed bpc for all compression.

I'm leaning towards the latter. 10bpc lossily compressed to 8bpc is likely
a better choice than plain 8bpc for visual clarity, so making them look the
same to userspace would result in some odd choices. At the same time, having
a separate way for userspace to know of any compression techniques applied
on the output would disambiguate that for those compositors that really care,
and would also mean we don't have to make subjective judgement calls for
anyone.

With regards to DSC for example, any vendor's decision to enable it by
default does not necessarily give us a good precedent for what side to
err on. amdgpu flips on DSC when it doesn't have to, and this has rubbed
some people wrong: https://gitlab.freedesktop.org/drm/amd/-/work_items/2043

The goal isn't so much to push driver logic into userspace, but to give
userspace a view into what the driver did, so that it can decide whether
it's happy or wants to try again differently. This means userspace isn't
ossifying on a set of parameters that made sense a decade ago; drivers can
still modify their decisions as they develop and hardware gains new
techniques.

> 
> If you're a media player, then you're in a good position to know what
> would be good to go over the wire, because you know (& are possibly in
> control of) the format over what comes in in the first place.
> 
> But everyone's tradeoffs are different, which is why sometimes the
> best choice is to ultimately leave it up to the user. If you dig into
> any media playback device (STBs running Android TV, Apple TV, Fire TV,
> et al), you'll see that all of them ultimately allow overrides for bpc
> / colour model / subsampling / etc. Those aren't just there for fun,
> but because they are usable to real people, and it's not possible for
> Amlogic or MediaTek or Rockchip or whoever to statically decide that a
> certain configuration is going to be best everywhere.
> 
> Right now we have drivers making magic per-vendor/SKU decisions,
> without even so much as a feedback mechanism to userspace (unless you
> count debugfs, maybe) so it can even figure out what's going on, let
> alone control it. To properly support some of those usecases,
> userspace needs to be able to control what goes out on the wire, but
> as a first step, it just wants to be informed of what the driver even
> did with the properties we gave it.
> 
> The end game of this isn't Weston logging something to stdout, it's to
> surface things to userspace so it can guide the kernel into making a
> good decision for usecases that may not be ones the silicon vendor
> decided was 'probably the best thing' however many years ago.
> 
> Cheers,
> Daniel
> 

Kind regards,
Nicolas Frattaroli

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

[Ville Syrjälä]

On Wed, Apr 01, 2026 at 01:25:31PM +0100, Daniel Stone wrote:
> On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > I think the idea of some kind of feedback properties in the atomic
> > commit has come up before, but no one has ever tried to implement them.
> 
> Yeah, if you're looking for context on these, the last place I
> remember it coming up was wanting to know which other objects would
> potentially be dragged into a commit. For example, on ye olde (?)
> Intel platforms, if programming a different mode is actually
> stop-the-world where all other CRTCs get affected by a CDCLK change,
> being able to know that those other CRTCs would be affected before it
> happens, rather than random -EBUSY after the fact.

For the success cases I think it should be pretty straightforward
to just walk the props in the commit again after the atomic check
and write back all the feedback values from the computed state.

I think adding this for error cases would be much harder. We'd have to
somehow make sure the value(s) we write back to userspace are at least
somewhat valid even though the state check may have failed half way
through.

Although that specific -EBUSY you mention I think is checked after
the actual atomic check, so it would work there. Assuming we'd have
a place for eg. the affected crtcs bitmask in the ioctl structure...

And speaking of which, if you'll permit me to go off on another
tangent, I have occasionally pondered introducing per-device
properties. We could introduce a new object type for the whole
device, and add a new enumeration thing to find it. Then per-device
properties could be added to atomic commits exactly like any other
properties. My original idea was to use this for some kind of
device wide "power vs. performance" knob, but it could also be
used for this affected crtcs bitmask feedback.

-- 
Ville Syrjälä
Intel

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

[Ville Syrjälä]

On Wed, Apr 01, 2026 at 09:40:15AM +0100, Daniel Stone wrote:
> Hi Harry,
> 
> On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote:
> > On 2026-03-31 08:50, Pekka Paalanen wrote:
> > > People who care about the picture quality down to these levels will
> > > likely want to know and learn about these techniques. They may also
> > > want to explicitly control them.
> > >
> > > In time, when these have been used enough in the wild, compositor
> > > developers will learn what makes a difference and what does not, so
> > > they will adjust their reporting to end users. The most important thing
> > > for the kernel is it offer an unambiguous and stable UAPI for these.
> > >
> > > Policy belongs in userspace.
> >
> > I don't like this as a blanket statement. There is a lot of policy that
> > intersects with HW nuances, whether it comes to power or otherwise.
> > Taking away driver vendor's abilities to optimize will hurt the Linux
> > ecosystem in the long run.
> >
> > IMO this needs to be evaluated on a case by case basis. There are
> > many places where it does make sense to give userspace a greater
> > say on policy, but we don't want to push driver (HW specific) logic
> > up into userspace.
> 
> It's not something that's _just_ specific to a particular
> display-controller manufacturer or a particular IP generation though.
> It very much depends on the usecase.
> 
> If you have a laptop and you're trying to give a presentation,
> applying dithering and/or DSC makes a lot of sense: you don't want
> your battery to die, and the projector's probably going to obliterate
> half the colour anyway, so might as well as go for the most efficient
> thing.

BTW DSC is not free. The compressor does actual work, which takes
energy. DSC may be a win power wise if you can then reduce the link
frequency (+ some internal voltages/etc.). But if you can't reduce
anything then all you really end up doing is burning more power
compressing things needlessly. But it's all very hardware specific
of course. So having explicit userspace control for this stuff doesn't 
seem like the best idea, apart from maybe a "no DSC at all" knob for
the people who can't tolerate any kind of compression artifacts.


I've been musing about userspace being able to provide some kind of
relative quality weights for each output. The driver could then use
those to figure out how to balance the final bpc and compression
between the outputs. Something like this would let userspace express
its preference while still allowing the driver to decide how to
actually get there. 

Simple 'desired bpc' seem somewhat insufficient because I would
imagine userspace just sets that to max for everything at the start,
so the driver might not be able to tell which outputs can be degraded
harder than others.

I suppose a desired+min bpc might work, but would potentially force
userspace to tweak the parameters in some semi random fashion and
try again if the end result isn't appealing. And exactly what to
tweak is really hard for userspace to figure out since it has no
idea of the possibly complex internal/tbt/mst topologies, power
costs, etc.

> If your laptop is plugged into your big display at home to write code,
> applying DSC to cram the highest possible resolution + refresh in
> would make sense. But if dithering only results in a marginal power
> saving, and your laptop is charging anyway - why bother degrading
> visual acuity?
> 
> If you're a media player, then you're in a good position to know what
> would be good to go over the wire, because you know (& are possibly in
> control of) the format over what comes in in the first place.
> 
> But everyone's tradeoffs are different, which is why sometimes the
> best choice is to ultimately leave it up to the user. If you dig into
> any media playback device (STBs running Android TV, Apple TV, Fire TV,
> et al), you'll see that all of them ultimately allow overrides for bpc
> / colour model / subsampling / etc. Those aren't just there for fun,
> but because they are usable to real people, and it's not possible for
> Amlogic or MediaTek or Rockchip or whoever to statically decide that a
> certain configuration is going to be best everywhere.
> 
> Right now we have drivers making magic per-vendor/SKU decisions,
> without even so much as a feedback mechanism to userspace (unless you
> count debugfs, maybe) so it can even figure out what's going on, let
> alone control it. To properly support some of those usecases,
> userspace needs to be able to control what goes out on the wire, but
> as a first step, it just wants to be informed of what the driver even
> did with the properties we gave it.
> 
> The end game of this isn't Weston logging something to stdout, it's to
> surface things to userspace so it can guide the kernel into making a
> good decision for usecases that may not be ones the silicon vendor
> decided was 'probably the best thing' however many years ago.
> 
> Cheers,
> Daniel

-- 
Ville Syrjälä
Intel

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

[Daniel Stone]

On Wed, 1 Apr 2026 at 14:58, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> I've been musing about userspace being able to provide some kind of
> relative quality weights for each output. The driver could then use
> those to figure out how to balance the final bpc and compression
> between the outputs. Something like this would let userspace express
> its preference while still allowing the driver to decide how to
> actually get there.
>
> Simple 'desired bpc' seem somewhat insufficient because I would
> imagine userspace just sets that to max for everything at the start,
> so the driver might not be able to tell which outputs can be degraded
> harder than others.
>
> I suppose a desired+min bpc might work, but would potentially force
> userspace to tweak the parameters in some semi random fashion and
> try again if the end result isn't appealing. And exactly what to
> tweak is really hard for userspace to figure out since it has no
> idea of the possibly complex internal/tbt/mst topologies, power
> costs, etc.

I agree with everything you've written, apart from 'I would imagine
userspace just sets that to max for everything at the start'.

I've taken it as axiomatic that all of these things should have an
'auto' value, and have it as their default setting. Userspace _may_
know better than the IHV, but it's only going to know on a situational
basis.

Compositors blindly setting random tuneables to MAX_AWESOME_POWER
would be just as stupid as distros shipping ye olde Option
"AGPFastWrite" and Option "AGPMode" "8" by default. I'd expect any
userspace which blindly did that to immediately get as many bug
reports as they have users, and for them to fix it accordingly.

By analogy, we allow userspace to ignore EDID and set whatever cool
awesome mode it wants to. But it doesn't do that unless it has a very
very good reason to override the driver, and 99 times out of 100, that
reason is 'the user has figured out that this is required'.

Does that help?

Cheers,
Daniel

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

[Harry Wentland]

On 2026-04-01 04:40, Daniel Stone wrote:
> Hi Harry,
> 
> On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote:
>> On 2026-03-31 08:50, Pekka Paalanen wrote:
>>> People who care about the picture quality down to these levels will
>>> likely want to know and learn about these techniques. They may also
>>> want to explicitly control them.
>>>
>>> In time, when these have been used enough in the wild, compositor
>>> developers will learn what makes a difference and what does not, so
>>> they will adjust their reporting to end users. The most important thing
>>> for the kernel is it offer an unambiguous and stable UAPI for these.
>>>
>>> Policy belongs in userspace.
>>
>> I don't like this as a blanket statement. There is a lot of policy that
>> intersects with HW nuances, whether it comes to power or otherwise.
>> Taking away driver vendor's abilities to optimize will hurt the Linux
>> ecosystem in the long run.
>>
>> IMO this needs to be evaluated on a case by case basis. There are
>> many places where it does make sense to give userspace a greater
>> say on policy, but we don't want to push driver (HW specific) logic
>> up into userspace.
> 
> It's not something that's _just_ specific to a particular
> display-controller manufacturer or a particular IP generation though.
> It very much depends on the usecase.
> 
> If you have a laptop and you're trying to give a presentation,
> applying dithering and/or DSC makes a lot of sense: you don't want
> your battery to die, and the projector's probably going to obliterate
> half the colour anyway, so might as well as go for the most efficient
> thing.
> 
> If your laptop is plugged into your big display at home to write code,
> applying DSC to cram the highest possible resolution + refresh in
> would make sense. But if dithering only results in a marginal power
> saving, and your laptop is charging anyway - why bother degrading
> visual acuity?
> 
> If you're a media player, then you're in a good position to know what
> would be good to go over the wire, because you know (& are possibly in
> control of) the format over what comes in in the first place.
> 
> But everyone's tradeoffs are different, which is why sometimes the
> best choice is to ultimately leave it up to the user. If you dig into
> any media playback device (STBs running Android TV, Apple TV, Fire TV,
> et al), you'll see that all of them ultimately allow overrides for bpc
> / colour model / subsampling / etc. Those aren't just there for fun,
> but because they are usable to real people, and it's not possible for
> Amlogic or MediaTek or Rockchip or whoever to statically decide that a
> certain configuration is going to be best everywhere.
> 
> Right now we have drivers making magic per-vendor/SKU decisions,
> without even so much as a feedback mechanism to userspace (unless you
> count debugfs, maybe) so it can even figure out what's going on, let
> alone control it. To properly support some of those usecases,
> userspace needs to be able to control what goes out on the wire, but
> as a first step, it just wants to be informed of what the driver even
> did with the properties we gave it.
> 
> The end game of this isn't Weston logging something to stdout, it's to
> surface things to userspace so it can guide the kernel into making a
> good decision for usecases that may not be ones the silicon vendor
> decided was 'probably the best thing' however many years ago.
> 

I agree with you.

But I wanted to respond to the statement that "policy belongs in
userspace" and add a bit more nuance. It depends on the use-case
and in any case, it's important drivers have the ability to set a
good default policy for a given HW.

We're still missing a lot of toggles to allow userspace to select a
desired policy and I'm sure we'll be able to add those where needed
but I agree with Michel and Ville that we need to get the end-to-end
implementation right.

Harry

> Cheers,
> Daniel

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

[Harry Wentland]

On 2026-04-01 08:46, Nicolas Frattaroli wrote:
> Chiming in here to basically agree with Daniel and underline his point with
> some evidence.
> 
> On Wednesday, 1 April 2026 10:40:15 Central European Summer Time Daniel Stone wrote:
>> Hi Harry,
>>
>> On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote:
>>> On 2026-03-31 08:50, Pekka Paalanen wrote:
>>>> People who care about the picture quality down to these levels will
>>>> likely want to know and learn about these techniques. They may also
>>>> want to explicitly control them.
>>>>
>>>> In time, when these have been used enough in the wild, compositor
>>>> developers will learn what makes a difference and what does not, so
>>>> they will adjust their reporting to end users. The most important thing
>>>> for the kernel is it offer an unambiguous and stable UAPI for these.
>>>>
>>>> Policy belongs in userspace.
>>>
>>> I don't like this as a blanket statement. There is a lot of policy that
>>> intersects with HW nuances, whether it comes to power or otherwise.
>>> Taking away driver vendor's abilities to optimize will hurt the Linux
>>> ecosystem in the long run.
>>>
>>> IMO this needs to be evaluated on a case by case basis. There are
>>> many places where it does make sense to give userspace a greater
>>> say on policy, but we don't want to push driver (HW specific) logic
>>> up into userspace.
>>
>> It's not something that's _just_ specific to a particular
>> display-controller manufacturer or a particular IP generation though.
>> It very much depends on the usecase.
>>
>> If you have a laptop and you're trying to give a presentation,
>> applying dithering and/or DSC makes a lot of sense: you don't want
>> your battery to die, and the projector's probably going to obliterate
>> half the colour anyway, so might as well as go for the most efficient
>> thing.
>>
>> If your laptop is plugged into your big display at home to write code,
>> applying DSC to cram the highest possible resolution + refresh in
>> would make sense. But if dithering only results in a marginal power
>> saving, and your laptop is charging anyway - why bother degrading
>> visual acuity?
> 
> This kind of encourages me to say that the meaning of "bpc" here should
> either be reduced by all compression (of which I see dithering as a
> primitive variant of) or left at the uncompressed bpc for all compression.
> 
> I'm leaning towards the latter. 10bpc lossily compressed to 8bpc is likely
> a better choice than plain 8bpc for visual clarity, so making them look the
> same to userspace would result in some odd choices. At the same time, having
> a separate way for userspace to know of any compression techniques applied
> on the output would disambiguate that for those compositors that really care,
> and would also mean we don't have to make subjective judgement calls for
> anyone.
> 
> With regards to DSC for example, any vendor's decision to enable it by
> default does not necessarily give us a good precedent for what side to
> err on. amdgpu flips on DSC when it doesn't have to, and this has rubbed
> some people wrong: https://gitlab.freedesktop.org/drm/amd/-/work_items/2043
> 

I fail to see a convincing explanation on how DSC degrades user experience.
No video or anything. It's somewhat difficult to judge the merit of a
ticket like that.

> The goal isn't so much to push driver logic into userspace, but to give
> userspace a view into what the driver did, so that it can decide whether
> it's happy or wants to try again differently. This means userspace isn't
> ossifying on a set of parameters that made sense a decade ago; drivers can
> still modify their decisions as they develop and hardware gains new
> techniques.
> 

I agree with this goal. First, reasonable defaults. Secondly, inform
userspace, thirdly, let userspace set different configs. In that order.
To get #2 and #3 right we need the conversation that Michel started.

Harry

>>
>> If you're a media player, then you're in a good position to know what
>> would be good to go over the wire, because you know (& are possibly in
>> control of) the format over what comes in in the first place.
>>
>> But everyone's tradeoffs are different, which is why sometimes the
>> best choice is to ultimately leave it up to the user. If you dig into
>> any media playback device (STBs running Android TV, Apple TV, Fire TV,
>> et al), you'll see that all of them ultimately allow overrides for bpc
>> / colour model / subsampling / etc. Those aren't just there for fun,
>> but because they are usable to real people, and it's not possible for
>> Amlogic or MediaTek or Rockchip or whoever to statically decide that a
>> certain configuration is going to be best everywhere.
>>
>> Right now we have drivers making magic per-vendor/SKU decisions,
>> without even so much as a feedback mechanism to userspace (unless you
>> count debugfs, maybe) so it can even figure out what's going on, let
>> alone control it. To properly support some of those usecases,
>> userspace needs to be able to control what goes out on the wire, but
>> as a first step, it just wants to be informed of what the driver even
>> did with the properties we gave it.
>>
>> The end game of this isn't Weston logging something to stdout, it's to
>> surface things to userspace so it can guide the kernel into making a
>> good decision for usecases that may not be ones the silicon vendor
>> decided was 'probably the best thing' however many years ago.
>>
>> Cheers,
>> Daniel
>>
> 
> Kind regards,
> Nicolas Frattaroli
> 
> 

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

[Michel Dänzer]

On 4/1/26 14:14, Nicolas Frattaroli wrote:
> On Wednesday, 1 April 2026 13:57:08 Central European Summer Time Xaver Hugl wrote:
>> Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli
>> <nicolas.frattaroli@collabora.com>:
>>>
>>> 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.
>>
>> Hi,
>> I think it's a really good idea to have a property for knowing the
>> actual bpc of the link... however, I do have one big concern with this
>> API specifically: It only gives me this information after a modeset.
>>
>> With this limitation, I can at most show the user which bpc was chosen
>> after the apply display settings and have the end user manually test
>> and figure things out, but I cannot show in the UI which bpc will be
>> chosen with some configuration before they apply it, and I cannot do
>> atomic tests to find a desired tradeoff automatically on the
>> compositor side.
> 
> To do this I'd need to see if there's some feedback mechanism for
> the output configuration chosen by the atomic check phase, so that
> userspace can then run a DRM_MODE_ATOMIC_TEST_ONLY and get the value
> back somehow.
> 
> The current implementation wouldn't be able to do this since it
> updates the property on commit_tail. I'll need to look into whether
> drivers already have everything figured out with regards to link bpc
> in the check phase, and how that would best be communicated to
> userspace.

Taking both the Weston use case described in this thread and Xaver's requirements into account, a "min bpc" property complementing the "max bpc" one (as suggested by Ville before) might be better than "link bpc".

That might be a better fit even just for the Weston use case described in this thread, since AFAICT that only really cares about the minimum bpc, not the maximum.

The compositor could set "min bpc" to any value <= the "max bpc" one. If the driver can't make things work with effective bpc >= "min bpc", the commit fails. Setting both properties to the same value would allow selecting a specific bpc. That would allow compositors to find possible bpc permutations using TEST_ONLY commits, as described by Xaver.

Setting "min bpc" to 0 (which should probably be the default value) would allow any bpc, i.e. "auto" behaviour.


One potential issue with the "min bpc" property is that if one DRM master leaves it at a non-0 value, and a later DRM master doesn't know about it yet, it might cause surprising commit failures for the latter. This kind of issue already exists with other properties though. (Some kind of "default state" mechanism might help for solving this kind of issue)


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