linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 00/17] New uAPI drm properties for color management
@ 2021-06-18  9:10 Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Werner Sembach
                   ` (16 more replies)
  0 siblings, 17 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:10 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete
albeit not fully tested.

I have not yet corrected the DSC behavior and double checked the dithering
behavior. I release the feature complete patch series now anyways so that
work on the userspace implementation can start.

I have no DP MST splitter at hand. I tried my best to not break anything,
but if one who has one could test it would be very helpful.

amdgpu in the former implementation was full color range only, albeit there
was a path prepared for limited color range on both rgb and ycbcr encoding,
which was never selected however. With the Broadcast RGB property, a user
can now select this program path.

On i915 Broadcast RGB still only affects rgb as ycbcr was and is always
limited with this driver, which I didn't change.

gma500 driver still uses it's own implementation of the "Broadcast RGB"
property, which doesn't have an "Automatic" setting. I too didn't touch
this as I can't test a corresponding card.



^ permalink raw reply	[flat|nested] 57+ messages in thread

* [PATCH v4 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 02/17] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc Werner Sembach
                   ` (15 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.

Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.

This patch also moves both checks in the same if-case. This  eliminates an
extra else-if-case.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

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 6fda0dfb78f8..44757720b15f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5353,10 +5353,7 @@ static void fill_stream_properties_from_drm_display_mode(
 	timing_out->v_border_bottom = 0;
 	/* TODO: un-hardcode */
 	if (drm_mode_is_420_only(info, mode_in)
-			&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-		timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-	else if (drm_mode_is_420_also(info, mode_in)
-			&& aconnector->force_yuv420_output)
+			|| (drm_mode_is_420_also(info, mode_in) && aconnector->force_yuv420_output))
 		timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
 	else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCRCB444)
 			&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 02/17] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property Werner Sembach
                   ` (14 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to
an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_111111
missing.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++++
 1 file changed, 4 insertions(+)

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 44757720b15f..cd1df5cf4815 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6705,6 +6705,10 @@ static int convert_dc_color_depth_into_bpc (enum dc_color_depth display_color_de
 			return 14;
 		case COLOR_DEPTH_161616:
 			return 16;
+		case COLOR_DEPTH_999:
+			return 9;
+		case COLOR_DEPTH_111111:
+			return 11;
 		default:
 			break;
 		}
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 02/17] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-22  6:46   ` Pekka Paalanen
  2021-06-28 17:03   ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 04/17] drm/amd/display: Add handling for new "active bpc" property Werner Sembach
                   ` (13 subsequent siblings)
  16 siblings, 2 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

Add a new general drm property "active bpc" which can be used by graphic
drivers to report the applied bit depth per pixel back to userspace.

While "max bpc" can be used to change the color depth, there was no way to
check which one actually got used. While in theory the driver chooses the
best/highest color depth within the max bpc setting a user might not be
fully aware what his hardware is or isn't capable off. This is meant as a
quick way to double check the setup.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h     |  8 ++++++
 2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..943f6b61053b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	drm_connector_attach_max_bpc_property() to create and attach the
  *	property to the connector during initialization.
  *
+ * active bpc:
+ *	This read-only range property tells userspace the pixel color bit depth
+ *	actually used by the hardware display engine on "the cable" on a
+ *	connector. The chosen value depends on hardware capabilities, both
+ *	display engine and connected monitor, and the "max bpc" property.
+ *	Drivers shall use drm_connector_attach_active_bpc_property() to install
+ *	this property.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
 
+/**
+ * drm_connector_attach_active_bpc_property - attach "active bpc" property
+ * @connector: connector to attach active bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used to check the applied bit depth on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if (!connector->active_bpc_property) {
+		prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "active bpc",
+						 min, max);
+		if (!prop)
+			return -ENOMEM;
+
+		connector->active_bpc_property = prop;
+		drm_object_attach_property(&connector->base, prop, 0);
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
+/**
+ * drm_connector_set_active_bpc_property - sets the active bits per color property for a connector
+ * @connector: drm connector
+ * @active_bpc: bits per color for the connector currently active on "the cable"
+ *
+ * Should be used by atomic drivers to update the active bits per color over a connector.
+ */
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc)
+{
+	drm_object_property_set_value(&connector->base, connector->active_bpc_property, active_bpc);
+}
+EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..eee86de62a5f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1380,6 +1380,12 @@ struct drm_connector {
 	 */
 	struct drm_property *max_bpc_property;
 
+	/**
+	 * @active_bpc_property: Default connector property for the active bpc
+	 * to be driven out of the connector.
+	 */
+	struct drm_property *active_bpc_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
 #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	int width, int height);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
+int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
+void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 04/17] drm/amd/display: Add handling for new "active bpc" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (2 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 05/17] drm/i915/display: " Werner Sembach
                   ` (12 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "active bpc" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++++++++++++++++++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 ++++
 2 files changed, 22 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 cd1df5cf4815..b6293b3104ed 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7713,8 +7713,10 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 				adev->mode_info.underscan_vborder_property,
 				0);
 
-	if (!aconnector->mst_port)
+	if (!aconnector->mst_port) {
 		drm_connector_attach_max_bpc_property(&aconnector->base, 8, 16);
+		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
+	}
 
 	/* This defaults to the max in the range, but we want 8bpc for non-edp. */
 	aconnector->base.state->max_bpc = (connector_type == DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -9083,6 +9085,21 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
 		mutex_unlock(&dm->dc_lock);
 	}
 
+	/* Extract information from crtc to communicate it to userspace as connector properties */
+	for_each_new_connector_in_state(state, connector, new_con_state, i) {
+		struct drm_crtc *crtc = new_con_state->crtc;
+
+		if (crtc) {
+			new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+			dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+			if (dm_new_crtc_state->stream)
+				drm_connector_set_active_bpc_property(connector,
+					convert_dc_color_depth_into_bpc(
+					dm_new_crtc_state->stream->timing.display_color_depth));
+		} else
+			drm_connector_set_active_bpc_property(connector, 0);
+	}
+
 	/* Count number of newly disabled CRTCs for dropping PM refs later. */
 	for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
 				      new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5568d4e518e6..0cf38743ec47 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -409,6 +409,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
 	if (connector->max_bpc_property)
 		drm_connector_attach_max_bpc_property(connector, 8, 16);
 
+	connector->active_bpc_property = master->base.active_bpc_property;
+	if (connector->active_bpc_property)
+		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
+
 	connector->vrr_capable_property = master->base.vrr_capable_property;
 	if (connector->vrr_capable_property)
 		drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 05/17] drm/i915/display: Add handling for new "active bpc" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (3 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 04/17] drm/amd/display: Add handling for new "active bpc" property Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace Werner Sembach
                   ` (11 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "active bpc" drm property for the Intel GPU
driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/i915/display/intel_display.c | 17 +++++++++++++++++
 drivers/gpu/drm/i915/display/intel_dp.c      |  7 +++++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +++++
 drivers/gpu/drm/i915/display/intel_hdmi.c    |  4 +++-
 4 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 6be1b31af07b..4b00d2f3b3c8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10839,6 +10839,9 @@ static int intel_atomic_commit(struct drm_device *dev,
 {
 	struct intel_atomic_state *state = to_intel_atomic_state(_state);
 	struct drm_i915_private *dev_priv = to_i915(dev);
+	struct drm_connector *connector;
+	struct drm_connector_state *new_conn_state;
+	int i;
 	int ret = 0;
 
 	state->wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
@@ -10907,6 +10910,20 @@ static int intel_atomic_commit(struct drm_device *dev,
 	intel_shared_dpll_swap_state(state);
 	intel_atomic_track_fbs(state);
 
+	/* Extract information from crtc to communicate it to userspace as connector properties */
+	for_each_new_connector_in_state(&state->base, connector, new_conn_state, i) {
+		struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
+
+		if (crtc) {
+			struct intel_crtc_state *new_crtc_state =
+				intel_atomic_get_new_crtc_state(state, crtc);
+
+			drm_connector_set_active_bpc_property(connector,
+				new_crtc_state->pipe_bpp / 3);
+		} else
+			drm_connector_set_active_bpc_property(connector, 0);
+	}
+
 	drm_atomic_state_get(&state->base);
 	INIT_WORK(&state->base.commit_work, intel_atomic_commit_work);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c9222283044..2d7b5318ae7b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4688,10 +4688,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect
 		intel_attach_force_audio_property(connector);
 
 	intel_attach_broadcast_rgb_property(connector);
-	if (HAS_GMCH(dev_priv))
+	if (HAS_GMCH(dev_priv)) {
 		drm_connector_attach_max_bpc_property(connector, 6, 10);
-	else if (DISPLAY_VER(dev_priv) >= 5)
+		drm_connector_attach_active_bpc_property(connector, 6, 10);
+	} else if (DISPLAY_VER(dev_priv) >= 5) {
 		drm_connector_attach_max_bpc_property(connector, 6, 12);
+		drm_connector_attach_active_bpc_property(connector, 6, 12);
+	}
 
 	/* Register HDMI colorspace for case of lspcon */
 	if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b170e272bdee..16bfc59570a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -851,6 +851,11 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 	if (connector->max_bpc_property)
 		drm_connector_attach_max_bpc_property(connector, 6, 12);
 
+	connector->active_bpc_property =
+		intel_dp->attached_connector->base.active_bpc_property;
+	if (connector->active_bpc_property)
+		drm_connector_attach_active_bpc_property(connector, 6, 12);
+
 	return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 7e51c98c475e..9160e21ac9d6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2513,8 +2513,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c
 	if (DISPLAY_VER(dev_priv) >= 10)
 		drm_connector_attach_hdr_output_metadata_property(connector);
 
-	if (!HAS_GMCH(dev_priv))
+	if (!HAS_GMCH(dev_priv)) {
 		drm_connector_attach_max_bpc_property(connector, 8, 12);
+		drm_connector_attach_active_bpc_property(connector, 8, 12);
+	}
 }
 
 /*
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (4 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 05/17] drm/i915/display: " Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-22  6:48   ` Pekka Paalanen
  2021-06-18  9:11 ` [PATCH v4 07/17] drm/amd/display: Add handling for new "active color format" property Werner Sembach
                   ` (10 subsequent siblings)
  16 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.

There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor, the GPU, and the connection used and what the default
behaviour of the used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915
prefers RGB). This property helps eliminating the guessing on this point.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/drm_connector.c | 61 +++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h     |  9 +++++
 2 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 943f6b61053b..684d7abdf0eb 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
 	{ DRM_MODE_SUBCONNECTOR_Native,	     "Native"    }, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
+	{ 0, "unknown" },
+	{ DRM_COLOR_FORMAT_RGB444, "rgb" },
+	{ DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+	{ DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 		 drm_dp_subconnector_enum_list)
 
@@ -1205,6 +1213,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	Drivers shall use drm_connector_attach_active_bpc_property() to install
  *	this property.
  *
+ * active color format:
+ *	This read-only property tells userspace the color format actually used
+ *	by the hardware display engine on "the cable" on a connector. The chosen
+ *	value depends on hardware capabilities, both display engine and
+ *	connected monitor. Drivers shall use
+ *	drm_connector_attach_active_color_format_property() to install this
+ *	property.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2203,6 +2219,51 @@ void drm_connector_set_active_bpc_property(struct drm_connector *connector, int
 }
 EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
 
+/**
+ * drm_connector_attach_active_color_format_property - attach "active color format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if (!connector->active_color_format_property) {
+		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, "active color format",
+						drm_active_color_format_enum_list,
+						ARRAY_SIZE(drm_active_color_format_enum_list));
+		if (!prop)
+			return -ENOMEM;
+
+		connector->active_color_format_property = prop;
+		drm_object_attach_property(&connector->base, prop, 0);
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
+
+/**
+ * drm_connector_set_active_color_format_property - sets the active color format property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_format: color format for the connector currently active on "the cable"
+ *
+ * Should be used by atomic drivers to update the active color format over a connector.
+ */
+void drm_connector_set_active_color_format_property(struct drm_connector *connector,
+						    u32 active_color_format)
+{
+	drm_object_property_set_value(&connector->base, connector->active_color_format_property,
+				      active_color_format);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index eee86de62a5f..8a5197f14e87 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1386,6 +1386,12 @@ struct drm_connector {
 	 */
 	struct drm_property *active_bpc_property;
 
+	/**
+	 * @active_color_format_property: Default connector property for the
+	 * active color format to be driven out of the connector.
+	 */
+	struct drm_property *active_color_format_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
 #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1710,6 +1716,9 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
 void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
+int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
+void drm_connector_set_active_color_format_property(struct drm_connector *connector,
+						    u32 active_color_format);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 07/17] drm/amd/display: Add handling for new "active color format" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (5 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 08/17] drm/i915/display: " Werner Sembach
                   ` (9 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "active color format" drm property for the AMD
GPU driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++++++++++++++++--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 31 insertions(+), 2 deletions(-)

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 b6293b3104ed..5086d6d74bf6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6715,6 +6715,24 @@ static int convert_dc_color_depth_into_bpc (enum dc_color_depth display_color_de
 	return 0;
 }
 
+static int convert_dc_pixel_encoding_into_drm_color_format(
+	enum dc_pixel_encoding display_pixel_encoding)
+{
+	switch (display_pixel_encoding) {
+	case PIXEL_ENCODING_RGB:
+		return DRM_COLOR_FORMAT_RGB444;
+	case PIXEL_ENCODING_YCBCR422:
+		return DRM_COLOR_FORMAT_YCRCB422;
+	case PIXEL_ENCODING_YCBCR444:
+		return DRM_COLOR_FORMAT_YCRCB444;
+	case PIXEL_ENCODING_YCBCR420:
+		return DRM_COLOR_FORMAT_YCRCB420;
+	default:
+		break;
+	}
+	return 0;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 					  struct drm_crtc_state *crtc_state,
 					  struct drm_connector_state *conn_state)
@@ -7716,6 +7734,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 	if (!aconnector->mst_port) {
 		drm_connector_attach_max_bpc_property(&aconnector->base, 8, 16);
 		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
+		drm_connector_attach_active_color_format_property(&aconnector->base);
 	}
 
 	/* This defaults to the max in the range, but we want 8bpc for non-edp. */
@@ -9092,12 +9111,18 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
 		if (crtc) {
 			new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 			dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
-			if (dm_new_crtc_state->stream)
+			if (dm_new_crtc_state->stream) {
 				drm_connector_set_active_bpc_property(connector,
 					convert_dc_color_depth_into_bpc(
 					dm_new_crtc_state->stream->timing.display_color_depth));
-		} else
+				drm_connector_set_active_color_format_property(connector,
+					convert_dc_pixel_encoding_into_drm_color_format(
+					dm_new_crtc_state->stream->timing.pixel_encoding));
+			}
+		} else {
 			drm_connector_set_active_bpc_property(connector, 0);
+			drm_connector_set_active_color_format_property(connector, 0);
+		}
 	}
 
 	/* Count number of newly disabled CRTCs for dropping PM refs later. */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 0cf38743ec47..13151d13aa73 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
 	if (connector->active_bpc_property)
 		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
 
+	connector->active_color_format_property = master->base.active_color_format_property;
+	if (connector->active_color_format_property)
+		drm_connector_attach_active_color_format_property(&aconnector->base);
+
 	connector->vrr_capable_property = master->base.vrr_capable_property;
 	if (connector->vrr_capable_property)
 		drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 08/17] drm/i915/display: Add handling for new "active color format" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (6 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 07/17] drm/amd/display: Add handling for new "active color format" property Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace Werner Sembach
                   ` (8 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "active color format" drm property for the Intel
GPU driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/i915/display/intel_display.c | 22 +++++++++++++++++++-
 drivers/gpu/drm/i915/display/intel_dp.c      |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +++++
 drivers/gpu/drm/i915/display/intel_hdmi.c    |  1 +
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 4b00d2f3b3c8..57bec7f452d8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10609,6 +10609,21 @@ static void intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
 	}
 }
 
+static int convert_intel_output_format_into_drm_color_format(enum intel_output_format output_format)
+{
+	switch (output_format) {
+	case INTEL_OUTPUT_FORMAT_RGB:
+		return DRM_COLOR_FORMAT_RGB444;
+	case INTEL_OUTPUT_FORMAT_YCBCR420:
+		return DRM_COLOR_FORMAT_YCRCB420;
+	case INTEL_OUTPUT_FORMAT_YCBCR444:
+		return DRM_COLOR_FORMAT_YCRCB444;
+	default:
+		break;
+	}
+	return 0;
+}
+
 static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 {
 	struct drm_device *dev = state->base.dev;
@@ -10920,8 +10935,13 @@ static int intel_atomic_commit(struct drm_device *dev,
 
 			drm_connector_set_active_bpc_property(connector,
 				new_crtc_state->pipe_bpp / 3);
-		} else
+			drm_connector_set_active_color_format_property(connector,
+				convert_intel_output_format_into_drm_color_format(
+					new_crtc_state->output_format));
+		} else {
 			drm_connector_set_active_bpc_property(connector, 0);
+			drm_connector_set_active_color_format_property(connector, 0);
+		}
 	}
 
 	drm_atomic_state_get(&state->base);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 2d7b5318ae7b..9204bc14590a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4691,9 +4691,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect
 	if (HAS_GMCH(dev_priv)) {
 		drm_connector_attach_max_bpc_property(connector, 6, 10);
 		drm_connector_attach_active_bpc_property(connector, 6, 10);
+		drm_connector_attach_active_color_format_property(connector);
 	} else if (DISPLAY_VER(dev_priv) >= 5) {
 		drm_connector_attach_max_bpc_property(connector, 6, 12);
 		drm_connector_attach_active_bpc_property(connector, 6, 12);
+		drm_connector_attach_active_color_format_property(connector);
 	}
 
 	/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 16bfc59570a5..3e4237df3360 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 	if (connector->active_bpc_property)
 		drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+	connector->active_color_format_property =
+		intel_dp->attached_connector->base.active_color_format_property;
+	if (connector->active_color_format_property)
+		drm_connector_attach_active_color_format_property(connector);
+
 	return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9160e21ac9d6..367aba57b55f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2516,6 +2516,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c
 	if (!HAS_GMCH(dev_priv)) {
 		drm_connector_attach_max_bpc_property(connector, 8, 12);
 		drm_connector_attach_active_bpc_property(connector, 8, 12);
+		drm_connector_attach_active_color_format_property(connector);
 	}
 }
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (7 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 08/17] drm/i915/display: " Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-22  7:00   ` Pekka Paalanen
  2021-06-18  9:11 ` [PATCH v4 10/17] drm/amd/display: Add handling for new "active color range" property Werner Sembach
                   ` (7 subsequent siblings)
  16 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.

There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor and what the default behaviour of the used driver is. This
property helps eliminating the guessing at this point.

In the future, automatic color calibration for screens might also depend on
this information being available.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/drm_connector.c | 59 +++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h     | 27 +++++++++++++++
 2 files changed, 86 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 684d7abdf0eb..818de58d972f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -897,6 +897,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
 	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
 };
 
+static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
+	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
+	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
+	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 		 drm_dp_subconnector_enum_list)
 
@@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	drm_connector_attach_active_color_format_property() to install this
  *	property.
  *
+ * active color range:
+ *	This read-only property tells userspace the color range actually used by
+ *	the hardware display engine on "the cable" on a connector. The chosen
+ *	value depends on hardware capabilities of the monitor and the used color
+ *	format. Drivers shall use
+ *	drm_connector_attach_active_color_range_property() to install this
+ *	property.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2264,6 +2278,51 @@ void drm_connector_set_active_color_format_property(struct drm_connector *connec
 }
 EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
 
+/**
+ * drm_connector_attach_active_color_range_property - attach "active color range" property
+ * @connector: connector to attach active color range property on.
+ *
+ * This is used to check the applied color range on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_range_property(struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if (!connector->active_color_range_property) {
+		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, "active color range",
+						drm_active_color_range_enum_list,
+						ARRAY_SIZE(drm_active_color_range_enum_list));
+		if (!prop)
+			return -ENOMEM;
+
+		connector->active_color_range_property = prop;
+		drm_object_attach_property(&connector->base, prop, DRM_MODE_COLOR_RANGE_UNSET);
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
+
+/**
+ * drm_connector_set_active_color_range_property - sets the active color range property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_range: color range for the connector currently active on "the cable"
+ *
+ * Should be used by atomic drivers to update the active color range over a connector.
+ */
+void drm_connector_set_active_color_range_property(struct drm_connector *connector,
+						   enum drm_mode_color_range active_color_range)
+{
+	drm_object_property_set_value(&connector->base, connector->active_color_range_property,
+				      active_color_range);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
+
 /**
  * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
  * @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8a5197f14e87..9fb7119b7a02 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -648,6 +648,24 @@ struct drm_tv_connector_state {
 	unsigned int hue;
 };
 
+/**
+ * enum drm_mode_color_range - color_range info for &drm_connector
+ *
+ * This enum is used to represent full or limited color range on the display
+ * connector signal.
+ *
+ * @DRM_MODE_COLOR_RANGE_UNSET:		Color range is unspecified/default.
+ * @DRM_MODE_COLOR_RANGE_FULL:		Color range is full range, 0-255 for
+ *					8-Bit color depth.
+ * DRM_MODE_COLOR_RANGE_LIMITED_16_235:	Color range is limited range, 16-235 for
+ *					8-Bit color depth.
+ */
+enum drm_mode_color_range {
+	DRM_MODE_COLOR_RANGE_UNSET,
+	DRM_MODE_COLOR_RANGE_FULL,
+	DRM_MODE_COLOR_RANGE_LIMITED_16_235,
+};
+
 /**
  * struct drm_connector_state - mutable connector state
  */
@@ -1392,6 +1410,12 @@ struct drm_connector {
 	 */
 	struct drm_property *active_color_format_property;
 
+	/**
+	 * @active_color_range_property: Default connector property for the
+	 * active color range to be driven out of the connector.
+	 */
+	struct drm_property *active_color_range_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
 #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1719,6 +1743,9 @@ void drm_connector_set_active_bpc_property(struct drm_connector *connector, int
 int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
 void drm_connector_set_active_color_format_property(struct drm_connector *connector,
 						    u32 active_color_format);
+int drm_connector_attach_active_color_range_property(struct drm_connector *connector);
+void drm_connector_set_active_color_range_property(struct drm_connector *connector,
+						   enum drm_mode_color_range active_color_range);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 10/17] drm/amd/display: Add handling for new "active color range" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (8 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 11/17] drm/i915/display: " Werner Sembach
                   ` (6 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "active color range" drm property for the AMD
GPU driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++++++++++++++++++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 37 insertions(+)

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 5086d6d74bf6..bce47f28e20a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6733,6 +6733,33 @@ static int convert_dc_pixel_encoding_into_drm_color_format(
 	return 0;
 }
 
+static int convert_dc_color_space_into_drm_mode_color_range(enum dc_color_space color_space)
+{
+	if (color_space == COLOR_SPACE_SRGB ||
+	    color_space == COLOR_SPACE_XR_RGB ||
+	    color_space == COLOR_SPACE_MSREF_SCRGB ||
+	    color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
+	    color_space == COLOR_SPACE_ADOBERGB ||
+	    color_space == COLOR_SPACE_DCIP3 ||
+	    color_space == COLOR_SPACE_DOLBYVISION ||
+	    color_space == COLOR_SPACE_YCBCR601 ||
+	    color_space == COLOR_SPACE_XV_YCC_601 ||
+	    color_space == COLOR_SPACE_YCBCR709 ||
+	    color_space == COLOR_SPACE_XV_YCC_709 ||
+	    color_space == COLOR_SPACE_2020_YCBCR ||
+	    color_space == COLOR_SPACE_YCBCR709_BLACK ||
+	    color_space == COLOR_SPACE_DISPLAYNATIVE ||
+	    color_space == COLOR_SPACE_APPCTRL ||
+	    color_space == COLOR_SPACE_CUSTOMPOINTS)
+		return DRM_MODE_COLOR_RANGE_FULL;
+	if (color_space == COLOR_SPACE_SRGB_LIMITED ||
+	    color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
+	    color_space == COLOR_SPACE_YCBCR601_LIMITED ||
+	    color_space == COLOR_SPACE_YCBCR709_LIMITED)
+		return DRM_MODE_COLOR_RANGE_LIMITED_16_235;
+	return DRM_MODE_COLOR_RANGE_UNSET;
+}
+
 static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 					  struct drm_crtc_state *crtc_state,
 					  struct drm_connector_state *conn_state)
@@ -7735,6 +7762,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 		drm_connector_attach_max_bpc_property(&aconnector->base, 8, 16);
 		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
 		drm_connector_attach_active_color_format_property(&aconnector->base);
+		drm_connector_attach_active_color_range_property(&aconnector->base);
 	}
 
 	/* This defaults to the max in the range, but we want 8bpc for non-edp. */
@@ -9118,10 +9146,15 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
 				drm_connector_set_active_color_format_property(connector,
 					convert_dc_pixel_encoding_into_drm_color_format(
 					dm_new_crtc_state->stream->timing.pixel_encoding));
+				drm_connector_set_active_color_range_property(connector,
+					convert_dc_color_space_into_drm_mode_color_range(
+					dm_new_crtc_state->stream->output_color_space));
 			}
 		} else {
 			drm_connector_set_active_bpc_property(connector, 0);
 			drm_connector_set_active_color_format_property(connector, 0);
+			drm_connector_set_active_color_range_property(connector,
+								      DRM_MODE_COLOR_RANGE_UNSET);
 		}
 	}
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 13151d13aa73..b5d57bbbdd20 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -417,6 +417,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
 	if (connector->active_color_format_property)
 		drm_connector_attach_active_color_format_property(&aconnector->base);
 
+	connector->active_color_range_property = master->base.active_color_range_property;
+	if (connector->active_color_range_property)
+		drm_connector_attach_active_color_range_property(&aconnector->base);
+
 	connector->vrr_capable_property = master->base.vrr_capable_property;
 	if (connector->vrr_capable_property)
 		drm_connector_attach_vrr_capable_property(connector);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 11/17] drm/i915/display: Add handling for new "active color range" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (9 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 10/17] drm/amd/display: Add handling for new "active color range" property Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace Werner Sembach
                   ` (5 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "active color range" drm property for the Intel
GPU driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/i915/display/intel_display.c | 6 ++++++
 drivers/gpu/drm/i915/display/intel_dp.c      | 2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c  | 5 +++++
 drivers/gpu/drm/i915/display/intel_hdmi.c    | 1 +
 4 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 57bec7f452d8..3d0bdca70c6a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10938,9 +10938,15 @@ static int intel_atomic_commit(struct drm_device *dev,
 			drm_connector_set_active_color_format_property(connector,
 				convert_intel_output_format_into_drm_color_format(
 					new_crtc_state->output_format));
+			drm_connector_set_active_color_range_property(connector,
+				new_crtc_state->limited_color_range ?
+					DRM_MODE_COLOR_RANGE_LIMITED_16_235 :
+					DRM_MODE_COLOR_RANGE_FULL);
 		} else {
 			drm_connector_set_active_bpc_property(connector, 0);
 			drm_connector_set_active_color_format_property(connector, 0);
+			drm_connector_set_active_color_range_property(connector,
+								      DRM_MODE_COLOR_RANGE_UNSET);
 		}
 	}
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 9204bc14590a..214010f7cbec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4692,10 +4692,12 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect
 		drm_connector_attach_max_bpc_property(connector, 6, 10);
 		drm_connector_attach_active_bpc_property(connector, 6, 10);
 		drm_connector_attach_active_color_format_property(connector);
+		drm_connector_attach_active_color_range_property(connector);
 	} else if (DISPLAY_VER(dev_priv) >= 5) {
 		drm_connector_attach_max_bpc_property(connector, 6, 12);
 		drm_connector_attach_active_bpc_property(connector, 6, 12);
 		drm_connector_attach_active_color_format_property(connector);
+		drm_connector_attach_active_color_range_property(connector);
 	}
 
 	/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 3e4237df3360..cb876175258f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -861,6 +861,11 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 	if (connector->active_color_format_property)
 		drm_connector_attach_active_color_format_property(connector);
 
+	connector->active_color_range_property =
+		intel_dp->attached_connector->base.active_color_range_property;
+	if (connector->active_color_range_property)
+		drm_connector_attach_active_color_range_property(connector);
+
 	return connector;
 
 err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 367aba57b55f..dacac23a6c30 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2517,6 +2517,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c
 		drm_connector_attach_max_bpc_property(connector, 8, 12);
 		drm_connector_attach_active_bpc_property(connector, 8, 12);
 		drm_connector_attach_active_color_format_property(connector);
+		drm_connector_attach_active_color_range_property(connector);
 	}
 }
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (10 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 11/17] drm/i915/display: " Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-22  7:15   ` Pekka Paalanen
  2021-06-18  9:11 ` [PATCH v4 13/17] drm/amd/display: Add handling for new "preferred color format" property Werner Sembach
                   ` (4 subsequent siblings)
  16 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.

Possible options are:
    - auto (default/current behaviour)
    - rgb
    - ycbcr444
    - ycbcr422 (not supported by both amdgpu and i915)
    - ycbcr420

In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look
better with rgb and some with ycbcr444.

Also, because of bad shielded connectors and/or cables, it might be
preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
for a signal that is less deceptible to interference.

In the future, automatic color calibration for screens might also depend on
this option being available.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
 drivers/gpu/drm/drm_connector.c     | 48 ++++++++++++++++++++++++++++-
 include/drm/drm_connector.h         | 17 ++++++++++
 4 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index bc3487964fb5..90d62f305257 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -687,6 +687,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 			if (old_connector_state->max_requested_bpc !=
 			    new_connector_state->max_requested_bpc)
 				new_crtc_state->connectors_changed = true;
+
+			if (old_connector_state->preferred_color_format !=
+			    new_connector_state->preferred_color_format)
+				new_crtc_state->connectors_changed = true;
 		}
 
 		if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 438e9585b225..c536f5e22016 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 						   fence_ptr);
 	} else if (property == connector->max_bpc_property) {
 		state->max_requested_bpc = val;
+	} else if (property == connector->preferred_color_format_property) {
+		state->preferred_color_format = val;
 	} else if (connector->funcs->atomic_set_property) {
 		return connector->funcs->atomic_set_property(connector,
 				state, property, val);
@@ -873,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = 0;
 	} else if (property == connector->max_bpc_property) {
 		*val = state->max_requested_bpc;
+	} else if (property == connector->preferred_color_format_property) {
+		*val = state->preferred_color_format;
 	} 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 818de58d972f..aea03dd02e33 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
 	{ DRM_MODE_SUBCONNECTOR_Native,	     "Native"    }, /* DP */
 };
 
+static const struct drm_prop_enum_list drm_preferred_color_format_enum_list[] = {
+	{ 0, "auto" },
+	{ DRM_COLOR_FORMAT_RGB444, "rgb" },
+	{ DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+	{ DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
 static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
 	{ 0, "unknown" },
 	{ DRM_COLOR_FORMAT_RGB444, "rgb" },
@@ -1219,11 +1227,19 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	Drivers shall use drm_connector_attach_active_bpc_property() to install
  *	this property.
  *
+ * preferred color format:
+ *	This property is used by userspace to change the used color format. When
+ *	used the driver will use the selected format if valid for the hardware,
+ *	sink, and current resolution and refresh rate combination. Drivers to
+ *	use the function drm_connector_attach_preferred_color_format_property()
+ *	to create and attach the property to the connector during
+ *	initialization.
+ *
  * active color format:
  *	This read-only property tells userspace the color format actually used
  *	by the hardware display engine on "the cable" on a connector. The chosen
  *	value depends on hardware capabilities, both display engine and
- *	connected monitor. Drivers shall use
+ *	connected monitor, and the "preferred color format". Drivers shall use
  *	drm_connector_attach_active_color_format_property() to install this
  *	property.
  *
@@ -2233,6 +2249,36 @@ void drm_connector_set_active_bpc_property(struct drm_connector *connector, int
 }
 EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
 
+/**
+ * drm_connector_attach_preferred_color_format_property - attach "preferred color format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to add support for selecting a color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_preferred_color_format_property(struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if (!connector->preferred_color_format_property) {
+		prop = drm_property_create_enum(dev, 0, "preferred color format",
+						drm_preferred_color_format_enum_list,
+						ARRAY_SIZE(drm_preferred_color_format_enum_list));
+		if (!prop)
+			return -ENOMEM;
+
+		connector->preferred_color_format_property = prop;
+		drm_object_attach_property(&connector->base, prop, 0);
+		connector->state->preferred_color_format = 0;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_preferred_color_format_property);
+
 /**
  * drm_connector_attach_active_color_format_property - attach "active color format" property
  * @connector: connector to attach active color format property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 9fb7119b7a02..7b85407ba45c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -799,6 +799,16 @@ struct drm_connector_state {
 	 */
 	u8 max_bpc;
 
+	/**
+	 * preferred_color_format: Property set by userspace to tell the GPU
+	 * driver which color format to use. It only gets applied if hardware,
+	 * meaning both the computer and the monitor, and the driver support the
+	 * given format at the current resolution and refresh rate. Userspace
+	 * can check for (un-)successful application via the active_color_format
+	 * property.
+	 */
+	u32 preferred_color_format;
+
 	/**
 	 * @hdr_output_metadata:
 	 * DRM blob property for HDR output metadata
@@ -1404,6 +1414,12 @@ struct drm_connector {
 	 */
 	struct drm_property *active_bpc_property;
 
+	/**
+	 * @preferred_color_format_property: Default connector property for the
+	 * preferred color format to be driven out of the connector.
+	 */
+	struct drm_property *preferred_color_format_property;
+
 	/**
 	 * @active_color_format_property: Default connector property for the
 	 * active color format to be driven out of the connector.
@@ -1740,6 +1756,7 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
 void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
+int drm_connector_attach_preferred_color_format_property(struct drm_connector *connector);
 int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
 void drm_connector_set_active_color_format_property(struct drm_connector *connector,
 						    u32 active_color_format);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 13/17] drm/amd/display: Add handling for new "preferred color format" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (11 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 14/17] drm/i915/display: " Werner Sembach
                   ` (3 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "preferred color format" drm property for the
AMD GPU driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++++++++++++++----
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +++
 2 files changed, 28 insertions(+), 6 deletions(-)

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 bce47f28e20a..9ffd2f9d3d75 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5351,15 +5351,32 @@ static void fill_stream_properties_from_drm_display_mode(
 	timing_out->h_border_right = 0;
 	timing_out->v_border_top = 0;
 	timing_out->v_border_bottom = 0;
-	/* TODO: un-hardcode */
-	if (drm_mode_is_420_only(info, mode_in)
-			|| (drm_mode_is_420_also(info, mode_in) && aconnector->force_yuv420_output))
+
+	if (connector_state
+			&& (connector_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB420
+			|| aconnector->force_yuv420_output) && drm_mode_is_420(info, mode_in))
 		timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
-	else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCRCB444)
-			&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+	else if (connector_state
+			&& connector_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB444
+			&& connector->display_info.color_formats & DRM_COLOR_FORMAT_YCRCB444)
 		timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
-	else
+	else if (connector_state
+			&& connector_state->preferred_color_format == DRM_COLOR_FORMAT_RGB444
+			&& !drm_mode_is_420_only(info, mode_in))
 		timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
+	else
+		/*
+		 * connector_state->preferred_color_format not possible
+		 * || connector_state->preferred_color_format == 0 (auto)
+		 * || connector_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB422
+		 */
+		if (drm_mode_is_420_only(info, mode_in))
+			timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
+		else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCRCB444)
+				&& stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+			timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
+		else
+			timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
 
 	timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
 	timing_out->display_color_depth = convert_color_depth_from_display_info(
@@ -7761,6 +7778,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 	if (!aconnector->mst_port) {
 		drm_connector_attach_max_bpc_property(&aconnector->base, 8, 16);
 		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
+		drm_connector_attach_preferred_color_format_property(&aconnector->base);
 		drm_connector_attach_active_color_format_property(&aconnector->base);
 		drm_connector_attach_active_color_range_property(&aconnector->base);
 	}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index b5d57bbbdd20..2563788ba95a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
 	if (connector->active_bpc_property)
 		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
 
+	connector->preferred_color_format_property = master->base.preferred_color_format_property;
+	if (connector->preferred_color_format_property)
+		drm_connector_attach_preferred_color_format_property(&aconnector->base);
+
 	connector->active_color_format_property = master->base.active_color_format_property;
 	if (connector->active_color_format_property)
 		drm_connector_attach_active_color_format_property(&aconnector->base);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 14/17] drm/i915/display: Add handling for new "preferred color format" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (12 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 13/17] drm/amd/display: Add handling for new "preferred color format" property Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context Werner Sembach
                   ` (2 subsequent siblings)
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "preferred color format" drm property for the
Intel GPU driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/i915/display/intel_dp.c     | 7 ++++++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++++
 drivers/gpu/drm/i915/display/intel_hdmi.c   | 6 ++++++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 214010f7cbec..4c01ab887904 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -616,9 +616,12 @@ intel_dp_output_format(struct drm_connector *connector,
 {
 	struct intel_dp *intel_dp = intel_attached_dp(to_intel_connector(connector));
 	const struct drm_display_info *info = &connector->display_info;
+	const struct drm_connector_state *connector_state = connector->state;
 
 	if (!connector->ycbcr_420_allowed ||
-	    !drm_mode_is_420_only(info, mode))
+	    !(drm_mode_is_420_only(info, mode) ||
+	    (drm_mode_is_420_also(info, mode) && connector_state &&
+	    connector_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB420)))
 		return INTEL_OUTPUT_FORMAT_RGB;
 
 	if (intel_dp->dfp.rgb_to_ycbcr &&
@@ -4691,11 +4694,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect
 	if (HAS_GMCH(dev_priv)) {
 		drm_connector_attach_max_bpc_property(connector, 6, 10);
 		drm_connector_attach_active_bpc_property(connector, 6, 10);
+		drm_connector_attach_preferred_color_format_property(connector);
 		drm_connector_attach_active_color_format_property(connector);
 		drm_connector_attach_active_color_range_property(connector);
 	} else if (DISPLAY_VER(dev_priv) >= 5) {
 		drm_connector_attach_max_bpc_property(connector, 6, 12);
 		drm_connector_attach_active_bpc_property(connector, 6, 12);
+		drm_connector_attach_preferred_color_format_property(connector);
 		drm_connector_attach_active_color_format_property(connector);
 		drm_connector_attach_active_color_range_property(connector);
 	}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cb876175258f..67f0fb649876 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 	if (connector->active_bpc_property)
 		drm_connector_attach_active_bpc_property(connector, 6, 12);
 
+	connector->preferred_color_format_property =
+		intel_dp->attached_connector->base.preferred_color_format_property;
+	if (connector->preferred_color_format_property)
+		drm_connector_attach_preferred_color_format_property(connector);
+
 	connector->active_color_format_property =
 		intel_dp->attached_connector->base.active_color_format_property;
 	if (connector->active_color_format_property)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index dacac23a6c30..bce253bc5b16 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2153,6 +2153,11 @@ static int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
 		crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
 	}
 
+	if (connector->ycbcr_420_allowed &&
+	    conn_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB420 &&
+	    drm_mode_is_420_also(&connector->display_info, adjusted_mode))
+		crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
 	ret = intel_hdmi_compute_clock(encoder, crtc_state);
 	if (ret) {
 		if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
@@ -2516,6 +2521,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c
 	if (!HAS_GMCH(dev_priv)) {
 		drm_connector_attach_max_bpc_property(connector, 8, 12);
 		drm_connector_attach_active_bpc_property(connector, 8, 12);
+		drm_connector_attach_preferred_color_format_property(connector);
 		drm_connector_attach_active_color_format_property(connector);
 		drm_connector_attach_active_color_range_property(connector);
 	}
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (13 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 14/17] drm/i915/display: " Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-22  7:25   ` Pekka Paalanen
  2021-06-18  9:11 ` [PATCH v4 16/17] drm/i915/display: Use the general "Broadcast RGB" implementation Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property Werner Sembach
  16 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.

Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detection.

Possible options are:
    - Automatic (default/current behaviour)
    - Full
    - Limited 16:235

In theory the driver should be able to automatically detect the monitors
capabilities, but because of flawed standard implementations in Monitors,
this might fail. In this case a manual overwrite is required to not have
washed out colors or lose details in very dark or bright scenes.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
 drivers/gpu/drm/drm_connector.c     | 43 +++++++++++++++++++++++++++++
 include/drm/drm_connector.h         | 16 +++++++++++
 4 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 90d62f305257..0c89d32efbd0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 			if (old_connector_state->preferred_color_format !=
 			    new_connector_state->preferred_color_format)
 				new_crtc_state->connectors_changed = true;
+
+			if (old_connector_state->preferred_color_range !=
+			    new_connector_state->preferred_color_range)
+				new_crtc_state->connectors_changed = true;
 		}
 
 		if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index c536f5e22016..c589bb1a8163 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 		state->max_requested_bpc = val;
 	} else if (property == connector->preferred_color_format_property) {
 		state->preferred_color_format = val;
+	} else if (property == connector->preferred_color_range_property) {
+		state->preferred_color_range = val;
 	} else if (connector->funcs->atomic_set_property) {
 		return connector->funcs->atomic_set_property(connector,
 				state, property, val);
@@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = state->max_requested_bpc;
 	} else if (property == connector->preferred_color_format_property) {
 		*val = state->preferred_color_format;
+	} else if (property == connector->preferred_color_range_property) {
+		*val = state->preferred_color_range;
 	} 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 aea03dd02e33..9bc596638613 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -905,6 +905,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
 	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
 };
 
+static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = {
+	{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
+	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
+	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
 static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
 	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
 	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
@@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	drm_connector_attach_active_color_format_property() to install this
  *	property.
  *
+ * Broadcast RGB:
+ *	This property is used by userspace to change the used color range. When
+ *	used the driver will use the selected range if valid for the current
+ *	color format. Drivers to use the function
+ *	drm_connector_attach_preferred_color_format_property() to create and
+ *	attach the property to the connector during initialization.
+ *
  * active color range:
  *	This read-only property tells userspace the color range actually used by
  *	the hardware display engine on "the cable" on a connector. The chosen
@@ -2324,6 +2337,36 @@ void drm_connector_set_active_color_format_property(struct drm_connector *connec
 }
 EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
 
+/**
+ * drm_connector_attach_preferred_color_range_property - attach "Broadcast RGB" property
+ * @connector: connector to attach preferred color range property on.
+ *
+ * This is used to add support for selecting a color range on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_preferred_color_range_property(struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if (!connector->preferred_color_range_property) {
+		prop = drm_property_create_enum(dev, 0, "Broadcast RGB",
+						drm_preferred_color_range_enum_list,
+						ARRAY_SIZE(drm_preferred_color_range_enum_list));
+		if (!prop)
+			return -ENOMEM;
+
+		connector->preferred_color_range_property = prop;
+		drm_object_attach_property(&connector->base, prop, DRM_MODE_COLOR_RANGE_UNSET);
+		connector->state->preferred_color_range = DRM_MODE_COLOR_RANGE_UNSET;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_preferred_color_range_property);
+
 /**
  * drm_connector_attach_active_color_range_property - attach "active color range" property
  * @connector: connector to attach active color range property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 7b85407ba45c..b319760d4a8c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -809,6 +809,15 @@ struct drm_connector_state {
 	 */
 	u32 preferred_color_format;
 
+	/**
+	 * preferred_color_range: Property set by userspace via "Broadcast RGB"
+	 * property to tell the GPU driver which color range to use. It
+	 * overwrites existing automatic detection mechanisms, if set and valid
+	 * for the current color format. Userspace can check for (un-)successful
+	 * application via the "active color range" property.
+	 */
+	enum drm_mode_color_range preferred_color_range;
+
 	/**
 	 * @hdr_output_metadata:
 	 * DRM blob property for HDR output metadata
@@ -1426,6 +1435,12 @@ struct drm_connector {
 	 */
 	struct drm_property *active_color_format_property;
 
+	/**
+	 * @preferred_color_range_property: Default connector property for the
+	 * preferred color range to be driven out of the connector.
+	 */
+	struct drm_property *preferred_color_range_property;
+
 	/**
 	 * @active_color_range_property: Default connector property for the
 	 * active color range to be driven out of the connector.
@@ -1760,6 +1775,7 @@ int drm_connector_attach_preferred_color_format_property(struct drm_connector *c
 int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
 void drm_connector_set_active_color_format_property(struct drm_connector *connector,
 						    u32 active_color_format);
+int drm_connector_attach_preferred_color_range_property(struct drm_connector *connector);
 int drm_connector_attach_active_color_range_property(struct drm_connector *connector);
 void drm_connector_set_active_color_range_property(struct drm_connector *connector,
 						   enum drm_mode_color_range active_color_range);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 16/17] drm/i915/display: Use the general "Broadcast RGB" implementation
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (14 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-18  9:11 ` [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property Werner Sembach
  16 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.

This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 drivers/gpu/drm/i915/display/intel_atomic.c   |  8 ------
 .../gpu/drm/i915/display/intel_connector.c    | 28 -------------------
 .../gpu/drm/i915/display/intel_connector.h    |  1 -
 .../drm/i915/display/intel_display_types.h    |  8 ------
 drivers/gpu/drm/i915/display/intel_dp.c       |  9 ++----
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  6 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c     |  8 ++----
 drivers/gpu/drm/i915/display/intel_sdvo.c     |  2 +-
 drivers/gpu/drm/i915/i915_drv.h               |  1 -
 9 files changed, 12 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c b/drivers/gpu/drm/i915/display/intel_atomic.c
index b4e7ac51aa31..f8d5a0e287b0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -63,8 +63,6 @@ int intel_digital_connector_atomic_get_property(struct drm_connector *connector,
 
 	if (property == dev_priv->force_audio_property)
 		*val = intel_conn_state->force_audio;
-	else if (property == dev_priv->broadcast_rgb_property)
-		*val = intel_conn_state->broadcast_rgb;
 	else {
 		drm_dbg_atomic(&dev_priv->drm,
 			       "Unknown property [PROP:%d:%s]\n",
@@ -99,11 +97,6 @@ int intel_digital_connector_atomic_set_property(struct drm_connector *connector,
 		return 0;
 	}
 
-	if (property == dev_priv->broadcast_rgb_property) {
-		intel_conn_state->broadcast_rgb = val;
-		return 0;
-	}
-
 	drm_dbg_atomic(&dev_priv->drm, "Unknown property [PROP:%d:%s]\n",
 		       property->base.id, property->name);
 	return -EINVAL;
@@ -134,7 +127,6 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn,
 	 * up in a modeset.
 	 */
 	if (new_conn_state->force_audio != old_conn_state->force_audio ||
-	    new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
 	    new_conn_state->base.colorspace != old_conn_state->base.colorspace ||
 	    new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio ||
 	    new_conn_state->base.content_type != old_conn_state->base.content_type ||
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c b/drivers/gpu/drm/i915/display/intel_connector.c
index 9bed1ccecea0..89f0edf19182 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -241,34 +241,6 @@ intel_attach_force_audio_property(struct drm_connector *connector)
 	drm_object_attach_property(&connector->base, prop, 0);
 }
 
-static const struct drm_prop_enum_list broadcast_rgb_names[] = {
-	{ INTEL_BROADCAST_RGB_AUTO, "Automatic" },
-	{ INTEL_BROADCAST_RGB_FULL, "Full" },
-	{ INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" },
-};
-
-void
-intel_attach_broadcast_rgb_property(struct drm_connector *connector)
-{
-	struct drm_device *dev = connector->dev;
-	struct drm_i915_private *dev_priv = to_i915(dev);
-	struct drm_property *prop;
-
-	prop = dev_priv->broadcast_rgb_property;
-	if (prop == NULL) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
-					   "Broadcast RGB",
-					   broadcast_rgb_names,
-					   ARRAY_SIZE(broadcast_rgb_names));
-		if (prop == NULL)
-			return;
-
-		dev_priv->broadcast_rgb_property = prop;
-	}
-
-	drm_object_attach_property(&connector->base, prop, 0);
-}
-
 void
 intel_attach_aspect_ratio_property(struct drm_connector *connector)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h b/drivers/gpu/drm/i915/display/intel_connector.h
index 661a37a3c6d8..f3058a035476 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -28,7 +28,6 @@ int intel_connector_update_modes(struct drm_connector *connector,
 				 struct edid *edid);
 int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
 void intel_attach_force_audio_property(struct drm_connector *connector);
-void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
 void intel_attach_hdmi_colorspace_property(struct drm_connector *connector);
 void intel_attach_dp_colorspace_property(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index 15e91a99c8b9..fb091216df78 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -77,13 +77,6 @@ enum hdmi_force_audio {
 	HDMI_AUDIO_ON,			/* force turn on HDMI audio */
 };
 
-/* "Broadcast RGB" property */
-enum intel_broadcast_rgb {
-	INTEL_BROADCAST_RGB_AUTO,
-	INTEL_BROADCAST_RGB_FULL,
-	INTEL_BROADCAST_RGB_LIMITED,
-};
-
 struct intel_fb_view {
 	/*
 	 * The remap information used in the remapped and rotated views to
@@ -552,7 +545,6 @@ struct intel_digital_connector_state {
 	struct drm_connector_state base;
 
 	enum hdmi_force_audio force_audio;
-	int broadcast_rgb;
 };
 
 #define to_intel_digital_connector_state(x) container_of(x, struct intel_digital_connector_state, base)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 4c01ab887904..d20da3b8f56a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1417,8 +1417,6 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
 bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
 				  const struct drm_connector_state *conn_state)
 {
-	const struct intel_digital_connector_state *intel_conn_state =
-		to_intel_digital_connector_state(conn_state);
 	const struct drm_display_mode *adjusted_mode =
 		&crtc_state->hw.adjusted_mode;
 
@@ -1432,7 +1430,7 @@ bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
 	if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
 		return false;
 
-	if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) {
+	if (conn_state->preferred_color_range == DRM_MODE_COLOR_RANGE_UNSET) {
 		/*
 		 * See:
 		 * CEA-861-E - 5.1 Default Encoding Parameters
@@ -1442,8 +1440,7 @@ bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
 			drm_default_rgb_quant_range(adjusted_mode) ==
 			HDMI_QUANTIZATION_RANGE_LIMITED;
 	} else {
-		return intel_conn_state->broadcast_rgb ==
-			INTEL_BROADCAST_RGB_LIMITED;
+		return conn_state->preferred_color_range == DRM_MODE_COLOR_RANGE_LIMITED_16_235;
 	}
 }
 
@@ -4690,7 +4687,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect
 	if (!IS_G4X(dev_priv) && port != PORT_A)
 		intel_attach_force_audio_property(connector);
 
-	intel_attach_broadcast_rgb_property(connector);
+	drm_connector_attach_preferred_color_range_property(connector);
 	if (HAS_GMCH(dev_priv)) {
 		drm_connector_attach_max_bpc_property(connector, 6, 10);
 		drm_connector_attach_active_bpc_property(connector, 6, 10);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 67f0fb649876..1a0684c0cb5d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -833,7 +833,6 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 		goto err;
 
 	intel_attach_force_audio_property(connector);
-	intel_attach_broadcast_rgb_property(connector);
 
 	if (DISPLAY_VER(dev_priv) <= 12) {
 		ret = intel_dp_hdcp_init(dig_port, intel_connector);
@@ -866,6 +865,11 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 	if (connector->active_color_format_property)
 		drm_connector_attach_active_color_format_property(connector);
 
+	connector->preferred_color_range_property =
+		intel_dp->attached_connector->base.preferred_color_range_property;
+	if (connector->preferred_color_range_property)
+		drm_connector_attach_preferred_color_range_property(connector);
+
 	connector->active_color_range_property =
 		intel_dp->attached_connector->base.active_color_range_property;
 	if (connector->active_color_range_property)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index bce253bc5b16..4faed5572160 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2091,8 +2091,6 @@ static int intel_hdmi_compute_clock(struct intel_encoder *encoder,
 bool intel_hdmi_limited_color_range(const struct intel_crtc_state *crtc_state,
 				    const struct drm_connector_state *conn_state)
 {
-	const struct intel_digital_connector_state *intel_conn_state =
-		to_intel_digital_connector_state(conn_state);
 	const struct drm_display_mode *adjusted_mode =
 		&crtc_state->hw.adjusted_mode;
 
@@ -2106,13 +2104,13 @@ bool intel_hdmi_limited_color_range(const struct intel_crtc_state *crtc_state,
 	if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
 		return false;
 
-	if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) {
+	if (conn_state->preferred_color_range == DRM_MODE_COLOR_RANGE_UNSET) {
 		/* See CEA-861-E - 5.1 Default Encoding Parameters */
 		return crtc_state->has_hdmi_sink &&
 			drm_default_rgb_quant_range(adjusted_mode) ==
 			HDMI_QUANTIZATION_RANGE_LIMITED;
 	} else {
-		return intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_LIMITED;
+		return conn_state->preferred_color_range == DRM_MODE_COLOR_RANGE_LIMITED_16_235;
 	}
 }
 
@@ -2509,7 +2507,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c
 	struct drm_i915_private *dev_priv = to_i915(connector->dev);
 
 	intel_attach_force_audio_property(connector);
-	intel_attach_broadcast_rgb_property(connector);
+	drm_connector_attach_preferred_color_range_property(connector);
 	intel_attach_aspect_ratio_property(connector);
 
 	intel_attach_hdmi_colorspace_property(connector);
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c b/drivers/gpu/drm/i915/display/intel_sdvo.c
index e4f91d7a5c60..bf4ecd029533 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2722,7 +2722,7 @@ intel_sdvo_add_hdmi_properties(struct intel_sdvo *intel_sdvo,
 {
 	intel_attach_force_audio_property(&connector->base.base);
 	if (intel_sdvo->colorimetry_cap & SDVO_COLORIMETRY_RGB220)
-		intel_attach_broadcast_rgb_property(&connector->base.base);
+		drm_connector_attach_preferred_color_range_property(&connector->base.base);
 	intel_attach_aspect_ratio_property(&connector->base.base);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01e11fe38642..f5987e809b78 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -999,7 +999,6 @@ struct drm_i915_private {
 	struct intel_fbdev *fbdev;
 	struct work_struct fbdev_suspend_work;
 
-	struct drm_property *broadcast_rgb_property;
 	struct drm_property *force_audio_property;
 
 	/* hda/i915 audio component */
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property
  2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
                   ` (15 preceding siblings ...)
  2021-06-18  9:11 ` [PATCH v4 16/17] drm/i915/display: Use the general "Broadcast RGB" implementation Werner Sembach
@ 2021-06-18  9:11 ` Werner Sembach
  2021-06-22  7:29   ` Pekka Paalanen
  16 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-18  9:11 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx
  Cc: Werner Sembach

This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++++++++++++++-----
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 ++++
 2 files changed, 21 insertions(+), 5 deletions(-)

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 9ffd2f9d3d75..c5dbf948a47a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
 }
 
 static enum dc_color_space
-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+		       enum drm_mode_color_range preferred_color_range)
 {
 	enum dc_color_space color_space = COLOR_SPACE_SRGB;
 
@@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
 		 * respectively
 		 */
 		if (dc_crtc_timing->pix_clk_100hz > 270300) {
-			if (dc_crtc_timing->flags.Y_ONLY)
+			if (dc_crtc_timing->flags.Y_ONLY
+					|| preferred_color_range ==
+						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
 				color_space =
 					COLOR_SPACE_YCBCR709_LIMITED;
 			else
 				color_space = COLOR_SPACE_YCBCR709;
 		} else {
-			if (dc_crtc_timing->flags.Y_ONLY)
+			if (dc_crtc_timing->flags.Y_ONLY
+					|| preferred_color_range ==
+						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
 				color_space =
 					COLOR_SPACE_YCBCR601_LIMITED;
 			else
@@ -5283,7 +5288,10 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
 	}
 	break;
 	case PIXEL_ENCODING_RGB:
-		color_space = COLOR_SPACE_SRGB;
+		if (preferred_color_range == DRM_MODE_COLOR_RANGE_LIMITED_16_235)
+			color_space = COLOR_SPACE_SRGB_LIMITED;
+		else
+			color_space = COLOR_SPACE_SRGB;
 		break;
 
 	default:
@@ -5429,7 +5437,10 @@ static void fill_stream_properties_from_drm_display_mode(
 
 	timing_out->aspect_ratio = get_aspect_ratio(mode_in);
 
-	stream->output_color_space = get_output_color_space(timing_out);
+	stream->output_color_space = get_output_color_space(timing_out,
+							    connector_state ?
+							    connector_state->preferred_color_range :
+							    DRM_MODE_COLOR_RANGE_UNSET);
 
 	stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
 	stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
@@ -7780,6 +7791,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
 		drm_connector_attach_preferred_color_format_property(&aconnector->base);
 		drm_connector_attach_active_color_format_property(&aconnector->base);
+		drm_connector_attach_preferred_color_range_property(&aconnector->base);
 		drm_connector_attach_active_color_range_property(&aconnector->base);
 	}
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2563788ba95a..80e1389fd0ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
 	if (connector->active_color_format_property)
 		drm_connector_attach_active_color_format_property(&aconnector->base);
 
+	connector->preferred_color_range_property = master->base.preferred_color_range_property;
+	if (connector->preferred_color_range_property)
+		drm_connector_attach_preferred_color_range_property(&aconnector->base);
+
 	connector->active_color_range_property = master->base.active_color_range_property;
 	if (connector->active_color_range_property)
 		drm_connector_attach_active_color_range_property(&aconnector->base);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-06-18  9:11 ` [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property Werner Sembach
@ 2021-06-22  6:46   ` Pekka Paalanen
  2021-06-28 17:03   ` Werner Sembach
  1 sibling, 0 replies; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-22  6:46 UTC (permalink / raw)
  To: Werner Sembach
  Cc: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

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

On Fri, 18 Jun 2021 11:11:02 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Add a new general drm property "active bpc" which can be used by graphic
> drivers to report the applied bit depth per pixel back to userspace.
> 
> While "max bpc" can be used to change the color depth, there was no way to
> check which one actually got used. While in theory the driver chooses the
> best/highest color depth within the max bpc setting a user might not be
> fully aware what his hardware is or isn't capable off. This is meant as a
> quick way to double check the setup.
> 
> In the future, automatic color calibration for screens might also depend on
> this information being available.
> 
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
>  include/drm/drm_connector.h     |  8 ++++++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index da39e7ff6965..943f6b61053b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	drm_connector_attach_max_bpc_property() to create and attach the
>   *	property to the connector during initialization.
>   *
> + * active bpc:
> + *	This read-only range property tells userspace the pixel color bit depth
> + *	actually used by the hardware display engine on "the cable" on a
> + *	connector. The chosen value depends on hardware capabilities, both
> + *	display engine and connected monitor, and the "max bpc" property.
> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
> + *	this property.
> + *
>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>  
> +/**
> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
> + * @connector: connector to attach active bpc property on.
> + * @min: The minimum bit depth supported by the connector.
> + * @max: The maximum bit depth supported by the connector.
> + *
> + * This is used to check the applied bit depth on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max)
> +{
> +	struct drm_device *dev = connector->dev;
> +	struct drm_property *prop;
> +
> +	if (!connector->active_bpc_property) {
> +		prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "active bpc",
> +						 min, max);
> +		if (!prop)
> +			return -ENOMEM;
> +
> +		connector->active_bpc_property = prop;
> +		drm_object_attach_property(&connector->base, prop, 0);
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
> +
> +/**
> + * drm_connector_set_active_bpc_property - sets the active bits per color property for a connector
> + * @connector: drm connector
> + * @active_bpc: bits per color for the connector currently active on "the cable"
> + *
> + * Should be used by atomic drivers to update the active bits per color over a connector.
> + */
> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc)
> +{
> +	drm_object_property_set_value(&connector->base, connector->active_bpc_property, active_bpc);
> +}
> +EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
> +
>  /**
>   * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
>   * @connector: connector to attach the property on.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 714d1a01c065..eee86de62a5f 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1380,6 +1380,12 @@ struct drm_connector {
>  	 */
>  	struct drm_property *max_bpc_property;
>  
> +	/**
> +	 * @active_bpc_property: Default connector property for the active bpc
> +	 * to be driven out of the connector.
> +	 */
> +	struct drm_property *active_bpc_property;
> +
>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk(
>  	int width, int height);
>  int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>  					  int min, int max);
> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
>  
>  /**
>   * struct drm_tile_group - Tile group metadata

Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace
  2021-06-18  9:11 ` [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace Werner Sembach
@ 2021-06-22  6:48   ` Pekka Paalanen
  0 siblings, 0 replies; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-22  6:48 UTC (permalink / raw)
  To: Werner Sembach
  Cc: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

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

On Fri, 18 Jun 2021 11:11:05 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Add a new general drm property "active color format" which can be used by
> graphic drivers to report the used color format back to userspace.
> 
> There was no way to check which color format got actually used on a given
> monitor. To surely predict this, one must know the exact capabilities of
> the monitor, the GPU, and the connection used and what the default
> behaviour of the used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915
> prefers RGB). This property helps eliminating the guessing on this point.
> 
> In the future, automatic color calibration for screens might also depend on
> this information being available.
> 
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 61 +++++++++++++++++++++++++++++++++
>  include/drm/drm_connector.h     |  9 +++++
>  2 files changed, 70 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 943f6b61053b..684d7abdf0eb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -889,6 +889,14 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
>  	{ DRM_MODE_SUBCONNECTOR_Native,	     "Native"    }, /* DP */
>  };
>  
> +static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
> +	{ 0, "unknown" },
> +	{ DRM_COLOR_FORMAT_RGB444, "rgb" },
> +	{ DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
> +	{ DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
> +	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
> +};
> +
>  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>  		 drm_dp_subconnector_enum_list)
>  
> @@ -1205,6 +1213,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	Drivers shall use drm_connector_attach_active_bpc_property() to install
>   *	this property.
>   *
> + * active color format:
> + *	This read-only property tells userspace the color format actually used
> + *	by the hardware display engine on "the cable" on a connector. The chosen
> + *	value depends on hardware capabilities, both display engine and
> + *	connected monitor. Drivers shall use
> + *	drm_connector_attach_active_color_format_property() to install this
> + *	property.
> + *
>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -2203,6 +2219,51 @@ void drm_connector_set_active_bpc_property(struct drm_connector *connector, int
>  }
>  EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
>  
> +/**
> + * drm_connector_attach_active_color_format_property - attach "active color format" property
> + * @connector: connector to attach active color format property on.
> + *
> + * This is used to check the applied color format on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_color_format_property(struct drm_connector *connector)
> +{
> +	struct drm_device *dev = connector->dev;
> +	struct drm_property *prop;
> +
> +	if (!connector->active_color_format_property) {
> +		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, "active color format",
> +						drm_active_color_format_enum_list,
> +						ARRAY_SIZE(drm_active_color_format_enum_list));
> +		if (!prop)
> +			return -ENOMEM;
> +
> +		connector->active_color_format_property = prop;
> +		drm_object_attach_property(&connector->base, prop, 0);
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
> +
> +/**
> + * drm_connector_set_active_color_format_property - sets the active color format property for a
> + * connector
> + * @connector: drm connector
> + * @active_color_format: color format for the connector currently active on "the cable"
> + *
> + * Should be used by atomic drivers to update the active color format over a connector.
> + */
> +void drm_connector_set_active_color_format_property(struct drm_connector *connector,
> +						    u32 active_color_format)
> +{
> +	drm_object_property_set_value(&connector->base, connector->active_color_format_property,
> +				      active_color_format);
> +}
> +EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
> +
>  /**
>   * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
>   * @connector: connector to attach the property on.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index eee86de62a5f..8a5197f14e87 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1386,6 +1386,12 @@ struct drm_connector {
>  	 */
>  	struct drm_property *active_bpc_property;
>  
> +	/**
> +	 * @active_color_format_property: Default connector property for the
> +	 * active color format to be driven out of the connector.
> +	 */
> +	struct drm_property *active_color_format_property;
> +
>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1710,6 +1716,9 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>  					  int min, int max);
>  int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
>  void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
> +int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
> +void drm_connector_set_active_color_format_property(struct drm_connector *connector,
> +						    u32 active_color_format);
>  
>  /**
>   * struct drm_tile_group - Tile group metadata

Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-18  9:11 ` [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace Werner Sembach
@ 2021-06-22  7:00   ` Pekka Paalanen
  2021-06-22  9:50     ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-22  7:00 UTC (permalink / raw)
  To: Werner Sembach
  Cc: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

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

On Fri, 18 Jun 2021 11:11:08 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Add a new general drm property "active color range" which can be used by
> graphic drivers to report the used color range back to userspace.
> 
> There was no way to check which color range got actually used on a given
> monitor. To surely predict this, one must know the exact capabilities of
> the monitor and what the default behaviour of the used driver is. This
> property helps eliminating the guessing at this point.
> 
> In the future, automatic color calibration for screens might also depend on
> this information being available.
> 
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 59 +++++++++++++++++++++++++++++++++
>  include/drm/drm_connector.h     | 27 +++++++++++++++
>  2 files changed, 86 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 684d7abdf0eb..818de58d972f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -897,6 +897,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>  };
>  
> +static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },

Doesn't "limited" mean different numbers on RGB vs. Y vs. CbCr? I have
a vague recollection that at least one of them was different from the
others.

Documenting DRM_MODE_COLOR_RANGE_UNSET as "unspecified/default" while
the string for it is "Unknown" seems inconsistent to me. I would
recommend to avoid the word "default" because "reset to defaults" might
become a thing one day, and that probably is not the same default as
here.

Is there actually a case for "unknown"? How can it be not known? Or
does it mean "not applicable"?

Otherwise looks good to me.


Thanks,
pq


> +};
> +
>  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>  		 drm_dp_subconnector_enum_list)
>  
> @@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	drm_connector_attach_active_color_format_property() to install this
>   *	property.
>   *
> + * active color range:
> + *	This read-only property tells userspace the color range actually used by
> + *	the hardware display engine on "the cable" on a connector. The chosen
> + *	value depends on hardware capabilities of the monitor and the used color
> + *	format. Drivers shall use
> + *	drm_connector_attach_active_color_range_property() to install this
> + *	property.
> + *
>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -2264,6 +2278,51 @@ void drm_connector_set_active_color_format_property(struct drm_connector *connec
>  }
>  EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
>  
> +/**
> + * drm_connector_attach_active_color_range_property - attach "active color range" property
> + * @connector: connector to attach active color range property on.
> + *
> + * This is used to check the applied color range on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_color_range_property(struct drm_connector *connector)
> +{
> +	struct drm_device *dev = connector->dev;
> +	struct drm_property *prop;
> +
> +	if (!connector->active_color_range_property) {
> +		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, "active color range",
> +						drm_active_color_range_enum_list,
> +						ARRAY_SIZE(drm_active_color_range_enum_list));
> +		if (!prop)
> +			return -ENOMEM;
> +
> +		connector->active_color_range_property = prop;
> +		drm_object_attach_property(&connector->base, prop, DRM_MODE_COLOR_RANGE_UNSET);
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
> +
> +/**
> + * drm_connector_set_active_color_range_property - sets the active color range property for a
> + * connector
> + * @connector: drm connector
> + * @active_color_range: color range for the connector currently active on "the cable"
> + *
> + * Should be used by atomic drivers to update the active color range over a connector.
> + */
> +void drm_connector_set_active_color_range_property(struct drm_connector *connector,
> +						   enum drm_mode_color_range active_color_range)
> +{
> +	drm_object_property_set_value(&connector->base, connector->active_color_range_property,
> +				      active_color_range);
> +}
> +EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
> +
>  /**
>   * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
>   * @connector: connector to attach the property on.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 8a5197f14e87..9fb7119b7a02 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -648,6 +648,24 @@ struct drm_tv_connector_state {
>  	unsigned int hue;
>  };
>  
> +/**
> + * enum drm_mode_color_range - color_range info for &drm_connector
> + *
> + * This enum is used to represent full or limited color range on the display
> + * connector signal.
> + *
> + * @DRM_MODE_COLOR_RANGE_UNSET:		Color range is unspecified/default.
> + * @DRM_MODE_COLOR_RANGE_FULL:		Color range is full range, 0-255 for
> + *					8-Bit color depth.
> + * DRM_MODE_COLOR_RANGE_LIMITED_16_235:	Color range is limited range, 16-235 for
> + *					8-Bit color depth.
> + */
> +enum drm_mode_color_range {
> +	DRM_MODE_COLOR_RANGE_UNSET,
> +	DRM_MODE_COLOR_RANGE_FULL,
> +	DRM_MODE_COLOR_RANGE_LIMITED_16_235,
> +};
> +
>  /**
>   * struct drm_connector_state - mutable connector state
>   */
> @@ -1392,6 +1410,12 @@ struct drm_connector {
>  	 */
>  	struct drm_property *active_color_format_property;
>  
> +	/**
> +	 * @active_color_range_property: Default connector property for the
> +	 * active color range to be driven out of the connector.
> +	 */
> +	struct drm_property *active_color_range_property;
> +
>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1719,6 +1743,9 @@ void drm_connector_set_active_bpc_property(struct drm_connector *connector, int
>  int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
>  void drm_connector_set_active_color_format_property(struct drm_connector *connector,
>  						    u32 active_color_format);
> +int drm_connector_attach_active_color_range_property(struct drm_connector *connector);
> +void drm_connector_set_active_color_range_property(struct drm_connector *connector,
> +						   enum drm_mode_color_range active_color_range);
>  
>  /**
>   * struct drm_tile_group - Tile group metadata


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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-18  9:11 ` [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace Werner Sembach
@ 2021-06-22  7:15   ` Pekka Paalanen
  2021-06-29  8:12     ` Simon Ser
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-22  7:15 UTC (permalink / raw)
  To: Werner Sembach
  Cc: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

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

On Fri, 18 Jun 2021 11:11:11 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Add a new general drm property "preferred color format" which can be used
> by userspace to tell the graphic drivers to which color format to use.
> 
> Possible options are:
>     - auto (default/current behaviour)
>     - rgb
>     - ycbcr444
>     - ycbcr422 (not supported by both amdgpu and i915)
>     - ycbcr420
> 
> In theory the auto option should choose the best available option for the
> current setup, but because of bad internal conversion some monitors look
> better with rgb and some with ycbcr444.
> 
> Also, because of bad shielded connectors and/or cables, it might be
> preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
> for a signal that is less deceptible to interference.
> 
> In the future, automatic color calibration for screens might also depend on
> this option being available.
> 
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>  drivers/gpu/drm/drm_connector.c     | 48 ++++++++++++++++++++++++++++-
>  include/drm/drm_connector.h         | 17 ++++++++++
>  4 files changed, 72 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index bc3487964fb5..90d62f305257 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -687,6 +687,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>  			if (old_connector_state->max_requested_bpc !=
>  			    new_connector_state->max_requested_bpc)
>  				new_crtc_state->connectors_changed = true;
> +
> +			if (old_connector_state->preferred_color_format !=
> +			    new_connector_state->preferred_color_format)
> +				new_crtc_state->connectors_changed = true;
>  		}
>  
>  		if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index 438e9585b225..c536f5e22016 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>  						   fence_ptr);
>  	} else if (property == connector->max_bpc_property) {
>  		state->max_requested_bpc = val;
> +	} else if (property == connector->preferred_color_format_property) {
> +		state->preferred_color_format = val;
>  	} else if (connector->funcs->atomic_set_property) {
>  		return connector->funcs->atomic_set_property(connector,
>  				state, property, val);
> @@ -873,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>  		*val = 0;
>  	} else if (property == connector->max_bpc_property) {
>  		*val = state->max_requested_bpc;
> +	} else if (property == connector->preferred_color_format_property) {
> +		*val = state->preferred_color_format;
>  	} 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 818de58d972f..aea03dd02e33 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -889,6 +889,14 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
>  	{ DRM_MODE_SUBCONNECTOR_Native,	     "Native"    }, /* DP */
>  };
>  
> +static const struct drm_prop_enum_list drm_preferred_color_format_enum_list[] = {
> +	{ 0, "auto" },
> +	{ DRM_COLOR_FORMAT_RGB444, "rgb" },
> +	{ DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
> +	{ DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
> +	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
> +};
> +
>  static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
>  	{ 0, "unknown" },
>  	{ DRM_COLOR_FORMAT_RGB444, "rgb" },
> @@ -1219,11 +1227,19 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	Drivers shall use drm_connector_attach_active_bpc_property() to install
>   *	this property.
>   *
> + * preferred color format:
> + *	This property is used by userspace to change the used color format. When
> + *	used the driver will use the selected format if valid for the hardware,
> + *	sink, and current resolution and refresh rate combination. Drivers to
> + *	use the function drm_connector_attach_preferred_color_format_property()
> + *	to create and attach the property to the connector during
> + *	initialization.
> + *
>   * active color format:
>   *	This read-only property tells userspace the color format actually used
>   *	by the hardware display engine on "the cable" on a connector. The chosen
>   *	value depends on hardware capabilities, both display engine and
> - *	connected monitor. Drivers shall use
> + *	connected monitor, and the "preferred color format". Drivers shall use
>   *	drm_connector_attach_active_color_format_property() to install this
>   *	property.
>   *
> @@ -2233,6 +2249,36 @@ void drm_connector_set_active_bpc_property(struct drm_connector *connector, int
>  }
>  EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
>  
> +/**
> + * drm_connector_attach_preferred_color_format_property - attach "preferred color format" property
> + * @connector: connector to attach active color format property on.
> + *
> + * This is used to add support for selecting a color format on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_preferred_color_format_property(struct drm_connector *connector)
> +{
> +	struct drm_device *dev = connector->dev;
> +	struct drm_property *prop;
> +
> +	if (!connector->preferred_color_format_property) {
> +		prop = drm_property_create_enum(dev, 0, "preferred color format",
> +						drm_preferred_color_format_enum_list,
> +						ARRAY_SIZE(drm_preferred_color_format_enum_list));
> +		if (!prop)
> +			return -ENOMEM;
> +
> +		connector->preferred_color_format_property = prop;
> +		drm_object_attach_property(&connector->base, prop, 0);
> +		connector->state->preferred_color_format = 0;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_preferred_color_format_property);
> +
>  /**
>   * drm_connector_attach_active_color_format_property - attach "active color format" property
>   * @connector: connector to attach active color format property on.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 9fb7119b7a02..7b85407ba45c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -799,6 +799,16 @@ struct drm_connector_state {
>  	 */
>  	u8 max_bpc;
>  
> +	/**
> +	 * preferred_color_format: Property set by userspace to tell the GPU
> +	 * driver which color format to use. It only gets applied if hardware,
> +	 * meaning both the computer and the monitor, and the driver support the
> +	 * given format at the current resolution and refresh rate. Userspace
> +	 * can check for (un-)successful application via the active_color_format
> +	 * property.
> +	 */
> +	u32 preferred_color_format;

Hi,

yes, I think this makes sense, even if it is a property that one can't
tell for sure what it does before hand.

Using a pair of properties, preference and active, to ask for something
and then check what actually worked is good for reducing the
combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
test different KMS configurations. Userspace has a better chance of
finding a configuration that is possible.

OTOH, this has the problem than in UI one cannot tell the user in
advance which options are truly possible. Given that KMS properties are
rarely completely independent, and in this case known to depend on
several other KMS properties, I think it is good enough to know after
the fact.

If a driver does not use what userspace prefers, there is no way to
understand why, or what else to change to make it happen. That problem
exists anyway, because TEST_ONLY commits do not give useful feedback
but only a yes/no.

Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>


Thanks,
pq


> +
>  	/**
>  	 * @hdr_output_metadata:
>  	 * DRM blob property for HDR output metadata
> @@ -1404,6 +1414,12 @@ struct drm_connector {
>  	 */
>  	struct drm_property *active_bpc_property;
>  
> +	/**
> +	 * @preferred_color_format_property: Default connector property for the
> +	 * preferred color format to be driven out of the connector.
> +	 */
> +	struct drm_property *preferred_color_format_property;
> +
>  	/**
>  	 * @active_color_format_property: Default connector property for the
>  	 * active color format to be driven out of the connector.
> @@ -1740,6 +1756,7 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>  					  int min, int max);
>  int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
>  void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
> +int drm_connector_attach_preferred_color_format_property(struct drm_connector *connector);
>  int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
>  void drm_connector_set_active_color_format_property(struct drm_connector *connector,
>  						    u32 active_color_format);


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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
  2021-06-18  9:11 ` [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context Werner Sembach
@ 2021-06-22  7:25   ` Pekka Paalanen
  2021-06-22  9:57     ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-22  7:25 UTC (permalink / raw)
  To: Werner Sembach
  Cc: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

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

On Fri, 18 Jun 2021 11:11:14 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Add "Broadcast RGB" to general drm context so that more drivers besides
> i915 and gma500 can implement it without duplicating code.
> 
> Userspace can use this property to tell the graphic driver to use full or
> limited color range for a given connector, overwriting the default
> behaviour/automatic detection.
> 
> Possible options are:
>     - Automatic (default/current behaviour)
>     - Full
>     - Limited 16:235
> 
> In theory the driver should be able to automatically detect the monitors
> capabilities, but because of flawed standard implementations in Monitors,
> this might fail. In this case a manual overwrite is required to not have
> washed out colors or lose details in very dark or bright scenes.
> 
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>  drivers/gpu/drm/drm_connector.c     | 43 +++++++++++++++++++++++++++++
>  include/drm/drm_connector.h         | 16 +++++++++++
>  4 files changed, 67 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 90d62f305257..0c89d32efbd0 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>  			if (old_connector_state->preferred_color_format !=
>  			    new_connector_state->preferred_color_format)
>  				new_crtc_state->connectors_changed = true;
> +
> +			if (old_connector_state->preferred_color_range !=
> +			    new_connector_state->preferred_color_range)
> +				new_crtc_state->connectors_changed = true;
>  		}
>  
>  		if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index c536f5e22016..c589bb1a8163 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>  		state->max_requested_bpc = val;
>  	} else if (property == connector->preferred_color_format_property) {
>  		state->preferred_color_format = val;
> +	} else if (property == connector->preferred_color_range_property) {
> +		state->preferred_color_range = val;
>  	} else if (connector->funcs->atomic_set_property) {
>  		return connector->funcs->atomic_set_property(connector,
>  				state, property, val);
> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>  		*val = state->max_requested_bpc;
>  	} else if (property == connector->preferred_color_format_property) {
>  		*val = state->preferred_color_format;
> +	} else if (property == connector->preferred_color_range_property) {
> +		*val = state->preferred_color_range;
>  	} 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 aea03dd02e33..9bc596638613 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>  };
>  
> +static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = {
> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },

Hi,

the same question here about these numbers as I asked on the "active
color range" property.

> +};
> +
>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
>  	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>  	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	drm_connector_attach_active_color_format_property() to install this
>   *	property.
>   *
> + * Broadcast RGB:
> + *	This property is used by userspace to change the used color range. When
> + *	used the driver will use the selected range if valid for the current
> + *	color format. Drivers to use the function
> + *	drm_connector_attach_preferred_color_format_property() to create and
> + *	attach the property to the connector during initialization.

An important detail to document here is: does userspace need to
take care that pixel data at the connector will already match the set
range, or will the driver program the hardware to produce the set range?

If the former, then I'm afraid the preference/active property pair
design does not work. Userspace needs to make sure the content is in
the right range, so the driver cannot second-guess that afterwards.

If the latter, then what does the driver assume about color range just
before the automatic conversion to the final color range, and does the
range conversion happen as the final step in the color pipeline?

If I remember the discussion about Intel right, then the driver does
the latter and assume that userspace programs KMS to always produce
full range pixels. There is no provision for userspace to produce
limited range pixels, IIRC.


Thanks,
pq

> + *
>   * active color range:
>   *	This read-only property tells userspace the color range actually used by
>   *	the hardware display engine on "the cable" on a connector. The chosen
> @@ -2324,6 +2337,36 @@ void drm_connector_set_active_color_format_property(struct drm_connector *connec
>  }
>  EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
>  
> +/**
> + * drm_connector_attach_preferred_color_range_property - attach "Broadcast RGB" property
> + * @connector: connector to attach preferred color range property on.
> + *
> + * This is used to add support for selecting a color range on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_preferred_color_range_property(struct drm_connector *connector)
> +{
> +	struct drm_device *dev = connector->dev;
> +	struct drm_property *prop;
> +
> +	if (!connector->preferred_color_range_property) {
> +		prop = drm_property_create_enum(dev, 0, "Broadcast RGB",
> +						drm_preferred_color_range_enum_list,
> +						ARRAY_SIZE(drm_preferred_color_range_enum_list));
> +		if (!prop)
> +			return -ENOMEM;
> +
> +		connector->preferred_color_range_property = prop;
> +		drm_object_attach_property(&connector->base, prop, DRM_MODE_COLOR_RANGE_UNSET);
> +		connector->state->preferred_color_range = DRM_MODE_COLOR_RANGE_UNSET;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_preferred_color_range_property);
> +
>  /**
>   * drm_connector_attach_active_color_range_property - attach "active color range" property
>   * @connector: connector to attach active color range property on.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 7b85407ba45c..b319760d4a8c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -809,6 +809,15 @@ struct drm_connector_state {
>  	 */
>  	u32 preferred_color_format;
>  
> +	/**
> +	 * preferred_color_range: Property set by userspace via "Broadcast RGB"
> +	 * property to tell the GPU driver which color range to use. It
> +	 * overwrites existing automatic detection mechanisms, if set and valid
> +	 * for the current color format. Userspace can check for (un-)successful
> +	 * application via the "active color range" property.
> +	 */
> +	enum drm_mode_color_range preferred_color_range;
> +
>  	/**
>  	 * @hdr_output_metadata:
>  	 * DRM blob property for HDR output metadata
> @@ -1426,6 +1435,12 @@ struct drm_connector {
>  	 */
>  	struct drm_property *active_color_format_property;
>  
> +	/**
> +	 * @preferred_color_range_property: Default connector property for the
> +	 * preferred color range to be driven out of the connector.
> +	 */
> +	struct drm_property *preferred_color_range_property;
> +
>  	/**
>  	 * @active_color_range_property: Default connector property for the
>  	 * active color range to be driven out of the connector.
> @@ -1760,6 +1775,7 @@ int drm_connector_attach_preferred_color_format_property(struct drm_connector *c
>  int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
>  void drm_connector_set_active_color_format_property(struct drm_connector *connector,
>  						    u32 active_color_format);
> +int drm_connector_attach_preferred_color_range_property(struct drm_connector *connector);
>  int drm_connector_attach_active_color_range_property(struct drm_connector *connector);
>  void drm_connector_set_active_color_range_property(struct drm_connector *connector,
>  						   enum drm_mode_color_range active_color_range);


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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property
  2021-06-18  9:11 ` [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property Werner Sembach
@ 2021-06-22  7:29   ` Pekka Paalanen
  2021-06-22  9:28     ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-22  7:29 UTC (permalink / raw)
  To: Werner Sembach
  Cc: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

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

On Fri, 18 Jun 2021 11:11:16 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> This commit implements the "Broadcast RGB" drm property for the AMD GPU
> driver.
> 
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++++++++++++++-----
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 ++++
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> 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 9ffd2f9d3d75..c5dbf948a47a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
>  }
>  
>  static enum dc_color_space
> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
> +		       enum drm_mode_color_range preferred_color_range)
>  {
>  	enum dc_color_space color_space = COLOR_SPACE_SRGB;
>  
> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>  		 * respectively
>  		 */
>  		if (dc_crtc_timing->pix_clk_100hz > 270300) {
> -			if (dc_crtc_timing->flags.Y_ONLY)
> +			if (dc_crtc_timing->flags.Y_ONLY
> +					|| preferred_color_range ==
> +						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>  				color_space =
>  					COLOR_SPACE_YCBCR709_LIMITED;
>  			else
>  				color_space = COLOR_SPACE_YCBCR709;

Hi,

does this mean that amdgpu would be using a property named "Broadcast
RGB" to control the range of YCbCr too?

That is surprising. If this is truly wanted, then the documentation of
"Broadcast RGB" must say that it applies to YCbCr too.

Does amdgpu do the same as intel wrt. to the question about whose
responsibility it is to make the pixels at the connector to match the
set range?


Thanks,
pq

>  		} else {
> -			if (dc_crtc_timing->flags.Y_ONLY)
> +			if (dc_crtc_timing->flags.Y_ONLY
> +					|| preferred_color_range ==
> +						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>  				color_space =
>  					COLOR_SPACE_YCBCR601_LIMITED;
>  			else
> @@ -5283,7 +5288,10 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>  	}
>  	break;
>  	case PIXEL_ENCODING_RGB:
> -		color_space = COLOR_SPACE_SRGB;
> +		if (preferred_color_range == DRM_MODE_COLOR_RANGE_LIMITED_16_235)
> +			color_space = COLOR_SPACE_SRGB_LIMITED;
> +		else
> +			color_space = COLOR_SPACE_SRGB;
>  		break;
>  
>  	default:
> @@ -5429,7 +5437,10 @@ static void fill_stream_properties_from_drm_display_mode(
>  
>  	timing_out->aspect_ratio = get_aspect_ratio(mode_in);
>  
> -	stream->output_color_space = get_output_color_space(timing_out);
> +	stream->output_color_space = get_output_color_space(timing_out,
> +							    connector_state ?
> +							    connector_state->preferred_color_range :
> +							    DRM_MODE_COLOR_RANGE_UNSET);
>  
>  	stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
>  	stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
> @@ -7780,6 +7791,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>  		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
>  		drm_connector_attach_preferred_color_format_property(&aconnector->base);
>  		drm_connector_attach_active_color_format_property(&aconnector->base);
> +		drm_connector_attach_preferred_color_range_property(&aconnector->base);
>  		drm_connector_attach_active_color_range_property(&aconnector->base);
>  	}
>  
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 2563788ba95a..80e1389fd0ec 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
>  	if (connector->active_color_format_property)
>  		drm_connector_attach_active_color_format_property(&aconnector->base);
>  
> +	connector->preferred_color_range_property = master->base.preferred_color_range_property;
> +	if (connector->preferred_color_range_property)
> +		drm_connector_attach_preferred_color_range_property(&aconnector->base);
> +
>  	connector->active_color_range_property = master->base.active_color_range_property;
>  	if (connector->active_color_range_property)
>  		drm_connector_attach_active_color_range_property(&aconnector->base);


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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property
  2021-06-22  7:29   ` Pekka Paalanen
@ 2021-06-22  9:28     ` Werner Sembach
  2021-06-23  8:01       ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-22  9:28 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: amd-gfx, tzimmermann, intel-gfx, sunpeng.li, dri-devel,
	joonas.lahtinen, maarten.lankhorst, linux-kernel, mripard,
	airlied, jani.nikula, daniel, rodrigo.vivi, alexander.deucher,
	harry.wentland, christian.koenig

Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:16 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> This commit implements the "Broadcast RGB" drm property for the AMD GPU
>> driver.
>>
>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>> ---
>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++++++++++++++-----
>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 ++++
>>  2 files changed, 21 insertions(+), 5 deletions(-)
>>
>> 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 9ffd2f9d3d75..c5dbf948a47a 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
>>  }
>>  
>>  static enum dc_color_space
>> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
>> +		       enum drm_mode_color_range preferred_color_range)
>>  {
>>  	enum dc_color_space color_space = COLOR_SPACE_SRGB;
>>  
>> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>>  		 * respectively
>>  		 */
>>  		if (dc_crtc_timing->pix_clk_100hz > 270300) {
>> -			if (dc_crtc_timing->flags.Y_ONLY)
>> +			if (dc_crtc_timing->flags.Y_ONLY
>> +					|| preferred_color_range ==
>> +						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>  				color_space =
>>  					COLOR_SPACE_YCBCR709_LIMITED;
>>  			else
>>  				color_space = COLOR_SPACE_YCBCR709;
> Hi,
>
> does this mean that amdgpu would be using a property named "Broadcast
> RGB" to control the range of YCbCr too?

Yes, because I avoided creating a new property, but I'm not really happy with it either.

Possibility 1: Use "Broadcast RGB" for Y'CbCr too and clarify in documentation
    - still confusing name
    - limited does not mean something a little bit different for Y'CbCr and not strictly 16-235:
https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization , but name
of option is given by preexisting property

Possibility 2: Deprecate "Broadcast RGB" and a a more neutral sounding "preferred color range", with the more neutral
sounding "limited" option instead of "Limited 16:235"
    - What's the relation between the 2? pq mentioned on the amdgpu gitlab that there is a posibility for userspace to
have only the new or the old one shown
    - Alternatively ignore "Broadcast RGB" when "preferred color range" is set and have them coexist?

>
> That is surprising. If this is truly wanted, then the documentation of
> "Broadcast RGB" must say that it applies to YCbCr too.
>
> Does amdgpu do the same as intel wrt. to the question about whose
> responsibility it is to make the pixels at the connector to match the
> set range?

I guess the kernel driver does the conversion, but i have to check for both.

For Intel I did not change the behavior of Boradcast RGB, but i think it's not clearly specified in the docs where the
conversion happens.

>
>
> Thanks,
> pq
>
>>  		} else {
>> -			if (dc_crtc_timing->flags.Y_ONLY)
>> +			if (dc_crtc_timing->flags.Y_ONLY
>> +					|| preferred_color_range ==
>> +						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>  				color_space =
>>  					COLOR_SPACE_YCBCR601_LIMITED;
>>  			else
>> @@ -5283,7 +5288,10 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>>  	}
>>  	break;
>>  	case PIXEL_ENCODING_RGB:
>> -		color_space = COLOR_SPACE_SRGB;
>> +		if (preferred_color_range == DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>> +			color_space = COLOR_SPACE_SRGB_LIMITED;
>> +		else
>> +			color_space = COLOR_SPACE_SRGB;
>>  		break;
>>  
>>  	default:
>> @@ -5429,7 +5437,10 @@ static void fill_stream_properties_from_drm_display_mode(
>>  
>>  	timing_out->aspect_ratio = get_aspect_ratio(mode_in);
>>  
>> -	stream->output_color_space = get_output_color_space(timing_out);
>> +	stream->output_color_space = get_output_color_space(timing_out,
>> +							    connector_state ?
>> +							    connector_state->preferred_color_range :
>> +							    DRM_MODE_COLOR_RANGE_UNSET);
>>  
>>  	stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
>>  	stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
>> @@ -7780,6 +7791,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>>  		drm_connector_attach_active_bpc_property(&aconnector->base, 8, 16);
>>  		drm_connector_attach_preferred_color_format_property(&aconnector->base);
>>  		drm_connector_attach_active_color_format_property(&aconnector->base);
>> +		drm_connector_attach_preferred_color_range_property(&aconnector->base);
>>  		drm_connector_attach_active_color_range_property(&aconnector->base);
>>  	}
>>  
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> index 2563788ba95a..80e1389fd0ec 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> @@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
>>  	if (connector->active_color_format_property)
>>  		drm_connector_attach_active_color_format_property(&aconnector->base);
>>  
>> +	connector->preferred_color_range_property = master->base.preferred_color_range_property;
>> +	if (connector->preferred_color_range_property)
>> +		drm_connector_attach_preferred_color_range_property(&aconnector->base);
>> +
>>  	connector->active_color_range_property = master->base.active_color_range_property;
>>  	if (connector->active_color_range_property)
>>  		drm_connector_attach_active_color_range_property(&aconnector->base);
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-22  7:00   ` Pekka Paalanen
@ 2021-06-22  9:50     ` Werner Sembach
  2021-06-22 11:48       ` Simon Ser
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-22  9:50 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: amd-gfx, tzimmermann, intel-gfx, sunpeng.li, dri-devel,
	joonas.lahtinen, maarten.lankhorst, linux-kernel, mripard,
	airlied, jani.nikula, daniel, rodrigo.vivi, alexander.deucher,
	harry.wentland, christian.koenig


Am 22.06.21 um 09:00 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:08 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Add a new general drm property "active color range" which can be used by
>> graphic drivers to report the used color range back to userspace.
>>
>> There was no way to check which color range got actually used on a given
>> monitor. To surely predict this, one must know the exact capabilities of
>> the monitor and what the default behaviour of the used driver is. This
>> property helps eliminating the guessing at this point.
>>
>> In the future, automatic color calibration for screens might also depend on
>> this information being available.
>>
>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>> ---
>>  drivers/gpu/drm/drm_connector.c | 59 +++++++++++++++++++++++++++++++++
>>  include/drm/drm_connector.h     | 27 +++++++++++++++
>>  2 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> index 684d7abdf0eb..818de58d972f 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -897,6 +897,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
>>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>  };
>>  
>> +static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
>> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
> Doesn't "limited" mean different numbers on RGB vs. Y vs. CbCr? I have
> a vague recollection that at least one of them was different from the
> others.

Yes, seems like it does:
https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization

I carried the option names over from "Broadcast RGB", see my other e-mail for more details.

>
> Documenting DRM_MODE_COLOR_RANGE_UNSET as "unspecified/default" while
> the string for it is "Unknown" seems inconsistent to me. I would
> recommend to avoid the word "default" because "reset to defaults" might
> become a thing one day, and that probably is not the same default as
> here.
>
> Is there actually a case for "unknown"? How can it be not known? Or
> does it mean "not applicable"?

Unknown is when no monitor is connected or is when the connector/monitor is disabled.

It also is the initial value when the driver fails to correctly set the property. This shouldn't happen, but I'm
wondering if I should still introduce an _ERROR state instead for this case?

I will rename it, maybe "unset" to match the enum? "not applicable" also fits if either the error state is defined or
not necessary.

>
> Otherwise looks good to me.
>
>
> Thanks,
> pq
>
>
>> +};
>> +
>>  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>>  		 drm_dp_subconnector_enum_list)
>>  
>> @@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>   *	drm_connector_attach_active_color_format_property() to install this
>>   *	property.
>>   *
>> + * active color range:
>> + *	This read-only property tells userspace the color range actually used by
>> + *	the hardware display engine on "the cable" on a connector. The chosen
>> + *	value depends on hardware capabilities of the monitor and the used color
>> + *	format. Drivers shall use
>> + *	drm_connector_attach_active_color_range_property() to install this
>> + *	property.
>> + *
>>   * Connectors also have one standardized atomic property:
>>   *
>>   * CRTC_ID:
>> @@ -2264,6 +2278,51 @@ void drm_connector_set_active_color_format_property(struct drm_connector *connec
>>  }
>>  EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
>>  
>> +/**
>> + * drm_connector_attach_active_color_range_property - attach "active color range" property
>> + * @connector: connector to attach active color range property on.
>> + *
>> + * This is used to check the applied color range on a connector.
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_connector_attach_active_color_range_property(struct drm_connector *connector)
>> +{
>> +	struct drm_device *dev = connector->dev;
>> +	struct drm_property *prop;
>> +
>> +	if (!connector->active_color_range_property) {
>> +		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, "active color range",
>> +						drm_active_color_range_enum_list,
>> +						ARRAY_SIZE(drm_active_color_range_enum_list));
>> +		if (!prop)
>> +			return -ENOMEM;
>> +
>> +		connector->active_color_range_property = prop;
>> +		drm_object_attach_property(&connector->base, prop, DRM_MODE_COLOR_RANGE_UNSET);
>> +	}
>> +
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
>> +
>> +/**
>> + * drm_connector_set_active_color_range_property - sets the active color range property for a
>> + * connector
>> + * @connector: drm connector
>> + * @active_color_range: color range for the connector currently active on "the cable"
>> + *
>> + * Should be used by atomic drivers to update the active color range over a connector.
>> + */
>> +void drm_connector_set_active_color_range_property(struct drm_connector *connector,
>> +						   enum drm_mode_color_range active_color_range)
>> +{
>> +	drm_object_property_set_value(&connector->base, connector->active_color_range_property,
>> +				      active_color_range);
>> +}
>> +EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
>> +
>>  /**
>>   * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
>>   * @connector: connector to attach the property on.
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 8a5197f14e87..9fb7119b7a02 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -648,6 +648,24 @@ struct drm_tv_connector_state {
>>  	unsigned int hue;
>>  };
>>  
>> +/**
>> + * enum drm_mode_color_range - color_range info for &drm_connector
>> + *
>> + * This enum is used to represent full or limited color range on the display
>> + * connector signal.
>> + *
>> + * @DRM_MODE_COLOR_RANGE_UNSET:		Color range is unspecified/default.
>> + * @DRM_MODE_COLOR_RANGE_FULL:		Color range is full range, 0-255 for
>> + *					8-Bit color depth.
>> + * DRM_MODE_COLOR_RANGE_LIMITED_16_235:	Color range is limited range, 16-235 for
>> + *					8-Bit color depth.
>> + */
>> +enum drm_mode_color_range {
>> +	DRM_MODE_COLOR_RANGE_UNSET,
>> +	DRM_MODE_COLOR_RANGE_FULL,
>> +	DRM_MODE_COLOR_RANGE_LIMITED_16_235,
>> +};
>> +
>>  /**
>>   * struct drm_connector_state - mutable connector state
>>   */
>> @@ -1392,6 +1410,12 @@ struct drm_connector {
>>  	 */
>>  	struct drm_property *active_color_format_property;
>>  
>> +	/**
>> +	 * @active_color_range_property: Default connector property for the
>> +	 * active color range to be driven out of the connector.
>> +	 */
>> +	struct drm_property *active_color_range_property;
>> +
>>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
>> @@ -1719,6 +1743,9 @@ void drm_connector_set_active_bpc_property(struct drm_connector *connector, int
>>  int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
>>  void drm_connector_set_active_color_format_property(struct drm_connector *connector,
>>  						    u32 active_color_format);
>> +int drm_connector_attach_active_color_range_property(struct drm_connector *connector);
>> +void drm_connector_set_active_color_range_property(struct drm_connector *connector,
>> +						   enum drm_mode_color_range active_color_range);
>>  
>>  /**
>>   * struct drm_tile_group - Tile group metadata
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
  2021-06-22  7:25   ` Pekka Paalanen
@ 2021-06-22  9:57     ` Werner Sembach
  2021-06-23  7:48       ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-22  9:57 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: amd-gfx, tzimmermann, intel-gfx, sunpeng.li, dri-devel,
	joonas.lahtinen, maarten.lankhorst, linux-kernel, mripard,
	airlied, jani.nikula, daniel, rodrigo.vivi, alexander.deucher,
	harry.wentland, christian.koenig

Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:14 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Add "Broadcast RGB" to general drm context so that more drivers besides
>> i915 and gma500 can implement it without duplicating code.
>>
>> Userspace can use this property to tell the graphic driver to use full or
>> limited color range for a given connector, overwriting the default
>> behaviour/automatic detection.
>>
>> Possible options are:
>>     - Automatic (default/current behaviour)
>>     - Full
>>     - Limited 16:235
>>
>> In theory the driver should be able to automatically detect the monitors
>> capabilities, but because of flawed standard implementations in Monitors,
>> this might fail. In this case a manual overwrite is required to not have
>> washed out colors or lose details in very dark or bright scenes.
>>
>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>>  drivers/gpu/drm/drm_connector.c     | 43 +++++++++++++++++++++++++++++
>>  include/drm/drm_connector.h         | 16 +++++++++++
>>  4 files changed, 67 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
>> index 90d62f305257..0c89d32efbd0 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>  			if (old_connector_state->preferred_color_format !=
>>  			    new_connector_state->preferred_color_format)
>>  				new_crtc_state->connectors_changed = true;
>> +
>> +			if (old_connector_state->preferred_color_range !=
>> +			    new_connector_state->preferred_color_range)
>> +				new_crtc_state->connectors_changed = true;
>>  		}
>>  
>>  		if (funcs->atomic_check)
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c536f5e22016..c589bb1a8163 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>>  		state->max_requested_bpc = val;
>>  	} else if (property == connector->preferred_color_format_property) {
>>  		state->preferred_color_format = val;
>> +	} else if (property == connector->preferred_color_range_property) {
>> +		state->preferred_color_range = val;
>>  	} else if (connector->funcs->atomic_set_property) {
>>  		return connector->funcs->atomic_set_property(connector,
>>  				state, property, val);
>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>>  		*val = state->max_requested_bpc;
>>  	} else if (property == connector->preferred_color_format_property) {
>>  		*val = state->preferred_color_format;
>> +	} else if (property == connector->preferred_color_range_property) {
>> +		*val = state->preferred_color_range;
>>  	} 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 aea03dd02e33..9bc596638613 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
>>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>  };
>>  
>> +static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = {
>> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
>> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
> Hi,
>
> the same question here about these numbers as I asked on the "active
> color range" property.
>
>> +};
>> +
>>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
>>  	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>>  	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>   *	drm_connector_attach_active_color_format_property() to install this
>>   *	property.
>>   *
>> + * Broadcast RGB:
>> + *	This property is used by userspace to change the used color range. When
>> + *	used the driver will use the selected range if valid for the current
>> + *	color format. Drivers to use the function
>> + *	drm_connector_attach_preferred_color_format_property() to create and
>> + *	attach the property to the connector during initialization.
> An important detail to document here is: does userspace need to
> take care that pixel data at the connector will already match the set
> range, or will the driver program the hardware to produce the set range?
Since until now, the userspace didn't even know for sure if RGB or YCbCr and therefore which full/limited format was
used I guess it's all kernel space conversion.
>
> If the former, then I'm afraid the preference/active property pair
> design does not work. Userspace needs to make sure the content is in
> the right range, so the driver cannot second-guess that afterwards.
>
> If the latter, then what does the driver assume about color range just
> before the automatic conversion to the final color range, and does the
> range conversion happen as the final step in the color pipeline?
>
> If I remember the discussion about Intel right, then the driver does
> the latter and assume that userspace programs KMS to always produce
> full range pixels. There is no provision for userspace to produce
> limited range pixels, IIRC.
I think I remember this too from an answer to one of the revisions of this patchset.
>
>
> Thanks,
> pq
>
>> + *
>>   * active color range:
>>   *	This read-only property tells userspace the color range actually used by
>>   *	the hardware display engine on "the cable" on a connector. The chosen
>> @@ -2324,6 +2337,36 @@ void drm_connector_set_active_color_format_property(struct drm_connector *connec
>>  }
>>  EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
>>  
>> +/**
>> + * drm_connector_attach_preferred_color_range_property - attach "Broadcast RGB" property
>> + * @connector: connector to attach preferred color range property on.
>> + *
>> + * This is used to add support for selecting a color range on a connector.
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_connector_attach_preferred_color_range_property(struct drm_connector *connector)
>> +{
>> +	struct drm_device *dev = connector->dev;
>> +	struct drm_property *prop;
>> +
>> +	if (!connector->preferred_color_range_property) {
>> +		prop = drm_property_create_enum(dev, 0, "Broadcast RGB",
>> +						drm_preferred_color_range_enum_list,
>> +						ARRAY_SIZE(drm_preferred_color_range_enum_list));
>> +		if (!prop)
>> +			return -ENOMEM;
>> +
>> +		connector->preferred_color_range_property = prop;
>> +		drm_object_attach_property(&connector->base, prop, DRM_MODE_COLOR_RANGE_UNSET);
>> +		connector->state->preferred_color_range = DRM_MODE_COLOR_RANGE_UNSET;
>> +	}
>> +
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL(drm_connector_attach_preferred_color_range_property);
>> +
>>  /**
>>   * drm_connector_attach_active_color_range_property - attach "active color range" property
>>   * @connector: connector to attach active color range property on.
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 7b85407ba45c..b319760d4a8c 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -809,6 +809,15 @@ struct drm_connector_state {
>>  	 */
>>  	u32 preferred_color_format;
>>  
>> +	/**
>> +	 * preferred_color_range: Property set by userspace via "Broadcast RGB"
>> +	 * property to tell the GPU driver which color range to use. It
>> +	 * overwrites existing automatic detection mechanisms, if set and valid
>> +	 * for the current color format. Userspace can check for (un-)successful
>> +	 * application via the "active color range" property.
>> +	 */
>> +	enum drm_mode_color_range preferred_color_range;
>> +
>>  	/**
>>  	 * @hdr_output_metadata:
>>  	 * DRM blob property for HDR output metadata
>> @@ -1426,6 +1435,12 @@ struct drm_connector {
>>  	 */
>>  	struct drm_property *active_color_format_property;
>>  
>> +	/**
>> +	 * @preferred_color_range_property: Default connector property for the
>> +	 * preferred color range to be driven out of the connector.
>> +	 */
>> +	struct drm_property *preferred_color_range_property;
>> +
>>  	/**
>>  	 * @active_color_range_property: Default connector property for the
>>  	 * active color range to be driven out of the connector.
>> @@ -1760,6 +1775,7 @@ int drm_connector_attach_preferred_color_format_property(struct drm_connector *c
>>  int drm_connector_attach_active_color_format_property(struct drm_connector *connector);
>>  void drm_connector_set_active_color_format_property(struct drm_connector *connector,
>>  						    u32 active_color_format);
>> +int drm_connector_attach_preferred_color_range_property(struct drm_connector *connector);
>>  int drm_connector_attach_active_color_range_property(struct drm_connector *connector);
>>  void drm_connector_set_active_color_range_property(struct drm_connector *connector,
>>  						   enum drm_mode_color_range active_color_range);
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-22  9:50     ` Werner Sembach
@ 2021-06-22 11:48       ` Simon Ser
  2021-06-23  7:32         ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Simon Ser @ 2021-06-22 11:48 UTC (permalink / raw)
  To: Werner Sembach
  Cc: Pekka Paalanen, sunpeng.li, intel-gfx, linux-kernel, dri-devel,
	airlied, amd-gfx, tzimmermann, rodrigo.vivi, alexander.deucher,
	christian.koenig

On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach <wse@tuxedocomputers.com> wrote:

> Unknown is when no monitor is connected or is when the
> connector/monitor is disabled.

I think the other connector props (link-status, non-desktop, etc) don't
have a special "unset" value, and instead the value is set to a random
enum entry. User-space should ignore the prop on these disconnected
connectors anyways.

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-22 11:48       ` Simon Ser
@ 2021-06-23  7:32         ` Pekka Paalanen
  2021-06-23 10:17           ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-23  7:32 UTC (permalink / raw)
  To: Simon Ser
  Cc: Werner Sembach, sunpeng.li, intel-gfx, linux-kernel, dri-devel,
	airlied, amd-gfx, tzimmermann, rodrigo.vivi, alexander.deucher,
	christian.koenig

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

On Tue, 22 Jun 2021 11:48:52 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach <wse@tuxedocomputers.com> wrote:
> 
> > Unknown is when no monitor is connected or is when the
> > connector/monitor is disabled.  
> 
> I think the other connector props (link-status, non-desktop, etc) don't
> have a special "unset" value, and instead the value is set to a random
> enum entry. User-space should ignore the prop on these disconnected
> connectors anyways.

That sounds fine to me.


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
  2021-06-22  9:57     ` Werner Sembach
@ 2021-06-23  7:48       ` Pekka Paalanen
  2021-06-23 10:10         ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-23  7:48 UTC (permalink / raw)
  To: Werner Sembach
  Cc: amd-gfx, tzimmermann, intel-gfx, sunpeng.li, dri-devel,
	joonas.lahtinen, maarten.lankhorst, linux-kernel, mripard,
	airlied, jani.nikula, daniel, rodrigo.vivi, alexander.deucher,
	harry.wentland, christian.koenig

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

On Tue, 22 Jun 2021 11:57:53 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> > On Fri, 18 Jun 2021 11:11:14 +0200
> > Werner Sembach <wse@tuxedocomputers.com> wrote:
> >  
> >> Add "Broadcast RGB" to general drm context so that more drivers besides
> >> i915 and gma500 can implement it without duplicating code.
> >>
> >> Userspace can use this property to tell the graphic driver to use full or
> >> limited color range for a given connector, overwriting the default
> >> behaviour/automatic detection.
> >>
> >> Possible options are:
> >>     - Automatic (default/current behaviour)
> >>     - Full
> >>     - Limited 16:235
> >>
> >> In theory the driver should be able to automatically detect the monitors
> >> capabilities, but because of flawed standard implementations in Monitors,
> >> this might fail. In this case a manual overwrite is required to not have
> >> washed out colors or lose details in very dark or bright scenes.
> >>
> >> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> >> ---
> >>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
> >>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
> >>  drivers/gpu/drm/drm_connector.c     | 43 +++++++++++++++++++++++++++++
> >>  include/drm/drm_connector.h         | 16 +++++++++++
> >>  4 files changed, 67 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 90d62f305257..0c89d32efbd0 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >>  			if (old_connector_state->preferred_color_format !=
> >>  			    new_connector_state->preferred_color_format)
> >>  				new_crtc_state->connectors_changed = true;
> >> +
> >> +			if (old_connector_state->preferred_color_range !=
> >> +			    new_connector_state->preferred_color_range)
> >> +				new_crtc_state->connectors_changed = true;
> >>  		}
> >>  
> >>  		if (funcs->atomic_check)
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index c536f5e22016..c589bb1a8163 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> >>  		state->max_requested_bpc = val;
> >>  	} else if (property == connector->preferred_color_format_property) {
> >>  		state->preferred_color_format = val;
> >> +	} else if (property == connector->preferred_color_range_property) {
> >> +		state->preferred_color_range = val;
> >>  	} else if (connector->funcs->atomic_set_property) {
> >>  		return connector->funcs->atomic_set_property(connector,
> >>  				state, property, val);
> >> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> >>  		*val = state->max_requested_bpc;
> >>  	} else if (property == connector->preferred_color_format_property) {
> >>  		*val = state->preferred_color_format;
> >> +	} else if (property == connector->preferred_color_range_property) {
> >> +		*val = state->preferred_color_range;
> >>  	} 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 aea03dd02e33..9bc596638613 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
> >>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
> >>  };
> >>  
> >> +static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = {
> >> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
> >> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
> >> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },  
> > Hi,
> >
> > the same question here about these numbers as I asked on the "active
> > color range" property.
> >  
> >> +};
> >> +
> >>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
> >>  	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
> >>  	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
> >> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >>   *	drm_connector_attach_active_color_format_property() to install this
> >>   *	property.
> >>   *
> >> + * Broadcast RGB:
> >> + *	This property is used by userspace to change the used color range. When
> >> + *	used the driver will use the selected range if valid for the current
> >> + *	color format. Drivers to use the function
> >> + *	drm_connector_attach_preferred_color_format_property() to create and
> >> + *	attach the property to the connector during initialization.  
> > An important detail to document here is: does userspace need to
> > take care that pixel data at the connector will already match the set
> > range, or will the driver program the hardware to produce the set range?  
> Since until now, the userspace didn't even know for sure if RGB or YCbCr and therefore which full/limited format was
> used I guess it's all kernel space conversion.
> >
> > If the former, then I'm afraid the preference/active property pair
> > design does not work. Userspace needs to make sure the content is in
> > the right range, so the driver cannot second-guess that afterwards.
> >
> > If the latter, then what does the driver assume about color range just
> > before the automatic conversion to the final color range, and does the
> > range conversion happen as the final step in the color pipeline?
> >
> > If I remember the discussion about Intel right, then the driver does
> > the latter and assume that userspace programs KMS to always produce
> > full range pixels. There is no provision for userspace to produce
> > limited range pixels, IIRC.  
> I think I remember this too from an answer to one of the revisions of this patchset.

As long as you keep the old KMS property as is, just moving code so it
is used by more drivers, this is fine and one can't do otherwise anyway.

(The rest of this email is merely pondering the future, so not about
this patch in particular.)


But if we had a new, more general property for the range reported to
monitors via infoframes, then it would be worth to re-visit the design.
The HDR properties only set the infoframe and expect userspace to make
sure that the pixels actually correspond to what the infoframes tell
the monitor. One can't do HDR tone mapping automatically in the kernel,
so in that sense the HDR property behaviour is obvious. But which
behaviour would fit range property or others better, I'm not sure.

Generally there seems to be two approaches to designing KMS properties:

- Let userspace describe what data it has and what data should be sent
  to a monitor, and let the kernel driver magically come up with a
  conversion.

- Only userspace understands how the pixel data is encoded, and
  programs the transformations (DEGAMMA/CTM/GAMMA etc.) such, that the
  result is what a monitor expects based on e.g. infoframes.

Doing the former requires policy in the kernel. If there is a
specification that uniquely defines what the conversion is, this is
good. But if not or if there are artistic decisions to be made, like
with HDR tone mapping, then it doesn't work.

OTOH, the former approach allows the driver to use any and all hardware
features it has to realize the conversion, perhaps taking advantage of
even fixed-function hardware blocks. The latter approach is much harder
to map to hardware features.

This dilemma has been discussed in length in
https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property
  2021-06-22  9:28     ` Werner Sembach
@ 2021-06-23  8:01       ` Pekka Paalanen
  2021-06-23  9:58         ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-23  8:01 UTC (permalink / raw)
  To: Werner Sembach
  Cc: amd-gfx, tzimmermann, intel-gfx, sunpeng.li, dri-devel,
	joonas.lahtinen, maarten.lankhorst, linux-kernel, mripard,
	airlied, jani.nikula, daniel, rodrigo.vivi, alexander.deucher,
	harry.wentland, christian.koenig

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

On Tue, 22 Jun 2021 11:28:57 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
> > On Fri, 18 Jun 2021 11:11:16 +0200
> > Werner Sembach <wse@tuxedocomputers.com> wrote:
> >  
> >> This commit implements the "Broadcast RGB" drm property for the AMD GPU
> >> driver.
> >>
> >> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> >> ---
> >>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++++++++++++++-----
> >>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 ++++
> >>  2 files changed, 21 insertions(+), 5 deletions(-)
> >>
> >> 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 9ffd2f9d3d75..c5dbf948a47a 100644
> >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
> >>  }
> >>  
> >>  static enum dc_color_space
> >> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
> >> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
> >> +		       enum drm_mode_color_range preferred_color_range)
> >>  {
> >>  	enum dc_color_space color_space = COLOR_SPACE_SRGB;
> >>  
> >> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
> >>  		 * respectively
> >>  		 */
> >>  		if (dc_crtc_timing->pix_clk_100hz > 270300) {
> >> -			if (dc_crtc_timing->flags.Y_ONLY)
> >> +			if (dc_crtc_timing->flags.Y_ONLY
> >> +					|| preferred_color_range ==
> >> +						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
> >>  				color_space =
> >>  					COLOR_SPACE_YCBCR709_LIMITED;
> >>  			else
> >>  				color_space = COLOR_SPACE_YCBCR709;  
> > Hi,
> >
> > does this mean that amdgpu would be using a property named "Broadcast
> > RGB" to control the range of YCbCr too?  
> 
> Yes, because I avoided creating a new property, but I'm not really happy with it either.
> 
> Possibility 1: Use "Broadcast RGB" for Y'CbCr too and clarify in documentation
>     - still confusing name
>     - limited does not mean something a little bit different for Y'CbCr and not strictly 16-235:
> https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization , but name
> of option is given by preexisting property
> 
> Possibility 2: Deprecate "Broadcast RGB" and a a more neutral sounding "preferred color range", with the more neutral
> sounding "limited" option instead of "Limited 16:235"
>     - What's the relation between the 2? pq mentioned on the amdgpu
> gitlab that there is a posibility for userspace to have only the new
> or the old one shown

It's just an idea that we could decide to expose only one or the other
property. It would need to be engineered in code, go through the UAPI
validation with userspace etc. I'm not aware of this being done before
exactly like this, but DRM client caps exist.

>     - Alternatively ignore "Broadcast RGB" when "preferred color range" is set and have them coexist?

Determining "is set" means we would need "unset" value for "preferred
color range". But there is no notion of who set it. If some KMS client
decides to set it, then it will likely remain set, even if you next
start another KMS client who does not use this property - it would just
confuse users when "Broadcast RGB" silently stopped working while it
still exists.

So I don't think this is a good solution.

When considering a new property, what I wrote just earlier fit here:
https://lists.freedesktop.org/archives/dri-devel/2021-June/312248.html

There are more questions that just what does the limited range actually
mean.

> > That is surprising. If this is truly wanted, then the documentation of
> > "Broadcast RGB" must say that it applies to YCbCr too.
> >
> > Does amdgpu do the same as intel wrt. to the question about whose
> > responsibility it is to make the pixels at the connector to match the
> > set range?  
> 
> I guess the kernel driver does the conversion, but i have to check
> for both.
> 
> For Intel I did not change the behavior of Boradcast RGB, but i think
> it's not clearly specified in the docs where the conversion happens.

Right, at the very least the current behaviour needs to be documented
before enrolling this property to any more drivers, so that those
drivers can then be reviewed to work the same way.

You notice I didn't actually answer your question 1 or 2. I don't know.
Going with 1 is easy compared to 2, even if the names are awkward but
it technically shouldn't cause any problems. 2 may or may not be
better, and until we have answers to which design is better, it's maybe
best to leave option 2 alone?


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property
  2021-06-23  8:01       ` Pekka Paalanen
@ 2021-06-23  9:58         ` Werner Sembach
  0 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-23  9:58 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

Am 23.06.21 um 10:01 schrieb Pekka Paalanen:
> On Tue, 22 Jun 2021 11:28:57 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
>>> On Fri, 18 Jun 2021 11:11:16 +0200
>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>  
>>>> This commit implements the "Broadcast RGB" drm property for the AMD GPU
>>>> driver.
>>>>
>>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>>>> ---
>>>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++++++++++++++-----
>>>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 ++++
>>>>  2 files changed, 21 insertions(+), 5 deletions(-)
>>>>
>>>> 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 9ffd2f9d3d75..c5dbf948a47a 100644
>>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>>> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
>>>>  }
>>>>  
>>>>  static enum dc_color_space
>>>> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>>>> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
>>>> +		       enum drm_mode_color_range preferred_color_range)
>>>>  {
>>>>  	enum dc_color_space color_space = COLOR_SPACE_SRGB;
>>>>  
>>>> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>>>>  		 * respectively
>>>>  		 */
>>>>  		if (dc_crtc_timing->pix_clk_100hz > 270300) {
>>>> -			if (dc_crtc_timing->flags.Y_ONLY)
>>>> +			if (dc_crtc_timing->flags.Y_ONLY
>>>> +					|| preferred_color_range ==
>>>> +						DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>>>  				color_space =
>>>>  					COLOR_SPACE_YCBCR709_LIMITED;
>>>>  			else
>>>>  				color_space = COLOR_SPACE_YCBCR709;  
>>> Hi,
>>>
>>> does this mean that amdgpu would be using a property named "Broadcast
>>> RGB" to control the range of YCbCr too?  
>> Yes, because I avoided creating a new property, but I'm not really happy with it either.
>>
>> Possibility 1: Use "Broadcast RGB" for Y'CbCr too and clarify in documentation
>>     - still confusing name
>>     - limited does not mean something a little bit different for Y'CbCr and not strictly 16-235:
>> https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization , but name
>> of option is given by preexisting property
>>
>> Possibility 2: Deprecate "Broadcast RGB" and a a more neutral sounding "preferred color range", with the more neutral
>> sounding "limited" option instead of "Limited 16:235"
>>     - What's the relation between the 2? pq mentioned on the amdgpu
>> gitlab that there is a posibility for userspace to have only the new
>> or the old one shown
> It's just an idea that we could decide to expose only one or the other
> property. It would need to be engineered in code, go through the UAPI
> validation with userspace etc. I'm not aware of this being done before
> exactly like this, but DRM client caps exist.
>
>>     - Alternatively ignore "Broadcast RGB" when "preferred color range" is set and have them coexist?
> Determining "is set" means we would need "unset" value for "preferred
> color range". But there is no notion of who set it. If some KMS client
> decides to set it, then it will likely remain set, even if you next
> start another KMS client who does not use this property - it would just
> confuse users when "Broadcast RGB" silently stopped working while it
> still exists.
Unset would be the "auto" option. But i think this problem exists already e.g. a KMS client is unaware of the new
"preferred color format" property and sets "Broadcast RGB" on intel which does nothing in the case of Y'CbCr.

Since the properties affecting each other, having only one not at default, potentially breaks KMS clients unaware of
them regardless.
>
> So I don't think this is a good solution.
>
> When considering a new property, what I wrote just earlier fit here:
> https://lists.freedesktop.org/archives/dri-devel/2021-June/312248.html
>
> There are more questions that just what does the limited range actually
> mean.
>
>>> That is surprising. If this is truly wanted, then the documentation of
>>> "Broadcast RGB" must say that it applies to YCbCr too.
>>>
>>> Does amdgpu do the same as intel wrt. to the question about whose
>>> responsibility it is to make the pixels at the connector to match the
>>> set range?  
>> I guess the kernel driver does the conversion, but i have to check
>> for both.
>>
>> For Intel I did not change the behavior of Boradcast RGB, but i think
>> it's not clearly specified in the docs where the conversion happens.
> Right, at the very least the current behaviour needs to be documented
> before enrolling this property to any more drivers, so that those
> drivers can then be reviewed to work the same way.
>
> You notice I didn't actually answer your question 1 or 2. I don't know.
> Going with 1 is easy compared to 2, even if the names are awkward but
> it technically shouldn't cause any problems. 2 may or may not be
> better, and until we have answers to which design is better, it's maybe
> best to leave option 2 alone?
OK, I will try to validate the behavior of the Intel driver and be detailed in the documentation, but keep the
implementation like this now (unless the intel driver does something different then I thought ofc).
>
>
> Thanks,
> pq

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
  2021-06-23  7:48       ` Pekka Paalanen
@ 2021-06-23 10:10         ` Werner Sembach
  2021-06-23 11:26           ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-23 10:10 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

Am 23.06.21 um 09:48 schrieb Pekka Paalanen:
> On Tue, 22 Jun 2021 11:57:53 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
>>> On Fri, 18 Jun 2021 11:11:14 +0200
>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>  
>>>> Add "Broadcast RGB" to general drm context so that more drivers besides
>>>> i915 and gma500 can implement it without duplicating code.
>>>>
>>>> Userspace can use this property to tell the graphic driver to use full or
>>>> limited color range for a given connector, overwriting the default
>>>> behaviour/automatic detection.
>>>>
>>>> Possible options are:
>>>>     - Automatic (default/current behaviour)
>>>>     - Full
>>>>     - Limited 16:235
>>>>
>>>> In theory the driver should be able to automatically detect the monitors
>>>> capabilities, but because of flawed standard implementations in Monitors,
>>>> this might fail. In this case a manual overwrite is required to not have
>>>> washed out colors or lose details in very dark or bright scenes.
>>>>
>>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>>>> ---
>>>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>>>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>>>>  drivers/gpu/drm/drm_connector.c     | 43 +++++++++++++++++++++++++++++
>>>>  include/drm/drm_connector.h         | 16 +++++++++++
>>>>  4 files changed, 67 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
>>>> index 90d62f305257..0c89d32efbd0 100644
>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>>>  			if (old_connector_state->preferred_color_format !=
>>>>  			    new_connector_state->preferred_color_format)
>>>>  				new_crtc_state->connectors_changed = true;
>>>> +
>>>> +			if (old_connector_state->preferred_color_range !=
>>>> +			    new_connector_state->preferred_color_range)
>>>> +				new_crtc_state->connectors_changed = true;
>>>>  		}
>>>>  
>>>>  		if (funcs->atomic_check)
>>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>>>> index c536f5e22016..c589bb1a8163 100644
>>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>>>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>>>>  		state->max_requested_bpc = val;
>>>>  	} else if (property == connector->preferred_color_format_property) {
>>>>  		state->preferred_color_format = val;
>>>> +	} else if (property == connector->preferred_color_range_property) {
>>>> +		state->preferred_color_range = val;
>>>>  	} else if (connector->funcs->atomic_set_property) {
>>>>  		return connector->funcs->atomic_set_property(connector,
>>>>  				state, property, val);
>>>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>>>>  		*val = state->max_requested_bpc;
>>>>  	} else if (property == connector->preferred_color_format_property) {
>>>>  		*val = state->preferred_color_format;
>>>> +	} else if (property == connector->preferred_color_range_property) {
>>>> +		*val = state->preferred_color_range;
>>>>  	} 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 aea03dd02e33..9bc596638613 100644
>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
>>>>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>>>  };
>>>>  
>>>> +static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = {
>>>> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
>>>> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>>>> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },  
>>> Hi,
>>>
>>> the same question here about these numbers as I asked on the "active
>>> color range" property.
>>>  
>>>> +};
>>>> +
>>>>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
>>>>  	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>>>>  	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>>>> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>>>   *	drm_connector_attach_active_color_format_property() to install this
>>>>   *	property.
>>>>   *
>>>> + * Broadcast RGB:
>>>> + *	This property is used by userspace to change the used color range. When
>>>> + *	used the driver will use the selected range if valid for the current
>>>> + *	color format. Drivers to use the function
>>>> + *	drm_connector_attach_preferred_color_format_property() to create and
>>>> + *	attach the property to the connector during initialization.  
>>> An important detail to document here is: does userspace need to
>>> take care that pixel data at the connector will already match the set
>>> range, or will the driver program the hardware to produce the set range?  
>> Since until now, the userspace didn't even know for sure if RGB or YCbCr and therefore which full/limited format was
>> used I guess it's all kernel space conversion.
>>> If the former, then I'm afraid the preference/active property pair
>>> design does not work. Userspace needs to make sure the content is in
>>> the right range, so the driver cannot second-guess that afterwards.
>>>
>>> If the latter, then what does the driver assume about color range just
>>> before the automatic conversion to the final color range, and does the
>>> range conversion happen as the final step in the color pipeline?
>>>
>>> If I remember the discussion about Intel right, then the driver does
>>> the latter and assume that userspace programs KMS to always produce
>>> full range pixels. There is no provision for userspace to produce
>>> limited range pixels, IIRC.  
>> I think I remember this too from an answer to one of the revisions of this patchset.
> As long as you keep the old KMS property as is, just moving code so it
> is used by more drivers, this is fine and one can't do otherwise anyway.
>
> (The rest of this email is merely pondering the future, so not about
> this patch in particular.)
>
>
> But if we had a new, more general property for the range reported to
> monitors via infoframes, then it would be worth to re-visit the design.
> The HDR properties only set the infoframe and expect userspace to make
> sure that the pixels actually correspond to what the infoframes tell
> the monitor. One can't do HDR tone mapping automatically in the kernel,
> so in that sense the HDR property behaviour is obvious. But which
> behaviour would fit range property or others better, I'm not sure.
>
> Generally there seems to be two approaches to designing KMS properties:
>
> - Let userspace describe what data it has and what data should be sent
>   to a monitor, and let the kernel driver magically come up with a
>   conversion.
>
> - Only userspace understands how the pixel data is encoded, and
>   programs the transformations (DEGAMMA/CTM/GAMMA etc.) such, that the
>   result is what a monitor expects based on e.g. infoframes.

Why not both?

This patchset is thought to control what's happening "on the cable", so if the input data is in a different format, the
kernel has to convert it.

Maybe in the future there could be an additional set of "input-" properties. aka "input bpc", "input color format", and
"input color range". With an additional constraint that if "input-" property == "active-" property the kernel is not
allowed to do any conversion regarding this aspect, giving userspace full control if wanted.

>
> Doing the former requires policy in the kernel. If there is a
> specification that uniquely defines what the conversion is, this is
> good. But if not or if there are artistic decisions to be made, like
> with HDR tone mapping, then it doesn't work.
>
> OTOH, the former approach allows the driver to use any and all hardware
> features it has to realize the conversion, perhaps taking advantage of
> even fixed-function hardware blocks. The latter approach is much harder
> to map to hardware features.
>
> This dilemma has been discussed in length in
> https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html
>
>
> Thanks,
> pq

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-23  7:32         ` Pekka Paalanen
@ 2021-06-23 10:17           ` Werner Sembach
  2021-06-23 11:14             ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-23 10:17 UTC (permalink / raw)
  To: Pekka Paalanen, Simon Ser
  Cc: amd-gfx, sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig


Am 23.06.21 um 09:32 schrieb Pekka Paalanen:
> On Tue, 22 Jun 2021 11:48:52 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
>> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach <wse@tuxedocomputers.com> wrote:
>>
>>> Unknown is when no monitor is connected or is when the
>>> connector/monitor is disabled.  
>> I think the other connector props (link-status, non-desktop, etc) don't
>> have a special "unset" value, and instead the value is set to a random
>> enum entry. User-space should ignore the prop on these disconnected
>> connectors anyways.
> That sounds fine to me.

Currently the only case for "not applicable" is when the monitor is disconnected, but sicne the properties are so
interdependent, there might be a case in the future where e.g. a color format that has no differentiation between full
and limited arises. When there is no special unset/not applicable option, the userspace has to know exactly when an
option is valid or not, possible requiring additional logic.

Setting a "not applicable" value allows userspace to be more dumb, without much hassle on the kernelspace side.

>
>
> Thanks,
> pq
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-23 10:17           ` Werner Sembach
@ 2021-06-23 11:14             ` Pekka Paalanen
  2021-06-23 11:19               ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-23 11:14 UTC (permalink / raw)
  To: Werner Sembach
  Cc: Simon Ser, amd-gfx, sunpeng.li, intel-gfx, linux-kernel,
	dri-devel, airlied, tzimmermann, rodrigo.vivi, alexander.deucher,
	christian.koenig

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

On Wed, 23 Jun 2021 12:17:40 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 23.06.21 um 09:32 schrieb Pekka Paalanen:
> > On Tue, 22 Jun 2021 11:48:52 +0000
> > Simon Ser <contact@emersion.fr> wrote:
> >  
> >> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach <wse@tuxedocomputers.com> wrote:
> >>  
> >>> Unknown is when no monitor is connected or is when the
> >>> connector/monitor is disabled.    
> >> I think the other connector props (link-status, non-desktop, etc) don't
> >> have a special "unset" value, and instead the value is set to a random
> >> enum entry. User-space should ignore the prop on these disconnected
> >> connectors anyways.  
> > That sounds fine to me.  
> 
> Currently the only case for "not applicable" is when the monitor is
> disconnected, but sicne the properties are so interdependent, there
> might be a case in the future where e.g. a color format that has no
> differentiation between full and limited arises. When there is no
> special unset/not applicable option, the userspace has to know
> exactly when an option is valid or not, possible requiring additional
> logic.
> 
> Setting a "not applicable" value allows userspace to be more dumb,
> without much hassle on the kernelspace side.

That's a good point too. So "not applicable" would be a value, but
"unknown" would not be.


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
  2021-06-23 11:14             ` Pekka Paalanen
@ 2021-06-23 11:19               ` Werner Sembach
  0 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-23 11:19 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

Am 23.06.21 um 13:14 schrieb Pekka Paalanen:
> On Wed, 23 Jun 2021 12:17:40 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 23.06.21 um 09:32 schrieb Pekka Paalanen:
>>> On Tue, 22 Jun 2021 11:48:52 +0000
>>> Simon Ser <contact@emersion.fr> wrote:
>>>  
>>>> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>>  
>>>>> Unknown is when no monitor is connected or is when the
>>>>> connector/monitor is disabled.    
>>>> I think the other connector props (link-status, non-desktop, etc) don't
>>>> have a special "unset" value, and instead the value is set to a random
>>>> enum entry. User-space should ignore the prop on these disconnected
>>>> connectors anyways.  
>>> That sounds fine to me.  
>> Currently the only case for "not applicable" is when the monitor is
>> disconnected, but sicne the properties are so interdependent, there
>> might be a case in the future where e.g. a color format that has no
>> differentiation between full and limited arises. When there is no
>> special unset/not applicable option, the userspace has to know
>> exactly when an option is valid or not, possible requiring additional
>> logic.
>>
>> Setting a "not applicable" value allows userspace to be more dumb,
>> without much hassle on the kernelspace side.
> That's a good point too. So "not applicable" would be a value, but
> "unknown" would not be.
Ok, I have already renamed the "unknown" option to "not applicable" in my next revision (not yet posted to the mailing
list).
>
>
> Thanks,
> pq

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
  2021-06-23 10:10         ` Werner Sembach
@ 2021-06-23 11:26           ` Pekka Paalanen
  2021-06-25  8:48             ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-23 11:26 UTC (permalink / raw)
  To: Werner Sembach
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

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

On Wed, 23 Jun 2021 12:10:14 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 23.06.21 um 09:48 schrieb Pekka Paalanen:
> > On Tue, 22 Jun 2021 11:57:53 +0200
> > Werner Sembach <wse@tuxedocomputers.com> wrote:
> >  
> >> Am 22.06.21 um 09:25 schrieb Pekka Paalanen:  
> >>> On Fri, 18 Jun 2021 11:11:14 +0200
> >>> Werner Sembach <wse@tuxedocomputers.com> wrote:
> >>>    
> >>>> Add "Broadcast RGB" to general drm context so that more drivers besides
> >>>> i915 and gma500 can implement it without duplicating code.
> >>>>
> >>>> Userspace can use this property to tell the graphic driver to use full or
> >>>> limited color range for a given connector, overwriting the default
> >>>> behaviour/automatic detection.
> >>>>
> >>>> Possible options are:
> >>>>     - Automatic (default/current behaviour)
> >>>>     - Full
> >>>>     - Limited 16:235
> >>>>
> >>>> In theory the driver should be able to automatically detect the monitors
> >>>> capabilities, but because of flawed standard implementations in Monitors,
> >>>> this might fail. In this case a manual overwrite is required to not have
> >>>> washed out colors or lose details in very dark or bright scenes.
> >>>>
> >>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> >>>> ---
> >>>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
> >>>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
> >>>>  drivers/gpu/drm/drm_connector.c     | 43 +++++++++++++++++++++++++++++
> >>>>  include/drm/drm_connector.h         | 16 +++++++++++
> >>>>  4 files changed, 67 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >>>> index 90d62f305257..0c89d32efbd0 100644
> >>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >>>>  			if (old_connector_state->preferred_color_format !=
> >>>>  			    new_connector_state->preferred_color_format)
> >>>>  				new_crtc_state->connectors_changed = true;
> >>>> +
> >>>> +			if (old_connector_state->preferred_color_range !=
> >>>> +			    new_connector_state->preferred_color_range)
> >>>> +				new_crtc_state->connectors_changed = true;
> >>>>  		}
> >>>>  
> >>>>  		if (funcs->atomic_check)
> >>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> >>>> index c536f5e22016..c589bb1a8163 100644
> >>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >>>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> >>>>  		state->max_requested_bpc = val;
> >>>>  	} else if (property == connector->preferred_color_format_property) {
> >>>>  		state->preferred_color_format = val;
> >>>> +	} else if (property == connector->preferred_color_range_property) {
> >>>> +		state->preferred_color_range = val;
> >>>>  	} else if (connector->funcs->atomic_set_property) {
> >>>>  		return connector->funcs->atomic_set_property(connector,
> >>>>  				state, property, val);
> >>>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> >>>>  		*val = state->max_requested_bpc;
> >>>>  	} else if (property == connector->preferred_color_format_property) {
> >>>>  		*val = state->preferred_color_format;
> >>>> +	} else if (property == connector->preferred_color_range_property) {
> >>>> +		*val = state->preferred_color_range;
> >>>>  	} 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 aea03dd02e33..9bc596638613 100644
> >>>> --- a/drivers/gpu/drm/drm_connector.c
> >>>> +++ b/drivers/gpu/drm/drm_connector.c
> >>>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
> >>>>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
> >>>>  };
> >>>>  
> >>>> +static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = {
> >>>> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
> >>>> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
> >>>> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },    
> >>> Hi,
> >>>
> >>> the same question here about these numbers as I asked on the "active
> >>> color range" property.
> >>>    
> >>>> +};
> >>>> +
> >>>>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
> >>>>  	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
> >>>>  	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
> >>>> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >>>>   *	drm_connector_attach_active_color_format_property() to install this
> >>>>   *	property.
> >>>>   *
> >>>> + * Broadcast RGB:
> >>>> + *	This property is used by userspace to change the used color range. When
> >>>> + *	used the driver will use the selected range if valid for the current
> >>>> + *	color format. Drivers to use the function
> >>>> + *	drm_connector_attach_preferred_color_format_property() to create and
> >>>> + *	attach the property to the connector during initialization.    
> >>> An important detail to document here is: does userspace need to
> >>> take care that pixel data at the connector will already match the set
> >>> range, or will the driver program the hardware to produce the set range?    
> >> Since until now, the userspace didn't even know for sure if RGB or YCbCr and therefore which full/limited format was
> >> used I guess it's all kernel space conversion.  
> >>> If the former, then I'm afraid the preference/active property pair
> >>> design does not work. Userspace needs to make sure the content is in
> >>> the right range, so the driver cannot second-guess that afterwards.
> >>>
> >>> If the latter, then what does the driver assume about color range just
> >>> before the automatic conversion to the final color range, and does the
> >>> range conversion happen as the final step in the color pipeline?
> >>>
> >>> If I remember the discussion about Intel right, then the driver does
> >>> the latter and assume that userspace programs KMS to always produce
> >>> full range pixels. There is no provision for userspace to produce
> >>> limited range pixels, IIRC.    
> >> I think I remember this too from an answer to one of the revisions of this patchset.  
> > As long as you keep the old KMS property as is, just moving code so it
> > is used by more drivers, this is fine and one can't do otherwise anyway.
> >
> > (The rest of this email is merely pondering the future, so not about
> > this patch in particular.)
> >
> >
> > But if we had a new, more general property for the range reported to
> > monitors via infoframes, then it would be worth to re-visit the design.
> > The HDR properties only set the infoframe and expect userspace to make
> > sure that the pixels actually correspond to what the infoframes tell
> > the monitor. One can't do HDR tone mapping automatically in the kernel,
> > so in that sense the HDR property behaviour is obvious. But which
> > behaviour would fit range property or others better, I'm not sure.
> >
> > Generally there seems to be two approaches to designing KMS properties:
> >
> > - Let userspace describe what data it has and what data should be sent
> >   to a monitor, and let the kernel driver magically come up with a
> >   conversion.
> >
> > - Only userspace understands how the pixel data is encoded, and
> >   programs the transformations (DEGAMMA/CTM/GAMMA etc.) such, that the
> >   result is what a monitor expects based on e.g. infoframes.  
> 
> Why not both?

Because "both" means you have overlapping sets of properties that might
contradict each other. Or then you need a switch between the two models.

> This patchset is thought to control what's happening "on the cable",
> so if the input data is in a different format, the kernel has to
> convert it.

Right, if that is the desired semantics.

That's not how the HDR property works. Kernel does not convert there.
The HDR property only sets infoframes that the monitor interprets.

> Maybe in the future there could be an additional set of "input-"
> properties. aka "input bpc", "input color format", and "input color
> range". With an additional constraint that if "input-" property ==
> "active-" property the kernel is not allowed to do any conversion
> regarding this aspect, giving userspace full control if wanted.

If by "input" you mean "the result from userspace provided content
going through the configured KMS pixel pipeline", then yes. But it's
hard to put it into words accurately.

The FB could contain whatever which userspace then programs DEGAMMA and
CTM to produce what would be the "input" pixels for example.

This is getting closer to the "abstract KMS pipeline" idea which has
been predicted to fall apart in the email thread linked below.

> > Doing the former requires policy in the kernel. If there is a
> > specification that uniquely defines what the conversion is, this is
> > good. But if not or if there are artistic decisions to be made, like
> > with HDR tone mapping, then it doesn't work.
> >
> > OTOH, the former approach allows the driver to use any and all hardware
> > features it has to realize the conversion, perhaps taking advantage of
> > even fixed-function hardware blocks. The latter approach is much harder
> > to map to hardware features.
> >
> > This dilemma has been discussed in length in
> > https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html
> >

Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
  2021-06-23 11:26           ` Pekka Paalanen
@ 2021-06-25  8:48             ` Werner Sembach
  0 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-06-25  8:48 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, amd-gfx, airlied, dri-devel,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig


Am 23.06.21 um 13:26 schrieb Pekka Paalanen:
> On Wed, 23 Jun 2021 12:10:14 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 23.06.21 um 09:48 schrieb Pekka Paalanen:
>>> On Tue, 22 Jun 2021 11:57:53 +0200
>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>  
>>>> Am 22.06.21 um 09:25 schrieb Pekka Paalanen:  
>>>>> On Fri, 18 Jun 2021 11:11:14 +0200
>>>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>>>    
>>>>>> Add "Broadcast RGB" to general drm context so that more drivers besides
>>>>>> i915 and gma500 can implement it without duplicating code.
>>>>>>
>>>>>> Userspace can use this property to tell the graphic driver to use full or
>>>>>> limited color range for a given connector, overwriting the default
>>>>>> behaviour/automatic detection.
>>>>>>
>>>>>> Possible options are:
>>>>>>     - Automatic (default/current behaviour)
>>>>>>     - Full
>>>>>>     - Limited 16:235
>>>>>>
>>>>>> In theory the driver should be able to automatically detect the monitors
>>>>>> capabilities, but because of flawed standard implementations in Monitors,
>>>>>> this might fail. In this case a manual overwrite is required to not have
>>>>>> washed out colors or lose details in very dark or bright scenes.
>>>>>>
>>>>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>>>>>> ---
>>>>>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>>>>>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>>>>>>  drivers/gpu/drm/drm_connector.c     | 43 +++++++++++++++++++++++++++++
>>>>>>  include/drm/drm_connector.h         | 16 +++++++++++
>>>>>>  4 files changed, 67 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>> index 90d62f305257..0c89d32efbd0 100644
>>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>>>>>  			if (old_connector_state->preferred_color_format !=
>>>>>>  			    new_connector_state->preferred_color_format)
>>>>>>  				new_crtc_state->connectors_changed = true;
>>>>>> +
>>>>>> +			if (old_connector_state->preferred_color_range !=
>>>>>> +			    new_connector_state->preferred_color_range)
>>>>>> +				new_crtc_state->connectors_changed = true;
>>>>>>  		}
>>>>>>  
>>>>>>  		if (funcs->atomic_check)
>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>>>>>> index c536f5e22016..c589bb1a8163 100644
>>>>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>>>>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>>>>>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>>>>>>  		state->max_requested_bpc = val;
>>>>>>  	} else if (property == connector->preferred_color_format_property) {
>>>>>>  		state->preferred_color_format = val;
>>>>>> +	} else if (property == connector->preferred_color_range_property) {
>>>>>> +		state->preferred_color_range = val;
>>>>>>  	} else if (connector->funcs->atomic_set_property) {
>>>>>>  		return connector->funcs->atomic_set_property(connector,
>>>>>>  				state, property, val);
>>>>>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>>>>>>  		*val = state->max_requested_bpc;
>>>>>>  	} else if (property == connector->preferred_color_format_property) {
>>>>>>  		*val = state->preferred_color_format;
>>>>>> +	} else if (property == connector->preferred_color_range_property) {
>>>>>> +		*val = state->preferred_color_range;
>>>>>>  	} 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 aea03dd02e33..9bc596638613 100644
>>>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>>>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
>>>>>>  	{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>>>>>  };
>>>>>>  
>>>>>> +static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] = {
>>>>>> +	{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
>>>>>> +	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>>>>>> +	{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },    
>>>>> Hi,
>>>>>
>>>>> the same question here about these numbers as I asked on the "active
>>>>> color range" property.
>>>>>    
>>>>>> +};
>>>>>> +
>>>>>>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
>>>>>>  	{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>>>>>>  	{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>>>>>> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>>>>>   *	drm_connector_attach_active_color_format_property() to install this
>>>>>>   *	property.
>>>>>>   *
>>>>>> + * Broadcast RGB:
>>>>>> + *	This property is used by userspace to change the used color range. When
>>>>>> + *	used the driver will use the selected range if valid for the current
>>>>>> + *	color format. Drivers to use the function
>>>>>> + *	drm_connector_attach_preferred_color_format_property() to create and
>>>>>> + *	attach the property to the connector during initialization.    
>>>>> An important detail to document here is: does userspace need to
>>>>> take care that pixel data at the connector will already match the set
>>>>> range, or will the driver program the hardware to produce the set range?    
>>>> Since until now, the userspace didn't even know for sure if RGB or YCbCr and therefore which full/limited format was
>>>> used I guess it's all kernel space conversion.  
>>>>> If the former, then I'm afraid the preference/active property pair
>>>>> design does not work. Userspace needs to make sure the content is in
>>>>> the right range, so the driver cannot second-guess that afterwards.
>>>>>
>>>>> If the latter, then what does the driver assume about color range just
>>>>> before the automatic conversion to the final color range, and does the
>>>>> range conversion happen as the final step in the color pipeline?
>>>>>
>>>>> If I remember the discussion about Intel right, then the driver does
>>>>> the latter and assume that userspace programs KMS to always produce
>>>>> full range pixels. There is no provision for userspace to produce
>>>>> limited range pixels, IIRC.    
>>>> I think I remember this too from an answer to one of the revisions of this patchset.  
>>> As long as you keep the old KMS property as is, just moving code so it
>>> is used by more drivers, this is fine and one can't do otherwise anyway.
>>>
>>> (The rest of this email is merely pondering the future, so not about
>>> this patch in particular.)
>>>
>>>
>>> But if we had a new, more general property for the range reported to
>>> monitors via infoframes, then it would be worth to re-visit the design.
>>> The HDR properties only set the infoframe and expect userspace to make
>>> sure that the pixels actually correspond to what the infoframes tell
>>> the monitor. One can't do HDR tone mapping automatically in the kernel,
>>> so in that sense the HDR property behaviour is obvious. But which
>>> behaviour would fit range property or others better, I'm not sure.
>>>
>>> Generally there seems to be two approaches to designing KMS properties:
>>>
>>> - Let userspace describe what data it has and what data should be sent
>>>   to a monitor, and let the kernel driver magically come up with a
>>>   conversion.
>>>
>>> - Only userspace understands how the pixel data is encoded, and
>>>   programs the transformations (DEGAMMA/CTM/GAMMA etc.) such, that the
>>>   result is what a monitor expects based on e.g. infoframes.  
>> Why not both?
> Because "both" means you have overlapping sets of properties that might
> contradict each other. Or then you need a switch between the two models.
>
>> This patchset is thought to control what's happening "on the cable",
>> so if the input data is in a different format, the kernel has to
>> convert it.
> Right, if that is the desired semantics.
>
> That's not how the HDR property works. Kernel does not convert there.
> The HDR property only sets infoframes that the monitor interprets.
>
>> Maybe in the future there could be an additional set of "input-"
>> properties. aka "input bpc", "input color format", and "input color
>> range". With an additional constraint that if "input-" property ==
>> "active-" property the kernel is not allowed to do any conversion
>> regarding this aspect, giving userspace full control if wanted.
> If by "input" you mean "the result from userspace provided content
> going through the configured KMS pixel pipeline", then yes. But it's
> hard to put it into words accurately.
>
> The FB could contain whatever which userspace then programs DEGAMMA and
> CTM to produce what would be the "input" pixels for example.
>
> This is getting closer to the "abstract KMS pipeline" idea which has
> been predicted to fall apart in the email thread linked below.
Ok, I'm not deep enough in the topic. For this patchset anyways I try to stick to the preexisting behavior of "max bpc"
and "Broadcast RGB", which I believe is the "on the cable/kernel does the conversion" discussed. I will double check on
that before I submit the next revision.
>
>>> Doing the former requires policy in the kernel. If there is a
>>> specification that uniquely defines what the conversion is, this is
>>> good. But if not or if there are artistic decisions to be made, like
>>> with HDR tone mapping, then it doesn't work.
>>>
>>> OTOH, the former approach allows the driver to use any and all hardware
>>> features it has to realize the conversion, perhaps taking advantage of
>>> even fixed-function hardware blocks. The latter approach is much harder
>>> to map to hardware features.
>>>
>>> This dilemma has been discussed in length in
>>> https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html
>>>
> Thanks,
> pq

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-06-18  9:11 ` [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property Werner Sembach
  2021-06-22  6:46   ` Pekka Paalanen
@ 2021-06-28 17:03   ` Werner Sembach
  2021-06-29 11:02     ` Werner Sembach
  1 sibling, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-28 17:03 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

Am 18.06.21 um 11:11 schrieb Werner Sembach:
> Add a new general drm property "active bpc" which can be used by graphic
> drivers to report the applied bit depth per pixel back to userspace.
>
> While "max bpc" can be used to change the color depth, there was no way to
> check which one actually got used. While in theory the driver chooses the
> best/highest color depth within the max bpc setting a user might not be
> fully aware what his hardware is or isn't capable off. This is meant as a
> quick way to double check the setup.
>
> In the future, automatic color calibration for screens might also depend on
> this information being available.
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
>  include/drm/drm_connector.h     |  8 ++++++
>  2 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index da39e7ff6965..943f6b61053b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	drm_connector_attach_max_bpc_property() to create and attach the
>   *	property to the connector during initialization.
>   *
> + * active bpc:
> + *	This read-only range property tells userspace the pixel color bit depth
> + *	actually used by the hardware display engine on "the cable" on a
> + *	connector. The chosen value depends on hardware capabilities, both
> + *	display engine and connected monitor, and the "max bpc" property.
> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
> + *	this property.
> + *

Regarding "on the cable" and dithering: As far as I can tell, what the dithering option does, is setting a hardware
register here:

- https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534

- https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571

So dithering seems to be calculated by fixed purpose hardware/firmware outside of the driver?

The Intel driver does not seem to set a target bpc/bpp for this hardware so I guess it defaults to 6 or 8 bpc?

Similar things happen on amd. Here the output dither depth seems to be written to a fixed value however:

- https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828

- https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769

Does anyone know about a resource where I can read up on the used registers and what this hardware actually does?

My proposal for now: "max bpc" affects what happens before dither, so I would keep "active bpc" the same and add another
drm property "dither active: true/false". No additional property to control dither, as amdgpu does have one already
(which isn't always active?) and Intel driver does only seem prepared for dithering at 6bpc (albeit I don't know why to
dither at 6bpc and what depth to dither to?).

>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>  
> +/**
> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
> + * @connector: connector to attach active bpc property on.
> + * @min: The minimum bit depth supported by the connector.
> + * @max: The maximum bit depth supported by the connector.
> + *
> + * This is used to check the applied bit depth on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max)
> +{
> +	struct drm_device *dev = connector->dev;
> +	struct drm_property *prop;
> +
> +	if (!connector->active_bpc_property) {
> +		prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "active bpc",
> +						 min, max);
> +		if (!prop)
> +			return -ENOMEM;
> +
> +		connector->active_bpc_property = prop;
> +		drm_object_attach_property(&connector->base, prop, 0);
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
> +
> +/**
> + * drm_connector_set_active_bpc_property - sets the active bits per color property for a connector
> + * @connector: drm connector
> + * @active_bpc: bits per color for the connector currently active on "the cable"
> + *
> + * Should be used by atomic drivers to update the active bits per color over a connector.
> + */
> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc)
> +{
> +	drm_object_property_set_value(&connector->base, connector->active_bpc_property, active_bpc);
> +}
> +EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
> +
>  /**
>   * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
>   * @connector: connector to attach the property on.
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 714d1a01c065..eee86de62a5f 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1380,6 +1380,12 @@ struct drm_connector {
>  	 */
>  	struct drm_property *max_bpc_property;
>  
> +	/**
> +	 * @active_bpc_property: Default connector property for the active bpc
> +	 * to be driven out of the connector.
> +	 */
> +	struct drm_property *active_bpc_property;
> +
>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk(
>  	int width, int height);
>  int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>  					  int min, int max);
> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
>  
>  /**
>   * struct drm_tile_group - Tile group metadata

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-22  7:15   ` Pekka Paalanen
@ 2021-06-29  8:12     ` Simon Ser
  2021-06-29 11:17       ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Simon Ser @ 2021-06-29  8:12 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: Werner Sembach, amd-gfx, tzimmermann, intel-gfx, sunpeng.li,
	dri-devel, linux-kernel, airlied, rodrigo.vivi,
	alexander.deucher, christian.koenig

On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:

> yes, I think this makes sense, even if it is a property that one can't
> tell for sure what it does before hand.
>
> Using a pair of properties, preference and active, to ask for something
> and then check what actually worked is good for reducing the
> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> test different KMS configurations. Userspace has a better chance of
> finding a configuration that is possible.
>
> OTOH, this has the problem than in UI one cannot tell the user in
> advance which options are truly possible. Given that KMS properties are
> rarely completely independent, and in this case known to depend on
> several other KMS properties, I think it is good enough to know after
> the fact.
>
> If a driver does not use what userspace prefers, there is no way to
> understand why, or what else to change to make it happen. That problem
> exists anyway, because TEST_ONLY commits do not give useful feedback
> but only a yes/no.

By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
property at a time), user-space can discover which property makes the atomic
commit fail.

I'm not a fan of this "preference" property approach. The only way to find out
whether it's possible to change the color format is to perform a user-visible
change (with a regular atomic commit) and check whether it worked
after-the-fact. This is unlike all other existing KMS properties.

I'd much rather see a more general approach to fix this combinatorial explosion
than to add special-cases like this.

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-06-28 17:03   ` Werner Sembach
@ 2021-06-29 11:02     ` Werner Sembach
  2021-06-30  8:21       ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-29 11:02 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

Am 28.06.21 um 19:03 schrieb Werner Sembach:
> Am 18.06.21 um 11:11 schrieb Werner Sembach:
>> Add a new general drm property "active bpc" which can be used by graphic
>> drivers to report the applied bit depth per pixel back to userspace.
>>
>> While "max bpc" can be used to change the color depth, there was no way to
>> check which one actually got used. While in theory the driver chooses the
>> best/highest color depth within the max bpc setting a user might not be
>> fully aware what his hardware is or isn't capable off. This is meant as a
>> quick way to double check the setup.
>>
>> In the future, automatic color calibration for screens might also depend on
>> this information being available.
>>
>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>> ---
>>  drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
>>  include/drm/drm_connector.h     |  8 ++++++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> index da39e7ff6965..943f6b61053b 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>   *	drm_connector_attach_max_bpc_property() to create and attach the
>>   *	property to the connector during initialization.
>>   *
>> + * active bpc:
>> + *	This read-only range property tells userspace the pixel color bit depth
>> + *	actually used by the hardware display engine on "the cable" on a
>> + *	connector. The chosen value depends on hardware capabilities, both
>> + *	display engine and connected monitor, and the "max bpc" property.
>> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
>> + *	this property.
>> + *
> Regarding "on the cable" and dithering: As far as I can tell, what the dithering option does, is setting a hardware
> register here:
>
> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>
> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>
> So dithering seems to be calculated by fixed purpose hardware/firmware outside of the driver?
>
> The Intel driver does not seem to set a target bpc/bpp for this hardware so I guess it defaults to 6 or 8 bpc?

Never mind it does. This switch-case does affect the dithering output:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537

As found in this documentation p.548:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf

So max bpc and active bpc are affecting/affected by the bpc after dithering.

>
> Similar things happen on amd. Here the output dither depth seems to be written to a fixed value however:
>
> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828
>
> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769
>
> Does anyone know about a resource where I can read up on the used registers and what this hardware actually does?
Searching now for a similar register reference for AMD GPUs.
>
> My proposal for now: "max bpc" affects what happens before dither, so I would keep "active bpc" the same and add another
> drm property "dither active: true/false". No additional property to control dither, as amdgpu does have one already
> (which isn't always active?) and Intel driver does only seem prepared for dithering at 6bpc (albeit I don't know why to
> dither at 6bpc and what depth to dither to?).
>
>>   * Connectors also have one standardized atomic property:
>>   *
>>   * CRTC_ID:
>> @@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>>  }
>>  EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>>  
>> +/**
>> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
>> + * @connector: connector to attach active bpc property on.
>> + * @min: The minimum bit depth supported by the connector.
>> + * @max: The maximum bit depth supported by the connector.
>> + *
>> + * This is used to check the applied bit depth on a connector.
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max)
>> +{
>> +	struct drm_device *dev = connector->dev;
>> +	struct drm_property *prop;
>> +
>> +	if (!connector->active_bpc_property) {
>> +		prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "active bpc",
>> +						 min, max);
>> +		if (!prop)
>> +			return -ENOMEM;
>> +
>> +		connector->active_bpc_property = prop;
>> +		drm_object_attach_property(&connector->base, prop, 0);
>> +	}
>> +
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
>> +
>> +/**
>> + * drm_connector_set_active_bpc_property - sets the active bits per color property for a connector
>> + * @connector: drm connector
>> + * @active_bpc: bits per color for the connector currently active on "the cable"
>> + *
>> + * Should be used by atomic drivers to update the active bits per color over a connector.
>> + */
>> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc)
>> +{
>> +	drm_object_property_set_value(&connector->base, connector->active_bpc_property, active_bpc);
>> +}
>> +EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
>> +
>>  /**
>>   * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
>>   * @connector: connector to attach the property on.
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 714d1a01c065..eee86de62a5f 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -1380,6 +1380,12 @@ struct drm_connector {
>>  	 */
>>  	struct drm_property *max_bpc_property;
>>  
>> +	/**
>> +	 * @active_bpc_property: Default connector property for the active bpc
>> +	 * to be driven out of the connector.
>> +	 */
>> +	struct drm_property *active_bpc_property;
>> +
>>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
>> @@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk(
>>  	int width, int height);
>>  int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>>  					  int min, int max);
>> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
>> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
>>  
>>  /**
>>   * struct drm_tile_group - Tile group metadata
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-29  8:12     ` Simon Ser
@ 2021-06-29 11:17       ` Pekka Paalanen
  2021-06-29 11:39         ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-29 11:17 UTC (permalink / raw)
  To: Simon Ser
  Cc: Werner Sembach, amd-gfx, tzimmermann, intel-gfx, sunpeng.li,
	dri-devel, linux-kernel, airlied, rodrigo.vivi,
	alexander.deucher, christian.koenig

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

On Tue, 29 Jun 2021 08:12:54 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> 
> > yes, I think this makes sense, even if it is a property that one can't
> > tell for sure what it does before hand.
> >
> > Using a pair of properties, preference and active, to ask for something
> > and then check what actually worked is good for reducing the
> > combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> > test different KMS configurations. Userspace has a better chance of
> > finding a configuration that is possible.
> >
> > OTOH, this has the problem than in UI one cannot tell the user in
> > advance which options are truly possible. Given that KMS properties are
> > rarely completely independent, and in this case known to depend on
> > several other KMS properties, I think it is good enough to know after
> > the fact.
> >
> > If a driver does not use what userspace prefers, there is no way to
> > understand why, or what else to change to make it happen. That problem
> > exists anyway, because TEST_ONLY commits do not give useful feedback
> > but only a yes/no.  
> 
> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
> property at a time), user-space can discover which property makes the atomic
> commit fail.

That works if the properties are independent of each other. Color
range, color format, bpc and more may all be interconnected,
allowing only certain combinations to work.

If all these properties have "auto" setting too, then it would be
possible to probe each property individually, but that still does not
tell which combinations are valid.

If you probe towards a certain configuration by setting the properties
one by one, then depending on the order you pick the properties, you
may come to a different conclusion on which property breaks the
configuration.

> I'm not a fan of this "preference" property approach. The only way to find out
> whether it's possible to change the color format is to perform a user-visible
> change (with a regular atomic commit) and check whether it worked
> after-the-fact. This is unlike all other existing KMS properties.

I agree. FWIW, "max bpc" exists already.

> I'd much rather see a more general approach to fix this combinatorial explosion
> than to add special-cases like this.

What would you suggest?

Maybe all properties should have an "auto" value in addition to the
explicit no-negotiation values where at all possible?

That might help probing each property individually with TEST_ONLY
commits, but it says nothing about combinations.

A feedback list perhaps? TEST_ONLY commit somehow returning a list of
property/value tuples indicating what value the "auto" valued
properties actually get?

What should a kernel driver optimize for when determining "auto" values?


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-29 11:17       ` Pekka Paalanen
@ 2021-06-29 11:39         ` Werner Sembach
  2021-06-30  8:41           ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-29 11:39 UTC (permalink / raw)
  To: Pekka Paalanen, Simon Ser
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig


Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 08:12:54 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
>>> Using a pair of properties, preference and active, to ask for something
>>> and then check what actually worked is good for reducing the
>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>> test different KMS configurations. Userspace has a better chance of
>>> finding a configuration that is possible.
>>>
>>> OTOH, this has the problem than in UI one cannot tell the user in
>>> advance which options are truly possible. Given that KMS properties are
>>> rarely completely independent, and in this case known to depend on
>>> several other KMS properties, I think it is good enough to know after
>>> the fact.
>>>
>>> If a driver does not use what userspace prefers, there is no way to
>>> understand why, or what else to change to make it happen. That problem
>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>> but only a yes/no.  
>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>> property at a time), user-space can discover which property makes the atomic
>> commit fail.
> That works if the properties are independent of each other. Color
> range, color format, bpc and more may all be interconnected,
> allowing only certain combinations to work.
>
> If all these properties have "auto" setting too, then it would be
> possible to probe each property individually, but that still does not
> tell which combinations are valid.
>
> If you probe towards a certain configuration by setting the properties
> one by one, then depending on the order you pick the properties, you
> may come to a different conclusion on which property breaks the
> configuration.

My mind crossed another point that must be considered: When plugin in a Monitor a list of possible Resolutions+Framerate
combinations is created for xrandr and other userspace (I guess by atomic checks? but I don't know). During this drm
properties are already considered, which is no problem atm because as far as i can tell there is currently no drm
property that would make a certain Resolutions+Framerate combination unreachable that would be possible with everything
on default.

However for example forcing YCbCr420 encoding would limit the available resolutions (my screen for example only supports
YCbCr420 on 4k@60 and @50Hz and on no other resolution or frequency (native is 2560x1440@144Hz).

So would a "force color format" that does not get resetted on repluging/reenabling a monitor break the output, for
example, of an not updated xrandr, unaware of this new property?

>> I'm not a fan of this "preference" property approach. The only way to find out
>> whether it's possible to change the color format is to perform a user-visible
>> change (with a regular atomic commit) and check whether it worked
>> after-the-fact. This is unlike all other existing KMS properties.
> I agree. FWIW, "max bpc" exists already.
>
>> I'd much rather see a more general approach to fix this combinatorial explosion
>> than to add special-cases like this.
> What would you suggest?
>
> Maybe all properties should have an "auto" value in addition to the
> explicit no-negotiation values where at all possible?
>
> That might help probing each property individually with TEST_ONLY
> commits, but it says nothing about combinations.
>
> A feedback list perhaps? TEST_ONLY commit somehow returning a list of
> property/value tuples indicating what value the "auto" valued
> properties actually get?
>
> What should a kernel driver optimize for when determining "auto" values?
>
>
> Thanks,
> pq
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-06-29 11:02     ` Werner Sembach
@ 2021-06-30  8:21       ` Pekka Paalanen
  2021-06-30  9:42         ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-30  8:21 UTC (permalink / raw)
  To: Werner Sembach
  Cc: harry.wentland, sunpeng.li, alexander.deucher, christian.koenig,
	airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
	jani.nikula, joonas.lahtinen, rodrigo.vivi, amd-gfx, dri-devel,
	linux-kernel, intel-gfx

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

On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 28.06.21 um 19:03 schrieb Werner Sembach:
> > Am 18.06.21 um 11:11 schrieb Werner Sembach:  
> >> Add a new general drm property "active bpc" which can be used by graphic
> >> drivers to report the applied bit depth per pixel back to userspace.
> >>
> >> While "max bpc" can be used to change the color depth, there was no way to
> >> check which one actually got used. While in theory the driver chooses the
> >> best/highest color depth within the max bpc setting a user might not be
> >> fully aware what his hardware is or isn't capable off. This is meant as a
> >> quick way to double check the setup.
> >>
> >> In the future, automatic color calibration for screens might also depend on
> >> this information being available.
> >>
> >> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> >> ---
> >>  drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
> >>  include/drm/drm_connector.h     |  8 ++++++
> >>  2 files changed, 59 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> index da39e7ff6965..943f6b61053b 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >>   *	drm_connector_attach_max_bpc_property() to create and attach the
> >>   *	property to the connector during initialization.
> >>   *
> >> + * active bpc:
> >> + *	This read-only range property tells userspace the pixel color bit depth
> >> + *	actually used by the hardware display engine on "the cable" on a
> >> + *	connector. The chosen value depends on hardware capabilities, both
> >> + *	display engine and connected monitor, and the "max bpc" property.
> >> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
> >> + *	this property.
> >> + *  
> > Regarding "on the cable" and dithering: As far as I can tell, what the dithering option does, is setting a hardware
> > register here:
> >
> > - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
> >
> > - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
> >
> > So dithering seems to be calculated by fixed purpose hardware/firmware outside of the driver?
> >
> > The Intel driver does not seem to set a target bpc/bpp for this hardware so I guess it defaults to 6 or 8 bpc?  
> 
> Never mind it does. This switch-case does affect the dithering output:
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537

Hi,

I obviously do not know the intel driver or hardware at all, but
to me that just looks like translating from bits per pixel to bits per
channel in RGB mapping?

> As found in this documentation p.548:
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
> 
> So max bpc and active bpc are affecting/affected by the bpc after dithering.

By definition, if the cable carries N bpc, then dithering does not
change that. The cable still carries N bpc, but due to spatial or
temporal dithering, the *observed* color resolution may or may not be
higher than the cable bpc.

Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
LSB on the cable are always zero, right?

Maybe one would want to do that if the monitor has a 6 bit panel and it
simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.

So, what does "max bpc" mean right now?

It seems like dither on/off is insufficient information, one would also
need to control the dithering target bpc. I suppose the driver has a
policy on how it chooses the target bpc, but what is that policy? Is
the dither target bpc the cable bpc or the sink bpc?

Needless to say, I'm quite confused.


Thanks,
pq

> >
> > Similar things happen on amd. Here the output dither depth seems to be written to a fixed value however:
> >
> > - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828
> >
> > - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769
> >
> > Does anyone know about a resource where I can read up on the used registers and what this hardware actually does?  
> Searching now for a similar register reference for AMD GPUs.
> >
> > My proposal for now: "max bpc" affects what happens before dither, so I would keep "active bpc" the same and add another
> > drm property "dither active: true/false". No additional property to control dither, as amdgpu does have one already
> > (which isn't always active?) and Intel driver does only seem prepared for dithering at 6bpc (albeit I don't know why to
> > dither at 6bpc and what depth to dither to?).
> >  
> >>   * Connectors also have one standardized atomic property:
> >>   *
> >>   * CRTC_ID:
> >> @@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
> >>  }
> >>  EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
> >>  
> >> +/**
> >> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
> >> + * @connector: connector to attach active bpc property on.
> >> + * @min: The minimum bit depth supported by the connector.
> >> + * @max: The maximum bit depth supported by the connector.
> >> + *
> >> + * This is used to check the applied bit depth on a connector.
> >> + *
> >> + * Returns:
> >> + * Zero on success, negative errno on failure.
> >> + */
> >> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max)
> >> +{
> >> +	struct drm_device *dev = connector->dev;
> >> +	struct drm_property *prop;
> >> +
> >> +	if (!connector->active_bpc_property) {
> >> +		prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "active bpc",
> >> +						 min, max);
> >> +		if (!prop)
> >> +			return -ENOMEM;
> >> +
> >> +		connector->active_bpc_property = prop;
> >> +		drm_object_attach_property(&connector->base, prop, 0);
> >> +	}
> >> +
> >> +	return 0;
> >> +}
> >> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
> >> +
> >> +/**
> >> + * drm_connector_set_active_bpc_property - sets the active bits per color property for a connector
> >> + * @connector: drm connector
> >> + * @active_bpc: bits per color for the connector currently active on "the cable"
> >> + *
> >> + * Should be used by atomic drivers to update the active bits per color over a connector.
> >> + */
> >> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc)
> >> +{
> >> +	drm_object_property_set_value(&connector->base, connector->active_bpc_property, active_bpc);
> >> +}
> >> +EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
> >> +
> >>  /**
> >>   * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
> >>   * @connector: connector to attach the property on.
> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >> index 714d1a01c065..eee86de62a5f 100644
> >> --- a/include/drm/drm_connector.h
> >> +++ b/include/drm/drm_connector.h
> >> @@ -1380,6 +1380,12 @@ struct drm_connector {
> >>  	 */
> >>  	struct drm_property *max_bpc_property;
> >>  
> >> +	/**
> >> +	 * @active_bpc_property: Default connector property for the active bpc
> >> +	 * to be driven out of the connector.
> >> +	 */
> >> +	struct drm_property *active_bpc_property;
> >> +
> >>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> >>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
> >>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> >> @@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk(
> >>  	int width, int height);
> >>  int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
> >>  					  int min, int max);
> >> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
> >> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
> >>  
> >>  /**
> >>   * struct drm_tile_group - Tile group metadata  
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx  


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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-29 11:39         ` Werner Sembach
@ 2021-06-30  8:41           ` Pekka Paalanen
  2021-06-30  9:20             ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-06-30  8:41 UTC (permalink / raw)
  To: Werner Sembach
  Cc: Simon Ser, sunpeng.li, intel-gfx, linux-kernel, dri-devel,
	airlied, amd-gfx, tzimmermann, rodrigo.vivi, alexander.deucher,
	christian.koenig

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

On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 08:12:54 +0000
> > Simon Ser <contact@emersion.fr> wrote:
> >  
> >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >>  
> >>> yes, I think this makes sense, even if it is a property that one can't
> >>> tell for sure what it does before hand.
> >>>
> >>> Using a pair of properties, preference and active, to ask for something
> >>> and then check what actually worked is good for reducing the
> >>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> >>> test different KMS configurations. Userspace has a better chance of
> >>> finding a configuration that is possible.
> >>>
> >>> OTOH, this has the problem than in UI one cannot tell the user in
> >>> advance which options are truly possible. Given that KMS properties are
> >>> rarely completely independent, and in this case known to depend on
> >>> several other KMS properties, I think it is good enough to know after
> >>> the fact.
> >>>
> >>> If a driver does not use what userspace prefers, there is no way to
> >>> understand why, or what else to change to make it happen. That problem
> >>> exists anyway, because TEST_ONLY commits do not give useful feedback
> >>> but only a yes/no.    
> >> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
> >> property at a time), user-space can discover which property makes the atomic
> >> commit fail.  
> > That works if the properties are independent of each other. Color
> > range, color format, bpc and more may all be interconnected,
> > allowing only certain combinations to work.
> >
> > If all these properties have "auto" setting too, then it would be
> > possible to probe each property individually, but that still does not
> > tell which combinations are valid.
> >
> > If you probe towards a certain configuration by setting the properties
> > one by one, then depending on the order you pick the properties, you
> > may come to a different conclusion on which property breaks the
> > configuration.  
> 
> My mind crossed another point that must be considered: When plugin in
> a Monitor a list of possible Resolutions+Framerate combinations is
> created for xrandr and other userspace (I guess by atomic checks? but
> I don't know).

Hi,

I would not think so, but I hope to be corrected if I'm wrong.

My belief is that the driver collects a list of modes from EDID, some
standard modes, and maybe some other hardcoded modes, and then
validates each entry against all the known limitations like vertical
and horizontal frequency limits, discarding modes that do not fit.

Not all limitations are known during that phase, which is why KMS
property "link-status" exists. When userspace actually programs a mode
(not a TEST_ONLY commit), the link training may fail. The kernel prunes
the mode from the list and sets the link status property to signal
failure, and sends a hotplug uevent. Userspace needs to re-check the
mode list and try again.

That is a generic escape hatch for when TEST_ONLY commit succeeds, but
in reality the hardware cannot do it, you just cannot know until you
actually try for real. It causes end user visible flicker if it happens
on an already running connector, but since it usually happens when
turning a connector on to begin with, there is no flicker to be seen,
just a small delay in finding a mode that works.

> During this drm
> properties are already considered, which is no problem atm because as
> far as i can tell there is currently no drm property that would make
> a certain Resolutions+Framerate combination unreachable that would be
> possible with everything on default.

I would not expect KMS properties to be considered at all. It would
reject modes that are actually possible if the some KMS properties were
changed. So at least going forward, current KMS property values cannot
factor in.

> However for example forcing YCbCr420 encoding would limit the
> available resolutions (my screen for example only supports YCbCr420
> on 4k@60 and @50Hz and on no other resolution or frequency (native is
> 2560x1440@144Hz).
> 
> So would a "force color format" that does not get resetted on
> repluging/reenabling a monitor break the output, for example, of an
> not updated xrandr, unaware of this new property?

Yes, not because the mode list would be missing the mode, but because
actually setting the mode would fail.

RandR in particular is problematic, because it does not actually
understand any KMS properties, it is merely a relay. So anything
that *uses* RandR protocol or xrandr command would also need to be
patched to understand the new properties.

The kernel automatically resetting *some* properties in *some*
occasions seems really fragile and complicated to me, which is why I'm
a lot more keen to see a "reset everything to sensible defaults"
generic mechanism added to KMS.


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-30  8:41           ` Pekka Paalanen
@ 2021-06-30  9:20             ` Werner Sembach
  2021-07-01  8:07               ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-30  9:20 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, Simon Ser, intel-gfx, linux-kernel, dri-devel,
	airlied, amd-gfx, tzimmermann, rodrigo.vivi, alexander.deucher,
	christian.koenig

Am 30.06.21 um 10:41 schrieb Pekka Paalanen:

> On Tue, 29 Jun 2021 13:39:18 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
>>> On Tue, 29 Jun 2021 08:12:54 +0000
>>> Simon Ser <contact@emersion.fr> wrote:
>>>   
>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>>>   
>>>>> yes, I think this makes sense, even if it is a property that one can't
>>>>> tell for sure what it does before hand.
>>>>>
>>>>> Using a pair of properties, preference and active, to ask for something
>>>>> and then check what actually worked is good for reducing the
>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>>>> test different KMS configurations. Userspace has a better chance of
>>>>> finding a configuration that is possible.
>>>>>
>>>>> OTOH, this has the problem than in UI one cannot tell the user in
>>>>> advance which options are truly possible. Given that KMS properties are
>>>>> rarely completely independent, and in this case known to depend on
>>>>> several other KMS properties, I think it is good enough to know after
>>>>> the fact.
>>>>>
>>>>> If a driver does not use what userspace prefers, there is no way to
>>>>> understand why, or what else to change to make it happen. That problem
>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>>>> but only a yes/no.
>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>>>> property at a time), user-space can discover which property makes the atomic
>>>> commit fail.
>>> That works if the properties are independent of each other. Color
>>> range, color format, bpc and more may all be interconnected,
>>> allowing only certain combinations to work.
>>>
>>> If all these properties have "auto" setting too, then it would be
>>> possible to probe each property individually, but that still does not
>>> tell which combinations are valid.
>>>
>>> If you probe towards a certain configuration by setting the properties
>>> one by one, then depending on the order you pick the properties, you
>>> may come to a different conclusion on which property breaks the
>>> configuration.
>> My mind crossed another point that must be considered: When plugin in
>> a Monitor a list of possible Resolutions+Framerate combinations is
>> created for xrandr and other userspace (I guess by atomic checks? but
>> I don't know).
> Hi,
>
> I would not think so, but I hope to be corrected if I'm wrong.
>
> My belief is that the driver collects a list of modes from EDID, some
> standard modes, and maybe some other hardcoded modes, and then
> validates each entry against all the known limitations like vertical
> and horizontal frequency limits, discarding modes that do not fit.
>
> Not all limitations are known during that phase, which is why KMS
> property "link-status" exists. When userspace actually programs a mode
> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
> the mode from the list and sets the link status property to signal
> failure, and sends a hotplug uevent. Userspace needs to re-check the
> mode list and try again.
>
> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
> in reality the hardware cannot do it, you just cannot know until you
> actually try for real. It causes end user visible flicker if it happens
> on an already running connector, but since it usually happens when
> turning a connector on to begin with, there is no flicker to be seen,
> just a small delay in finding a mode that works.
>
>> During this drm
>> properties are already considered, which is no problem atm because as
>> far as i can tell there is currently no drm property that would make
>> a certain Resolutions+Framerate combination unreachable that would be
>> possible with everything on default.
> I would not expect KMS properties to be considered at all. It would
> reject modes that are actually possible if the some KMS properties were
> changed. So at least going forward, current KMS property values cannot
> factor in.

At least the debugfs variable "force_yuv420_output" did change the 
available modes here: 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165 
before my patch 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf

Forcing a color format via a DRM property in this function would 
reintroduce the problem.

And I think i915 driver works similar in this regard.

>
>> However for example forcing YCbCr420 encoding would limit the
>> available resolutions (my screen for example only supports YCbCr420
>> on 4k@60 and @50Hz and on no other resolution or frequency (native is
>> 2560x1440@144Hz).
>>
>> So would a "force color format" that does not get resetted on
>> repluging/reenabling a monitor break the output, for example, of an
>> not updated xrandr, unaware of this new property?
> Yes, not because the mode list would be missing the mode, but because
> actually setting the mode would fail.
Well, like described above, I think the mode would actually be missing, 
which is also an unexpected behavior from a user perspective.
>
> RandR in particular is problematic, because it does not actually
> understand any KMS properties, it is merely a relay. So anything
> that *uses* RandR protocol or xrandr command would also need to be
> patched to understand the new properties.
>
> The kernel automatically resetting *some* properties in *some*
> occasions seems really fragile and complicated to me, which is why I'm
> a lot more keen to see a "reset everything to sensible defaults"
> generic mechanism added to KMS.
Would you see that mechanism not (yet) existing a blocker for this 
patchset/the "force-" properties?
>
>
> Thanks,
> pq
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-06-30  8:21       ` Pekka Paalanen
@ 2021-06-30  9:42         ` Werner Sembach
  2021-07-01  7:42           ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-06-30  9:42 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: amd-gfx, tzimmermann, intel-gfx, sunpeng.li, dri-devel,
	linux-kernel, airlied, rodrigo.vivi, alexander.deucher,
	christian.koenig


Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 13:02:05 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 28.06.21 um 19:03 schrieb Werner Sembach:
>>> Am 18.06.21 um 11:11 schrieb Werner Sembach:
>>>> Add a new general drm property "active bpc" which can be used by graphic
>>>> drivers to report the applied bit depth per pixel back to userspace.
>>>>
>>>> While "max bpc" can be used to change the color depth, there was no way to
>>>> check which one actually got used. While in theory the driver chooses the
>>>> best/highest color depth within the max bpc setting a user might not be
>>>> fully aware what his hardware is or isn't capable off. This is meant as a
>>>> quick way to double check the setup.
>>>>
>>>> In the future, automatic color calibration for screens might also depend on
>>>> this information being available.
>>>>
>>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>>>> ---
>>>>   drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
>>>>   include/drm/drm_connector.h     |  8 ++++++
>>>>   2 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>>> index da39e7ff6965..943f6b61053b 100644
>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>>>    *	drm_connector_attach_max_bpc_property() to create and attach the
>>>>    *	property to the connector during initialization.
>>>>    *
>>>> + * active bpc:
>>>> + *	This read-only range property tells userspace the pixel color bit depth
>>>> + *	actually used by the hardware display engine on "the cable" on a
>>>> + *	connector. The chosen value depends on hardware capabilities, both
>>>> + *	display engine and connected monitor, and the "max bpc" property.
>>>> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
>>>> + *	this property.
>>>> + *
>>> Regarding "on the cable" and dithering: As far as I can tell, what the dithering option does, is setting a hardware
>>> register here:
>>>
>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>>>
>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>>>
>>> So dithering seems to be calculated by fixed purpose hardware/firmware outside of the driver?
>>>
>>> The Intel driver does not seem to set a target bpc/bpp for this hardware so I guess it defaults to 6 or 8 bpc?
>> Never mind it does. This switch-case does affect the dithering output:
>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537
> Hi,
>
> I obviously do not know the intel driver or hardware at all, but
> to me that just looks like translating from bits per pixel to bits per
> channel in RGB mapping?
No, if i understand the documentation correctly: Writing bit depth here 
with dithering enabled sets the dithering target bpc.
>
>> As found in this documentation p.548:
>> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
>>
>> So max bpc and active bpc are affecting/affected by the bpc after dithering.
> By definition, if the cable carries N bpc, then dithering does not
> change that. The cable still carries N bpc, but due to spatial or
> temporal dithering, the *observed* color resolution may or may not be
> higher than the cable bpc.
Yes, and max bpc and active bpc tell the cable bpc ist not the 
*observed* bpc.
>
> Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
> LSB on the cable are always zero, right?
I would assume that in this case only 6 bpc are actually send? Isn't the 
whole thing of dithering that you can't send, for example, 8 bpc?
>
> Maybe one would want to do that if the monitor has a 6 bit panel and it
> simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.

Is there dithering actually doing this? aka is my assumption above wrong?

AMD code that confused me before, is hinting that you might be right: 
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826

there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP

>
> So, what does "max bpc" mean right now?
>
> It seems like dither on/off is insufficient information, one would also
> need to control the dithering target bpc. I suppose the driver has a
> policy on how it chooses the target bpc, but what is that policy? Is
> the dither target bpc the cable bpc or the sink bpc?
>
> Needless to say, I'm quite confused.

... We need someone who knows what dithering on intel and amd gpu 
actually means.

But I don't want this to become a blocker for this patchset, because if 
there is no dithering, which seems to be the norm, the active bpc 
property is already really usefull as it is. So add a note to the docs 
that the value might be invalid when dithering is active for now?

>
>
> Thanks,
> pq
>
>>> Similar things happen on amd. Here the output dither depth seems to be written to a fixed value however:
>>>
>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828
>>>
>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769
>>>
>>> Does anyone know about a resource where I can read up on the used registers and what this hardware actually does?
>> Searching now for a similar register reference for AMD GPUs.
>>> My proposal for now: "max bpc" affects what happens before dither, so I would keep "active bpc" the same and add another
>>> drm property "dither active: true/false". No additional property to control dither, as amdgpu does have one already
>>> (which isn't always active?) and Intel driver does only seem prepared for dithering at 6bpc (albeit I don't know why to
>>> dither at 6bpc and what depth to dither to?).
>>>   
>>>>    * Connectors also have one standardized atomic property:
>>>>    *
>>>>    * CRTC_ID:
>>>> @@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>>>>   }
>>>>   EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>>>>   
>>>> +/**
>>>> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
>>>> + * @connector: connector to attach active bpc property on.
>>>> + * @min: The minimum bit depth supported by the connector.
>>>> + * @max: The maximum bit depth supported by the connector.
>>>> + *
>>>> + * This is used to check the applied bit depth on a connector.
>>>> + *
>>>> + * Returns:
>>>> + * Zero on success, negative errno on failure.
>>>> + */
>>>> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max)
>>>> +{
>>>> +	struct drm_device *dev = connector->dev;
>>>> +	struct drm_property *prop;
>>>> +
>>>> +	if (!connector->active_bpc_property) {
>>>> +		prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "active bpc",
>>>> +						 min, max);
>>>> +		if (!prop)
>>>> +			return -ENOMEM;
>>>> +
>>>> +		connector->active_bpc_property = prop;
>>>> +		drm_object_attach_property(&connector->base, prop, 0);
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
>>>> +
>>>> +/**
>>>> + * drm_connector_set_active_bpc_property - sets the active bits per color property for a connector
>>>> + * @connector: drm connector
>>>> + * @active_bpc: bits per color for the connector currently active on "the cable"
>>>> + *
>>>> + * Should be used by atomic drivers to update the active bits per color over a connector.
>>>> + */
>>>> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc)
>>>> +{
>>>> +	drm_object_property_set_value(&connector->base, connector->active_bpc_property, active_bpc);
>>>> +}
>>>> +EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
>>>> +
>>>>   /**
>>>>    * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property
>>>>    * @connector: connector to attach the property on.
>>>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>>>> index 714d1a01c065..eee86de62a5f 100644
>>>> --- a/include/drm/drm_connector.h
>>>> +++ b/include/drm/drm_connector.h
>>>> @@ -1380,6 +1380,12 @@ struct drm_connector {
>>>>   	 */
>>>>   	struct drm_property *max_bpc_property;
>>>>   
>>>> +	/**
>>>> +	 * @active_bpc_property: Default connector property for the active bpc
>>>> +	 * to be driven out of the connector.
>>>> +	 */
>>>> +	struct drm_property *active_bpc_property;
>>>> +
>>>>   #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>>>>   #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>>>>   #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
>>>> @@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk(
>>>>   	int width, int height);
>>>>   int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>>>>   					  int min, int max);
>>>> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max);
>>>> +void drm_connector_set_active_bpc_property(struct drm_connector *connector, int active_bpc);
>>>>   
>>>>   /**
>>>>    * struct drm_tile_group - Tile group metadata
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-06-30  9:42         ` Werner Sembach
@ 2021-07-01  7:42           ` Pekka Paalanen
  2021-07-01 11:30             ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-07-01  7:42 UTC (permalink / raw)
  To: Werner Sembach
  Cc: amd-gfx, tzimmermann, intel-gfx, sunpeng.li, dri-devel,
	linux-kernel, airlied, rodrigo.vivi, alexander.deucher,
	christian.koenig

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

On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 13:02:05 +0200
> > Werner Sembach <wse@tuxedocomputers.com> wrote:
> >  
> >> Am 28.06.21 um 19:03 schrieb Werner Sembach:  
> >>> Am 18.06.21 um 11:11 schrieb Werner Sembach:  
> >>>> Add a new general drm property "active bpc" which can be used by graphic
> >>>> drivers to report the applied bit depth per pixel back to userspace.
> >>>>
> >>>> While "max bpc" can be used to change the color depth, there was no way to
> >>>> check which one actually got used. While in theory the driver chooses the
> >>>> best/highest color depth within the max bpc setting a user might not be
> >>>> fully aware what his hardware is or isn't capable off. This is meant as a
> >>>> quick way to double check the setup.
> >>>>
> >>>> In the future, automatic color calibration for screens might also depend on
> >>>> this information being available.
> >>>>
> >>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> >>>> ---
> >>>>   drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
> >>>>   include/drm/drm_connector.h     |  8 ++++++
> >>>>   2 files changed, 59 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >>>> index da39e7ff6965..943f6b61053b 100644
> >>>> --- a/drivers/gpu/drm/drm_connector.c
> >>>> +++ b/drivers/gpu/drm/drm_connector.c
> >>>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >>>>    *	drm_connector_attach_max_bpc_property() to create and attach the
> >>>>    *	property to the connector during initialization.
> >>>>    *
> >>>> + * active bpc:
> >>>> + *	This read-only range property tells userspace the pixel color bit depth
> >>>> + *	actually used by the hardware display engine on "the cable" on a
> >>>> + *	connector. The chosen value depends on hardware capabilities, both
> >>>> + *	display engine and connected monitor, and the "max bpc" property.
> >>>> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
> >>>> + *	this property.
> >>>> + *  
> >>> Regarding "on the cable" and dithering: As far as I can tell, what the dithering option does, is setting a hardware
> >>> register here:
> >>>
> >>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
> >>>
> >>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
> >>>
> >>> So dithering seems to be calculated by fixed purpose hardware/firmware outside of the driver?
> >>>
> >>> The Intel driver does not seem to set a target bpc/bpp for this hardware so I guess it defaults to 6 or 8 bpc?  
> >> Never mind it does. This switch-case does affect the dithering output:
> >> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537  
> > Hi,
> >
> > I obviously do not know the intel driver or hardware at all, but
> > to me that just looks like translating from bits per pixel to bits per
> > channel in RGB mapping?  
> No, if i understand the documentation correctly: Writing bit depth here 
> with dithering enabled sets the dithering target bpc.
> >  
> >> As found in this documentation p.548:
> >> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
> >>
> >> So max bpc and active bpc are affecting/affected by the bpc after dithering.  
> > By definition, if the cable carries N bpc, then dithering does not
> > change that. The cable still carries N bpc, but due to spatial or
> > temporal dithering, the *observed* color resolution may or may not be
> > higher than the cable bpc.  
> Yes, and max bpc and active bpc tell the cable bpc ist not the 
> *observed* bpc.
> >
> > Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
> > LSB on the cable are always zero, right?  
> I would assume that in this case only 6 bpc are actually send? Isn't the 
> whole thing of dithering that you can't send, for example, 8 bpc?
> >
> > Maybe one would want to do that if the monitor has a 6 bit panel and it
> > simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.  
> 
> Is there dithering actually doing this? aka is my assumption above wrong?
> 
> AMD code that confused me before, is hinting that you might be right: 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826
> 
> there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP
> 
> >
> > So, what does "max bpc" mean right now?
> >
> > It seems like dither on/off is insufficient information, one would also
> > need to control the dithering target bpc. I suppose the driver has a
> > policy on how it chooses the target bpc, but what is that policy? Is
> > the dither target bpc the cable bpc or the sink bpc?
> >
> > Needless to say, I'm quite confused.  
> 
> ... We need someone who knows what dithering on intel and amd gpu 
> actually means.
> 
> But I don't want this to become a blocker for this patchset, because if 
> there is no dithering, which seems to be the norm, the active bpc 
> property is already really usefull as it is. So add a note to the docs 
> that the value might be invalid when dithering is active for now?

Hi,

not necessarily invalid. It all depends on how "max bpc" and "active
bpc" are defined.

If they are defined and implemented as "on the cable", then they are
both well-defined and always valid, regardless of what dithering or bit
clamping does, so this is the semantics I'd would prefer. It's clear,
but of course does not tell full story.

When better properties for dithering are added, those can then define
how it works on top of cable bpc, with no impact on "max bpc" or
"active bpc" properties.

So if we cannot tell what "max bpc" is, then "active bpc" should just
be defined as the same thing as "max bpc" affects, and leave the
precise definition of both for later.

If the definition was observed bpc, then we would have problems and
would need to know everything right now. But you can't really make
promises of observed bpc anyway, because you don't know what the
monitor does to the video signal I suppose. Unless you define it "as if
observed through an ideal theoretical monitor" which then gets awkward
to explain.


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-06-30  9:20             ` Werner Sembach
@ 2021-07-01  8:07               ` Pekka Paalanen
  2021-07-01 12:50                 ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-07-01  8:07 UTC (permalink / raw)
  To: Werner Sembach
  Cc: sunpeng.li, Simon Ser, intel-gfx, linux-kernel, dri-devel,
	airlied, amd-gfx, tzimmermann, rodrigo.vivi, alexander.deucher,
	christian.koenig

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

On Wed, 30 Jun 2021 11:20:18 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
> 
> > On Tue, 29 Jun 2021 13:39:18 +0200
> > Werner Sembach <wse@tuxedocomputers.com> wrote:
> >  
> >> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:  
> >>> On Tue, 29 Jun 2021 08:12:54 +0000
> >>> Simon Ser <contact@emersion.fr> wrote:
> >>>     
> >>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >>>>     
> >>>>> yes, I think this makes sense, even if it is a property that one can't
> >>>>> tell for sure what it does before hand.
> >>>>>
> >>>>> Using a pair of properties, preference and active, to ask for something
> >>>>> and then check what actually worked is good for reducing the
> >>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> >>>>> test different KMS configurations. Userspace has a better chance of
> >>>>> finding a configuration that is possible.
> >>>>>
> >>>>> OTOH, this has the problem than in UI one cannot tell the user in
> >>>>> advance which options are truly possible. Given that KMS properties are
> >>>>> rarely completely independent, and in this case known to depend on
> >>>>> several other KMS properties, I think it is good enough to know after
> >>>>> the fact.
> >>>>>
> >>>>> If a driver does not use what userspace prefers, there is no way to
> >>>>> understand why, or what else to change to make it happen. That problem
> >>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
> >>>>> but only a yes/no.  
> >>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
> >>>> property at a time), user-space can discover which property makes the atomic
> >>>> commit fail.  
> >>> That works if the properties are independent of each other. Color
> >>> range, color format, bpc and more may all be interconnected,
> >>> allowing only certain combinations to work.
> >>>
> >>> If all these properties have "auto" setting too, then it would be
> >>> possible to probe each property individually, but that still does not
> >>> tell which combinations are valid.
> >>>
> >>> If you probe towards a certain configuration by setting the properties
> >>> one by one, then depending on the order you pick the properties, you
> >>> may come to a different conclusion on which property breaks the
> >>> configuration.  
> >> My mind crossed another point that must be considered: When plugin in
> >> a Monitor a list of possible Resolutions+Framerate combinations is
> >> created for xrandr and other userspace (I guess by atomic checks? but
> >> I don't know).  
> > Hi,
> >
> > I would not think so, but I hope to be corrected if I'm wrong.
> >
> > My belief is that the driver collects a list of modes from EDID, some
> > standard modes, and maybe some other hardcoded modes, and then
> > validates each entry against all the known limitations like vertical
> > and horizontal frequency limits, discarding modes that do not fit.
> >
> > Not all limitations are known during that phase, which is why KMS
> > property "link-status" exists. When userspace actually programs a mode
> > (not a TEST_ONLY commit), the link training may fail. The kernel prunes
> > the mode from the list and sets the link status property to signal
> > failure, and sends a hotplug uevent. Userspace needs to re-check the
> > mode list and try again.
> >
> > That is a generic escape hatch for when TEST_ONLY commit succeeds, but
> > in reality the hardware cannot do it, you just cannot know until you
> > actually try for real. It causes end user visible flicker if it happens
> > on an already running connector, but since it usually happens when
> > turning a connector on to begin with, there is no flicker to be seen,
> > just a small delay in finding a mode that works.
> >  
> >> During this drm
> >> properties are already considered, which is no problem atm because as
> >> far as i can tell there is currently no drm property that would make
> >> a certain Resolutions+Framerate combination unreachable that would be
> >> possible with everything on default.  
> > I would not expect KMS properties to be considered at all. It would
> > reject modes that are actually possible if the some KMS properties were
> > changed. So at least going forward, current KMS property values cannot
> > factor in.  
> 
> At least the debugfs variable "force_yuv420_output" did change the 
> available modes here: 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165 
> before my patch 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf

Hi,

debugfs is not proper UAPI, so we can just ignore it. Display servers
cannot be expected to poke in debugfs. Debugfs is not even supposed to
exist in production systems, but I'm sure people use it for hacking
stuff. But that's all it is for: developer testing and hacking.

> Forcing a color format via a DRM property in this function would 
> reintroduce the problem.

The property would need to be defined differently because its presence
could otherwise break existing userspace. Well, I suppose it could
break existing userspace no matter what, so we would need the generic
"reset to sane defaults" mechanism first IMO.

DRM has client caps for exposing video modes that old userspace might
not expect, to avoid breaking old userspace. Care needs to be taken
with all new UAPI, because if a kernel upgrade makes something wrong,
it's the kernel's fault no matter what userspace is doing, in principle.

Debugfs has no problem breaking userspace AFAIU, since it's not proper
UAPI.

> And I think i915 driver works similar in this regard.
> 
> >  
> >> However for example forcing YCbCr420 encoding would limit the
> >> available resolutions (my screen for example only supports YCbCr420
> >> on 4k@60 and @50Hz and on no other resolution or frequency (native is
> >> 2560x1440@144Hz).
> >>
> >> So would a "force color format" that does not get resetted on
> >> repluging/reenabling a monitor break the output, for example, of an
> >> not updated xrandr, unaware of this new property?  
> > Yes, not because the mode list would be missing the mode, but because
> > actually setting the mode would fail.  
> Well, like described above, I think the mode would actually be missing, 
> which is also an unexpected behavior from a user perspective.

I think that is not how the property should work.

If KMS properties would affect the list of modes, then userspace would
need to set the properties for real (TEST_ONLY cannot change anything)
and re-fetch the mode lists (maybe there is a hotplug event, maybe
not). That workflow just doesn't work.

A very interesting question is when should link-status failure not drop
the current mode from the mode list, if other KMS properties affect the
bandwidth etc. requirements of the mode. That mechanism is engineered
for old userspace that doesn't actually handle link-status but does
handle hotplug, so the hotplug triggers re-fetching the mode list and
userspace maybe trying again with a better luck since the offending
mode is gone. How to keep that working when introducing KMS properties
forcing the cable format, I don't know.

As long as the other affecting KMS properties are all "auto", the
driver will probably exhaust all possibilities to make the mode work
before signalling link-status failure and pruning the mode.
Theoretically, as I have no idea what drivers actually do.

> >
> > RandR in particular is problematic, because it does not actually
> > understand any KMS properties, it is merely a relay. So anything
> > that *uses* RandR protocol or xrandr command would also need to be
> > patched to understand the new properties.
> >
> > The kernel automatically resetting *some* properties in *some*
> > occasions seems really fragile and complicated to me, which is why I'm
> > a lot more keen to see a "reset everything to sensible defaults"
> > generic mechanism added to KMS.  
> Would you see that mechanism not (yet) existing a blocker for this 
> patchset/the "force-" properties?

For the active properties, no.

For the force properties, that is a very good question and I am
somewhat concerned. I can very much see how the force properties would
break userspace, but since it would require other userspace to mess up
the KMS configuration first, I'm not sure if kernel developers would
see that as a kernel regression as it is an existing problem. The force
properties just make it more pronounced.


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-07-01  7:42           ` Pekka Paalanen
@ 2021-07-01 11:30             ` Werner Sembach
  2021-07-14 18:18               ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-07-01 11:30 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig


Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
> On Wed, 30 Jun 2021 11:42:10 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
>>> On Tue, 29 Jun 2021 13:02:05 +0200
>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>  
>>>> Am 28.06.21 um 19:03 schrieb Werner Sembach:  
>>>>> Am 18.06.21 um 11:11 schrieb Werner Sembach:  
>>>>>> Add a new general drm property "active bpc" which can be used by graphic
>>>>>> drivers to report the applied bit depth per pixel back to userspace.
>>>>>>
>>>>>> While "max bpc" can be used to change the color depth, there was no way to
>>>>>> check which one actually got used. While in theory the driver chooses the
>>>>>> best/highest color depth within the max bpc setting a user might not be
>>>>>> fully aware what his hardware is or isn't capable off. This is meant as a
>>>>>> quick way to double check the setup.
>>>>>>
>>>>>> In the future, automatic color calibration for screens might also depend on
>>>>>> this information being available.
>>>>>>
>>>>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>>>>>> ---
>>>>>>   drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
>>>>>>   include/drm/drm_connector.h     |  8 ++++++
>>>>>>   2 files changed, 59 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>>>>> index da39e7ff6965..943f6b61053b 100644
>>>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>>>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>>>>>    *	drm_connector_attach_max_bpc_property() to create and attach the
>>>>>>    *	property to the connector during initialization.
>>>>>>    *
>>>>>> + * active bpc:
>>>>>> + *	This read-only range property tells userspace the pixel color bit depth
>>>>>> + *	actually used by the hardware display engine on "the cable" on a
>>>>>> + *	connector. The chosen value depends on hardware capabilities, both
>>>>>> + *	display engine and connected monitor, and the "max bpc" property.
>>>>>> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
>>>>>> + *	this property.
>>>>>> + *  
>>>>> Regarding "on the cable" and dithering: As far as I can tell, what the dithering option does, is setting a hardware
>>>>> register here:
>>>>>
>>>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>>>>>
>>>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>>>>>
>>>>> So dithering seems to be calculated by fixed purpose hardware/firmware outside of the driver?
>>>>>
>>>>> The Intel driver does not seem to set a target bpc/bpp for this hardware so I guess it defaults to 6 or 8 bpc?  
>>>> Never mind it does. This switch-case does affect the dithering output:
>>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537  
>>> Hi,
>>>
>>> I obviously do not know the intel driver or hardware at all, but
>>> to me that just looks like translating from bits per pixel to bits per
>>> channel in RGB mapping?  
>> No, if i understand the documentation correctly: Writing bit depth here 
>> with dithering enabled sets the dithering target bpc.
>>>  
>>>> As found in this documentation p.548:
>>>> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
>>>>
>>>> So max bpc and active bpc are affecting/affected by the bpc after dithering.  
>>> By definition, if the cable carries N bpc, then dithering does not
>>> change that. The cable still carries N bpc, but due to spatial or
>>> temporal dithering, the *observed* color resolution may or may not be
>>> higher than the cable bpc.  
>> Yes, and max bpc and active bpc tell the cable bpc ist not the 
>> *observed* bpc.
>>> Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
>>> LSB on the cable are always zero, right?  
>> I would assume that in this case only 6 bpc are actually send? Isn't the 
>> whole thing of dithering that you can't send, for example, 8 bpc?
>>> Maybe one would want to do that if the monitor has a 6 bit panel and it
>>> simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.  
>> Is there dithering actually doing this? aka is my assumption above wrong?
>>
>> AMD code that confused me before, is hinting that you might be right: 
>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826
>>
>> there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP
>>
>>> So, what does "max bpc" mean right now?
>>>
>>> It seems like dither on/off is insufficient information, one would also
>>> need to control the dithering target bpc. I suppose the driver has a
>>> policy on how it chooses the target bpc, but what is that policy? Is
>>> the dither target bpc the cable bpc or the sink bpc?
>>>
>>> Needless to say, I'm quite confused.  
>> ... We need someone who knows what dithering on intel and amd gpu 
>> actually means.
>>
>> But I don't want this to become a blocker for this patchset, because if 
>> there is no dithering, which seems to be the norm, the active bpc 
>> property is already really usefull as it is. So add a note to the docs 
>> that the value might be invalid when dithering is active for now?
> Hi,
>
> not necessarily invalid. It all depends on how "max bpc" and "active
> bpc" are defined.
>
> If they are defined and implemented as "on the cable", then they are
> both well-defined and always valid, regardless of what dithering or bit
> clamping does, so this is the semantics I'd would prefer. It's clear,
> but of course does not tell full story.
>
> When better properties for dithering are added, those can then define
> how it works on top of cable bpc, with no impact on "max bpc" or
> "active bpc" properties.
>
> So if we cannot tell what "max bpc" is, then "active bpc" should just
> be defined as the same thing as "max bpc" affects, and leave the
> precise definition of both for later.
But as long as I don't know exactly how dithering is affected by max bpc I can't tell for sure if active bpc is acting
the same. That's why I wrote it is "undefined" to not run into a trap where the actual behavior have to change after the
fact.
>
> If the definition was observed bpc, then we would have problems and
> would need to know everything right now. But you can't really make
> promises of observed bpc anyway, because you don't know what the
> monitor does to the video signal I suppose. Unless you define it "as if
> observed through an ideal theoretical monitor" which then gets awkward
> to explain.
Yes, that's why I think describing the "raw" signal is the best and leave it to the user to know what his or her Monitor
is making out of it.
>
>
> Thanks,
> pq

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-07-01  8:07               ` Pekka Paalanen
@ 2021-07-01 12:50                 ` Werner Sembach
  2021-07-01 13:24                   ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-07-01 12:50 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

Am 01.07.21 um 10:07 schrieb Pekka Paalanen:

> On Wed, 30 Jun 2021 11:20:18 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>
>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>  
>>>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:  
>>>>> On Tue, 29 Jun 2021 08:12:54 +0000
>>>>> Simon Ser <contact@emersion.fr> wrote:
>>>>>     
>>>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>>>>>     
>>>>>>> yes, I think this makes sense, even if it is a property that one can't
>>>>>>> tell for sure what it does before hand.
>>>>>>>
>>>>>>> Using a pair of properties, preference and active, to ask for something
>>>>>>> and then check what actually worked is good for reducing the
>>>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>>>>>> test different KMS configurations. Userspace has a better chance of
>>>>>>> finding a configuration that is possible.
>>>>>>>
>>>>>>> OTOH, this has the problem than in UI one cannot tell the user in
>>>>>>> advance which options are truly possible. Given that KMS properties are
>>>>>>> rarely completely independent, and in this case known to depend on
>>>>>>> several other KMS properties, I think it is good enough to know after
>>>>>>> the fact.
>>>>>>>
>>>>>>> If a driver does not use what userspace prefers, there is no way to
>>>>>>> understand why, or what else to change to make it happen. That problem
>>>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>>>>>> but only a yes/no.  
>>>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>>>>>> property at a time), user-space can discover which property makes the atomic
>>>>>> commit fail.  
>>>>> That works if the properties are independent of each other. Color
>>>>> range, color format, bpc and more may all be interconnected,
>>>>> allowing only certain combinations to work.
>>>>>
>>>>> If all these properties have "auto" setting too, then it would be
>>>>> possible to probe each property individually, but that still does not
>>>>> tell which combinations are valid.
>>>>>
>>>>> If you probe towards a certain configuration by setting the properties
>>>>> one by one, then depending on the order you pick the properties, you
>>>>> may come to a different conclusion on which property breaks the
>>>>> configuration.  
>>>> My mind crossed another point that must be considered: When plugin in
>>>> a Monitor a list of possible Resolutions+Framerate combinations is
>>>> created for xrandr and other userspace (I guess by atomic checks? but
>>>> I don't know).  
>>> Hi,
>>>
>>> I would not think so, but I hope to be corrected if I'm wrong.
>>>
>>> My belief is that the driver collects a list of modes from EDID, some
>>> standard modes, and maybe some other hardcoded modes, and then
>>> validates each entry against all the known limitations like vertical
>>> and horizontal frequency limits, discarding modes that do not fit.
>>>
>>> Not all limitations are known during that phase, which is why KMS
>>> property "link-status" exists. When userspace actually programs a mode
>>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
>>> the mode from the list and sets the link status property to signal
>>> failure, and sends a hotplug uevent. Userspace needs to re-check the
>>> mode list and try again.
>>>
>>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
>>> in reality the hardware cannot do it, you just cannot know until you
>>> actually try for real. It causes end user visible flicker if it happens
>>> on an already running connector, but since it usually happens when
>>> turning a connector on to begin with, there is no flicker to be seen,
>>> just a small delay in finding a mode that works.
>>>  
>>>> During this drm
>>>> properties are already considered, which is no problem atm because as
>>>> far as i can tell there is currently no drm property that would make
>>>> a certain Resolutions+Framerate combination unreachable that would be
>>>> possible with everything on default.  
>>> I would not expect KMS properties to be considered at all. It would
>>> reject modes that are actually possible if the some KMS properties were
>>> changed. So at least going forward, current KMS property values cannot
>>> factor in.  
>> At least the debugfs variable "force_yuv420_output" did change the 
>> available modes here: 
>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165 
>> before my patch 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf
> Hi,
>
> debugfs is not proper UAPI, so we can just ignore it. Display servers
> cannot be expected to poke in debugfs. Debugfs is not even supposed to
> exist in production systems, but I'm sure people use it for hacking
> stuff. But that's all it is for: developer testing and hacking.
e.g. Ubuntu has it active by default, but only read (and writable) by root.
>
>> Forcing a color format via a DRM property in this function would 
>> reintroduce the problem.
> The property would need to be defined differently because its presence
> could otherwise break existing userspace. Well, I suppose it could
> break existing userspace no matter what, so we would need the generic
> "reset to sane defaults" mechanism first IMO.
>
> DRM has client caps for exposing video modes that old userspace might
> not expect, to avoid breaking old userspace. Care needs to be taken
> with all new UAPI, because if a kernel upgrade makes something wrong,
> it's the kernel's fault no matter what userspace is doing, in principle.
Can you give me a link describing how I define this caps?
>
> Debugfs has no problem breaking userspace AFAIU, since it's not proper
> UAPI.
>
>> And I think i915 driver works similar in this regard.
>>
>>>  
>>>> However for example forcing YCbCr420 encoding would limit the
>>>> available resolutions (my screen for example only supports YCbCr420
>>>> on 4k@60 and @50Hz and on no other resolution or frequency (native is
>>>> 2560x1440@144Hz).
>>>>
>>>> So would a "force color format" that does not get resetted on
>>>> repluging/reenabling a monitor break the output, for example, of an
>>>> not updated xrandr, unaware of this new property?  
>>> Yes, not because the mode list would be missing the mode, but because
>>> actually setting the mode would fail.  
>> Well, like described above, I think the mode would actually be missing, 
>> which is also an unexpected behavior from a user perspective.
> I think that is not how the property should work.
>
> If KMS properties would affect the list of modes, then userspace would
> need to set the properties for real (TEST_ONLY cannot change anything)
> and re-fetch the mode lists (maybe there is a hotplug event, maybe
> not). That workflow just doesn't work.
The properties are set before the list is created in the first place. Because, in my example, the properties get set
before the monitor is plugged in and the list can only be created as soon as the monitor is plugged in.
>
> A very interesting question is when should link-status failure not drop
> the current mode from the mode list, if other KMS properties affect the
> bandwidth etc. requirements of the mode. That mechanism is engineered
> for old userspace that doesn't actually handle link-status but does
> handle hotplug, so the hotplug triggers re-fetching the mode list and
> userspace maybe trying again with a better luck since the offending
> mode is gone. How to keep that working when introducing KMS properties
> forcing the cable format, I don't know.
>
> As long as the other affecting KMS properties are all "auto", the
> driver will probably exhaust all possibilities to make the mode work
> before signalling link-status failure and pruning the mode.
> Theoretically, as I have no idea what drivers actually do.
Isn't that exactly how the "preferred color format" property works in my patchset now?
>
>>> RandR in particular is problematic, because it does not actually
>>> understand any KMS properties, it is merely a relay. So anything
>>> that *uses* RandR protocol or xrandr command would also need to be
>>> patched to understand the new properties.
>>>
>>> The kernel automatically resetting *some* properties in *some*
>>> occasions seems really fragile and complicated to me, which is why I'm
>>> a lot more keen to see a "reset everything to sensible defaults"
>>> generic mechanism added to KMS.  
>> Would you see that mechanism not (yet) existing a blocker for this 
>> patchset/the "force-" properties?
> For the active properties, no.
>
> For the force properties, that is a very good question and I am
> somewhat concerned. I can very much see how the force properties would
> break userspace, but since it would require other userspace to mess up
> the KMS configuration first, I'm not sure if kernel developers would
> see that as a kernel regression as it is an existing problem. The force
> properties just make it more pronounced.
>
>
> Thanks,
> pq

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-07-01 12:50                 ` Werner Sembach
@ 2021-07-01 13:24                   ` Pekka Paalanen
  2021-07-05 15:49                     ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-07-01 13:24 UTC (permalink / raw)
  To: Werner Sembach
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

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

On Thu, 1 Jul 2021 14:50:13 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
> 
> > On Wed, 30 Jun 2021 11:20:18 +0200
> > Werner Sembach <wse@tuxedocomputers.com> wrote:
> >  
> >> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
> >>  
> >>> On Tue, 29 Jun 2021 13:39:18 +0200
> >>> Werner Sembach <wse@tuxedocomputers.com> wrote:
> >>>    
> >>>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:    
> >>>>> On Tue, 29 Jun 2021 08:12:54 +0000
> >>>>> Simon Ser <contact@emersion.fr> wrote:
> >>>>>       
> >>>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >>>>>>       
> >>>>>>> yes, I think this makes sense, even if it is a property that one can't
> >>>>>>> tell for sure what it does before hand.
> >>>>>>>
> >>>>>>> Using a pair of properties, preference and active, to ask for something
> >>>>>>> and then check what actually worked is good for reducing the
> >>>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> >>>>>>> test different KMS configurations. Userspace has a better chance of
> >>>>>>> finding a configuration that is possible.
> >>>>>>>
> >>>>>>> OTOH, this has the problem than in UI one cannot tell the user in
> >>>>>>> advance which options are truly possible. Given that KMS properties are
> >>>>>>> rarely completely independent, and in this case known to depend on
> >>>>>>> several other KMS properties, I think it is good enough to know after
> >>>>>>> the fact.
> >>>>>>>
> >>>>>>> If a driver does not use what userspace prefers, there is no way to
> >>>>>>> understand why, or what else to change to make it happen. That problem
> >>>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
> >>>>>>> but only a yes/no.    
> >>>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
> >>>>>> property at a time), user-space can discover which property makes the atomic
> >>>>>> commit fail.    
> >>>>> That works if the properties are independent of each other. Color
> >>>>> range, color format, bpc and more may all be interconnected,
> >>>>> allowing only certain combinations to work.
> >>>>>
> >>>>> If all these properties have "auto" setting too, then it would be
> >>>>> possible to probe each property individually, but that still does not
> >>>>> tell which combinations are valid.
> >>>>>
> >>>>> If you probe towards a certain configuration by setting the properties
> >>>>> one by one, then depending on the order you pick the properties, you
> >>>>> may come to a different conclusion on which property breaks the
> >>>>> configuration.    
> >>>> My mind crossed another point that must be considered: When plugin in
> >>>> a Monitor a list of possible Resolutions+Framerate combinations is
> >>>> created for xrandr and other userspace (I guess by atomic checks? but
> >>>> I don't know).    
> >>> Hi,
> >>>
> >>> I would not think so, but I hope to be corrected if I'm wrong.
> >>>
> >>> My belief is that the driver collects a list of modes from EDID, some
> >>> standard modes, and maybe some other hardcoded modes, and then
> >>> validates each entry against all the known limitations like vertical
> >>> and horizontal frequency limits, discarding modes that do not fit.
> >>>
> >>> Not all limitations are known during that phase, which is why KMS
> >>> property "link-status" exists. When userspace actually programs a mode
> >>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
> >>> the mode from the list and sets the link status property to signal
> >>> failure, and sends a hotplug uevent. Userspace needs to re-check the
> >>> mode list and try again.
> >>>
> >>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
> >>> in reality the hardware cannot do it, you just cannot know until you
> >>> actually try for real. It causes end user visible flicker if it happens
> >>> on an already running connector, but since it usually happens when
> >>> turning a connector on to begin with, there is no flicker to be seen,
> >>> just a small delay in finding a mode that works.
> >>>    
> >>>> During this drm
> >>>> properties are already considered, which is no problem atm because as
> >>>> far as i can tell there is currently no drm property that would make
> >>>> a certain Resolutions+Framerate combination unreachable that would be
> >>>> possible with everything on default.    
> >>> I would not expect KMS properties to be considered at all. It would
> >>> reject modes that are actually possible if the some KMS properties were
> >>> changed. So at least going forward, current KMS property values cannot
> >>> factor in.    
> >> At least the debugfs variable "force_yuv420_output" did change the 
> >> available modes here: 
> >> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165 
> >> before my patch 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf  
> > Hi,
> >
> > debugfs is not proper UAPI, so we can just ignore it. Display servers
> > cannot be expected to poke in debugfs. Debugfs is not even supposed to
> > exist in production systems, but I'm sure people use it for hacking
> > stuff. But that's all it is for: developer testing and hacking.  
> e.g. Ubuntu has it active by default, but only read (and writable) by root.

Hi,

that's normal, yes. Root can do damage anyway, and it's useful for
debugging. KMS clients OTOH often do not run as root.

> >  
> >> Forcing a color format via a DRM property in this function would 
> >> reintroduce the problem.  
> > The property would need to be defined differently because its presence
> > could otherwise break existing userspace. Well, I suppose it could
> > break existing userspace no matter what, so we would need the generic
> > "reset to sane defaults" mechanism first IMO.
> >
> > DRM has client caps for exposing video modes that old userspace might
> > not expect, to avoid breaking old userspace. Care needs to be taken
> > with all new UAPI, because if a kernel upgrade makes something wrong,
> > it's the kernel's fault no matter what userspace is doing, in principle.  
> Can you give me a link describing how I define this caps?

I don't have any, but you can find all the existing ones by grepping
for DRM_CLIENT_CAP_.

I'm not saying that we need it, but mentioning them as a possible
workaround if userspace breakage seems imminent or is proven.

> >
> > Debugfs has no problem breaking userspace AFAIU, since it's not proper
> > UAPI.
> >  
> >> And I think i915 driver works similar in this regard.
> >>  
> >>>    
> >>>> However for example forcing YCbCr420 encoding would limit the
> >>>> available resolutions (my screen for example only supports YCbCr420
> >>>> on 4k@60 and @50Hz and on no other resolution or frequency (native is
> >>>> 2560x1440@144Hz).
> >>>>
> >>>> So would a "force color format" that does not get resetted on
> >>>> repluging/reenabling a monitor break the output, for example, of an
> >>>> not updated xrandr, unaware of this new property?    
> >>> Yes, not because the mode list would be missing the mode, but because
> >>> actually setting the mode would fail.    
> >> Well, like described above, I think the mode would actually be missing, 
> >> which is also an unexpected behavior from a user perspective.  
> > I think that is not how the property should work.
> >
> > If KMS properties would affect the list of modes, then userspace would
> > need to set the properties for real (TEST_ONLY cannot change anything)
> > and re-fetch the mode lists (maybe there is a hotplug event, maybe
> > not). That workflow just doesn't work.  

> The properties are set before the list is created in the first place.
> Because, in my example, the properties get set before the monitor is
> plugged in and the list can only be created as soon as the monitor is
> plugged in.

That's just an accident, it's not what I mean.

What I mean is, we cannot have the KMS properties affect the list of
modes, because then userspace that want to use specific values on those
properties would have to program those properties first, and then get
the list of modes. KMS UAPI does not work that way AFAIK.

If the initial mode list is created on hotplug like you say, then the
initial list could already be missing some modes that would be valid if
some KMS properties had different values.

> >
> > A very interesting question is when should link-status failure not drop
> > the current mode from the mode list, if other KMS properties affect the
> > bandwidth etc. requirements of the mode. That mechanism is engineered
> > for old userspace that doesn't actually handle link-status but does
> > handle hotplug, so the hotplug triggers re-fetching the mode list and
> > userspace maybe trying again with a better luck since the offending
> > mode is gone. How to keep that working when introducing KMS properties
> > forcing the cable format, I don't know.
> >
> > As long as the other affecting KMS properties are all "auto", the
> > driver will probably exhaust all possibilities to make the mode work
> > before signalling link-status failure and pruning the mode.
> > Theoretically, as I have no idea what drivers actually do.  

> Isn't that exactly how the "preferred color format" property works in
> my patchset now?

There was an argument that "preferred" with no guarantees is not
useful enough. So I'm considering the force property instead.
The problem is, "auto" is not the only possible value.

When the value is not "auto", should link failure drop the mode or not?
Userspace might change the value back to "auto" next time. If you
dropped the mode, it would be gone. If you didn't drop the mode,
userspace might be stuck picking the same non-working mode again and
again if it doesn't know about the force mode property.

You could argue that changing the value back to "auto" needs to reset
the mode list, but that only gets us back to the "need to set
properties before getting mode list".

Maybe there needs to be an assumption that if "force color format" is
not "auto", then link failure does not drop modes and userspace knows
to handle this. Messy.

I'm afraid I just don't know to give any clear answer. It's also
possible that, as I'm not a kernel dev, I have some false assumptions
here.


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-07-01 13:24                   ` Pekka Paalanen
@ 2021-07-05 15:49                     ` Werner Sembach
  2021-07-06  7:09                       ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-07-05 15:49 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, amd-gfx, airlied, dri-devel,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig


Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
> On Thu, 1 Jul 2021 14:50:13 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
>>
>>> On Wed, 30 Jun 2021 11:20:18 +0200
>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>  
>>>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>>>  
>>>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>>>    
>>>>>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:    
>>>>>>> On Tue, 29 Jun 2021 08:12:54 +0000
>>>>>>> Simon Ser <contact@emersion.fr> wrote:
>>>>>>>       
>>>>>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>>>>>>>       
>>>>>>>>> yes, I think this makes sense, even if it is a property that one can't
>>>>>>>>> tell for sure what it does before hand.
>>>>>>>>>
>>>>>>>>> Using a pair of properties, preference and active, to ask for something
>>>>>>>>> and then check what actually worked is good for reducing the
>>>>>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>>>>>>>> test different KMS configurations. Userspace has a better chance of
>>>>>>>>> finding a configuration that is possible.
>>>>>>>>>
>>>>>>>>> OTOH, this has the problem than in UI one cannot tell the user in
>>>>>>>>> advance which options are truly possible. Given that KMS properties are
>>>>>>>>> rarely completely independent, and in this case known to depend on
>>>>>>>>> several other KMS properties, I think it is good enough to know after
>>>>>>>>> the fact.
>>>>>>>>>
>>>>>>>>> If a driver does not use what userspace prefers, there is no way to
>>>>>>>>> understand why, or what else to change to make it happen. That problem
>>>>>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>>>>>>>> but only a yes/no.    
>>>>>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>>>>>>>> property at a time), user-space can discover which property makes the atomic
>>>>>>>> commit fail.    
>>>>>>> That works if the properties are independent of each other. Color
>>>>>>> range, color format, bpc and more may all be interconnected,
>>>>>>> allowing only certain combinations to work.
>>>>>>>
>>>>>>> If all these properties have "auto" setting too, then it would be
>>>>>>> possible to probe each property individually, but that still does not
>>>>>>> tell which combinations are valid.
>>>>>>>
>>>>>>> If you probe towards a certain configuration by setting the properties
>>>>>>> one by one, then depending on the order you pick the properties, you
>>>>>>> may come to a different conclusion on which property breaks the
>>>>>>> configuration.    
>>>>>> My mind crossed another point that must be considered: When plugin in
>>>>>> a Monitor a list of possible Resolutions+Framerate combinations is
>>>>>> created for xrandr and other userspace (I guess by atomic checks? but
>>>>>> I don't know).    
>>>>> Hi,
>>>>>
>>>>> I would not think so, but I hope to be corrected if I'm wrong.
>>>>>
>>>>> My belief is that the driver collects a list of modes from EDID, some
>>>>> standard modes, and maybe some other hardcoded modes, and then
>>>>> validates each entry against all the known limitations like vertical
>>>>> and horizontal frequency limits, discarding modes that do not fit.
>>>>>
>>>>> Not all limitations are known during that phase, which is why KMS
>>>>> property "link-status" exists. When userspace actually programs a mode
>>>>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
>>>>> the mode from the list and sets the link status property to signal
>>>>> failure, and sends a hotplug uevent. Userspace needs to re-check the
>>>>> mode list and try again.
>>>>>
>>>>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
>>>>> in reality the hardware cannot do it, you just cannot know until you
>>>>> actually try for real. It causes end user visible flicker if it happens
>>>>> on an already running connector, but since it usually happens when
>>>>> turning a connector on to begin with, there is no flicker to be seen,
>>>>> just a small delay in finding a mode that works.
>>>>>    
>>>>>> During this drm
>>>>>> properties are already considered, which is no problem atm because as
>>>>>> far as i can tell there is currently no drm property that would make
>>>>>> a certain Resolutions+Framerate combination unreachable that would be
>>>>>> possible with everything on default.    
>>>>> I would not expect KMS properties to be considered at all. It would
>>>>> reject modes that are actually possible if the some KMS properties were
>>>>> changed. So at least going forward, current KMS property values cannot
>>>>> factor in.    
>>>> At least the debugfs variable "force_yuv420_output" did change the 
>>>> available modes here: 
>>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165 
>>>> before my patch 
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf  
>>> Hi,
>>>
>>> debugfs is not proper UAPI, so we can just ignore it. Display servers
>>> cannot be expected to poke in debugfs. Debugfs is not even supposed to
>>> exist in production systems, but I'm sure people use it for hacking
>>> stuff. But that's all it is for: developer testing and hacking.  
>> e.g. Ubuntu has it active by default, but only read (and writable) by root.
> Hi,
>
> that's normal, yes. Root can do damage anyway, and it's useful for
> debugging. KMS clients OTOH often do not run as root.
>
>>>  
>>>> Forcing a color format via a DRM property in this function would 
>>>> reintroduce the problem.  
>>> The property would need to be defined differently because its presence
>>> could otherwise break existing userspace. Well, I suppose it could
>>> break existing userspace no matter what, so we would need the generic
>>> "reset to sane defaults" mechanism first IMO.
>>>
>>> DRM has client caps for exposing video modes that old userspace might
>>> not expect, to avoid breaking old userspace. Care needs to be taken
>>> with all new UAPI, because if a kernel upgrade makes something wrong,
>>> it's the kernel's fault no matter what userspace is doing, in principle.  
>> Can you give me a link describing how I define this caps?
> I don't have any, but you can find all the existing ones by grepping
> for DRM_CLIENT_CAP_.
>
> I'm not saying that we need it, but mentioning them as a possible
> workaround if userspace breakage seems imminent or is proven.
>
>>> Debugfs has no problem breaking userspace AFAIU, since it's not proper
>>> UAPI.
>>>  
>>>> And I think i915 driver works similar in this regard.
>>>>  
>>>>>    
>>>>>> However for example forcing YCbCr420 encoding would limit the
>>>>>> available resolutions (my screen for example only supports YCbCr420
>>>>>> on 4k@60 and @50Hz and on no other resolution or frequency (native is
>>>>>> 2560x1440@144Hz).
>>>>>>
>>>>>> So would a "force color format" that does not get resetted on
>>>>>> repluging/reenabling a monitor break the output, for example, of an
>>>>>> not updated xrandr, unaware of this new property?    
>>>>> Yes, not because the mode list would be missing the mode, but because
>>>>> actually setting the mode would fail.    
>>>> Well, like described above, I think the mode would actually be missing, 
>>>> which is also an unexpected behavior from a user perspective.  
>>> I think that is not how the property should work.
>>>
>>> If KMS properties would affect the list of modes, then userspace would
>>> need to set the properties for real (TEST_ONLY cannot change anything)
>>> and re-fetch the mode lists (maybe there is a hotplug event, maybe
>>> not). That workflow just doesn't work.  
>> The properties are set before the list is created in the first place.
>> Because, in my example, the properties get set before the monitor is
>> plugged in and the list can only be created as soon as the monitor is
>> plugged in.
> That's just an accident, it's not what I mean.
>
> What I mean is, we cannot have the KMS properties affect the list of
> modes, because then userspace that want to use specific values on those
> properties would have to program those properties first, and then get
> the list of modes. KMS UAPI does not work that way AFAIK.
>
> If the initial mode list is created on hotplug like you say, then the
> initial list could already be missing some modes that would be valid if
> some KMS properties had different values.

Depends if the mode list is created by TEST_ONLY:

- The force properties should return false on TEST_ONLY

- The force properties should not prevent the mode from showing up in the list

If the list is created by TEST_ONLY both things can't be fulfilled at the same time obviously.

I hope some can give more insights or has an idea how the properties could work best.

>
>>> A very interesting question is when should link-status failure not drop
>>> the current mode from the mode list, if other KMS properties affect the
>>> bandwidth etc. requirements of the mode. That mechanism is engineered
>>> for old userspace that doesn't actually handle link-status but does
>>> handle hotplug, so the hotplug triggers re-fetching the mode list and
>>> userspace maybe trying again with a better luck since the offending
>>> mode is gone. How to keep that working when introducing KMS properties
>>> forcing the cable format, I don't know.
>>>
>>> As long as the other affecting KMS properties are all "auto", the
>>> driver will probably exhaust all possibilities to make the mode work
>>> before signalling link-status failure and pruning the mode.
>>> Theoretically, as I have no idea what drivers actually do.  
>> Isn't that exactly how the "preferred color format" property works in
>> my patchset now?
> There was an argument that "preferred" with no guarantees is not
> useful enough. So I'm considering the force property instead.
> The problem is, "auto" is not the only possible value.
>
> When the value is not "auto", should link failure drop the mode or not?
> Userspace might change the value back to "auto" next time. If you
> dropped the mode, it would be gone. If you didn't drop the mode,
> userspace might be stuck picking the same non-working mode again and
> again if it doesn't know about the force mode property.
>
> You could argue that changing the value back to "auto" needs to reset
> the mode list, but that only gets us back to the "need to set
> properties before getting mode list".
>
> Maybe there needs to be an assumption that if "force color format" is
> not "auto", then link failure does not drop modes and userspace knows
> to handle this. Messy.
>
> I'm afraid I just don't know to give any clear answer. It's also
> possible that, as I'm not a kernel dev, I have some false assumptions
> here.
>
>
> Thanks,
> pq
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-07-05 15:49                     ` Werner Sembach
@ 2021-07-06  7:09                       ` Pekka Paalanen
  2021-07-14 17:59                         ` Werner Sembach
  0 siblings, 1 reply; 57+ messages in thread
From: Pekka Paalanen @ 2021-07-06  7:09 UTC (permalink / raw)
  To: Werner Sembach
  Cc: sunpeng.li, intel-gfx, linux-kernel, amd-gfx, airlied, dri-devel,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

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

On Mon, 5 Jul 2021 17:49:42 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
> > On Thu, 1 Jul 2021 14:50:13 +0200
> > Werner Sembach <wse@tuxedocomputers.com> wrote:
> >  
> >> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
> >>  
> >>> On Wed, 30 Jun 2021 11:20:18 +0200
> >>> Werner Sembach <wse@tuxedocomputers.com> wrote:
> >>>    
> >>>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
> >>>>    
> >>>>> On Tue, 29 Jun 2021 13:39:18 +0200
> >>>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
> >>>>>      
> >>>>>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:      
> >>>>>>> On Tue, 29 Jun 2021 08:12:54 +0000
> >>>>>>> Simon Ser <contact@emersion.fr> wrote:
> >>>>>>>         
> >>>>>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >>>>>>>>         
> >>>>>>>>> yes, I think this makes sense, even if it is a property that one can't
> >>>>>>>>> tell for sure what it does before hand.
> >>>>>>>>>
> >>>>>>>>> Using a pair of properties, preference and active, to ask for something
> >>>>>>>>> and then check what actually worked is good for reducing the
> >>>>>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> >>>>>>>>> test different KMS configurations. Userspace has a better chance of
> >>>>>>>>> finding a configuration that is possible.
> >>>>>>>>>
> >>>>>>>>> OTOH, this has the problem than in UI one cannot tell the user in
> >>>>>>>>> advance which options are truly possible. Given that KMS properties are
> >>>>>>>>> rarely completely independent, and in this case known to depend on
> >>>>>>>>> several other KMS properties, I think it is good enough to know after
> >>>>>>>>> the fact.
> >>>>>>>>>
> >>>>>>>>> If a driver does not use what userspace prefers, there is no way to
> >>>>>>>>> understand why, or what else to change to make it happen. That problem
> >>>>>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
> >>>>>>>>> but only a yes/no.      
> >>>>>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
> >>>>>>>> property at a time), user-space can discover which property makes the atomic
> >>>>>>>> commit fail.      
> >>>>>>> That works if the properties are independent of each other. Color
> >>>>>>> range, color format, bpc and more may all be interconnected,
> >>>>>>> allowing only certain combinations to work.
> >>>>>>>
> >>>>>>> If all these properties have "auto" setting too, then it would be
> >>>>>>> possible to probe each property individually, but that still does not
> >>>>>>> tell which combinations are valid.
> >>>>>>>
> >>>>>>> If you probe towards a certain configuration by setting the properties
> >>>>>>> one by one, then depending on the order you pick the properties, you
> >>>>>>> may come to a different conclusion on which property breaks the
> >>>>>>> configuration.      
> >>>>>> My mind crossed another point that must be considered: When plugin in
> >>>>>> a Monitor a list of possible Resolutions+Framerate combinations is
> >>>>>> created for xrandr and other userspace (I guess by atomic checks? but
> >>>>>> I don't know).      
> >>>>> Hi,
> >>>>>
> >>>>> I would not think so, but I hope to be corrected if I'm wrong.
> >>>>>
> >>>>> My belief is that the driver collects a list of modes from EDID, some
> >>>>> standard modes, and maybe some other hardcoded modes, and then
> >>>>> validates each entry against all the known limitations like vertical
> >>>>> and horizontal frequency limits, discarding modes that do not fit.
> >>>>>
> >>>>> Not all limitations are known during that phase, which is why KMS
> >>>>> property "link-status" exists. When userspace actually programs a mode
> >>>>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
> >>>>> the mode from the list and sets the link status property to signal
> >>>>> failure, and sends a hotplug uevent. Userspace needs to re-check the
> >>>>> mode list and try again.
> >>>>>
> >>>>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
> >>>>> in reality the hardware cannot do it, you just cannot know until you
> >>>>> actually try for real. It causes end user visible flicker if it happens
> >>>>> on an already running connector, but since it usually happens when
> >>>>> turning a connector on to begin with, there is no flicker to be seen,
> >>>>> just a small delay in finding a mode that works.
> >>>>>      
> >>>>>> During this drm
> >>>>>> properties are already considered, which is no problem atm because as
> >>>>>> far as i can tell there is currently no drm property that would make
> >>>>>> a certain Resolutions+Framerate combination unreachable that would be
> >>>>>> possible with everything on default.      
> >>>>> I would not expect KMS properties to be considered at all. It would
> >>>>> reject modes that are actually possible if the some KMS properties were
> >>>>> changed. So at least going forward, current KMS property values cannot
> >>>>> factor in.      
> >>>> At least the debugfs variable "force_yuv420_output" did change the 
> >>>> available modes here: 
> >>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165 
> >>>> before my patch 
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf    
> >>> Hi,
> >>>
> >>> debugfs is not proper UAPI, so we can just ignore it. Display servers
> >>> cannot be expected to poke in debugfs. Debugfs is not even supposed to
> >>> exist in production systems, but I'm sure people use it for hacking
> >>> stuff. But that's all it is for: developer testing and hacking.    
> >> e.g. Ubuntu has it active by default, but only read (and writable) by root.  
> > Hi,
> >
> > that's normal, yes. Root can do damage anyway, and it's useful for
> > debugging. KMS clients OTOH often do not run as root.
> >  
> >>>    
> >>>> Forcing a color format via a DRM property in this function would 
> >>>> reintroduce the problem.    
> >>> The property would need to be defined differently because its presence
> >>> could otherwise break existing userspace. Well, I suppose it could
> >>> break existing userspace no matter what, so we would need the generic
> >>> "reset to sane defaults" mechanism first IMO.
> >>>
> >>> DRM has client caps for exposing video modes that old userspace might
> >>> not expect, to avoid breaking old userspace. Care needs to be taken
> >>> with all new UAPI, because if a kernel upgrade makes something wrong,
> >>> it's the kernel's fault no matter what userspace is doing, in principle.    
> >> Can you give me a link describing how I define this caps?  
> > I don't have any, but you can find all the existing ones by grepping
> > for DRM_CLIENT_CAP_.
> >
> > I'm not saying that we need it, but mentioning them as a possible
> > workaround if userspace breakage seems imminent or is proven.
> >  
> >>> Debugfs has no problem breaking userspace AFAIU, since it's not proper
> >>> UAPI.
> >>>    
> >>>> And I think i915 driver works similar in this regard.
> >>>>    
> >>>>>      
> >>>>>> However for example forcing YCbCr420 encoding would limit the
> >>>>>> available resolutions (my screen for example only supports YCbCr420
> >>>>>> on 4k@60 and @50Hz and on no other resolution or frequency (native is
> >>>>>> 2560x1440@144Hz).
> >>>>>>
> >>>>>> So would a "force color format" that does not get resetted on
> >>>>>> repluging/reenabling a monitor break the output, for example, of an
> >>>>>> not updated xrandr, unaware of this new property?      
> >>>>> Yes, not because the mode list would be missing the mode, but because
> >>>>> actually setting the mode would fail.      
> >>>> Well, like described above, I think the mode would actually be missing, 
> >>>> which is also an unexpected behavior from a user perspective.    
> >>> I think that is not how the property should work.
> >>>
> >>> If KMS properties would affect the list of modes, then userspace would
> >>> need to set the properties for real (TEST_ONLY cannot change anything)
> >>> and re-fetch the mode lists (maybe there is a hotplug event, maybe
> >>> not). That workflow just doesn't work.    
> >> The properties are set before the list is created in the first place.
> >> Because, in my example, the properties get set before the monitor is
> >> plugged in and the list can only be created as soon as the monitor is
> >> plugged in.  
> > That's just an accident, it's not what I mean.
> >
> > What I mean is, we cannot have the KMS properties affect the list of
> > modes, because then userspace that want to use specific values on those
> > properties would have to program those properties first, and then get
> > the list of modes. KMS UAPI does not work that way AFAIK.
> >
> > If the initial mode list is created on hotplug like you say, then the
> > initial list could already be missing some modes that would be valid if
> > some KMS properties had different values.  
> 
> Depends if the mode list is created by TEST_ONLY:

Hi,

I'm pretty sure it's not created by any kind of atomic test probing,
exactly because some properties might affect the result. Also because
of legacy: the mode lists predate atomic by far. It just doesn't make
sense to prune the mode list based on current arbitrary property values.

The function drm_helper_probe_single_connector_modes() looks relevant
to me. It has a big comment that seems to point towards more things to
look at.


Thanks,
pq

> - The force properties should return false on TEST_ONLY
> 
> - The force properties should not prevent the mode from showing up in the list
> 
> If the list is created by TEST_ONLY both things can't be fulfilled at the same time obviously.
> 
> I hope some can give more insights or has an idea how the properties could work best.
> 
> >  
> >>> A very interesting question is when should link-status failure not drop
> >>> the current mode from the mode list, if other KMS properties affect the
> >>> bandwidth etc. requirements of the mode. That mechanism is engineered
> >>> for old userspace that doesn't actually handle link-status but does
> >>> handle hotplug, so the hotplug triggers re-fetching the mode list and
> >>> userspace maybe trying again with a better luck since the offending
> >>> mode is gone. How to keep that working when introducing KMS properties
> >>> forcing the cable format, I don't know.
> >>>
> >>> As long as the other affecting KMS properties are all "auto", the
> >>> driver will probably exhaust all possibilities to make the mode work
> >>> before signalling link-status failure and pruning the mode.
> >>> Theoretically, as I have no idea what drivers actually do.    
> >> Isn't that exactly how the "preferred color format" property works in
> >> my patchset now?  
> > There was an argument that "preferred" with no guarantees is not
> > useful enough. So I'm considering the force property instead.
> > The problem is, "auto" is not the only possible value.
> >
> > When the value is not "auto", should link failure drop the mode or not?
> > Userspace might change the value back to "auto" next time. If you
> > dropped the mode, it would be gone. If you didn't drop the mode,
> > userspace might be stuck picking the same non-working mode again and
> > again if it doesn't know about the force mode property.
> >
> > You could argue that changing the value back to "auto" needs to reset
> > the mode list, but that only gets us back to the "need to set
> > properties before getting mode list".
> >
> > Maybe there needs to be an assumption that if "force color format" is
> > not "auto", then link failure does not drop modes and userspace knows
> > to handle this. Messy.
> >
> > I'm afraid I just don't know to give any clear answer. It's also
> > possible that, as I'm not a kernel dev, I have some false assumptions
> > here.
> >
> >
> > Thanks,
> > pq
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx  


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

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
  2021-07-06  7:09                       ` Pekka Paalanen
@ 2021-07-14 17:59                         ` Werner Sembach
  0 siblings, 0 replies; 57+ messages in thread
From: Werner Sembach @ 2021-07-14 17:59 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

Am 06.07.21 um 09:09 schrieb Pekka Paalanen:
> On Mon, 5 Jul 2021 17:49:42 +0200
> Werner Sembach <wse@tuxedocomputers.com> wrote:
>
>> Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
>>> On Thu, 1 Jul 2021 14:50:13 +0200
>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>   
>>>> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
>>>>   
>>>>> On Wed, 30 Jun 2021 11:20:18 +0200
>>>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>>>     
>>>>>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>>>>>     
>>>>>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>>>>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>>>>>       
>>>>>>>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
>>>>>>>>> On Tue, 29 Jun 2021 08:12:54 +0000
>>>>>>>>> Simon Ser <contact@emersion.fr> wrote:
>>>>>>>>>          
>>>>>>>>>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>>>>>>>>>          
>>>>>>>>>>> yes, I think this makes sense, even if it is a property that one can't
>>>>>>>>>>> tell for sure what it does before hand.
>>>>>>>>>>>
>>>>>>>>>>> Using a pair of properties, preference and active, to ask for something
>>>>>>>>>>> and then check what actually worked is good for reducing the
>>>>>>>>>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>>>>>>>>>> test different KMS configurations. Userspace has a better chance of
>>>>>>>>>>> finding a configuration that is possible.
>>>>>>>>>>>
>>>>>>>>>>> OTOH, this has the problem than in UI one cannot tell the user in
>>>>>>>>>>> advance which options are truly possible. Given that KMS properties are
>>>>>>>>>>> rarely completely independent, and in this case known to depend on
>>>>>>>>>>> several other KMS properties, I think it is good enough to know after
>>>>>>>>>>> the fact.
>>>>>>>>>>>
>>>>>>>>>>> If a driver does not use what userspace prefers, there is no way to
>>>>>>>>>>> understand why, or what else to change to make it happen. That problem
>>>>>>>>>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>>>>>>>>>> but only a yes/no.
>>>>>>>>>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>>>>>>>>>> property at a time), user-space can discover which property makes the atomic
>>>>>>>>>> commit fail.
>>>>>>>>> That works if the properties are independent of each other. Color
>>>>>>>>> range, color format, bpc and more may all be interconnected,
>>>>>>>>> allowing only certain combinations to work.
>>>>>>>>>
>>>>>>>>> If all these properties have "auto" setting too, then it would be
>>>>>>>>> possible to probe each property individually, but that still does not
>>>>>>>>> tell which combinations are valid.
>>>>>>>>>
>>>>>>>>> If you probe towards a certain configuration by setting the properties
>>>>>>>>> one by one, then depending on the order you pick the properties, you
>>>>>>>>> may come to a different conclusion on which property breaks the
>>>>>>>>> configuration.
>>>>>>>> My mind crossed another point that must be considered: When plugin in
>>>>>>>> a Monitor a list of possible Resolutions+Framerate combinations is
>>>>>>>> created for xrandr and other userspace (I guess by atomic checks? but
>>>>>>>> I don't know).
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would not think so, but I hope to be corrected if I'm wrong.
>>>>>>>
>>>>>>> My belief is that the driver collects a list of modes from EDID, some
>>>>>>> standard modes, and maybe some other hardcoded modes, and then
>>>>>>> validates each entry against all the known limitations like vertical
>>>>>>> and horizontal frequency limits, discarding modes that do not fit.
>>>>>>>
>>>>>>> Not all limitations are known during that phase, which is why KMS
>>>>>>> property "link-status" exists. When userspace actually programs a mode
>>>>>>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
>>>>>>> the mode from the list and sets the link status property to signal
>>>>>>> failure, and sends a hotplug uevent. Userspace needs to re-check the
>>>>>>> mode list and try again.
>>>>>>>
>>>>>>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
>>>>>>> in reality the hardware cannot do it, you just cannot know until you
>>>>>>> actually try for real. It causes end user visible flicker if it happens
>>>>>>> on an already running connector, but since it usually happens when
>>>>>>> turning a connector on to begin with, there is no flicker to be seen,
>>>>>>> just a small delay in finding a mode that works.
>>>>>>>       
>>>>>>>> During this drm
>>>>>>>> properties are already considered, which is no problem atm because as
>>>>>>>> far as i can tell there is currently no drm property that would make
>>>>>>>> a certain Resolutions+Framerate combination unreachable that would be
>>>>>>>> possible with everything on default.
>>>>>>> I would not expect KMS properties to be considered at all. It would
>>>>>>> reject modes that are actually possible if the some KMS properties were
>>>>>>> changed. So at least going forward, current KMS property values cannot
>>>>>>> factor in.
>>>>>> At least the debugfs variable "force_yuv420_output" did change the
>>>>>> available modes here:
>>>>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165
>>>>>> before my patch
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf
>>>>> Hi,
>>>>>
>>>>> debugfs is not proper UAPI, so we can just ignore it. Display servers
>>>>> cannot be expected to poke in debugfs. Debugfs is not even supposed to
>>>>> exist in production systems, but I'm sure people use it for hacking
>>>>> stuff. But that's all it is for: developer testing and hacking.
>>>> e.g. Ubuntu has it active by default, but only read (and writable) by root.
>>> Hi,
>>>
>>> that's normal, yes. Root can do damage anyway, and it's useful for
>>> debugging. KMS clients OTOH often do not run as root.
>>>   
>>>>>     
>>>>>> Forcing a color format via a DRM property in this function would
>>>>>> reintroduce the problem.
>>>>> The property would need to be defined differently because its presence
>>>>> could otherwise break existing userspace. Well, I suppose it could
>>>>> break existing userspace no matter what, so we would need the generic
>>>>> "reset to sane defaults" mechanism first IMO.
>>>>>
>>>>> DRM has client caps for exposing video modes that old userspace might
>>>>> not expect, to avoid breaking old userspace. Care needs to be taken
>>>>> with all new UAPI, because if a kernel upgrade makes something wrong,
>>>>> it's the kernel's fault no matter what userspace is doing, in principle.
>>>> Can you give me a link describing how I define this caps?
>>> I don't have any, but you can find all the existing ones by grepping
>>> for DRM_CLIENT_CAP_.
>>>
>>> I'm not saying that we need it, but mentioning them as a possible
>>> workaround if userspace breakage seems imminent or is proven.
>>>   
>>>>> Debugfs has no problem breaking userspace AFAIU, since it's not proper
>>>>> UAPI.
>>>>>     
>>>>>> And I think i915 driver works similar in this regard.
>>>>>>     
>>>>>>>       
>>>>>>>> However for example forcing YCbCr420 encoding would limit the
>>>>>>>> available resolutions (my screen for example only supports YCbCr420
>>>>>>>> on 4k@60 and @50Hz and on no other resolution or frequency (native is
>>>>>>>> 2560x1440@144Hz).
>>>>>>>>
>>>>>>>> So would a "force color format" that does not get resetted on
>>>>>>>> repluging/reenabling a monitor break the output, for example, of an
>>>>>>>> not updated xrandr, unaware of this new property?
>>>>>>> Yes, not because the mode list would be missing the mode, but because
>>>>>>> actually setting the mode would fail.
>>>>>> Well, like described above, I think the mode would actually be missing,
>>>>>> which is also an unexpected behavior from a user perspective.
>>>>> I think that is not how the property should work.
>>>>>
>>>>> If KMS properties would affect the list of modes, then userspace would
>>>>> need to set the properties for real (TEST_ONLY cannot change anything)
>>>>> and re-fetch the mode lists (maybe there is a hotplug event, maybe
>>>>> not). That workflow just doesn't work.
>>>> The properties are set before the list is created in the first place.
>>>> Because, in my example, the properties get set before the monitor is
>>>> plugged in and the list can only be created as soon as the monitor is
>>>> plugged in.
>>> That's just an accident, it's not what I mean.
>>>
>>> What I mean is, we cannot have the KMS properties affect the list of
>>> modes, because then userspace that want to use specific values on those
>>> properties would have to program those properties first, and then get
>>> the list of modes. KMS UAPI does not work that way AFAIK.
>>>
>>> If the initial mode list is created on hotplug like you say, then the
>>> initial list could already be missing some modes that would be valid if
>>> some KMS properties had different values.
>> Depends if the mode list is created by TEST_ONLY:
> Hi,
>
> I'm pretty sure it's not created by any kind of atomic test probing,
> exactly because some properties might affect the result. Also because
> of legacy: the mode lists predate atomic by far. It just doesn't make
> sense to prune the mode list based on current arbitrary property values.

I implemented a buggy prototype for "force color format" and it doesn't 
make modes disappear as I feared.

It does successfully prevent setting a color format that is unsupported 
by the currently connected monitor.

However, if no monitor is connected and the property is set or the 
monitor is switched to another one that doesn't support currently the 
selected mode, the screen might stay black.

I don't think this should be the intended behavior, but the only 2 
sollutions i come up with violate the principle of not having a 
decentralized reset:

1. On monitor connect always reset the property to auto

     - alternatively: set on disconnect and don't allow to change 
without a connected monitor

2. On monitor connect, try the current setting and reset to auto if it 
fails (basically a one time "preferred color format" until the monitor 
capabilities are known).

>
> The function drm_helper_probe_single_connector_modes() looks relevant
> to me. It has a big comment that seems to point towards more things to
> look at.
>
>
> Thanks,
> pq
>
>> - The force properties should return false on TEST_ONLY
>>
>> - The force properties should not prevent the mode from showing up in the list
>>
>> If the list is created by TEST_ONLY both things can't be fulfilled at the same time obviously.
>>
>> I hope some can give more insights or has an idea how the properties could work best.
>>
>>>   
>>>>> A very interesting question is when should link-status failure not drop
>>>>> the current mode from the mode list, if other KMS properties affect the
>>>>> bandwidth etc. requirements of the mode. That mechanism is engineered
>>>>> for old userspace that doesn't actually handle link-status but does
>>>>> handle hotplug, so the hotplug triggers re-fetching the mode list and
>>>>> userspace maybe trying again with a better luck since the offending
>>>>> mode is gone. How to keep that working when introducing KMS properties
>>>>> forcing the cable format, I don't know.
>>>>>
>>>>> As long as the other affecting KMS properties are all "auto", the
>>>>> driver will probably exhaust all possibilities to make the mode work
>>>>> before signalling link-status failure and pruning the mode.
>>>>> Theoretically, as I have no idea what drivers actually do.
>>>> Isn't that exactly how the "preferred color format" property works in
>>>> my patchset now?
>>> There was an argument that "preferred" with no guarantees is not
>>> useful enough. So I'm considering the force property instead.
>>> The problem is, "auto" is not the only possible value.
>>>
>>> When the value is not "auto", should link failure drop the mode or not?
>>> Userspace might change the value back to "auto" next time. If you
>>> dropped the mode, it would be gone. If you didn't drop the mode,
>>> userspace might be stuck picking the same non-working mode again and
>>> again if it doesn't know about the force mode property.
>>>
>>> You could argue that changing the value back to "auto" needs to reset
>>> the mode list, but that only gets us back to the "need to set
>>> properties before getting mode list".
>>>
>>> Maybe there needs to be an assumption that if "force color format" is
>>> not "auto", then link failure does not drop modes and userspace knows
>>> to handle this. Messy.
>>>
>>> I'm afraid I just don't know to give any clear answer. It's also
>>> possible that, as I'm not a kernel dev, I have some false assumptions
>>> here.
>>>
>>>
>>> Thanks,
>>> pq
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-07-01 11:30             ` Werner Sembach
@ 2021-07-14 18:18               ` Werner Sembach
  2021-07-15  9:10                 ` Pekka Paalanen
  0 siblings, 1 reply; 57+ messages in thread
From: Werner Sembach @ 2021-07-14 18:18 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

Am 01.07.21 um 13:30 schrieb Werner Sembach:
> Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
>> On Wed, 30 Jun 2021 11:42:10 +0200
>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>
>>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
>>>> On Tue, 29 Jun 2021 13:02:05 +0200
>>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
>>>>   
>>>>> Am 28.06.21 um 19:03 schrieb Werner Sembach:
>>>>>> Am 18.06.21 um 11:11 schrieb Werner Sembach:
>>>>>>> Add a new general drm property "active bpc" which can be used by graphic
>>>>>>> drivers to report the applied bit depth per pixel back to userspace.
>>>>>>>
>>>>>>> While "max bpc" can be used to change the color depth, there was no way to
>>>>>>> check which one actually got used. While in theory the driver chooses the
>>>>>>> best/highest color depth within the max bpc setting a user might not be
>>>>>>> fully aware what his hardware is or isn't capable off. This is meant as a
>>>>>>> quick way to double check the setup.
>>>>>>>
>>>>>>> In the future, automatic color calibration for screens might also depend on
>>>>>>> this information being available.
>>>>>>>
>>>>>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>>>>>>> ---
>>>>>>>    drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
>>>>>>>    include/drm/drm_connector.h     |  8 ++++++
>>>>>>>    2 files changed, 59 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>>>>>> index da39e7ff6965..943f6b61053b 100644
>>>>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>>>>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>>>>>>     *	drm_connector_attach_max_bpc_property() to create and attach the
>>>>>>>     *	property to the connector during initialization.
>>>>>>>     *
>>>>>>> + * active bpc:
>>>>>>> + *	This read-only range property tells userspace the pixel color bit depth
>>>>>>> + *	actually used by the hardware display engine on "the cable" on a
>>>>>>> + *	connector. The chosen value depends on hardware capabilities, both
>>>>>>> + *	display engine and connected monitor, and the "max bpc" property.
>>>>>>> + *	Drivers shall use drm_connector_attach_active_bpc_property() to install
>>>>>>> + *	this property.
>>>>>>> + *
>>>>>> Regarding "on the cable" and dithering: As far as I can tell, what the dithering option does, is setting a hardware
>>>>>> register here:
>>>>>>
>>>>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>>>>>>
>>>>>> - https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>>>>>>
>>>>>> So dithering seems to be calculated by fixed purpose hardware/firmware outside of the driver?
>>>>>>
>>>>>> The Intel driver does not seem to set a target bpc/bpp for this hardware so I guess it defaults to 6 or 8 bpc?
>>>>> Never mind it does. This switch-case does affect the dithering output:
>>>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537
>>>> Hi,
>>>>
>>>> I obviously do not know the intel driver or hardware at all, but
>>>> to me that just looks like translating from bits per pixel to bits per
>>>> channel in RGB mapping?
>>> No, if i understand the documentation correctly: Writing bit depth here
>>> with dithering enabled sets the dithering target bpc.
>>>>   
>>>>> As found in this documentation p.548:
>>>>> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
>>>>>
>>>>> So max bpc and active bpc are affecting/affected by the bpc after dithering.
>>>> By definition, if the cable carries N bpc, then dithering does not
>>>> change that. The cable still carries N bpc, but due to spatial or
>>>> temporal dithering, the *observed* color resolution may or may not be
>>>> higher than the cable bpc.
>>> Yes, and max bpc and active bpc tell the cable bpc ist not the
>>> *observed* bpc.
>>>> Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
>>>> LSB on the cable are always zero, right?
>>> I would assume that in this case only 6 bpc are actually send? Isn't the
>>> whole thing of dithering that you can't send, for example, 8 bpc?
>>>> Maybe one would want to do that if the monitor has a 6 bit panel and it
>>>> simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.
>>> Is there dithering actually doing this? aka is my assumption above wrong?
>>>
>>> AMD code that confused me before, is hinting that you might be right:
>>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826
>>>
>>> there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP
>>>
>>>> So, what does "max bpc" mean right now?
>>>>
>>>> It seems like dither on/off is insufficient information, one would also
>>>> need to control the dithering target bpc. I suppose the driver has a
>>>> policy on how it chooses the target bpc, but what is that policy? Is
>>>> the dither target bpc the cable bpc or the sink bpc?
>>>>
>>>> Needless to say, I'm quite confused.
>>> ... We need someone who knows what dithering on intel and amd gpu
>>> actually means.
>>>
>>> But I don't want this to become a blocker for this patchset, because if
>>> there is no dithering, which seems to be the norm, the active bpc
>>> property is already really usefull as it is. So add a note to the docs
>>> that the value might be invalid when dithering is active for now?
>> Hi,
>>
>> not necessarily invalid. It all depends on how "max bpc" and "active
>> bpc" are defined.
>>
>> If they are defined and implemented as "on the cable", then they are
>> both well-defined and always valid, regardless of what dithering or bit
>> clamping does, so this is the semantics I'd would prefer. It's clear,
>> but of course does not tell full story.
>>
>> When better properties for dithering are added, those can then define
>> how it works on top of cable bpc, with no impact on "max bpc" or
>> "active bpc" properties.
>>
>> So if we cannot tell what "max bpc" is, then "active bpc" should just
>> be defined as the same thing as "max bpc" affects, and leave the
>> precise definition of both for later.
> But as long as I don't know exactly how dithering is affected by max bpc I can't tell for sure if active bpc is acting
> the same. That's why I wrote it is "undefined" to not run into a trap where the actual behavior have to change after the
> fact.
>> If the definition was observed bpc, then we would have problems and
>> would need to know everything right now. But you can't really make
>> promises of observed bpc anyway, because you don't know what the
>> monitor does to the video signal I suppose. Unless you define it "as if
>> observed through an ideal theoretical monitor" which then gets awkward
>> to explain.
> Yes, that's why I think describing the "raw" signal is the best and leave it to the user to know what his or her Monitor
> is making out of it.
>>
>> Thanks,
>> pq
New idea: Instead of the "active"-properties with various if cases in 
the kernel code, there could just be blob properties exposing the hdmi 
infoframes, hdmi general control packages, dp misc0 and misc1 and dp vsc 
sdp.

Combined they have all the color information and it is made sure that 
it's what is actually send to the monitor (I would consider sending 
something differed then what is told in the infoframes a bug).

They also have built in version numbers, if in the future they contain 
more information.

Only disadvantage: We leave parsing for human readable output to the 
userspace.

Alternatively keep the "active"-properties but fill them from the 
infoframes.

I'm not entirely sure where to do that on amd, because there the 
infoframes are directly created in the dc code shortly before writing 
them to the hardware registers and immediately forgotten afterwards. But 
you still have access to the connector struct from that code so the 
property could be updated directly there.


^ permalink raw reply	[flat|nested] 57+ messages in thread

* Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
  2021-07-14 18:18               ` Werner Sembach
@ 2021-07-15  9:10                 ` Pekka Paalanen
  0 siblings, 0 replies; 57+ messages in thread
From: Pekka Paalanen @ 2021-07-15  9:10 UTC (permalink / raw)
  To: Werner Sembach
  Cc: sunpeng.li, intel-gfx, linux-kernel, dri-devel, airlied, amd-gfx,
	tzimmermann, rodrigo.vivi, alexander.deucher, christian.koenig

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

On Wed, 14 Jul 2021 20:18:57 +0200
Werner Sembach <wse@tuxedocomputers.com> wrote:

> Am 01.07.21 um 13:30 schrieb Werner Sembach:
> > Am 01.07.21 um 09:42 schrieb Pekka Paalanen:  
> >> On Wed, 30 Jun 2021 11:42:10 +0200
> >> Werner Sembach <wse@tuxedocomputers.com> wrote:
> >>  
> >>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:  
> >>>> On Tue, 29 Jun 2021 13:02:05 +0200
> >>>> Werner Sembach <wse@tuxedocomputers.com> wrote:
> >>>>     
> >>>>> Am 28.06.21 um 19:03 schrieb Werner Sembach:  
> >>>>>> Am 18.06.21 um 11:11 schrieb Werner Sembach:  
> >>>>>>> Add a new general drm property "active bpc" which can be used by graphic
> >>>>>>> drivers to report the applied bit depth per pixel back to userspace.
> >>>>>>>
> >>>>>>> While "max bpc" can be used to change the color depth, there was no way to
> >>>>>>> check which one actually got used. While in theory the driver chooses the
> >>>>>>> best/highest color depth within the max bpc setting a user might not be
> >>>>>>> fully aware what his hardware is or isn't capable off. This is meant as a
> >>>>>>> quick way to double check the setup.
> >>>>>>>
> >>>>>>> In the future, automatic color calibration for screens might also depend on
> >>>>>>> this information being available.
> >>>>>>>
> >>>>>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> >>>>>>> ---
> >>>>>>>    drivers/gpu/drm/drm_connector.c | 51 +++++++++++++++++++++++++++++++++
> >>>>>>>    include/drm/drm_connector.h     |  8 ++++++
> >>>>>>>    2 files changed, 59 insertions(+)

> New idea: Instead of the "active"-properties with various if cases in 
> the kernel code, there could just be blob properties exposing the hdmi 
> infoframes, hdmi general control packages, dp misc0 and misc1 and dp vsc 
> sdp.
> 
> Combined they have all the color information and it is made sure that 
> it's what is actually send to the monitor (I would consider sending 
> something differed then what is told in the infoframes a bug).
> 
> They also have built in version numbers, if in the future they contain 
> more information.
> 
> Only disadvantage: We leave parsing for human readable output to the 
> userspace.
> 
> Alternatively keep the "active"-properties but fill them from the 
> infoframes.
> 
> I'm not entirely sure where to do that on amd, because there the 
> infoframes are directly created in the dc code shortly before writing 
> them to the hardware registers and immediately forgotten afterwards. But 
> you still have access to the connector struct from that code so the 
> property could be updated directly there.
> 

Hi,

I'm not fundamentally against that as long as we have a common
userspace library to parse those blobs. In libdrm perhaps? Or a new
library?

But I also don't know about the technical feasibility, is it a good
idea.

OTOH, that could be the best thing for testing drivers vs. KMS UAPI
when you don't have a hardware HDMI/DP grabber to inspect the
infoframes. So maybe kernel CI would like that?


Thanks,
pq

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

^ permalink raw reply	[flat|nested] 57+ messages in thread

end of thread, other threads:[~2021-07-15  9:10 UTC | newest]

Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-18  9:10 [PATCH v4 00/17] New uAPI drm properties for color management Werner Sembach
2021-06-18  9:11 ` [PATCH v4 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Werner Sembach
2021-06-18  9:11 ` [PATCH v4 02/17] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc Werner Sembach
2021-06-18  9:11 ` [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property Werner Sembach
2021-06-22  6:46   ` Pekka Paalanen
2021-06-28 17:03   ` Werner Sembach
2021-06-29 11:02     ` Werner Sembach
2021-06-30  8:21       ` Pekka Paalanen
2021-06-30  9:42         ` Werner Sembach
2021-07-01  7:42           ` Pekka Paalanen
2021-07-01 11:30             ` Werner Sembach
2021-07-14 18:18               ` Werner Sembach
2021-07-15  9:10                 ` Pekka Paalanen
2021-06-18  9:11 ` [PATCH v4 04/17] drm/amd/display: Add handling for new "active bpc" property Werner Sembach
2021-06-18  9:11 ` [PATCH v4 05/17] drm/i915/display: " Werner Sembach
2021-06-18  9:11 ` [PATCH v4 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace Werner Sembach
2021-06-22  6:48   ` Pekka Paalanen
2021-06-18  9:11 ` [PATCH v4 07/17] drm/amd/display: Add handling for new "active color format" property Werner Sembach
2021-06-18  9:11 ` [PATCH v4 08/17] drm/i915/display: " Werner Sembach
2021-06-18  9:11 ` [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace Werner Sembach
2021-06-22  7:00   ` Pekka Paalanen
2021-06-22  9:50     ` Werner Sembach
2021-06-22 11:48       ` Simon Ser
2021-06-23  7:32         ` Pekka Paalanen
2021-06-23 10:17           ` Werner Sembach
2021-06-23 11:14             ` Pekka Paalanen
2021-06-23 11:19               ` Werner Sembach
2021-06-18  9:11 ` [PATCH v4 10/17] drm/amd/display: Add handling for new "active color range" property Werner Sembach
2021-06-18  9:11 ` [PATCH v4 11/17] drm/i915/display: " Werner Sembach
2021-06-18  9:11 ` [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace Werner Sembach
2021-06-22  7:15   ` Pekka Paalanen
2021-06-29  8:12     ` Simon Ser
2021-06-29 11:17       ` Pekka Paalanen
2021-06-29 11:39         ` Werner Sembach
2021-06-30  8:41           ` Pekka Paalanen
2021-06-30  9:20             ` Werner Sembach
2021-07-01  8:07               ` Pekka Paalanen
2021-07-01 12:50                 ` Werner Sembach
2021-07-01 13:24                   ` Pekka Paalanen
2021-07-05 15:49                     ` Werner Sembach
2021-07-06  7:09                       ` Pekka Paalanen
2021-07-14 17:59                         ` Werner Sembach
2021-06-18  9:11 ` [PATCH v4 13/17] drm/amd/display: Add handling for new "preferred color format" property Werner Sembach
2021-06-18  9:11 ` [PATCH v4 14/17] drm/i915/display: " Werner Sembach
2021-06-18  9:11 ` [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context Werner Sembach
2021-06-22  7:25   ` Pekka Paalanen
2021-06-22  9:57     ` Werner Sembach
2021-06-23  7:48       ` Pekka Paalanen
2021-06-23 10:10         ` Werner Sembach
2021-06-23 11:26           ` Pekka Paalanen
2021-06-25  8:48             ` Werner Sembach
2021-06-18  9:11 ` [PATCH v4 16/17] drm/i915/display: Use the general "Broadcast RGB" implementation Werner Sembach
2021-06-18  9:11 ` [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property Werner Sembach
2021-06-22  7:29   ` Pekka Paalanen
2021-06-22  9:28     ` Werner Sembach
2021-06-23  8:01       ` Pekka Paalanen
2021-06-23  9:58         ` Werner Sembach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).