[PATCH v3 00/17] Enable Colorspace connector property in amdgpu

[PATCH v3 00/17] Enable Colorspace connector property in amdgpu

[Harry Wentland]

This patchset is based on Joshua's previous patchset [1], as well
as my previous patchset [2].

It is
- enabling support for the colorspace property in amdgpu, as well as
- allowing drivers to specify the supported set of colorspaces, and
- deprecating the BT2020_YCC and BT2020_RGB properties in favor of
  a common BT2020 property. We leave the BT2020_CYCC property untouched
  for now, same as the other _YVV properties. If they'll see use later
  we might need to do something similar there, or allow userspace to
  decide on the output encoding (RGB vs YUV).

Colorspace, Infoframes, and YCbCr matrix
---------------------------------------

Even though the initial intent of the colorspace property was to set the
colorspace field in the respective HDMI AVI and DP SDP infoframes that
is not sufficient in all scenarios. For DP the colorspace information
also affects the MSA (main stream attribute) packet. For YUV output the
colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace
field of the infopackets also depends on the encoding used, which is
something that is decided by the driver and not known to userspace.

For these reasons a driver will need to be able to select the supported
colorspaces at property creation.

Note: There seems to be an understanding that the colorspace property
should ONLY modify the infoframe. While this is current behavior and
sufficient in some cases it is nowhere specified that this should be the
only use of this property. As outlined above this limitation is not
going to work in all cases.

This patchset does not affect current behavior for the drivers that
implement this property: i915 and vc4.

In the future we might want to give userspace control over the encoding
format on the wire, in particular to avoid use of YUV420 when image
fidelity is important. This work would likely go hand in hand with a
min_bpc property and wouldn't conflict with the work done in this
patchset.

Colorspace on crtc or connector?
--------------------------------

There have been suggestions of programming 'colorspace' on the drm_crtc
but I don't think the crtc is the right place for this property. The
drm_plane and drm_crtc will be used to offload color processing that
would normally be done via the GFX or other pipelines. The drm_connector
controls the signalling with the display and ensures the wire format is
appropriate for the encoding by programming the RGB-to-YCbCr matrix.

[1] https://patchwork.freedesktop.org/series/113632/
[2] https://patchwork.freedesktop.org/series/111865/

v2:
- Tested with DP and HDMI analyzers
- Confirmed driver will fallback to lower bpc when needed
- Dropped hunk to set HDMI AVI infoframe as it was a no-op
- Fixed BT.2020 YCbCr colorimetry (JoshuaAshton)
- Simplify initialization of supported colorspaces (Jani)
- Fix kerneldoc (kernel test robot)

v3:
- Added documentation for colorspaces (Pekka, Joshua)
- Split 'Allow drivers to pass list of supported colorspaces' patch
  to pull out code to create common colorspace array and keep it separate
  from change to create only supported colorspaces

Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Michel Dänzer <michel.daenzer@mailbox.org>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org

Harry Wentland (12):
  drm/connector: Convert DRM_MODE_COLORIMETRY to enum
  drm/connector: Pull out common create_colorspace_property code
  drm/connector: Use common colorspace_names array
  drm/connector: Print connector colorspace in state debugfs
  drm/connector: Allow drivers to pass list of supported colorspaces
  drm/amd/display: Always pass connector_state to stream validation
  drm/amd/display: Register Colorspace property for DP and HDMI
  drm/amd/display: Signal mode_changed if colorspace changed
  drm/amd/display: Send correct DP colorspace infopacket
  drm/amd/display: Add support for explicit BT601_YCC
  drm/amd/display: Add debugfs for testing output colorspace
  drm/amd/display: Add default case for output_color_space switch

Joshua Ashton (5):
  drm/connector: Add enum documentation to drm_colorspace
  drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
  drm/amd/display: Always set crtcinfo from create_stream_for_sink
  drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not
    RGB
  drm/amd/display: Refactor avi_info_frame colorimetry determination

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  84 +++++---
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |  57 ++++++
 .../gpu/drm/amd/display/dc/core/dc_resource.c |  28 +--
 drivers/gpu/drm/display/drm_hdmi_helper.c     |   7 +-
 drivers/gpu/drm/drm_atomic.c                  |   1 +
 drivers/gpu/drm/drm_connector.c               | 182 +++++++++++-------
 .../gpu/drm/i915/display/intel_connector.c    |   4 +-
 drivers/gpu/drm/i915/display/intel_dp.c       |  14 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c                |   2 +-
 include/drm/display/drm_dp.h                  |   2 +-
 include/drm/drm_connector.h                   | 128 +++++++++---
 11 files changed, 363 insertions(+), 146 deletions(-)

--
2.39.2

[PATCH v3 01/17] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

[Harry Wentland]

This allows us to use strongly typed arguments.

v2:
 - Bring NO_DATA back
 - Provide explicit enum values

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Simon Ser <contact@emersion.fr>

Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
---
 include/drm/display/drm_dp.h |  2 +-
 include/drm/drm_connector.h  | 49 ++++++++++++++++++------------------
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index ed10e6b6f99d..28899a03245c 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1623,7 +1623,7 @@ enum dp_pixelformat {
  *
  * This enum is used to indicate DP VSC SDP Colorimetry formats.
  * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
- * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
+ * DB18] and a name of enum member follows &enum drm_colorimetry definition.
  *
  * @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
  *                          ITU-R BT.601 colorimetry format
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4d830fc55a3d..6d6a53a6b010 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -371,29 +371,30 @@ enum drm_privacy_screen_status {
  * a colorspace property which will be created and exposed to
  * userspace.
  */
-
-/* For Default case, driver will set the colorspace */
-#define DRM_MODE_COLORIMETRY_DEFAULT			0
-/* CEA 861 Normal Colorimetry options */
-#define DRM_MODE_COLORIMETRY_NO_DATA			0
-#define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC		1
-#define DRM_MODE_COLORIMETRY_BT709_YCC			2
-/* CEA 861 Extended Colorimetry Options */
-#define DRM_MODE_COLORIMETRY_XVYCC_601			3
-#define DRM_MODE_COLORIMETRY_XVYCC_709			4
-#define DRM_MODE_COLORIMETRY_SYCC_601			5
-#define DRM_MODE_COLORIMETRY_OPYCC_601			6
-#define DRM_MODE_COLORIMETRY_OPRGB			7
-#define DRM_MODE_COLORIMETRY_BT2020_CYCC		8
-#define DRM_MODE_COLORIMETRY_BT2020_RGB			9
-#define DRM_MODE_COLORIMETRY_BT2020_YCC			10
-/* Additional Colorimetry extension added as part of CTA 861.G */
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65		11
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER		12
-/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED		13
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT		14
-#define DRM_MODE_COLORIMETRY_BT601_YCC			15
+enum drm_colorspace {
+	/* For Default case, driver will set the colorspace */
+	DRM_MODE_COLORIMETRY_DEFAULT 		= 0,
+	DRM_MODE_COLORIMETRY_NO_DATA		= 0,
+	/* CEA 861 Normal Colorimetry options */
+	DRM_MODE_COLORIMETRY_SMPTE_170M_YCC	= 1,
+	DRM_MODE_COLORIMETRY_BT709_YCC		= 2,
+	/* CEA 861 Extended Colorimetry Options */
+	DRM_MODE_COLORIMETRY_XVYCC_601		= 3,
+	DRM_MODE_COLORIMETRY_XVYCC_709		= 4,
+	DRM_MODE_COLORIMETRY_SYCC_601		= 5,
+	DRM_MODE_COLORIMETRY_OPYCC_601		= 6,
+	DRM_MODE_COLORIMETRY_OPRGB		= 7,
+	DRM_MODE_COLORIMETRY_BT2020_CYCC	= 8,
+	DRM_MODE_COLORIMETRY_BT2020_RGB		= 9,
+	DRM_MODE_COLORIMETRY_BT2020_YCC		= 10,
+	/* Additional Colorimetry extension added as part of CTA 861.G */
+	DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65	= 11,
+	DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER	= 12,
+	/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
+	DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED	= 13,
+	DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT	= 14,
+	DRM_MODE_COLORIMETRY_BT601_YCC		= 15,
+};
 
 /**
  * enum drm_bus_flags - bus_flags info for &drm_display_info
@@ -826,7 +827,7 @@ struct drm_connector_state {
 	 * colorspace change on Sink. This is most commonly used to switch
 	 * to wider color gamuts like BT2020.
 	 */
-	u32 colorspace;
+	enum drm_colorspace colorspace;
 
 	/**
 	 * @writeback_job: Writeback job for writeback connectors
-- 
2.39.2

[PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

[Harry Wentland]

From: Joshua Ashton <joshua@froggi.es>

To match the other enums, and add more information about these values.

v2:
 - Specify where an enum entry comes from
 - Clarify DEFAULT and NO_DATA behavior
 - BT.2020 CYCC is "constant luminance"
 - correct type for BT.601

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>

Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
---
 include/drm/drm_connector.h | 67 +++++++++++++++++++++++++++++++++++--
 1 file changed, 65 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 6d6a53a6b010..bb078666dc34 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
 	PRIVACY_SCREEN_ENABLED_LOCKED,
 };
 
-/*
- * This is a consolidated colorimetry list supported by HDMI and
+/**
+ * enum drm_colorspace - color space
+ *
+ * This enum is a consolidated colorimetry list supported by HDMI and
  * DP protocol standard. The respective connectors will register
  * a property with the subset of this list (supported by that
  * respective protocol). Userspace will set the colorspace through
  * a colorspace property which will be created and exposed to
  * userspace.
+ *
+ * DP definitions come from the DP v2.0 spec
+ * HDMI definitions come from the CTA-861-H spec
+ *
+ * @DRM_MODE_COLORIMETRY_DEFAULT:
+ *   Driver specific behavior.
+ *   For DP:
+ *   	RGB encoded: sRGB (IEC 61966-2-1)
+ *   	YCbCr encoded: ITU-R BT.601 colorimetry format
+ * @DRM_MODE_COLORIMETRY_NO_DATA:
+ *   Driver specific behavior.
+ *   For HDMI:
+ * 	Sets "No Data" in infoframe
+ * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
+ *   (HDMI)
+ *   SMPTE ST 170M colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT709_YCC:
+ *   (HDMI, DP)
+ *   ITU-R BT.709 colorimetry format
+ * @DRM_MODE_COLORIMETRY_XVYCC_601:
+ *   (HDMI, DP)
+ *   xvYCC601 colorimetry format
+ * @DRM_MODE_COLORIMETRY_XVYCC_709:
+ *   (HDMI, DP)
+ *   xvYCC709 colorimetry format
+ * @DRM_MODE_COLORIMETRY_SYCC_601:
+ *   (HDMI, DP)
+ *   sYCC601 colorimetry format
+ * @DRM_MODE_COLORIMETRY_OPYCC_601:
+ *   (HDMI, DP)
+ *   opYCC601 colorimetry format
+ * @DRM_MODE_COLORIMETRY_OPRGB:
+ *   (HDMI, DP)
+ *   opRGB colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ *   (HDMI, DP)
+ *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT2020_RGB:
+ *   (HDMI, DP)
+ *   ITU-R BT.2020 R' G' B' colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT2020_YCC:
+ *   (HDMI, DP)
+ *   ITU-R BT.2020 Y' C'b C'r colorimetry format
+ * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
+ *   (HDMI)
+ *   SMPTE ST 2113 P3D65 colorimetry format
+ * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
+ *   (HDMI)
+ *   SMPTE ST 2113 P3DCI colorimetry format
+ * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
+ *   (DP)
+ *   RGB wide gamut fixed point colorimetry format
+ * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
+ *   (DP)
+ *   RGB wide gamut floating point
+ *   (scRGB (IEC 61966-2-2)) colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT601_YCC:
+ *   (DP)
+ *   ITU-R BT.601 colorimetry format
+ *   The DP spec does not say whether this is the 525 or the 625
+ *   line version.
  */
 enum drm_colorspace {
 	/* For Default case, driver will set the colorspace */
-- 
2.39.2

[PATCH v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Harry Wentland]

From: Joshua Ashton <joshua@froggi.es>

Userspace has no way of controlling or knowing the pixel encoding
currently, so there is no way for it to ever get the right values here.

When we do add pixel_encoding control from userspace,we can pick the
right value for the colorimetry packet based on the
pixel_encoding + the colorspace.

Let's deprecate these values, and have one BT.2020 colorspace entry
that userspace can use.

v2:
 - leave CYCC alone for now; it serves a purpose
 - leave BT2020_RGB the new default BT2020

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>

Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/display/drm_hdmi_helper.c |  7 +++----
 drivers/gpu/drm/drm_connector.c           |  8 ++++----
 drivers/gpu/drm/i915/display/intel_dp.c   | 14 +++++++-------
 include/drm/drm_connector.h               | 15 +++++++++------
 4 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c b/drivers/gpu/drm/display/drm_hdmi_helper.c
index faf5e9efa7d3..05a0d03ffcda 100644
--- a/drivers/gpu/drm/display/drm_hdmi_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
@@ -97,8 +97,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
 #define HDMI_COLORIMETRY_OPYCC_601		(C(3) | EC(3) | ACE(0))
 #define HDMI_COLORIMETRY_OPRGB			(C(3) | EC(4) | ACE(0))
 #define HDMI_COLORIMETRY_BT2020_CYCC		(C(3) | EC(5) | ACE(0))
-#define HDMI_COLORIMETRY_BT2020_RGB		(C(3) | EC(6) | ACE(0))
-#define HDMI_COLORIMETRY_BT2020_YCC		(C(3) | EC(6) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020			(C(3) | EC(6) | ACE(0))
 #define HDMI_COLORIMETRY_DCI_P3_RGB_D65		(C(3) | EC(7) | ACE(0))
 #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER	(C(3) | EC(7) | ACE(1))
 
@@ -112,8 +111,8 @@ static const u32 hdmi_colorimetry_val[] = {
 	[DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
 	[DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
 	[DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
-	[DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
-	[DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
+	[DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = HDMI_COLORIMETRY_BT2020,
+	[DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
 };
 
 #undef C
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 61c29ce74b03..fe7eab15f727 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1031,9 +1031,9 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
 	/* Colorimetry based on ITU-R BT.2020 */
 	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
 	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
 	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
 	/* Added as part of Additional Colorimetry Extension in 861.G */
 	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
 	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
@@ -1054,7 +1054,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
 	/* Colorimetry based on SMPTE RP 431-2 */
 	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
 	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
 	{ DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
 	{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
 	/* Standard Definition Colorimetry based on IEC 61966-2-4 */
@@ -1068,7 +1068,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
 	/* Colorimetry based on ITU-R BT.2020 */
 	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
 	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index c9be61d2348e..be100a193bf5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1766,11 +1766,11 @@ static void intel_dp_compute_vsc_colorimetry(const struct intel_crtc_state *crtc
 	case DRM_MODE_COLORIMETRY_BT2020_CYCC:
 		vsc->colorimetry = DP_COLORIMETRY_BT2020_CYCC;
 		break;
-	case DRM_MODE_COLORIMETRY_BT2020_RGB:
-		vsc->colorimetry = DP_COLORIMETRY_BT2020_RGB;
-		break;
-	case DRM_MODE_COLORIMETRY_BT2020_YCC:
-		vsc->colorimetry = DP_COLORIMETRY_BT2020_YCC;
+	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
+	case DRM_MODE_COLORIMETRY_BT2020:
+		vsc->colorimetry = vsc->pixelformat == DP_PIXELFORMAT_RGB
+			? DP_COLORIMETRY_BT2020_RGB
+			: DP_COLORIMETRY_BT2020_YCC;
 		break;
 	case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
 	case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
@@ -3043,9 +3043,9 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
 	switch (conn_state->colorspace) {
 	case DRM_MODE_COLORIMETRY_SYCC_601:
 	case DRM_MODE_COLORIMETRY_OPYCC_601:
-	case DRM_MODE_COLORIMETRY_BT2020_YCC:
-	case DRM_MODE_COLORIMETRY_BT2020_RGB:
 	case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
+	case DRM_MODE_COLORIMETRY_BT2020:
 		return true;
 	default:
 		break;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index bb078666dc34..3e2e1bc7aa04 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -409,12 +409,15 @@ enum drm_privacy_screen_status {
  * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
  *   (HDMI, DP)
  *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
- * @DRM_MODE_COLORIMETRY_BT2020_RGB:
+ * @DRM_MODE_COLORIMETRY_BT2020:
  *   (HDMI, DP)
- *   ITU-R BT.2020 R' G' B' colorimetry format
- * @DRM_MODE_COLORIMETRY_BT2020_YCC:
+ *   ITU-R BT.2020 [R' G' B'] or
+ * 	 ITU-R BT.2020 [Y' C'b C'r] or
+ *   ITU-R BT.2020 [Y'c C'bc C'rc] (linear)
+ *   colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
  *   (HDMI, DP)
- *   ITU-R BT.2020 Y' C'b C'r colorimetry format
+ *   deprecated; same as DRM_MODE_COLORIMETRY_BT2020
  * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
  *   (HDMI)
  *   SMPTE ST 2113 P3D65 colorimetry format
@@ -448,8 +451,8 @@ enum drm_colorspace {
 	DRM_MODE_COLORIMETRY_OPYCC_601		= 6,
 	DRM_MODE_COLORIMETRY_OPRGB		= 7,
 	DRM_MODE_COLORIMETRY_BT2020_CYCC	= 8,
-	DRM_MODE_COLORIMETRY_BT2020_RGB		= 9,
-	DRM_MODE_COLORIMETRY_BT2020_YCC		= 10,
+	DRM_MODE_COLORIMETRY_BT2020		= 9,
+	DRM_MODE_COLORIMETRY_BT2020_DEPRECATED	= 10,
 	/* Additional Colorimetry extension added as part of CTA 861.G */
 	DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65	= 11,
 	DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER	= 12,
-- 
2.39.2

[PATCH v3 04/17] drm/connector: Pull out common create_colorspace_property code

[Harry Wentland]

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 drivers/gpu/drm/drm_connector.c | 54 ++++++++++++++++-----------------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index fe7eab15f727..ff4af48c029a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1971,33 +1971,44 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
  * drm_mode_create_dp_colorspace_property() is used for DP connector.
  */
 
-/**
- * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
- * @connector: connector to create the Colorspace property on.
- *
- * Called by a driver the first time it's needed, must be attached to desired
- * HDMI connectors.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+static int drm_mode_create_colorspace_property(struct drm_connector *connector,
+					const struct drm_prop_enum_list *colorspaces,
+					int size)
 {
 	struct drm_device *dev = connector->dev;
 
 	if (connector->colorspace_property)
 		return 0;
 
+	if (!colorspaces)
+		return 0;
+
 	connector->colorspace_property =
 		drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-					 hdmi_colorspaces,
-					 ARRAY_SIZE(hdmi_colorspaces));
+					colorspaces,
+					size);
 
 	if (!connector->colorspace_property)
 		return -ENOMEM;
 
 	return 0;
 }
+/**
+ * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * HDMI connectors.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+{
+	return drm_mode_create_colorspace_property(connector,
+						   hdmi_colorspaces,
+						   ARRAY_SIZE(hdmi_colorspaces));
+}
 EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
 
 /**
@@ -2012,20 +2023,9 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
  */
 int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
 {
-	struct drm_device *dev = connector->dev;
-
-	if (connector->colorspace_property)
-		return 0;
-
-	connector->colorspace_property =
-		drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-					 dp_colorspaces,
-					 ARRAY_SIZE(dp_colorspaces));
-
-	if (!connector->colorspace_property)
-		return -ENOMEM;
-
-	return 0;
+	return drm_mode_create_colorspace_property(connector,
+						   dp_colorspaces,
+						   ARRAY_SIZE(dp_colorspaces));
 }
 EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
 
-- 
2.39.2

[PATCH v3 05/17] drm/connector: Use common colorspace_names array

[Harry Wentland]

We an use bitfields to track the support ones for HDMI
and DP. This allows us to print colorspaces in a consistent
manner without needing to know whether we're dealing with
DP or HDMI.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/drm_connector.c | 131 +++++++++++++++++++-------------
 include/drm/drm_connector.h     |   1 +
 2 files changed, 78 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ff4af48c029a..7649f0ac454f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1012,64 +1012,70 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 		 drm_dp_subconnector_enum_list)
 
-static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+
+static const char * const colorspace_names[] = {
 	/* For Default case, driver will set the colorspace */
-	{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+	[DRM_MODE_COLORIMETRY_DEFAULT] = "Default",
 	/* Standard Definition Colorimetry based on CEA 861 */
-	{ DRM_MODE_COLORIMETRY_SMPTE_170M_YCC, "SMPTE_170M_YCC" },
-	{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+	[DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = "SMPTE_170M_YCC",
+	[DRM_MODE_COLORIMETRY_BT709_YCC] = "BT709_YCC",
 	/* Standard Definition Colorimetry based on IEC 61966-2-4 */
-	{ DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+	[DRM_MODE_COLORIMETRY_XVYCC_601] = "XVYCC_601",
 	/* High Definition Colorimetry based on IEC 61966-2-4 */
-	{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+	[DRM_MODE_COLORIMETRY_XVYCC_709] = "XVYCC_709",
 	/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
-	{ DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
+	[DRM_MODE_COLORIMETRY_SYCC_601] = "SYCC_601",
 	/* Colorimetry based on IEC 61966-2-5 [33] */
-	{ DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+	[DRM_MODE_COLORIMETRY_OPYCC_601] = "opYCC_601",
 	/* Colorimetry based on IEC 61966-2-5 */
-	{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+	[DRM_MODE_COLORIMETRY_OPRGB] = "opRGB",
 	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+	[DRM_MODE_COLORIMETRY_BT2020_CYCC] = "BT2020_CYCC",
 	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
+	[DRM_MODE_COLORIMETRY_BT2020] = "BT2020",
 	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
-	/* Added as part of Additional Colorimetry Extension in 861.G */
-	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
-	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
+	[DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = "BT2020_DEPRECATED",
+	/* Colorimetry based on SMPTE RP 431-2 */
+	[DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65] = "P3_RGB_D65",
+	[DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER] = "P3_RGB_Theater",
+	[DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED] = "RGB_WIDE_FIXED",
+	/* Colorimetry based on scRGB (IEC 61966-2-2) */
+	[DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT] = "RGB_WIDE_FLOAT",
+	[DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
 };
 
+static const u32 hdmi_colorspaces =
+	BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
+	BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+	BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
+	BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
+	BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
+	BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
+	BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED) |
+	BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
+	BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+
 /*
  * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
  * Format Table 2-120
  */
-static const struct drm_prop_enum_list dp_colorspaces[] = {
-	/* For Default case, driver will set the colorspace */
-	{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
-	{ DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
-	/* Colorimetry based on scRGB (IEC 61966-2-2) */
-	{ DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point" },
-	/* Colorimetry based on IEC 61966-2-5 */
-	{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
-	/* Colorimetry based on SMPTE RP 431-2 */
-	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
-	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
-	{ DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
-	{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
-	/* Standard Definition Colorimetry based on IEC 61966-2-4 */
-	{ DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
-	/* High Definition Colorimetry based on IEC 61966-2-4 */
-	{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
-	/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
-	{ DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
-	/* Colorimetry based on IEC 61966-2-5 [33] */
-	{ DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
-	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
-	/* Colorimetry based on ITU-R BT.2020 */
-	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
-};
+static const u32 dp_colorspaces =
+	BIT(DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED) |
+	BIT(DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT) |
+	BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+	BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020) |
+	BIT(DRM_MODE_COLORIMETRY_BT601_YCC) |
+	BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+	BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
+	BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
+	BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
+	BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
 
 /**
  * DOC: standard connector properties
@@ -1972,30 +1978,49 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
  */
 
 static int drm_mode_create_colorspace_property(struct drm_connector *connector,
-					const struct drm_prop_enum_list *colorspaces,
-					int size)
+					u32 supported_colorspaces)
 {
 	struct drm_device *dev = connector->dev;
+	u32 colorspaces = supported_colorspaces | BIT(DRM_MODE_COLORIMETRY_DEFAULT);
+	struct drm_prop_enum_list enum_list[DRM_MODE_COLORIMETRY_MAX];
+	int i, len;
 
 	if (connector->colorspace_property)
 		return 0;
 
-	if (!colorspaces)
-		return 0;
+	if (!supported_colorspaces)
+		drm_dbg_kms(dev, "Driver is not passing supported colorspaces on [CONNECTOR:%d:%s]\n",
+			    connector->base.id, connector->name);
+
+	if ((supported_colorspaces & -BIT(DRM_MODE_COLORIMETRY_MAX)) != 0)
+		return -EINVAL;
+
+	len = 0;
+	for (i = 0; i < DRM_MODE_COLORIMETRY_MAX; i++) {
+		if (supported_colorspaces != 0 && (colorspaces & BIT(i)) == 0)
+			continue;
+
+		enum_list[len].type = i;
+		enum_list[len].name = colorspace_names[i];
+		len++;
+	}
 
 	connector->colorspace_property =
 		drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-					colorspaces,
-					size);
+					enum_list,
+					len);
 
 	if (!connector->colorspace_property)
 		return -ENOMEM;
 
 	return 0;
 }
+
 /**
  * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
  * @connector: connector to create the Colorspace property on.
+ * @supported_colorspaces: A bitfield of supported colorspaces or 0 for all
+ *                         HDMI colorspaces
  *
  * Called by a driver the first time it's needed, must be attached to desired
  * HDMI connectors.
@@ -2005,15 +2030,15 @@ static int drm_mode_create_colorspace_property(struct drm_connector *connector,
  */
 int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
 {
-	return drm_mode_create_colorspace_property(connector,
-						   hdmi_colorspaces,
-						   ARRAY_SIZE(hdmi_colorspaces));
+	return drm_mode_create_colorspace_property(connector, hdmi_colorspaces);
 }
 EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
 
 /**
  * drm_mode_create_dp_colorspace_property - create dp colorspace property
  * @connector: connector to create the Colorspace property on.
+ * @supported_colorspaces: A bitfield of supported colorspaces or 0 for all
+ *                         DP colorspaces
  *
  * Called by a driver the first time it's needed, must be attached to desired
  * DP connectors.
@@ -2023,9 +2048,7 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
  */
 int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
 {
-	return drm_mode_create_colorspace_property(connector,
-						   dp_colorspaces,
-						   ARRAY_SIZE(dp_colorspaces));
+	return drm_mode_create_colorspace_property(connector, dp_colorspaces);
 }
 EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3e2e1bc7aa04..46c064d9ffef 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -460,6 +460,7 @@ enum drm_colorspace {
 	DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED	= 13,
 	DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT	= 14,
 	DRM_MODE_COLORIMETRY_BT601_YCC		= 15,
+	DRM_MODE_COLORIMETRY_MAX
 };
 
 /**
-- 
2.39.2

[PATCH v3 06/17] drm/connector: Print connector colorspace in state debugfs

[Harry Wentland]

v3: Fix kerneldocs (kernel test robot)

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 drivers/gpu/drm/drm_atomic.c    |  1 +
 drivers/gpu/drm/drm_connector.c | 15 +++++++++++++++
 include/drm/drm_connector.h     |  1 +
 3 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0dc5858a723..d6d04c4ccfc0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1071,6 +1071,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
 	drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)");
 	drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware);
 	drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
+	drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace));
 
 	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
 		if (state->writeback_job && state->writeback_job->fb)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7649f0ac454f..7ed48f9cbb20 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1044,6 +1044,21 @@ static const char * const colorspace_names[] = {
 	[DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
 };
 
+/**
+ * drm_get_colorspace_name - return a string for color encoding
+ * @colorspace: color space to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace)
+{
+	if (WARN_ON(colorspace >= ARRAY_SIZE(colorspace_names)))
+		return "unknown";
+
+	return colorspace_names[colorspace];
+}
+
 static const u32 hdmi_colorspaces =
 	BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
 	BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 46c064d9ffef..c77e42408522 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1970,6 +1970,7 @@ void drm_connector_list_iter_end(struct drm_connector_list_iter *iter);
 
 bool drm_connector_has_possible_encoder(struct drm_connector *connector,
 					struct drm_encoder *encoder);
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
 
 /**
  * drm_for_each_connector_iter - connector_list iterator macro
-- 
2.39.2

[PATCH v3 07/17] drm/connector: Allow drivers to pass list of supported colorspaces

[Harry Wentland]

Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.

Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.

v2:
 - Use 0 to indicate support for all colorspaces (Jani)
 - Print drm_dbg_kms message when drivers pass 0
   to signal that drivers should specify supported
   colorspaecs explicity (Jani)
v3:
 - Move changes to create a common colorspace_names array
   to separate patch

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 drivers/gpu/drm/drm_connector.c                | 14 ++++++++++----
 drivers/gpu/drm/i915/display/intel_connector.c |  4 ++--
 drivers/gpu/drm/vc4/vc4_hdmi.c                 |  2 +-
 include/drm/drm_connector.h                    |  7 +++++--
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7ed48f9cbb20..2581cab7f936 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2043,9 +2043,12 @@ static int drm_mode_create_colorspace_property(struct drm_connector *connector,
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
+					     u32 supported_colorspaces)
 {
-	return drm_mode_create_colorspace_property(connector, hdmi_colorspaces);
+	u32 colorspaces = supported_colorspaces & hdmi_colorspaces;
+
+	return drm_mode_create_colorspace_property(connector, colorspaces);
 }
 EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
 
@@ -2061,9 +2064,12 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
  * Returns:
  * Zero on success, negative errno on failure.
  */
-int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
+int drm_mode_create_dp_colorspace_property(struct drm_connector *connector,
+					   u32 supported_colorspaces)
 {
-	return drm_mode_create_colorspace_property(connector, dp_colorspaces);
+	u32 colorspaces = supported_colorspaces & dp_colorspaces;
+
+	return drm_mode_create_colorspace_property(connector, colorspaces);
 }
 EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
 
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c b/drivers/gpu/drm/i915/display/intel_connector.c
index 6d5cbeb8df4d..9e4b054266ea 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -283,13 +283,13 @@ intel_attach_aspect_ratio_property(struct drm_connector *connector)
 void
 intel_attach_hdmi_colorspace_property(struct drm_connector *connector)
 {
-	if (!drm_mode_create_hdmi_colorspace_property(connector))
+	if (!drm_mode_create_hdmi_colorspace_property(connector, 0))
 		drm_connector_attach_colorspace_property(connector);
 }
 
 void
 intel_attach_dp_colorspace_property(struct drm_connector *connector)
 {
-	if (!drm_mode_create_dp_colorspace_property(connector))
+	if (!drm_mode_create_dp_colorspace_property(connector, 0))
 		drm_connector_attach_colorspace_property(connector);
 }
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9e145690c480..95d73b817b05 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -605,7 +605,7 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
 	if (ret)
 		return ret;
 
-	ret = drm_mode_create_hdmi_colorspace_property(connector);
+	ret = drm_mode_create_hdmi_colorspace_property(connector, 0);
 	if (ret)
 		return ret;
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index c77e42408522..693e4cba9cb5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -30,6 +30,7 @@
 #include <linux/notifier.h>
 #include <drm/drm_mode_object.h>
 #include <drm/drm_util.h>
+#include <drm/drm_property.h>
 
 #include <uapi/drm/drm_mode.h>
 
@@ -1886,8 +1887,10 @@ int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
 bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state *old_state,
 					     struct drm_connector_state *new_state);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector);
-int drm_mode_create_dp_colorspace_property(struct drm_connector *connector);
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
+					     u32 supported_colorspaces);
+int drm_mode_create_dp_colorspace_property(struct drm_connector *connector,
+					   u32 supported_colorspaces);
 int drm_mode_create_content_type_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
 
-- 
2.39.2

[PATCH v3 08/17] drm/amd/display: Always pass connector_state to stream validation

[Harry Wentland]

We need the connector_state for colorspace and scaling information
and can get it from connector->state.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++++----
 1 file changed, 5 insertions(+), 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 4217ebe6391b..f91b2ea13d96 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5916,15 +5916,14 @@ create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
 {
 	struct drm_display_mode *preferred_mode = NULL;
 	struct drm_connector *drm_connector;
-	const struct drm_connector_state *con_state =
-		dm_state ? &dm_state->base : NULL;
+	const struct drm_connector_state *con_state = &dm_state->base;
 	struct dc_stream_state *stream = NULL;
 	struct drm_display_mode mode;
 	struct drm_display_mode saved_mode;
 	struct drm_display_mode *freesync_mode = NULL;
 	bool native_mode_found = false;
 	bool recalculate_timing = false;
-	bool scale = dm_state ? (dm_state->scaling != RMX_OFF) : false;
+	bool scale = dm_state->scaling != RMX_OFF;
 	int mode_refresh;
 	int preferred_refresh = 0;
 	enum color_transfer_func tf = TRANSFER_FUNC_UNKNOWN;
@@ -6541,7 +6540,9 @@ enum drm_mode_status amdgpu_dm_connector_mode_valid(struct drm_connector *connec
 		goto fail;
 	}
 
-	stream = create_validate_stream_for_sink(aconnector, mode, NULL, NULL);
+	stream = create_validate_stream_for_sink(aconnector, mode,
+						 to_dm_connector_state(connector->state),
+						 NULL);
 	if (stream) {
 		dc_stream_release(stream);
 		result = MODE_OK;
-- 
2.39.2

[PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Harry Wentland]

We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
 1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
 	return amdgpu_dm_connector->num_modes;
 }
 
+static const u32 supported_colorspaces =
+	BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+	BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020) |
+	BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
+
 void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 				     struct amdgpu_dm_connector *aconnector,
 				     int connector_type,
@@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 				adev->mode_info.abm_level_property, 0);
 	}
 
+	if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
+		if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
+			drm_connector_attach_colorspace_property(&aconnector->base);
+	} else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+		   connector_type == DRM_MODE_CONNECTOR_eDP) {
+		if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
+			drm_connector_attach_colorspace_property(&aconnector->base);
+	}
+
 	if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
 	    connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
 	    connector_type == DRM_MODE_CONNECTOR_eDP) {
-- 
2.39.2

[PATCH v3 10/17] drm/amd/display: Signal mode_changed if colorspace changed

[Harry Wentland]

We need to signal mode_changed to make sure we update the output
colorspace.

v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
    own infoframe packing.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Leo Li <sunpeng.li@amd.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +++++++++-
 1 file changed, 9 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 2d883c6dae90..58fc719bec8d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6636,6 +6636,14 @@ amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
 	if (!crtc)
 		return 0;
 
+	if (new_con_state->colorspace != old_con_state->colorspace) {
+		new_crtc_state = drm_atomic_get_crtc_state(state, crtc);
+		if (IS_ERR(new_crtc_state))
+			return PTR_ERR(new_crtc_state);
+
+		new_crtc_state->mode_changed = true;
+	}
+
 	if (!drm_connector_atomic_hdr_metadata_equal(old_con_state, new_con_state)) {
 		struct dc_info_packet hdr_infopacket;
 
@@ -6658,7 +6666,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
 		 * set is permissible, however. So only force a
 		 * modeset if we're entering or exiting HDR.
 		 */
-		new_crtc_state->mode_changed =
+		new_crtc_state->mode_changed = new_crtc_state->mode_changed ||
 			!old_con_state->hdr_output_metadata ||
 			!new_con_state->hdr_output_metadata;
 	}
-- 
2.39.2

[PATCH v3 11/17] drm/amd/display: Send correct DP colorspace infopacket

[Harry Wentland]

Look at connector->colorimetry to determine output colorspace.

We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 +++++++++++--------
 1 file changed, 22 insertions(+), 16 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 58fc719bec8d..cdfd09d50ee6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5302,21 +5302,21 @@ 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,
+		       const struct drm_connector_state *connector_state)
 {
 	enum dc_color_space color_space = COLOR_SPACE_SRGB;
 
-	switch (dc_crtc_timing->pixel_encoding)	{
-	case PIXEL_ENCODING_YCBCR422:
-	case PIXEL_ENCODING_YCBCR444:
-	case PIXEL_ENCODING_YCBCR420:
-	{
+	switch (connector_state->colorspace) {
+	case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
+		if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
+			color_space = COLOR_SPACE_SRGB;
 		/*
 		 * 27030khz is the separation point between HDTV and SDTV
 		 * according to HDMI spec, we use YCbCr709 and YCbCr601
 		 * respectively
 		 */
-		if (dc_crtc_timing->pix_clk_100hz > 270300) {
+		} else if (dc_crtc_timing->pix_clk_100hz > 270300) {
 			if (dc_crtc_timing->flags.Y_ONLY)
 				color_space =
 					COLOR_SPACE_YCBCR709_LIMITED;
@@ -5329,15 +5329,21 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
 			else
 				color_space = COLOR_SPACE_YCBCR601;
 		}
-
-	}
-	break;
-	case PIXEL_ENCODING_RGB:
-		color_space = COLOR_SPACE_SRGB;
 		break;
-
-	default:
-		WARN_ON(1);
+	case DRM_MODE_COLORIMETRY_BT709_YCC:
+		if (dc_crtc_timing->flags.Y_ONLY)
+			color_space = COLOR_SPACE_YCBCR709_LIMITED;
+		else
+			color_space = COLOR_SPACE_YCBCR709;
+		break;
+	case DRM_MODE_COLORIMETRY_OPRGB:
+		color_space = COLOR_SPACE_ADOBERGB;
+		break;
+	case DRM_MODE_COLORIMETRY_BT2020:
+		color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+		break;
+	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
+		color_space = COLOR_SPACE_2020_YCBCR;
 		break;
 	}
 
@@ -5476,7 +5482,7 @@ static void fill_stream_properties_from_drm_display_mode(
 		}
 	}
 
-	stream->output_color_space = get_output_color_space(timing_out);
+	stream->output_color_space = get_output_color_space(timing_out, connector_state);
 }
 
 static void fill_audio_info(struct audio_info *audio_info,
-- 
2.39.2

[PATCH v3 12/17] drm/amd/display: Always set crtcinfo from create_stream_for_sink

[Harry Wentland]

From: Joshua Ashton <joshua@froggi.es>

Given that we always pass dm_state into here now, this won't ever
trigger anymore.

This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Harry Wentland <harry.wentland@amd.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 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 cdfd09d50ee6..580d076b7749 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6010,7 +6010,7 @@ create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
 
 	if (recalculate_timing)
 		drm_mode_set_crtcinfo(&saved_mode, 0);
-	else if (!dm_state)
+	else
 		drm_mode_set_crtcinfo(&mode, 0);
 
 	/*
-- 
2.39.2

[PATCH v3 13/17] drm/amd/display: Add support for explicit BT601_YCC

[Harry Wentland]

We use this by default but if userspace passes this explicitly
we should respect it.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++++++
 1 file changed, 6 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 580d076b7749..7f77e226f1eb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5330,6 +5330,12 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
 				color_space = COLOR_SPACE_YCBCR601;
 		}
 		break;
+	case DRM_MODE_COLORIMETRY_BT601_YCC:
+		if (dc_crtc_timing->flags.Y_ONLY)
+			color_space = COLOR_SPACE_YCBCR601_LIMITED;
+		else
+			color_space = COLOR_SPACE_YCBCR601;
+		break;
 	case DRM_MODE_COLORIMETRY_BT709_YCC:
 		if (dc_crtc_timing->flags.Y_ONLY)
 			color_space = COLOR_SPACE_YCBCR709_LIMITED;
-- 
2.39.2

[PATCH v3 14/17] drm/amd/display: Add debugfs for testing output colorspace

[Harry Wentland]

In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.

This might also come in handy when debugging display
issues.

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 4a5dae578d97..f0022c16b708 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -906,6 +906,61 @@ static int amdgpu_current_bpc_show(struct seq_file *m, void *data)
 }
 DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
 
+/*
+ * Returns the current bpc for the crtc.
+ * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_colorspace
+ */
+static int amdgpu_current_colorspace_show(struct seq_file *m, void *data)
+{
+	struct drm_crtc *crtc = m->private;
+	struct drm_device *dev = crtc->dev;
+	struct dm_crtc_state *dm_crtc_state = NULL;
+	int res = -ENODEV;
+
+	mutex_lock(&dev->mode_config.mutex);
+	drm_modeset_lock(&crtc->mutex, NULL);
+	if (crtc->state == NULL)
+		goto unlock;
+
+	dm_crtc_state = to_dm_crtc_state(crtc->state);
+	if (dm_crtc_state->stream == NULL)
+		goto unlock;
+
+	switch (dm_crtc_state->stream->output_color_space) {
+	case COLOR_SPACE_SRGB:
+		seq_printf(m, "RGB");
+		break;
+	case COLOR_SPACE_YCBCR601:
+	case COLOR_SPACE_YCBCR601_LIMITED:
+		seq_printf(m, "BT601_YCC");
+		break;
+	case COLOR_SPACE_YCBCR709:
+	case COLOR_SPACE_YCBCR709_LIMITED:
+		seq_printf(m, "BT709_YCC");
+		break;
+	case COLOR_SPACE_ADOBERGB:
+		seq_printf(m, "opRGB");
+		break;
+	case COLOR_SPACE_2020_RGB_FULLRANGE:
+		seq_printf(m, "BT2020_RGB");
+		break;
+	case COLOR_SPACE_2020_YCBCR:
+		seq_printf(m, "BT2020_YCC");
+		break;
+	default:
+		goto unlock;
+	}
+	res = 0;
+
+unlock:
+	drm_modeset_unlock(&crtc->mutex);
+	mutex_unlock(&dev->mode_config.mutex);
+
+	return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);
+
+
 /*
  * Example usage:
  * Disable dsc passthrough, i.e.,: have dsc decoding at converver, not external RX
@@ -3235,6 +3290,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
 #endif
 	debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
 			    crtc, &amdgpu_current_bpc_fops);
+	debugfs_create_file("amdgpu_current_colorspace", 0644, crtc->debugfs_entry,
+			    crtc, &amdgpu_current_colorspace_fops);
 }
 
 /*
-- 
2.39.2

[PATCH v3 15/17] drm/amd/display: Add default case for output_color_space switch

[Harry Wentland]

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++++++++++---------
 1 file changed, 22 insertions(+), 21 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 7f77e226f1eb..a15b26962496 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5308,7 +5308,29 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
 	enum dc_color_space color_space = COLOR_SPACE_SRGB;
 
 	switch (connector_state->colorspace) {
+	case DRM_MODE_COLORIMETRY_BT601_YCC:
+		if (dc_crtc_timing->flags.Y_ONLY)
+			color_space = COLOR_SPACE_YCBCR601_LIMITED;
+		else
+			color_space = COLOR_SPACE_YCBCR601;
+		break;
+	case DRM_MODE_COLORIMETRY_BT709_YCC:
+		if (dc_crtc_timing->flags.Y_ONLY)
+			color_space = COLOR_SPACE_YCBCR709_LIMITED;
+		else
+			color_space = COLOR_SPACE_YCBCR709;
+		break;
+	case DRM_MODE_COLORIMETRY_OPRGB:
+		color_space = COLOR_SPACE_ADOBERGB;
+		break;
+	case DRM_MODE_COLORIMETRY_BT2020:
+		color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+		break;
+	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
+		color_space = COLOR_SPACE_2020_YCBCR;
+		break;
 	case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
+	default:
 		if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
 			color_space = COLOR_SPACE_SRGB;
 		/*
@@ -5330,27 +5352,6 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
 				color_space = COLOR_SPACE_YCBCR601;
 		}
 		break;
-	case DRM_MODE_COLORIMETRY_BT601_YCC:
-		if (dc_crtc_timing->flags.Y_ONLY)
-			color_space = COLOR_SPACE_YCBCR601_LIMITED;
-		else
-			color_space = COLOR_SPACE_YCBCR601;
-		break;
-	case DRM_MODE_COLORIMETRY_BT709_YCC:
-		if (dc_crtc_timing->flags.Y_ONLY)
-			color_space = COLOR_SPACE_YCBCR709_LIMITED;
-		else
-			color_space = COLOR_SPACE_YCBCR709;
-		break;
-	case DRM_MODE_COLORIMETRY_OPRGB:
-		color_space = COLOR_SPACE_ADOBERGB;
-		break;
-	case DRM_MODE_COLORIMETRY_BT2020:
-		color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
-		break;
-	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
-		color_space = COLOR_SPACE_2020_YCBCR;
-		break;
 	}
 
 	return color_space;
-- 
2.39.2

[PATCH v3 16/17] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB

[Harry Wentland]

From: Joshua Ashton <joshua@froggi.es>

Userspace might not aware whether we're sending RGB or YCbCr
data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is
requested but the output encoding is YCbCr we should
send COLOR_SPACE_2020_YCBCR.

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 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 a15b26962496..d5e1f3423cce 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5324,10 +5324,11 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
 		color_space = COLOR_SPACE_ADOBERGB;
 		break;
 	case DRM_MODE_COLORIMETRY_BT2020:
-		color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
-		break;
 	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
-		color_space = COLOR_SPACE_2020_YCBCR;
+		if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB)
+			color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+		else
+			color_space = COLOR_SPACE_2020_YCBCR;
 		break;
 	case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
 	default:
-- 
2.39.2

[PATCH v3 17/17] drm/amd/display: Refactor avi_info_frame colorimetry determination

[Harry Wentland]

From: Joshua Ashton <joshua@froggi.es>

Replace the messy two if-else chains here that were
on the same value with a switch on the enum.

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
---
 .../gpu/drm/amd/display/dc/core/dc_resource.c | 28 +++++++++++--------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index d9f2ef242b0f..34a7fb225629 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -3010,23 +3010,29 @@ static void set_avi_info_frame(
 	hdmi_info.bits.S0_S1 = scan_type;
 
 	/* C0, C1 : Colorimetry */
-	if (color_space == COLOR_SPACE_YCBCR709 ||
-			color_space == COLOR_SPACE_YCBCR709_LIMITED)
+	switch (color_space) {
+	case COLOR_SPACE_YCBCR709:
+	case COLOR_SPACE_YCBCR709_LIMITED:
 		hdmi_info.bits.C0_C1 = COLORIMETRY_ITU709;
-	else if (color_space == COLOR_SPACE_YCBCR601 ||
-			color_space == COLOR_SPACE_YCBCR601_LIMITED)
+		break;
+	case COLOR_SPACE_YCBCR601:
+	case COLOR_SPACE_YCBCR601_LIMITED:
 		hdmi_info.bits.C0_C1 = COLORIMETRY_ITU601;
-	else {
-		hdmi_info.bits.C0_C1 = COLORIMETRY_NO_DATA;
-	}
-	if (color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
-			color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
-			color_space == COLOR_SPACE_2020_YCBCR) {
+		break;
+	case COLOR_SPACE_2020_RGB_FULLRANGE:
+	case COLOR_SPACE_2020_RGB_LIMITEDRANGE:
+	case COLOR_SPACE_2020_YCBCR:
 		hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_BT2020RGBYCBCR;
 		hdmi_info.bits.C0_C1   = COLORIMETRY_EXTENDED;
-	} else if (color_space == COLOR_SPACE_ADOBERGB) {
+		break;
+	case COLOR_SPACE_ADOBERGB:
 		hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_ADOBERGB;
 		hdmi_info.bits.C0_C1   = COLORIMETRY_EXTENDED;
+		break;
+	case COLOR_SPACE_SRGB:
+	default:
+		hdmi_info.bits.C0_C1 = COLORIMETRY_NO_DATA;
+		break;
 	}
 
 	if (pixel_encoding && color_space == COLOR_SPACE_2020_YCBCR &&
-- 
2.39.2

Re: [PATCH v3 01/17] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

[Simon Ser]

On Tuesday, March 7th, 2023 at 16:10, Harry Wentland <harry.wentland@amd.com> wrote:

> * This enum is used to indicate DP VSC SDP Colorimetry formats.
> * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
> - * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
> + * DB18] and a name of enum member follows &enum drm_colorimetry definition.

Nit: the "&" is not necessary here, "enum drm_colorimetry" alone should
linkify properly.

[PATCH v4 01/17] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

[Harry Wentland]

This allows us to use strongly typed arguments.

v2:
 - Bring NO_DATA back
 - Provide explicit enum values

v4: Drop unnecessary '&' from kerneldoc (emersion)

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Simon Ser <contact@emersion.fr>

Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
---
 include/drm/display/drm_dp.h |  2 +-
 include/drm/drm_connector.h  | 49 ++++++++++++++++++------------------
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index ed10e6b6f99d..dae5e9c201e4 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1623,7 +1623,7 @@ enum dp_pixelformat {
  *
  * This enum is used to indicate DP VSC SDP Colorimetry formats.
  * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
- * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
+ * DB18] and a name of enum member follows enum drm_colorimetry definition.
  *
  * @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
  *                          ITU-R BT.601 colorimetry format
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4d830fc55a3d..6d6a53a6b010 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -371,29 +371,30 @@ enum drm_privacy_screen_status {
  * a colorspace property which will be created and exposed to
  * userspace.
  */
-
-/* For Default case, driver will set the colorspace */
-#define DRM_MODE_COLORIMETRY_DEFAULT			0
-/* CEA 861 Normal Colorimetry options */
-#define DRM_MODE_COLORIMETRY_NO_DATA			0
-#define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC		1
-#define DRM_MODE_COLORIMETRY_BT709_YCC			2
-/* CEA 861 Extended Colorimetry Options */
-#define DRM_MODE_COLORIMETRY_XVYCC_601			3
-#define DRM_MODE_COLORIMETRY_XVYCC_709			4
-#define DRM_MODE_COLORIMETRY_SYCC_601			5
-#define DRM_MODE_COLORIMETRY_OPYCC_601			6
-#define DRM_MODE_COLORIMETRY_OPRGB			7
-#define DRM_MODE_COLORIMETRY_BT2020_CYCC		8
-#define DRM_MODE_COLORIMETRY_BT2020_RGB			9
-#define DRM_MODE_COLORIMETRY_BT2020_YCC			10
-/* Additional Colorimetry extension added as part of CTA 861.G */
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65		11
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER		12
-/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED		13
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT		14
-#define DRM_MODE_COLORIMETRY_BT601_YCC			15
+enum drm_colorspace {
+	/* For Default case, driver will set the colorspace */
+	DRM_MODE_COLORIMETRY_DEFAULT 		= 0,
+	DRM_MODE_COLORIMETRY_NO_DATA		= 0,
+	/* CEA 861 Normal Colorimetry options */
+	DRM_MODE_COLORIMETRY_SMPTE_170M_YCC	= 1,
+	DRM_MODE_COLORIMETRY_BT709_YCC		= 2,
+	/* CEA 861 Extended Colorimetry Options */
+	DRM_MODE_COLORIMETRY_XVYCC_601		= 3,
+	DRM_MODE_COLORIMETRY_XVYCC_709		= 4,
+	DRM_MODE_COLORIMETRY_SYCC_601		= 5,
+	DRM_MODE_COLORIMETRY_OPYCC_601		= 6,
+	DRM_MODE_COLORIMETRY_OPRGB		= 7,
+	DRM_MODE_COLORIMETRY_BT2020_CYCC	= 8,
+	DRM_MODE_COLORIMETRY_BT2020_RGB		= 9,
+	DRM_MODE_COLORIMETRY_BT2020_YCC		= 10,
+	/* Additional Colorimetry extension added as part of CTA 861.G */
+	DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65	= 11,
+	DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER	= 12,
+	/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
+	DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED	= 13,
+	DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT	= 14,
+	DRM_MODE_COLORIMETRY_BT601_YCC		= 15,
+};
 
 /**
  * enum drm_bus_flags - bus_flags info for &drm_display_info
@@ -826,7 +827,7 @@ struct drm_connector_state {
 	 * colorspace change on Sink. This is most commonly used to switch
 	 * to wider color gamuts like BT2020.
 	 */
-	u32 colorspace;
+	enum drm_colorspace colorspace;
 
 	/**
 	 * @writeback_job: Writeback job for writeback connectors
-- 
2.39.2

Re: [PATCH v4 01/17] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:29:34 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> This allows us to use strongly typed arguments.
> 
> v2:
>  - Bring NO_DATA back
>  - Provide explicit enum values
> 
> v4: Drop unnecessary '&' from kerneldoc (emersion)
> 
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Reviewed-by: Simon Ser <contact@emersion.fr>
> 
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Uma Shankar <uma.shankar@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  include/drm/display/drm_dp.h |  2 +-
>  include/drm/drm_connector.h  | 49 ++++++++++++++++++------------------
>  2 files changed, 26 insertions(+), 25 deletions(-)
> 
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index ed10e6b6f99d..dae5e9c201e4 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -1623,7 +1623,7 @@ enum dp_pixelformat {
>   *
>   * This enum is used to indicate DP VSC SDP Colorimetry formats.
>   * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
> - * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
> + * DB18] and a name of enum member follows enum drm_colorimetry definition.
>   *
>   * @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
>   *                          ITU-R BT.601 colorimetry format
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 4d830fc55a3d..6d6a53a6b010 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -371,29 +371,30 @@ enum drm_privacy_screen_status {
>   * a colorspace property which will be created and exposed to
>   * userspace.
>   */
> -
> -/* For Default case, driver will set the colorspace */
> -#define DRM_MODE_COLORIMETRY_DEFAULT			0
> -/* CEA 861 Normal Colorimetry options */
> -#define DRM_MODE_COLORIMETRY_NO_DATA			0
> -#define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC		1
> -#define DRM_MODE_COLORIMETRY_BT709_YCC			2
> -/* CEA 861 Extended Colorimetry Options */
> -#define DRM_MODE_COLORIMETRY_XVYCC_601			3
> -#define DRM_MODE_COLORIMETRY_XVYCC_709			4
> -#define DRM_MODE_COLORIMETRY_SYCC_601			5
> -#define DRM_MODE_COLORIMETRY_OPYCC_601			6
> -#define DRM_MODE_COLORIMETRY_OPRGB			7
> -#define DRM_MODE_COLORIMETRY_BT2020_CYCC		8
> -#define DRM_MODE_COLORIMETRY_BT2020_RGB			9
> -#define DRM_MODE_COLORIMETRY_BT2020_YCC			10
> -/* Additional Colorimetry extension added as part of CTA 861.G */
> -#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65		11
> -#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER		12
> -/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
> -#define DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED		13
> -#define DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT		14
> -#define DRM_MODE_COLORIMETRY_BT601_YCC			15
> +enum drm_colorspace {
> +	/* For Default case, driver will set the colorspace */
> +	DRM_MODE_COLORIMETRY_DEFAULT 		= 0,
> +	DRM_MODE_COLORIMETRY_NO_DATA		= 0,
> +	/* CEA 861 Normal Colorimetry options */

This comment seems to be in the wrong place, NO_DATA should be under
this comment.

With that fixed:
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>


Thanks,
pq

> +	DRM_MODE_COLORIMETRY_SMPTE_170M_YCC	= 1,
> +	DRM_MODE_COLORIMETRY_BT709_YCC		= 2,
> +	/* CEA 861 Extended Colorimetry Options */
> +	DRM_MODE_COLORIMETRY_XVYCC_601		= 3,
> +	DRM_MODE_COLORIMETRY_XVYCC_709		= 4,
> +	DRM_MODE_COLORIMETRY_SYCC_601		= 5,
> +	DRM_MODE_COLORIMETRY_OPYCC_601		= 6,
> +	DRM_MODE_COLORIMETRY_OPRGB		= 7,
> +	DRM_MODE_COLORIMETRY_BT2020_CYCC	= 8,
> +	DRM_MODE_COLORIMETRY_BT2020_RGB		= 9,
> +	DRM_MODE_COLORIMETRY_BT2020_YCC		= 10,
> +	/* Additional Colorimetry extension added as part of CTA 861.G */
> +	DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65	= 11,
> +	DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER	= 12,
> +	/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
> +	DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED	= 13,
> +	DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT	= 14,
> +	DRM_MODE_COLORIMETRY_BT601_YCC		= 15,
> +};
>  
>  /**
>   * enum drm_bus_flags - bus_flags info for &drm_display_info
> @@ -826,7 +827,7 @@ struct drm_connector_state {
>  	 * colorspace change on Sink. This is most commonly used to switch
>  	 * to wider color gamuts like BT2020.
>  	 */
> -	u32 colorspace;
> +	enum drm_colorspace colorspace;
>  
>  	/**
>  	 * @writeback_job: Writeback job for writeback connectors


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

Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:10:52 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> From: Joshua Ashton <joshua@froggi.es>
> 
> To match the other enums, and add more information about these values.
> 
> v2:
>  - Specify where an enum entry comes from
>  - Clarify DEFAULT and NO_DATA behavior
>  - BT.2020 CYCC is "constant luminance"
>  - correct type for BT.601
> 
> Signed-off-by: Joshua Ashton <joshua@froggi.es>
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Reviewed-by: Harry Wentland <harry.wentland@amd.com>

Hi,

this effort is really good, but of course I still find things to
nitpick about. If there is no answer to my questions, then I would
prefer the documentation to spell out the unknowns and ambiguities.

> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Uma Shankar <uma.shankar@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  include/drm/drm_connector.h | 67 +++++++++++++++++++++++++++++++++++--
>  1 file changed, 65 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 6d6a53a6b010..bb078666dc34 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
>  	PRIVACY_SCREEN_ENABLED_LOCKED,
>  };
>  
> -/*
> - * This is a consolidated colorimetry list supported by HDMI and
> +/**
> + * enum drm_colorspace - color space
> + *
> + * This enum is a consolidated colorimetry list supported by HDMI and
>   * DP protocol standard. The respective connectors will register
>   * a property with the subset of this list (supported by that
>   * respective protocol). Userspace will set the colorspace through
>   * a colorspace property which will be created and exposed to
>   * userspace.
> + *
> + * DP definitions come from the DP v2.0 spec
> + * HDMI definitions come from the CTA-861-H spec
> + *
> + * @DRM_MODE_COLORIMETRY_DEFAULT:
> + *   Driver specific behavior.
> + *   For DP:
> + *   	RGB encoded: sRGB (IEC 61966-2-1)
> + *   	YCbCr encoded: ITU-R BT.601 colorimetry format

Does this mean that HDMI behavior is driver-specific while DP behavior
is as defined?

Is it intentional that YCbCr encoding also uses different RGB-primaries
than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)

Or do you need to be more explicit on which parts of each spec apply
(ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
CICP parlance)?

E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.

> + * @DRM_MODE_COLORIMETRY_NO_DATA:
> + *   Driver specific behavior.
> + *   For HDMI:
> + * 	Sets "No Data" in infoframe

Does DEFAULT mean that something else than "No Data" may be set in the
HDMI infoframe?

If so, since these two have the same value, where is the difference? Is
DEFAULT purely an UAPI token, and NO_DATA used internally? Or NO_DATA
used only when crafting actual infoframe packets?

Should NO_DATA be documented to be a strictly driver-internal value,
and not documented with UAPI?

I am unclear if userspace is using these enum values directly, or do
they use the string names only.

> + * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> + *   (HDMI)
> + *   SMPTE ST 170M colorimetry format

Does "colorimetry format" mean that the spec is used in full, for all
of ColourPrimaries, TransferCharacteristics and MatrixCoefficients?

If yes, good. If not, the wording misleads me.

> + * @DRM_MODE_COLORIMETRY_BT709_YCC:
> + *   (HDMI, DP)
> + *   ITU-R BT.709 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_601:
> + *   (HDMI, DP)
> + *   xvYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_709:
> + *   (HDMI, DP)
> + *   xvYCC709 colorimetry format

Btw. xvYCC are funny because they require limited quantization range
encoding, but use the foot- and headroom to encode out-of-nominal-range
values in order to expand the color gamut with negative and greater
than unity values.

Just for curiosity, is it in any way possible today to make use of that
extended color gamut through KMS? Has it ever been possible?

I mean, the KMS color pipeline assumes full-range RGB, so I don't see
any way to make use of xvYCC.

> + * @DRM_MODE_COLORIMETRY_SYCC_601:
> + *   (HDMI, DP)
> + *   sYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPYCC_601:
> + *   (HDMI, DP)
> + *   opYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPRGB:
> + *   (HDMI, DP)
> + *   opRGB colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
> + *   (HDMI, DP)
> + *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_RGB:
> + *   (HDMI, DP)
> + *   ITU-R BT.2020 R' G' B' colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_YCC:
> + *   (HDMI, DP)
> + *   ITU-R BT.2020 Y' C'b C'r colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> + *   (HDMI)
> + *   SMPTE ST 2113 P3D65 colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> + *   (HDMI)
> + *   SMPTE ST 2113 P3DCI colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
> + *   (DP)
> + *   RGB wide gamut fixed point colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
> + *   (DP)
> + *   RGB wide gamut floating point
> + *   (scRGB (IEC 61966-2-2)) colorimetry format

Again, there is no way to actually make use of WIDE since the KMS color
pipeline is limited to the unit range color values, right? Or is it
possible by setting all color pipeline KMS properties to pass-through
and using a floating-point FB?

I suppose the FIXED vs. FLOAT has the exact same problems as BT2020_YCC
vs. BT2020_RGB, but I would be surprised if anyone cared.

> + * @DRM_MODE_COLORIMETRY_BT601_YCC:
> + *   (DP)
> + *   ITU-R BT.601 colorimetry format
> + *   The DP spec does not say whether this is the 525 or the 625
> + *   line version.

Good to note that ambiguity here. :-)

Or maybe the DP spec writer was thinking about BT.709 ColourPrimaries
and BT.601 MatrixCoefficients...

>   */
>  enum drm_colorspace {
>  	/* For Default case, driver will set the colorspace */


Thanks,
pq

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

Re: [PATCH v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:10:53 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> From: Joshua Ashton <joshua@froggi.es>
> 
> Userspace has no way of controlling or knowing the pixel encoding
> currently, so there is no way for it to ever get the right values here.
> 
> When we do add pixel_encoding control from userspace,we can pick the
> right value for the colorimetry packet based on the
> pixel_encoding + the colorspace.
> 
> Let's deprecate these values, and have one BT.2020 colorspace entry
> that userspace can use.
> 
> v2:
>  - leave CYCC alone for now; it serves a purpose
>  - leave BT2020_RGB the new default BT2020
> 
> Signed-off-by: Joshua Ashton <joshua@froggi.es>
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Reviewed-by: Harry Wentland <harry.wentland@amd.com>
> 
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Uma Shankar <uma.shankar@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  drivers/gpu/drm/display/drm_hdmi_helper.c |  7 +++----
>  drivers/gpu/drm/drm_connector.c           |  8 ++++----
>  drivers/gpu/drm/i915/display/intel_dp.c   | 14 +++++++-------
>  include/drm/drm_connector.h               | 15 +++++++++------
>  4 files changed, 23 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c b/drivers/gpu/drm/display/drm_hdmi_helper.c
> index faf5e9efa7d3..05a0d03ffcda 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> @@ -97,8 +97,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>  #define HDMI_COLORIMETRY_OPYCC_601		(C(3) | EC(3) | ACE(0))
>  #define HDMI_COLORIMETRY_OPRGB			(C(3) | EC(4) | ACE(0))
>  #define HDMI_COLORIMETRY_BT2020_CYCC		(C(3) | EC(5) | ACE(0))
> -#define HDMI_COLORIMETRY_BT2020_RGB		(C(3) | EC(6) | ACE(0))
> -#define HDMI_COLORIMETRY_BT2020_YCC		(C(3) | EC(6) | ACE(0))
> +#define HDMI_COLORIMETRY_BT2020			(C(3) | EC(6) | ACE(0))
>  #define HDMI_COLORIMETRY_DCI_P3_RGB_D65		(C(3) | EC(7) | ACE(0))
>  #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER	(C(3) | EC(7) | ACE(1))
>  
> @@ -112,8 +111,8 @@ static const u32 hdmi_colorimetry_val[] = {
>  	[DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
>  	[DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
>  	[DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> -	[DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> -	[DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
> +	[DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = HDMI_COLORIMETRY_BT2020,
> +	[DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
>  };
>  
>  #undef C
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 61c29ce74b03..fe7eab15f727 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1031,9 +1031,9 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
>  	/* Colorimetry based on ITU-R BT.2020 */
>  	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>  	/* Colorimetry based on ITU-R BT.2020 */
> -	{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> +	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
>  	/* Colorimetry based on ITU-R BT.2020 */
> -	{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> +	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
>  	/* Added as part of Additional Colorimetry Extension in 861.G */
>  	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
>  	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> @@ -1054,7 +1054,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>  	/* Colorimetry based on SMPTE RP 431-2 */
>  	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
>  	/* Colorimetry based on ITU-R BT.2020 */
> -	{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> +	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
>  	{ DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
>  	{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
>  	/* Standard Definition Colorimetry based on IEC 61966-2-4 */
> @@ -1068,7 +1068,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>  	/* Colorimetry based on ITU-R BT.2020 */
>  	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>  	/* Colorimetry based on ITU-R BT.2020 */
> -	{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> +	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },

Let's hope no-one complains about missing the old string names in UABI. :-)

Actually, you should write in the commit message why removing old names
is fine.

>  };
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index c9be61d2348e..be100a193bf5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1766,11 +1766,11 @@ static void intel_dp_compute_vsc_colorimetry(const struct intel_crtc_state *crtc
>  	case DRM_MODE_COLORIMETRY_BT2020_CYCC:
>  		vsc->colorimetry = DP_COLORIMETRY_BT2020_CYCC;
>  		break;
> -	case DRM_MODE_COLORIMETRY_BT2020_RGB:
> -		vsc->colorimetry = DP_COLORIMETRY_BT2020_RGB;
> -		break;
> -	case DRM_MODE_COLORIMETRY_BT2020_YCC:
> -		vsc->colorimetry = DP_COLORIMETRY_BT2020_YCC;
> +	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> +	case DRM_MODE_COLORIMETRY_BT2020:
> +		vsc->colorimetry = vsc->pixelformat == DP_PIXELFORMAT_RGB
> +			? DP_COLORIMETRY_BT2020_RGB
> +			: DP_COLORIMETRY_BT2020_YCC;
>  		break;
>  	case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
>  	case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> @@ -3043,9 +3043,9 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
>  	switch (conn_state->colorspace) {
>  	case DRM_MODE_COLORIMETRY_SYCC_601:
>  	case DRM_MODE_COLORIMETRY_OPYCC_601:
> -	case DRM_MODE_COLORIMETRY_BT2020_YCC:
> -	case DRM_MODE_COLORIMETRY_BT2020_RGB:
>  	case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> +	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> +	case DRM_MODE_COLORIMETRY_BT2020:
>  		return true;
>  	default:
>  		break;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index bb078666dc34..3e2e1bc7aa04 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -409,12 +409,15 @@ enum drm_privacy_screen_status {
>   * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
>   *   (HDMI, DP)
>   *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
> - * @DRM_MODE_COLORIMETRY_BT2020_RGB:
> + * @DRM_MODE_COLORIMETRY_BT2020:
>   *   (HDMI, DP)
> - *   ITU-R BT.2020 R' G' B' colorimetry format
> - * @DRM_MODE_COLORIMETRY_BT2020_YCC:
> + *   ITU-R BT.2020 [R' G' B'] or
> + * 	 ITU-R BT.2020 [Y' C'b C'r] or
> + *   ITU-R BT.2020 [Y'c C'bc C'rc] (linear)

Drop the constant luminance variant from this value's doc.

> + *   colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
>   *   (HDMI, DP)
> - *   ITU-R BT.2020 Y' C'b C'r colorimetry format
> + *   deprecated; same as DRM_MODE_COLORIMETRY_BT2020
>   * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
>   *   (HDMI)
>   *   SMPTE ST 2113 P3D65 colorimetry format
> @@ -448,8 +451,8 @@ enum drm_colorspace {
>  	DRM_MODE_COLORIMETRY_OPYCC_601		= 6,
>  	DRM_MODE_COLORIMETRY_OPRGB		= 7,
>  	DRM_MODE_COLORIMETRY_BT2020_CYCC	= 8,
> -	DRM_MODE_COLORIMETRY_BT2020_RGB		= 9,
> -	DRM_MODE_COLORIMETRY_BT2020_YCC		= 10,
> +	DRM_MODE_COLORIMETRY_BT2020		= 9,
> +	DRM_MODE_COLORIMETRY_BT2020_DEPRECATED	= 10,
>  	/* Additional Colorimetry extension added as part of CTA 861.G */
>  	DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65	= 11,
>  	DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER	= 12,

With the caveat noted and nitpick fixed:
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>


Thanks,
pq

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

Re: [PATCH v3 05/17] drm/connector: Use common colorspace_names array

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:10:55 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> We an use bitfields to track the support ones for HDMI
> and DP. This allows us to print colorspaces in a consistent
> manner without needing to know whether we're dealing with
> DP or HDMI.
> 
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Uma Shankar <uma.shankar@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_connector.c | 131 +++++++++++++++++++-------------
>  include/drm/drm_connector.h     |   1 +
>  2 files changed, 78 insertions(+), 54 deletions(-)
> 

...

> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 3e2e1bc7aa04..46c064d9ffef 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -460,6 +460,7 @@ enum drm_colorspace {
>  	DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED	= 13,
>  	DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT	= 14,
>  	DRM_MODE_COLORIMETRY_BT601_YCC		= 15,
> +	DRM_MODE_COLORIMETRY_MAX

Maybe a comment to say that MAX is not a valid value?
Given that things like iccMAX exist (even though it makes no sense as a
colorspace), MAX could perhaps be confused with something.

Or call it DRM_MODE_COLORIMETRY__COUNT? or __END?


Thanks,
pq

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

Re: [PATCH v3 06/17] drm/connector: Print connector colorspace in state debugfs

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:10:56 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> v3: Fix kerneldocs (kernel test robot)
> 
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Uma Shankar <uma.shankar@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Reviewed-By: Joshua Ashton <joshua@froggi.es>
> ---
>  drivers/gpu/drm/drm_atomic.c    |  1 +
>  drivers/gpu/drm/drm_connector.c | 15 +++++++++++++++
>  include/drm/drm_connector.h     |  1 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c0dc5858a723..d6d04c4ccfc0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1071,6 +1071,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
>  	drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)");
>  	drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware);
>  	drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
> +	drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace));
>  
>  	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>  		if (state->writeback_job && state->writeback_job->fb)
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7649f0ac454f..7ed48f9cbb20 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1044,6 +1044,21 @@ static const char * const colorspace_names[] = {
>  	[DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
>  };
>  
> +/**
> + * drm_get_colorspace_name - return a string for color encoding
> + * @colorspace: color space to compute name of
> + *
> + * In contrast to the other drm_get_*_name functions this one here returns a
> + * const pointer and hence is threadsafe.
> + */
> +const char *drm_get_colorspace_name(enum drm_colorspace colorspace)
> +{
> +	if (WARN_ON(colorspace >= ARRAY_SIZE(colorspace_names)))
> +		return "unknown";
> +
> +	return colorspace_names[colorspace];

Should this protect against returning NULL? Well, I suppose that cannot
happen right now, and probably holes will not be added in the enum. But
should kernel code still be more paranoid?


Thanks,
pq

> +}
> +
>  static const u32 hdmi_colorspaces =
>  	BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
>  	BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 46c064d9ffef..c77e42408522 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1970,6 +1970,7 @@ void drm_connector_list_iter_end(struct drm_connector_list_iter *iter);
>  
>  bool drm_connector_has_possible_encoder(struct drm_connector *connector,
>  					struct drm_encoder *encoder);
> +const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
>  
>  /**
>   * drm_for_each_connector_iter - connector_list iterator macro


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

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:10:59 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> We want compositors to be able to set the output
> colorspace on DP and HDMI outputs, based on the
> caps reported from the receiver via EDID.
> 
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Reviewed-By: Joshua Ashton <joshua@froggi.es>
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
>  1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
>  	return amdgpu_dm_connector->num_modes;
>  }
>  
> +static const u32 supported_colorspaces =
> +	BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> +	BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> +	BIT(DRM_MODE_COLORIMETRY_BT2020) |
> +	BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);

No DEFAULT?
No BT.709 RGB, i.e. sRGB?

Doesn't DRM core reject enum uint values that are not listed in the enum
property?


Thanks,
pq

> +
>  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>  				     struct amdgpu_dm_connector *aconnector,
>  				     int connector_type,
> @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>  				adev->mode_info.abm_level_property, 0);
>  	}
>  
> +	if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> +		if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
> +			drm_connector_attach_colorspace_property(&aconnector->base);
> +	} else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> +		   connector_type == DRM_MODE_CONNECTOR_eDP) {
> +		if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
> +			drm_connector_attach_colorspace_property(&aconnector->base);
> +	}
> +
>  	if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>  	    connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>  	    connector_type == DRM_MODE_CONNECTOR_eDP) {


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

Re: [PATCH v3 14/17] drm/amd/display: Add debugfs for testing output colorspace

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:11:04 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> In order to IGT test colorspace we'll want to print
> the currently enabled colorspace on a stream. We add
> a new debugfs to do so, using the same scheme as
> current bpc reporting.
> 
> This might also come in handy when debugging display
> issues.
> 
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Reviewed-By: Joshua Ashton <joshua@froggi.es>
> ---
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 4a5dae578d97..f0022c16b708 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -906,6 +906,61 @@ static int amdgpu_current_bpc_show(struct seq_file *m, void *data)
>  }
>  DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
>  
> +/*
> + * Returns the current bpc for the crtc.

Hi,

bpc?

> + * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_colorspace
> + */
> +static int amdgpu_current_colorspace_show(struct seq_file *m, void *data)


Thanks,
pq

> +{
> +	struct drm_crtc *crtc = m->private;
> +	struct drm_device *dev = crtc->dev;
> +	struct dm_crtc_state *dm_crtc_state = NULL;
> +	int res = -ENODEV;
> +
> +	mutex_lock(&dev->mode_config.mutex);
> +	drm_modeset_lock(&crtc->mutex, NULL);
> +	if (crtc->state == NULL)
> +		goto unlock;
> +
> +	dm_crtc_state = to_dm_crtc_state(crtc->state);
> +	if (dm_crtc_state->stream == NULL)
> +		goto unlock;
> +
> +	switch (dm_crtc_state->stream->output_color_space) {
> +	case COLOR_SPACE_SRGB:
> +		seq_printf(m, "RGB");
> +		break;
> +	case COLOR_SPACE_YCBCR601:
> +	case COLOR_SPACE_YCBCR601_LIMITED:
> +		seq_printf(m, "BT601_YCC");
> +		break;
> +	case COLOR_SPACE_YCBCR709:
> +	case COLOR_SPACE_YCBCR709_LIMITED:
> +		seq_printf(m, "BT709_YCC");
> +		break;
> +	case COLOR_SPACE_ADOBERGB:
> +		seq_printf(m, "opRGB");
> +		break;
> +	case COLOR_SPACE_2020_RGB_FULLRANGE:
> +		seq_printf(m, "BT2020_RGB");
> +		break;
> +	case COLOR_SPACE_2020_YCBCR:
> +		seq_printf(m, "BT2020_YCC");
> +		break;
> +	default:
> +		goto unlock;
> +	}
> +	res = 0;
> +
> +unlock:
> +	drm_modeset_unlock(&crtc->mutex);
> +	mutex_unlock(&dev->mode_config.mutex);
> +
> +	return res;
> +}
> +DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);
> +
> +
>  /*
>   * Example usage:
>   * Disable dsc passthrough, i.e.,: have dsc decoding at converver, not external RX
> @@ -3235,6 +3290,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
>  #endif
>  	debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
>  			    crtc, &amdgpu_current_bpc_fops);
> +	debugfs_create_file("amdgpu_current_colorspace", 0644, crtc->debugfs_entry,
> +			    crtc, &amdgpu_current_colorspace_fops);
>  }
>  
>  /*


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

Re: [PATCH v3 15/17] drm/amd/display: Add default case for output_color_space switch

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:11:05 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Reviewed-By: Joshua Ashton <joshua@froggi.es>

Hi,

why?

Isn't the bitmask of supported values supposed to stop arbitrary values
from coming through?

Why handle unsupported values like DEFAULT instead of as a kernel bug?

If this is only to stop compiler warnings of not handling all enum
values in a switch, is the commit ordering in this series even
bisectable?


Thanks,
pq

> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++++++++++---------
>  1 file changed, 22 insertions(+), 21 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 7f77e226f1eb..a15b26962496 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5308,7 +5308,29 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
>  	enum dc_color_space color_space = COLOR_SPACE_SRGB;
>  
>  	switch (connector_state->colorspace) {
> +	case DRM_MODE_COLORIMETRY_BT601_YCC:
> +		if (dc_crtc_timing->flags.Y_ONLY)
> +			color_space = COLOR_SPACE_YCBCR601_LIMITED;
> +		else
> +			color_space = COLOR_SPACE_YCBCR601;
> +		break;
> +	case DRM_MODE_COLORIMETRY_BT709_YCC:
> +		if (dc_crtc_timing->flags.Y_ONLY)
> +			color_space = COLOR_SPACE_YCBCR709_LIMITED;
> +		else
> +			color_space = COLOR_SPACE_YCBCR709;
> +		break;
> +	case DRM_MODE_COLORIMETRY_OPRGB:
> +		color_space = COLOR_SPACE_ADOBERGB;
> +		break;
> +	case DRM_MODE_COLORIMETRY_BT2020:
> +		color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
> +		break;
> +	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> +		color_space = COLOR_SPACE_2020_YCBCR;
> +		break;
>  	case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
> +	default:
>  		if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
>  			color_space = COLOR_SPACE_SRGB;
>  		/*
> @@ -5330,27 +5352,6 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
>  				color_space = COLOR_SPACE_YCBCR601;
>  		}
>  		break;
> -	case DRM_MODE_COLORIMETRY_BT601_YCC:
> -		if (dc_crtc_timing->flags.Y_ONLY)
> -			color_space = COLOR_SPACE_YCBCR601_LIMITED;
> -		else
> -			color_space = COLOR_SPACE_YCBCR601;
> -		break;
> -	case DRM_MODE_COLORIMETRY_BT709_YCC:
> -		if (dc_crtc_timing->flags.Y_ONLY)
> -			color_space = COLOR_SPACE_YCBCR709_LIMITED;
> -		else
> -			color_space = COLOR_SPACE_YCBCR709;
> -		break;
> -	case DRM_MODE_COLORIMETRY_OPRGB:
> -		color_space = COLOR_SPACE_ADOBERGB;
> -		break;
> -	case DRM_MODE_COLORIMETRY_BT2020:
> -		color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
> -		break;
> -	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> -		color_space = COLOR_SPACE_2020_YCBCR;
> -		break;
>  	}
>  
>  	return color_space;


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

Re: [PATCH v3 00/17] Enable Colorspace connector property in amdgpu

[Pekka Paalanen]

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

On Tue, 7 Mar 2023 10:10:50 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> This patchset is based on Joshua's previous patchset [1], as well
> as my previous patchset [2].
> 
> It is
> - enabling support for the colorspace property in amdgpu, as well as
> - allowing drivers to specify the supported set of colorspaces, and
> - deprecating the BT2020_YCC and BT2020_RGB properties in favor of
>   a common BT2020 property. We leave the BT2020_CYCC property untouched
>   for now, same as the other _YVV properties. If they'll see use later
>   we might need to do something similar there, or allow userspace to
>   decide on the output encoding (RGB vs YUV).
> 
> Colorspace, Infoframes, and YCbCr matrix
> ---------------------------------------
> 
> Even though the initial intent of the colorspace property was to set the
> colorspace field in the respective HDMI AVI and DP SDP infoframes that
> is not sufficient in all scenarios. For DP the colorspace information
> also affects the MSA (main stream attribute) packet. For YUV output the
> colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace
> field of the infopackets also depends on the encoding used, which is
> something that is decided by the driver and not known to userspace.
> 
> For these reasons a driver will need to be able to select the supported
> colorspaces at property creation.
> 
> Note: There seems to be an understanding that the colorspace property
> should ONLY modify the infoframe. While this is current behavior and
> sufficient in some cases it is nowhere specified that this should be the
> only use of this property. As outlined above this limitation is not
> going to work in all cases.
> 
> This patchset does not affect current behavior for the drivers that
> implement this property: i915 and vc4.
> 
> In the future we might want to give userspace control over the encoding
> format on the wire, in particular to avoid use of YUV420 when image
> fidelity is important. This work would likely go hand in hand with a
> min_bpc property and wouldn't conflict with the work done in this
> patchset.
> 
> Colorspace on crtc or connector?
> --------------------------------
> 
> There have been suggestions of programming 'colorspace' on the drm_crtc
> but I don't think the crtc is the right place for this property. The
> drm_plane and drm_crtc will be used to offload color processing that
> would normally be done via the GFX or other pipelines. The drm_connector
> controls the signalling with the display and ensures the wire format is
> appropriate for the encoding by programming the RGB-to-YCbCr matrix.
> 
> [1] https://patchwork.freedesktop.org/series/113632/
> [2] https://patchwork.freedesktop.org/series/111865/

Hi Harry,

this is a really good cover letter.

I've given all the comments I have on this iteration.


Thanks,
pq

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

Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

[Sebastian Wick]

On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Tue, 7 Mar 2023 10:10:52 -0500
> Harry Wentland <harry.wentland@amd.com> wrote:
>
> > From: Joshua Ashton <joshua@froggi.es>
> >
> > To match the other enums, and add more information about these values.
> >
> > v2:
> >  - Specify where an enum entry comes from
> >  - Clarify DEFAULT and NO_DATA behavior
> >  - BT.2020 CYCC is "constant luminance"
> >  - correct type for BT.601
> >
> > Signed-off-by: Joshua Ashton <joshua@froggi.es>
> > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > Reviewed-by: Harry Wentland <harry.wentland@amd.com>
>
> Hi,
>
> this effort is really good, but of course I still find things to
> nitpick about. If there is no answer to my questions, then I would
> prefer the documentation to spell out the unknowns and ambiguities.
>
> > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > Cc: Vitaly.Prosyak@amd.com
> > Cc: Uma Shankar <uma.shankar@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Joshua Ashton <joshua@froggi.es>
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: amd-gfx@lists.freedesktop.org
> > ---
> >  include/drm/drm_connector.h | 67 +++++++++++++++++++++++++++++++++++--
> >  1 file changed, 65 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 6d6a53a6b010..bb078666dc34 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
> >       PRIVACY_SCREEN_ENABLED_LOCKED,
> >  };
> >
> > -/*
> > - * This is a consolidated colorimetry list supported by HDMI and
> > +/**
> > + * enum drm_colorspace - color space
> > + *
> > + * This enum is a consolidated colorimetry list supported by HDMI and
> >   * DP protocol standard. The respective connectors will register
> >   * a property with the subset of this list (supported by that
> >   * respective protocol). Userspace will set the colorspace through
> >   * a colorspace property which will be created and exposed to
> >   * userspace.
> > + *
> > + * DP definitions come from the DP v2.0 spec
> > + * HDMI definitions come from the CTA-861-H spec
> > + *
> > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > + *   Driver specific behavior.
> > + *   For DP:
> > + *           RGB encoded: sRGB (IEC 61966-2-1)
> > + *           YCbCr encoded: ITU-R BT.601 colorimetry format
>
> Does this mean that HDMI behavior is driver-specific while DP behavior
> is as defined?
>
> Is it intentional that YCbCr encoding also uses different RGB-primaries
> than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
>
> Or do you need to be more explicit on which parts of each spec apply
> (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> CICP parlance)?
>
> E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.

Yeah, just adding to this: The Default Colorspace is something well
defined. CTA-861 says:

"If bits C0 and C1 are zero, the colorimetry shall correspond to the
default colorimetry defined in Section 5.1"

and in Section 5.1

"In all cases described above, the RGB color space used should be the
RGB color space the Sink declares in the Basic Display Parameters and
Feature Block of its EDID."

If I set DRM_MODE_COLORIMETRY_DEFAULT, I expect the Colorimetry the
EDID reports to be in effect and not some driver specific nonsense.

> > + * @DRM_MODE_COLORIMETRY_NO_DATA:
> > + *   Driver specific behavior.
> > + *   For HDMI:
> > + *   Sets "No Data" in infoframe
>
> Does DEFAULT mean that something else than "No Data" may be set in the
> HDMI infoframe?
>
> If so, since these two have the same value, where is the difference? Is
> DEFAULT purely an UAPI token, and NO_DATA used internally? Or NO_DATA
> used only when crafting actual infoframe packets?
>
> Should NO_DATA be documented to be a strictly driver-internal value,
> and not documented with UAPI?
>
> I am unclear if userspace is using these enum values directly, or do
> they use the string names only.
>
> > + * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> > + *   (HDMI)
> > + *   SMPTE ST 170M colorimetry format
>
> Does "colorimetry format" mean that the spec is used in full, for all
> of ColourPrimaries, TransferCharacteristics and MatrixCoefficients?
>
> If yes, good. If not, the wording misleads me.
>
> > + * @DRM_MODE_COLORIMETRY_BT709_YCC:
> > + *   (HDMI, DP)
> > + *   ITU-R BT.709 colorimetry format
> > + * @DRM_MODE_COLORIMETRY_XVYCC_601:
> > + *   (HDMI, DP)
> > + *   xvYCC601 colorimetry format
> > + * @DRM_MODE_COLORIMETRY_XVYCC_709:
> > + *   (HDMI, DP)
> > + *   xvYCC709 colorimetry format
>
> Btw. xvYCC are funny because they require limited quantization range
> encoding, but use the foot- and headroom to encode out-of-nominal-range
> values in order to expand the color gamut with negative and greater
> than unity values.
>
> Just for curiosity, is it in any way possible today to make use of that
> extended color gamut through KMS? Has it ever been possible?
>
> I mean, the KMS color pipeline assumes full-range RGB, so I don't see
> any way to make use of xvYCC.
>
> > + * @DRM_MODE_COLORIMETRY_SYCC_601:
> > + *   (HDMI, DP)
> > + *   sYCC601 colorimetry format
> > + * @DRM_MODE_COLORIMETRY_OPYCC_601:
> > + *   (HDMI, DP)
> > + *   opYCC601 colorimetry format
> > + * @DRM_MODE_COLORIMETRY_OPRGB:
> > + *   (HDMI, DP)
> > + *   opRGB colorimetry format
> > + * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
> > + *   (HDMI, DP)
> > + *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
> > + * @DRM_MODE_COLORIMETRY_BT2020_RGB:
> > + *   (HDMI, DP)
> > + *   ITU-R BT.2020 R' G' B' colorimetry format
> > + * @DRM_MODE_COLORIMETRY_BT2020_YCC:
> > + *   (HDMI, DP)
> > + *   ITU-R BT.2020 Y' C'b C'r colorimetry format
> > + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> > + *   (HDMI)
> > + *   SMPTE ST 2113 P3D65 colorimetry format
> > + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> > + *   (HDMI)
> > + *   SMPTE ST 2113 P3DCI colorimetry format
> > + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
> > + *   (DP)
> > + *   RGB wide gamut fixed point colorimetry format
> > + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
> > + *   (DP)
> > + *   RGB wide gamut floating point
> > + *   (scRGB (IEC 61966-2-2)) colorimetry format
>
> Again, there is no way to actually make use of WIDE since the KMS color
> pipeline is limited to the unit range color values, right? Or is it
> possible by setting all color pipeline KMS properties to pass-through
> and using a floating-point FB?
>
> I suppose the FIXED vs. FLOAT has the exact same problems as BT2020_YCC
> vs. BT2020_RGB, but I would be surprised if anyone cared.
>
> > + * @DRM_MODE_COLORIMETRY_BT601_YCC:
> > + *   (DP)
> > + *   ITU-R BT.601 colorimetry format
> > + *   The DP spec does not say whether this is the 525 or the 625
> > + *   line version.
>
> Good to note that ambiguity here. :-)
>
> Or maybe the DP spec writer was thinking about BT.709 ColourPrimaries
> and BT.601 MatrixCoefficients...
>
> >   */
> >  enum drm_colorspace {
> >       /* For Default case, driver will set the colorspace */
>
>
> Thanks,
> pq

Re: [PATCH v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Sebastian Wick]

On Wed, Mar 8, 2023 at 10:09 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Tue, 7 Mar 2023 10:10:53 -0500
> Harry Wentland <harry.wentland@amd.com> wrote:
>
> > From: Joshua Ashton <joshua@froggi.es>
> >
> > Userspace has no way of controlling or knowing the pixel encoding
> > currently, so there is no way for it to ever get the right values here.
> >
> > When we do add pixel_encoding control from userspace,we can pick the
> > right value for the colorimetry packet based on the
> > pixel_encoding + the colorspace.
> >
> > Let's deprecate these values, and have one BT.2020 colorspace entry
> > that userspace can use.
> >
> > v2:
> >  - leave CYCC alone for now; it serves a purpose
> >  - leave BT2020_RGB the new default BT2020
> >
> > Signed-off-by: Joshua Ashton <joshua@froggi.es>
> > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > Reviewed-by: Harry Wentland <harry.wentland@amd.com>
> >
> > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > Cc: Vitaly.Prosyak@amd.com
> > Cc: Uma Shankar <uma.shankar@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Joshua Ashton <joshua@froggi.es>
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: amd-gfx@lists.freedesktop.org
> > ---
> >  drivers/gpu/drm/display/drm_hdmi_helper.c |  7 +++----
> >  drivers/gpu/drm/drm_connector.c           |  8 ++++----
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 14 +++++++-------
> >  include/drm/drm_connector.h               | 15 +++++++++------
> >  4 files changed, 23 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > index faf5e9efa7d3..05a0d03ffcda 100644
> > --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > @@ -97,8 +97,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> >  #define HDMI_COLORIMETRY_OPYCC_601           (C(3) | EC(3) | ACE(0))
> >  #define HDMI_COLORIMETRY_OPRGB                       (C(3) | EC(4) | ACE(0))
> >  #define HDMI_COLORIMETRY_BT2020_CYCC         (C(3) | EC(5) | ACE(0))
> > -#define HDMI_COLORIMETRY_BT2020_RGB          (C(3) | EC(6) | ACE(0))
> > -#define HDMI_COLORIMETRY_BT2020_YCC          (C(3) | EC(6) | ACE(0))
> > +#define HDMI_COLORIMETRY_BT2020                      (C(3) | EC(6) | ACE(0))
> >  #define HDMI_COLORIMETRY_DCI_P3_RGB_D65              (C(3) | EC(7) | ACE(0))
> >  #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER  (C(3) | EC(7) | ACE(1))
> >
> > @@ -112,8 +111,8 @@ static const u32 hdmi_colorimetry_val[] = {
> >       [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
> >       [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> >       [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> > -     [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> > -     [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
> > +     [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = HDMI_COLORIMETRY_BT2020,
> > +     [DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
> >  };
> >
> >  #undef C
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 61c29ce74b03..fe7eab15f727 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1031,9 +1031,9 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> >       /* Colorimetry based on ITU-R BT.2020 */
> >       { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> >       /* Colorimetry based on ITU-R BT.2020 */
> > -     { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > +     { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> >       /* Colorimetry based on ITU-R BT.2020 */
> > -     { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > +     { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> >       /* Added as part of Additional Colorimetry Extension in 861.G */
> >       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> >       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> > @@ -1054,7 +1054,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >       /* Colorimetry based on SMPTE RP 431-2 */
> >       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> >       /* Colorimetry based on ITU-R BT.2020 */
> > -     { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > +     { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> >       { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> >       { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> >       /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> > @@ -1068,7 +1068,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >       /* Colorimetry based on ITU-R BT.2020 */
> >       { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> >       /* Colorimetry based on ITU-R BT.2020 */
> > -     { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > +     { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
>
> Let's hope no-one complains about missing the old string names in UABI. :-)
>
> Actually, you should write in the commit message why removing old names
> is fine.

Uhm, yeah, I'm just going to do that. This breaks my code! Mutter
actually uses the strings and not the values.

It's still not clear to me if we want to break backwards compatibility
or not. This patch definitely does break backwards compatibility but
it also doesn't get rid of all the other crap, so it's the worst of
both worlds.

> >  };
> >
> >  /**
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > index c9be61d2348e..be100a193bf5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1766,11 +1766,11 @@ static void intel_dp_compute_vsc_colorimetry(const struct intel_crtc_state *crtc
> >       case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> >               vsc->colorimetry = DP_COLORIMETRY_BT2020_CYCC;
> >               break;
> > -     case DRM_MODE_COLORIMETRY_BT2020_RGB:
> > -             vsc->colorimetry = DP_COLORIMETRY_BT2020_RGB;
> > -             break;
> > -     case DRM_MODE_COLORIMETRY_BT2020_YCC:
> > -             vsc->colorimetry = DP_COLORIMETRY_BT2020_YCC;
> > +     case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> > +     case DRM_MODE_COLORIMETRY_BT2020:
> > +             vsc->colorimetry = vsc->pixelformat == DP_PIXELFORMAT_RGB
> > +                     ? DP_COLORIMETRY_BT2020_RGB
> > +                     : DP_COLORIMETRY_BT2020_YCC;
> >               break;
> >       case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> >       case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> > @@ -3043,9 +3043,9 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
> >       switch (conn_state->colorspace) {
> >       case DRM_MODE_COLORIMETRY_SYCC_601:
> >       case DRM_MODE_COLORIMETRY_OPYCC_601:
> > -     case DRM_MODE_COLORIMETRY_BT2020_YCC:
> > -     case DRM_MODE_COLORIMETRY_BT2020_RGB:
> >       case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> > +     case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> > +     case DRM_MODE_COLORIMETRY_BT2020:
> >               return true;
> >       default:
> >               break;
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index bb078666dc34..3e2e1bc7aa04 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -409,12 +409,15 @@ enum drm_privacy_screen_status {
> >   * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
> >   *   (HDMI, DP)
> >   *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
> > - * @DRM_MODE_COLORIMETRY_BT2020_RGB:
> > + * @DRM_MODE_COLORIMETRY_BT2020:
> >   *   (HDMI, DP)
> > - *   ITU-R BT.2020 R' G' B' colorimetry format
> > - * @DRM_MODE_COLORIMETRY_BT2020_YCC:
> > + *   ITU-R BT.2020 [R' G' B'] or
> > + *    ITU-R BT.2020 [Y' C'b C'r] or
> > + *   ITU-R BT.2020 [Y'c C'bc C'rc] (linear)
>
> Drop the constant luminance variant from this value's doc.
>
> > + *   colorimetry format
> > + * @DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> >   *   (HDMI, DP)
> > - *   ITU-R BT.2020 Y' C'b C'r colorimetry format
> > + *   deprecated; same as DRM_MODE_COLORIMETRY_BT2020
> >   * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> >   *   (HDMI)
> >   *   SMPTE ST 2113 P3D65 colorimetry format
> > @@ -448,8 +451,8 @@ enum drm_colorspace {
> >       DRM_MODE_COLORIMETRY_OPYCC_601          = 6,
> >       DRM_MODE_COLORIMETRY_OPRGB              = 7,
> >       DRM_MODE_COLORIMETRY_BT2020_CYCC        = 8,
> > -     DRM_MODE_COLORIMETRY_BT2020_RGB         = 9,
> > -     DRM_MODE_COLORIMETRY_BT2020_YCC         = 10,
> > +     DRM_MODE_COLORIMETRY_BT2020             = 9,
> > +     DRM_MODE_COLORIMETRY_BT2020_DEPRECATED  = 10,
> >       /* Additional Colorimetry extension added as part of CTA 861.G */
> >       DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65     = 11,
> >       DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER = 12,
>
> With the caveat noted and nitpick fixed:
> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
>
>
> Thanks,
> pq

Re: [PATCH v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Ville Syrjälä]

On Thu, Mar 09, 2023 at 02:05:55AM +0100, Sebastian Wick wrote:
> On Wed, Mar 8, 2023 at 10:09 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Tue, 7 Mar 2023 10:10:53 -0500
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >
> > > From: Joshua Ashton <joshua@froggi.es>
> > >
> > > Userspace has no way of controlling or knowing the pixel encoding
> > > currently, so there is no way for it to ever get the right values here.
> > >
> > > When we do add pixel_encoding control from userspace,we can pick the
> > > right value for the colorimetry packet based on the
> > > pixel_encoding + the colorspace.
> > >
> > > Let's deprecate these values, and have one BT.2020 colorspace entry
> > > that userspace can use.
> > >
> > > v2:
> > >  - leave CYCC alone for now; it serves a purpose
> > >  - leave BT2020_RGB the new default BT2020
> > >
> > > Signed-off-by: Joshua Ashton <joshua@froggi.es>
> > > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > > Reviewed-by: Harry Wentland <harry.wentland@amd.com>
> > >
> > > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > > Cc: Vitaly.Prosyak@amd.com
> > > Cc: Uma Shankar <uma.shankar@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Joshua Ashton <joshua@froggi.es>
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: amd-gfx@lists.freedesktop.org
> > > ---
> > >  drivers/gpu/drm/display/drm_hdmi_helper.c |  7 +++----
> > >  drivers/gpu/drm/drm_connector.c           |  8 ++++----
> > >  drivers/gpu/drm/i915/display/intel_dp.c   | 14 +++++++-------
> > >  include/drm/drm_connector.h               | 15 +++++++++------
> > >  4 files changed, 23 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > > index faf5e9efa7d3..05a0d03ffcda 100644
> > > --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > > +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > > @@ -97,8 +97,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> > >  #define HDMI_COLORIMETRY_OPYCC_601           (C(3) | EC(3) | ACE(0))
> > >  #define HDMI_COLORIMETRY_OPRGB                       (C(3) | EC(4) | ACE(0))
> > >  #define HDMI_COLORIMETRY_BT2020_CYCC         (C(3) | EC(5) | ACE(0))
> > > -#define HDMI_COLORIMETRY_BT2020_RGB          (C(3) | EC(6) | ACE(0))
> > > -#define HDMI_COLORIMETRY_BT2020_YCC          (C(3) | EC(6) | ACE(0))
> > > +#define HDMI_COLORIMETRY_BT2020                      (C(3) | EC(6) | ACE(0))
> > >  #define HDMI_COLORIMETRY_DCI_P3_RGB_D65              (C(3) | EC(7) | ACE(0))
> > >  #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER  (C(3) | EC(7) | ACE(1))
> > >
> > > @@ -112,8 +111,8 @@ static const u32 hdmi_colorimetry_val[] = {
> > >       [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
> > >       [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> > >       [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> > > -     [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> > > -     [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
> > > +     [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = HDMI_COLORIMETRY_BT2020,
> > > +     [DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
> > >  };
> > >
> > >  #undef C
> > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > index 61c29ce74b03..fe7eab15f727 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -1031,9 +1031,9 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> > >       /* Colorimetry based on ITU-R BT.2020 */
> > >       { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> > >       /* Colorimetry based on ITU-R BT.2020 */
> > > -     { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > > +     { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> > >       /* Colorimetry based on ITU-R BT.2020 */
> > > -     { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > > +     { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> > >       /* Added as part of Additional Colorimetry Extension in 861.G */
> > >       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> > >       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> > > @@ -1054,7 +1054,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> > >       /* Colorimetry based on SMPTE RP 431-2 */
> > >       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> > >       /* Colorimetry based on ITU-R BT.2020 */
> > > -     { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > > +     { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> > >       { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> > >       { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> > >       /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> > > @@ -1068,7 +1068,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> > >       /* Colorimetry based on ITU-R BT.2020 */
> > >       { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> > >       /* Colorimetry based on ITU-R BT.2020 */
> > > -     { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > > +     { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> >
> > Let's hope no-one complains about missing the old string names in UABI. :-)
> >
> > Actually, you should write in the commit message why removing old names
> > is fine.
> 
> Uhm, yeah, I'm just going to do that. This breaks my code! Mutter
> actually uses the strings and not the values.
> 
> It's still not clear to me if we want to break backwards compatibility
> or not. This patch definitely does break backwards compatibility but
> it also doesn't get rid of all the other crap, so it's the worst of
> both worlds.

Yeah, why are people still massaging this same turd? Wasn't the
earlier conclusion just to define a new property that controls
both the infoframes/msa/sdp stuff and RGB->YCbCr conversion
(if necessary)?

-- 
Ville Syrjälä
Intel

Re: [PATCH v3 05/17] drm/connector: Use common colorspace_names array

[Sebastian Wick]

On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> We an use bitfields to track the support ones for HDMI
> and DP. This allows us to print colorspaces in a consistent
> manner without needing to know whether we're dealing with
> DP or HDMI.
>
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Uma Shankar <uma.shankar@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_connector.c | 131 +++++++++++++++++++-------------
>  include/drm/drm_connector.h     |   1 +
>  2 files changed, 78 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index ff4af48c029a..7649f0ac454f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1012,64 +1012,70 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
>  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>                  drm_dp_subconnector_enum_list)
>
> -static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> +
> +static const char * const colorspace_names[] = {
>         /* For Default case, driver will set the colorspace */
> -       { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> +       [DRM_MODE_COLORIMETRY_DEFAULT] = "Default",
>         /* Standard Definition Colorimetry based on CEA 861 */
> -       { DRM_MODE_COLORIMETRY_SMPTE_170M_YCC, "SMPTE_170M_YCC" },
> -       { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> +       [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = "SMPTE_170M_YCC",
> +       [DRM_MODE_COLORIMETRY_BT709_YCC] = "BT709_YCC",
>         /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> -       { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> +       [DRM_MODE_COLORIMETRY_XVYCC_601] = "XVYCC_601",
>         /* High Definition Colorimetry based on IEC 61966-2-4 */
> -       { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> +       [DRM_MODE_COLORIMETRY_XVYCC_709] = "XVYCC_709",
>         /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> -       { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
> +       [DRM_MODE_COLORIMETRY_SYCC_601] = "SYCC_601",
>         /* Colorimetry based on IEC 61966-2-5 [33] */
> -       { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> +       [DRM_MODE_COLORIMETRY_OPYCC_601] = "opYCC_601",
>         /* Colorimetry based on IEC 61966-2-5 */
> -       { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> +       [DRM_MODE_COLORIMETRY_OPRGB] = "opRGB",
>         /* Colorimetry based on ITU-R BT.2020 */
> -       { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> +       [DRM_MODE_COLORIMETRY_BT2020_CYCC] = "BT2020_CYCC",
>         /* Colorimetry based on ITU-R BT.2020 */
> -       { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> +       [DRM_MODE_COLORIMETRY_BT2020] = "BT2020",
>         /* Colorimetry based on ITU-R BT.2020 */
> -       { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> -       /* Added as part of Additional Colorimetry Extension in 861.G */
> -       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> -       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> +       [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = "BT2020_DEPRECATED",
> +       /* Colorimetry based on SMPTE RP 431-2 */
> +       [DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65] = "P3_RGB_D65",
> +       [DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER] = "P3_RGB_Theater",
> +       [DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED] = "RGB_WIDE_FIXED",
> +       /* Colorimetry based on scRGB (IEC 61966-2-2) */
> +       [DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT] = "RGB_WIDE_FLOAT",
> +       [DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
>  };
>
> +static const u32 hdmi_colorspaces =
> +       BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
> +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> +       BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
> +       BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
> +       BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
> +       BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
> +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED) |
> +       BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> +       BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> +
>  /*
>   * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
>   * Format Table 2-120
>   */
> -static const struct drm_prop_enum_list dp_colorspaces[] = {
> -       /* For Default case, driver will set the colorspace */
> -       { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> -       { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
> -       /* Colorimetry based on scRGB (IEC 61966-2-2) */
> -       { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point" },
> -       /* Colorimetry based on IEC 61966-2-5 */
> -       { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> -       /* Colorimetry based on SMPTE RP 431-2 */
> -       { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> -       /* Colorimetry based on ITU-R BT.2020 */
> -       { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> -       { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> -       { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> -       /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> -       { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> -       /* High Definition Colorimetry based on IEC 61966-2-4 */
> -       { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> -       /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> -       { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
> -       /* Colorimetry based on IEC 61966-2-5 [33] */
> -       { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> -       /* Colorimetry based on ITU-R BT.2020 */
> -       { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> -       /* Colorimetry based on ITU-R BT.2020 */
> -       { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> -};
> +static const u32 dp_colorspaces =
> +       BIT(DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED) |
> +       BIT(DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT) |
> +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> +       BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> +       BIT(DRM_MODE_COLORIMETRY_BT601_YCC) |
> +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> +       BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
> +       BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
> +       BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
> +       BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
>
>  /**
>   * DOC: standard connector properties
> @@ -1972,30 +1978,49 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
>   */
>
>  static int drm_mode_create_colorspace_property(struct drm_connector *connector,
> -                                       const struct drm_prop_enum_list *colorspaces,
> -                                       int size)
> +                                       u32 supported_colorspaces)
>  {
>         struct drm_device *dev = connector->dev;
> +       u32 colorspaces = supported_colorspaces | BIT(DRM_MODE_COLORIMETRY_DEFAULT);
> +       struct drm_prop_enum_list enum_list[DRM_MODE_COLORIMETRY_MAX];
> +       int i, len;
>
>         if (connector->colorspace_property)
>                 return 0;
>
> -       if (!colorspaces)
> -               return 0;
> +       if (!supported_colorspaces)
> +               drm_dbg_kms(dev, "Driver is not passing supported colorspaces on [CONNECTOR:%d:%s]\n",
> +                           connector->base.id, connector->name);
> +
> +       if ((supported_colorspaces & -BIT(DRM_MODE_COLORIMETRY_MAX)) != 0)
> +               return -EINVAL;
> +
> +       len = 0;
> +       for (i = 0; i < DRM_MODE_COLORIMETRY_MAX; i++) {
> +               if (supported_colorspaces != 0 && (colorspaces & BIT(i)) == 0)
> +                       continue;
> +
> +               enum_list[len].type = i;
> +               enum_list[len].name = colorspace_names[i];
> +               len++;
> +       }
>
>         connector->colorspace_property =
>                 drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
> -                                       colorspaces,
> -                                       size);
> +                                       enum_list,
> +                                       len);
>
>         if (!connector->colorspace_property)
>                 return -ENOMEM;
>
>         return 0;
>  }
> +
>  /**
>   * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
>   * @connector: connector to create the Colorspace property on.
> + * @supported_colorspaces: A bitfield of supported colorspaces or 0 for all
> + *                         HDMI colorspaces

That belongs in a later patch. Same on drm_mode_create_dp_colorspace_property.

>   *
>   * Called by a driver the first time it's needed, must be attached to desired
>   * HDMI connectors.
> @@ -2005,15 +2030,15 @@ static int drm_mode_create_colorspace_property(struct drm_connector *connector,
>   */
>  int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
>  {
> -       return drm_mode_create_colorspace_property(connector,
> -                                                  hdmi_colorspaces,
> -                                                  ARRAY_SIZE(hdmi_colorspaces));
> +       return drm_mode_create_colorspace_property(connector, hdmi_colorspaces);
>  }
>  EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
>
>  /**
>   * drm_mode_create_dp_colorspace_property - create dp colorspace property
>   * @connector: connector to create the Colorspace property on.
> + * @supported_colorspaces: A bitfield of supported colorspaces or 0 for all
> + *                         DP colorspaces
>   *
>   * Called by a driver the first time it's needed, must be attached to desired
>   * DP connectors.
> @@ -2023,9 +2048,7 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
>   */
>  int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
>  {
> -       return drm_mode_create_colorspace_property(connector,
> -                                                  dp_colorspaces,
> -                                                  ARRAY_SIZE(dp_colorspaces));
> +       return drm_mode_create_colorspace_property(connector, dp_colorspaces);
>  }
>  EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 3e2e1bc7aa04..46c064d9ffef 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -460,6 +460,7 @@ enum drm_colorspace {
>         DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED     = 13,
>         DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT     = 14,
>         DRM_MODE_COLORIMETRY_BT601_YCC          = 15,
> +       DRM_MODE_COLORIMETRY_MAX
>  };
>
>  /**
> --
> 2.39.2
>

Re: [PATCH v3 11/17] drm/amd/display: Send correct DP colorspace infopacket

[Sebastian Wick]

On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> Look at connector->colorimetry to determine output colorspace.
>
> We don't want to impact current SDR behavior, so
> DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
>
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Reviewed-By: Joshua Ashton <joshua@froggi.es>
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 +++++++++++--------
>  1 file changed, 22 insertions(+), 16 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 58fc719bec8d..cdfd09d50ee6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5302,21 +5302,21 @@ 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,
> +                      const struct drm_connector_state *connector_state)
>  {
>         enum dc_color_space color_space = COLOR_SPACE_SRGB;
>
> -       switch (dc_crtc_timing->pixel_encoding) {
> -       case PIXEL_ENCODING_YCBCR422:
> -       case PIXEL_ENCODING_YCBCR444:
> -       case PIXEL_ENCODING_YCBCR420:
> -       {
> +       switch (connector_state->colorspace) {
> +       case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601

So, I do get random behavior with DRM_MODE_COLORIMETRY_DEFAULT instead
of the colorimetry that the EDID specifies? That doesn't sound good at
all.

> +               if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
> +                       color_space = COLOR_SPACE_SRGB;
>                 /*
>                  * 27030khz is the separation point between HDTV and SDTV
>                  * according to HDMI spec, we use YCbCr709 and YCbCr601
>                  * respectively
>                  */
> -               if (dc_crtc_timing->pix_clk_100hz > 270300) {
> +               } else if (dc_crtc_timing->pix_clk_100hz > 270300) {
>                         if (dc_crtc_timing->flags.Y_ONLY)
>                                 color_space =
>                                         COLOR_SPACE_YCBCR709_LIMITED;
> @@ -5329,15 +5329,21 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>                         else
>                                 color_space = COLOR_SPACE_YCBCR601;
>                 }
> -
> -       }
> -       break;
> -       case PIXEL_ENCODING_RGB:
> -               color_space = COLOR_SPACE_SRGB;
>                 break;
> -
> -       default:
> -               WARN_ON(1);
> +       case DRM_MODE_COLORIMETRY_BT709_YCC:
> +               if (dc_crtc_timing->flags.Y_ONLY)
> +                       color_space = COLOR_SPACE_YCBCR709_LIMITED;
> +               else
> +                       color_space = COLOR_SPACE_YCBCR709;
> +               break;
> +       case DRM_MODE_COLORIMETRY_OPRGB:
> +               color_space = COLOR_SPACE_ADOBERGB;
> +               break;
> +       case DRM_MODE_COLORIMETRY_BT2020:
> +               color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
> +               break;
> +       case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> +               color_space = COLOR_SPACE_2020_YCBCR;
>                 break;
>         }
>
> @@ -5476,7 +5482,7 @@ static void fill_stream_properties_from_drm_display_mode(
>                 }
>         }
>
> -       stream->output_color_space = get_output_color_space(timing_out);
> +       stream->output_color_space = get_output_color_space(timing_out, connector_state);
>  }
>
>  static void fill_audio_info(struct audio_info *audio_info,
> --
> 2.39.2
>

Re: [PATCH v3 14/17] drm/amd/display: Add debugfs for testing output colorspace

[Sebastian Wick]

On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> In order to IGT test colorspace we'll want to print
> the currently enabled colorspace on a stream. We add
> a new debugfs to do so, using the same scheme as
> current bpc reporting.
>
> This might also come in handy when debugging display
> issues.
>
> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Reviewed-By: Joshua Ashton <joshua@froggi.es>
> ---
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 4a5dae578d97..f0022c16b708 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -906,6 +906,61 @@ static int amdgpu_current_bpc_show(struct seq_file *m, void *data)
>  }
>  DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
>
> +/*
> + * Returns the current bpc for the crtc.
> + * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_colorspace
> + */
> +static int amdgpu_current_colorspace_show(struct seq_file *m, void *data)
> +{
> +       struct drm_crtc *crtc = m->private;
> +       struct drm_device *dev = crtc->dev;
> +       struct dm_crtc_state *dm_crtc_state = NULL;
> +       int res = -ENODEV;
> +
> +       mutex_lock(&dev->mode_config.mutex);
> +       drm_modeset_lock(&crtc->mutex, NULL);
> +       if (crtc->state == NULL)
> +               goto unlock;
> +
> +       dm_crtc_state = to_dm_crtc_state(crtc->state);
> +       if (dm_crtc_state->stream == NULL)
> +               goto unlock;
> +
> +       switch (dm_crtc_state->stream->output_color_space) {
> +       case COLOR_SPACE_SRGB:
> +               seq_printf(m, "RGB");
> +               break;

Why does it print "RGB" when it says the color space is sRGB? Looking
at the value when I didn't specify any color space it says RGB. Why is
your default color space sRGB?


> +       case COLOR_SPACE_YCBCR601:
> +       case COLOR_SPACE_YCBCR601_LIMITED:
> +               seq_printf(m, "BT601_YCC");
> +               break;
> +       case COLOR_SPACE_YCBCR709:
> +       case COLOR_SPACE_YCBCR709_LIMITED:
> +               seq_printf(m, "BT709_YCC");
> +               break;
> +       case COLOR_SPACE_ADOBERGB:
> +               seq_printf(m, "opRGB");
> +               break;
> +       case COLOR_SPACE_2020_RGB_FULLRANGE:
> +               seq_printf(m, "BT2020_RGB");
> +               break;
> +       case COLOR_SPACE_2020_YCBCR:
> +               seq_printf(m, "BT2020_YCC");
> +               break;
> +       default:
> +               goto unlock;
> +       }
> +       res = 0;
> +
> +unlock:
> +       drm_modeset_unlock(&crtc->mutex);
> +       mutex_unlock(&dev->mode_config.mutex);
> +
> +       return res;
> +}
> +DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);
> +
> +
>  /*
>   * Example usage:
>   * Disable dsc passthrough, i.e.,: have dsc decoding at converver, not external RX
> @@ -3235,6 +3290,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
>  #endif
>         debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
>                             crtc, &amdgpu_current_bpc_fops);
> +       debugfs_create_file("amdgpu_current_colorspace", 0644, crtc->debugfs_entry,
> +                           crtc, &amdgpu_current_colorspace_fops);
>  }
>
>  /*
> --
> 2.39.2
>

Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

[Pekka Paalanen]

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

On Thu, 9 Mar 2023 01:56:11 +0100
Sebastian Wick <sebastian.wick@redhat.com> wrote:

> On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Tue, 7 Mar 2023 10:10:52 -0500
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >  
> > > From: Joshua Ashton <joshua@froggi.es>
> > >
> > > To match the other enums, and add more information about these values.
> > >
> > > v2:
> > >  - Specify where an enum entry comes from
> > >  - Clarify DEFAULT and NO_DATA behavior
> > >  - BT.2020 CYCC is "constant luminance"
> > >  - correct type for BT.601
> > >
> > > Signed-off-by: Joshua Ashton <joshua@froggi.es>
> > > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > > Reviewed-by: Harry Wentland <harry.wentland@amd.com>  
> >
> > Hi,
> >
> > this effort is really good, but of course I still find things to
> > nitpick about. If there is no answer to my questions, then I would
> > prefer the documentation to spell out the unknowns and ambiguities.
> >  
> > > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > > Cc: Vitaly.Prosyak@amd.com
> > > Cc: Uma Shankar <uma.shankar@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Joshua Ashton <joshua@froggi.es>
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: amd-gfx@lists.freedesktop.org
> > > ---
> > >  include/drm/drm_connector.h | 67 +++++++++++++++++++++++++++++++++++--
> > >  1 file changed, 65 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index 6d6a53a6b010..bb078666dc34 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
> > >       PRIVACY_SCREEN_ENABLED_LOCKED,
> > >  };
> > >
> > > -/*
> > > - * This is a consolidated colorimetry list supported by HDMI and
> > > +/**
> > > + * enum drm_colorspace - color space
> > > + *
> > > + * This enum is a consolidated colorimetry list supported by HDMI and
> > >   * DP protocol standard. The respective connectors will register
> > >   * a property with the subset of this list (supported by that
> > >   * respective protocol). Userspace will set the colorspace through
> > >   * a colorspace property which will be created and exposed to
> > >   * userspace.
> > > + *
> > > + * DP definitions come from the DP v2.0 spec
> > > + * HDMI definitions come from the CTA-861-H spec
> > > + *
> > > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > > + *   Driver specific behavior.
> > > + *   For DP:
> > > + *           RGB encoded: sRGB (IEC 61966-2-1)
> > > + *           YCbCr encoded: ITU-R BT.601 colorimetry format  
> >
> > Does this mean that HDMI behavior is driver-specific while DP behavior
> > is as defined?
> >
> > Is it intentional that YCbCr encoding also uses different RGB-primaries
> > than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
> >
> > Or do you need to be more explicit on which parts of each spec apply
> > (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> > CICP parlance)?
> >
> > E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.  
> 
> Yeah, just adding to this: The Default Colorspace is something well
> defined. CTA-861 says:
> 
> "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> default colorimetry defined in Section 5.1"
> 
> and in Section 5.1
> 
> "In all cases described above, the RGB color space used should be the
> RGB color space the Sink declares in the Basic Display Parameters and
> Feature Block of its EDID."
> 
> If I set DRM_MODE_COLORIMETRY_DEFAULT, I expect the Colorimetry the
> EDID reports to be in effect and not some driver specific nonsense.

Does that also define the MatrixCoefficients for YCbCr signal with
DRM_MODE_COLORIMETRY_DEFAULT?

Not that userspace would even care, since RGB-to-YCbCr is all
driver-internal.

It is interesting you point that out. I guess it means that the basic
colorimetry from EDID is supposed to be really only the default
colorimetry and might not have anything to do with the actual panel
primaries.


Thanks,
pq

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

Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

[Sebastian Wick]

On Thu, Mar 9, 2023 at 11:03 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Thu, 9 Mar 2023 01:56:11 +0100
> Sebastian Wick <sebastian.wick@redhat.com> wrote:
>
> > On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
> > > On Tue, 7 Mar 2023 10:10:52 -0500
> > > Harry Wentland <harry.wentland@amd.com> wrote:
> > >
> > > > From: Joshua Ashton <joshua@froggi.es>
> > > >
> > > > To match the other enums, and add more information about these values.
> > > >
> > > > v2:
> > > >  - Specify where an enum entry comes from
> > > >  - Clarify DEFAULT and NO_DATA behavior
> > > >  - BT.2020 CYCC is "constant luminance"
> > > >  - correct type for BT.601
> > > >
> > > > Signed-off-by: Joshua Ashton <joshua@froggi.es>
> > > > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > > > Reviewed-by: Harry Wentland <harry.wentland@amd.com>
> > >
> > > Hi,
> > >
> > > this effort is really good, but of course I still find things to
> > > nitpick about. If there is no answer to my questions, then I would
> > > prefer the documentation to spell out the unknowns and ambiguities.
> > >
> > > > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > > > Cc: Vitaly.Prosyak@amd.com
> > > > Cc: Uma Shankar <uma.shankar@intel.com>
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Cc: Joshua Ashton <joshua@froggi.es>
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: amd-gfx@lists.freedesktop.org
> > > > ---
> > > >  include/drm/drm_connector.h | 67 +++++++++++++++++++++++++++++++++++--
> > > >  1 file changed, 65 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > index 6d6a53a6b010..bb078666dc34 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
> > > >       PRIVACY_SCREEN_ENABLED_LOCKED,
> > > >  };
> > > >
> > > > -/*
> > > > - * This is a consolidated colorimetry list supported by HDMI and
> > > > +/**
> > > > + * enum drm_colorspace - color space
> > > > + *
> > > > + * This enum is a consolidated colorimetry list supported by HDMI and
> > > >   * DP protocol standard. The respective connectors will register
> > > >   * a property with the subset of this list (supported by that
> > > >   * respective protocol). Userspace will set the colorspace through
> > > >   * a colorspace property which will be created and exposed to
> > > >   * userspace.
> > > > + *
> > > > + * DP definitions come from the DP v2.0 spec
> > > > + * HDMI definitions come from the CTA-861-H spec
> > > > + *
> > > > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > > > + *   Driver specific behavior.
> > > > + *   For DP:
> > > > + *           RGB encoded: sRGB (IEC 61966-2-1)
> > > > + *           YCbCr encoded: ITU-R BT.601 colorimetry format
> > >
> > > Does this mean that HDMI behavior is driver-specific while DP behavior
> > > is as defined?
> > >
> > > Is it intentional that YCbCr encoding also uses different RGB-primaries
> > > than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
> > >
> > > Or do you need to be more explicit on which parts of each spec apply
> > > (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> > > CICP parlance)?
> > >
> > > E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.
> >
> > Yeah, just adding to this: The Default Colorspace is something well
> > defined. CTA-861 says:
> >
> > "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> > default colorimetry defined in Section 5.1"
> >
> > and in Section 5.1
> >
> > "In all cases described above, the RGB color space used should be the
> > RGB color space the Sink declares in the Basic Display Parameters and
> > Feature Block of its EDID."
> >
> > If I set DRM_MODE_COLORIMETRY_DEFAULT, I expect the Colorimetry the
> > EDID reports to be in effect and not some driver specific nonsense.
>
> Does that also define the MatrixCoefficients for YCbCr signal with
> DRM_MODE_COLORIMETRY_DEFAULT?

Good question. It doesn't seem like it does, which would make
supporting YCC with the default color space impossible.

> Not that userspace would even care, since RGB-to-YCbCr is all
> driver-internal.
>
> It is interesting you point that out. I guess it means that the basic
> colorimetry from EDID is supposed to be really only the default
> colorimetry and might not have anything to do with the actual panel
> primaries.
>
>
> Thanks,
> pq

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Sebastian Wick]

On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> We want compositors to be able to set the output
> colorspace on DP and HDMI outputs, based on the
> caps reported from the receiver via EDID.

About that... The documentation says that user space has to check the
EDID for what the sink actually supports. So whatever is in
supported_colorspaces is just what the driver/hardware is able to set
but doesn't actually indicate that the sink supports it.

So the only way to enable bt2020 is by checking if the sink supports
both RGB and YUV variants because both could be used by the driver.
Not great at all. Something to remember for the new property.

> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Sebastian Wick <sebastian.wick@redhat.com>
> Cc: Vitaly.Prosyak@amd.com
> Cc: Joshua Ashton <joshua@froggi.es>
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Reviewed-By: Joshua Ashton <joshua@froggi.es>
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
>  1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
>         return amdgpu_dm_connector->num_modes;
>  }
>
> +static const u32 supported_colorspaces =
> +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> +
>  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>                                      struct amdgpu_dm_connector *aconnector,
>                                      int connector_type,
> @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>                                 adev->mode_info.abm_level_property, 0);
>         }
>
> +       if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> +               if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
> +                       drm_connector_attach_colorspace_property(&aconnector->base);
> +       } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> +                  connector_type == DRM_MODE_CONNECTOR_eDP) {
> +               if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
> +                       drm_connector_attach_colorspace_property(&aconnector->base);
> +       }
> +
>         if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>             connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>             connector_type == DRM_MODE_CONNECTOR_eDP) {
> --
> 2.39.2
>

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> >
> > We want compositors to be able to set the output
> > colorspace on DP and HDMI outputs, based on the
> > caps reported from the receiver via EDID.
> 
> About that... The documentation says that user space has to check the
> EDID for what the sink actually supports. So whatever is in
> supported_colorspaces is just what the driver/hardware is able to set
> but doesn't actually indicate that the sink supports it.
> 
> So the only way to enable bt2020 is by checking if the sink supports
> both RGB and YUV variants because both could be used by the driver.
> Not great at all. Something to remember for the new property.

Hmm. I wonder if that's even legal... Looks like maybe it
is since I can't immediately spot anything in CTA-861 to
forbid it :/

> 
> > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > Cc: Vitaly.Prosyak@amd.com
> > Cc: Joshua Ashton <joshua@froggi.es>
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: amd-gfx@lists.freedesktop.org
> > Reviewed-By: Joshua Ashton <joshua@froggi.es>
> > ---
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
> >  1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
> >         return amdgpu_dm_connector->num_modes;
> >  }
> >
> > +static const u32 supported_colorspaces =
> > +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> > +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> > +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> > +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> > +
> >  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> >                                      struct amdgpu_dm_connector *aconnector,
> >                                      int connector_type,
> > @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> >                                 adev->mode_info.abm_level_property, 0);
> >         }
> >
> > +       if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> > +               if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
> > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > +       } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > +                  connector_type == DRM_MODE_CONNECTOR_eDP) {
> > +               if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
> > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > +       }
> > +
> >         if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> >             connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> >             connector_type == DRM_MODE_CONNECTOR_eDP) {
> > --
> > 2.39.2
> >

-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Pekka Paalanen]

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

On Thu, 16 Mar 2023 11:50:27 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:  
> > >
> > > We want compositors to be able to set the output
> > > colorspace on DP and HDMI outputs, based on the
> > > caps reported from the receiver via EDID.  
> > 
> > About that... The documentation says that user space has to check the
> > EDID for what the sink actually supports. So whatever is in
> > supported_colorspaces is just what the driver/hardware is able to set
> > but doesn't actually indicate that the sink supports it.
> > 
> > So the only way to enable bt2020 is by checking if the sink supports
> > both RGB and YUV variants because both could be used by the driver.
> > Not great at all. Something to remember for the new property.  
> 
> Hmm. I wonder if that's even legal... Looks like maybe it
> is since I can't immediately spot anything in CTA-861 to
> forbid it :/

Wouldn't the driver do the same EDID check before choosing whether it
uses RGB or YCbCr signalling?

So if EDID says only one of them is supported, userspace should be
confident that that is the BT2020 mode the driver will match?


Thanks,
pq

> 
> >   
> > > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > > Cc: Vitaly.Prosyak@amd.com
> > > Cc: Joshua Ashton <joshua@froggi.es>
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: amd-gfx@lists.freedesktop.org
> > > Reviewed-By: Joshua Ashton <joshua@froggi.es>
> > > ---
> > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
> > >  1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
> > >         return amdgpu_dm_connector->num_modes;
> > >  }
> > >
> > > +static const u32 supported_colorspaces =
> > > +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> > > +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> > > +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> > > +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> > > +
> > >  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > >                                      struct amdgpu_dm_connector *aconnector,
> > >                                      int connector_type,
> > > @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > >                                 adev->mode_info.abm_level_property, 0);
> > >         }
> > >
> > > +       if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> > > +               if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
> > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > +       } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > > +                  connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > +               if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
> > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > +       }
> > > +
> > >         if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > >             connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > >             connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > --
> > > 2.39.2
> > >  
> 


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

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> On Thu, 16 Mar 2023 11:50:27 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:  
> > > >
> > > > We want compositors to be able to set the output
> > > > colorspace on DP and HDMI outputs, based on the
> > > > caps reported from the receiver via EDID.  
> > > 
> > > About that... The documentation says that user space has to check the
> > > EDID for what the sink actually supports. So whatever is in
> > > supported_colorspaces is just what the driver/hardware is able to set
> > > but doesn't actually indicate that the sink supports it.
> > > 
> > > So the only way to enable bt2020 is by checking if the sink supports
> > > both RGB and YUV variants because both could be used by the driver.
> > > Not great at all. Something to remember for the new property.  
> > 
> > Hmm. I wonder if that's even legal... Looks like maybe it
> > is since I can't immediately spot anything in CTA-861 to
> > forbid it :/
> 
> Wouldn't the driver do the same EDID check before choosing whether it
> uses RGB or YCbCr signalling?

I suppose it could. The modeset would then fail, which is perhaps
not a huge issue, except maybe for suspend+resume if we fail in
the resume path. Although I guess the EDID/etc. should not yet
be refreshed at that point so if the modeset worked before suspend
resume should be able to restore it without failures.

> 
> So if EDID says only one of them is supported, userspace should be
> confident that that is the BT2020 mode the driver will match?
> 
> 
> Thanks,
> pq
> 
> > 
> > >   
> > > > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > > > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > > > Cc: Vitaly.Prosyak@amd.com
> > > > Cc: Joshua Ashton <joshua@froggi.es>
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: amd-gfx@lists.freedesktop.org
> > > > Reviewed-By: Joshua Ashton <joshua@froggi.es>
> > > > ---
> > > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
> > > >  1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
> > > >         return amdgpu_dm_connector->num_modes;
> > > >  }
> > > >
> > > > +static const u32 supported_colorspaces =
> > > > +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> > > > +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> > > > +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> > > > +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> > > > +
> > > >  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > > >                                      struct amdgpu_dm_connector *aconnector,
> > > >                                      int connector_type,
> > > > @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > > >                                 adev->mode_info.abm_level_property, 0);
> > > >         }
> > > >
> > > > +       if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> > > > +               if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
> > > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > > +       } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > > > +                  connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > > +               if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
> > > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > > +       }
> > > > +
> > > >         if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > > >             connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > > >             connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > > --
> > > > 2.39.2
> > > >  
> > 
> 



-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Pekka Paalanen]

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

On Thu, 16 Mar 2023 12:47:51 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > On Thu, 16 Mar 2023 11:50:27 +0200
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >   
> > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:  
> > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:    
> > > > >
> > > > > We want compositors to be able to set the output
> > > > > colorspace on DP and HDMI outputs, based on the
> > > > > caps reported from the receiver via EDID.    
> > > > 
> > > > About that... The documentation says that user space has to check the
> > > > EDID for what the sink actually supports. So whatever is in
> > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > but doesn't actually indicate that the sink supports it.
> > > > 
> > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > both RGB and YUV variants because both could be used by the driver.
> > > > Not great at all. Something to remember for the new property.    
> > > 
> > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > is since I can't immediately spot anything in CTA-861 to
> > > forbid it :/  
> > 
> > Wouldn't the driver do the same EDID check before choosing whether it
> > uses RGB or YCbCr signalling?  
> 
> I suppose it could. The modeset would then fail, which is perhaps

Could? What are they missing?

I mean, drivers are already automatically choosing between RGB and YCbCr
signalling based on e.g. available bandwidth. Surely they already will
not attempt to send a signal format to a monitor that does not say it
supports that?

> not a huge issue, except maybe for suspend+resume if we fail in
> the resume path. Although I guess the EDID/etc. should not yet
> be refreshed at that point so if the modeset worked before suspend
> resume should be able to restore it without failures.

I assumed that if a monitor can be driven, and it supports any BT2020
format, then it always supports the BT2020 format it is being driven
in (RGB vs. YCbCr flavors). Bad assumption?


Thanks,
pq

> > 
> > So if EDID says only one of them is supported, userspace should be
> > confident that that is the BT2020 mode the driver will match?
> > 
> > 
> > Thanks,
> > pq
> >   
> > >   
> > > >     
> > > > > Signed-off-by: Harry Wentland <harry.wentland@amd.com>
> > > > > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > > > Cc: Sebastian Wick <sebastian.wick@redhat.com>
> > > > > Cc: Vitaly.Prosyak@amd.com
> > > > > Cc: Joshua Ashton <joshua@froggi.es>
> > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > Cc: amd-gfx@lists.freedesktop.org
> > > > > Reviewed-By: Joshua Ashton <joshua@froggi.es>
> > > > > ---
> > > > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
> > > > >  1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
> > > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
> > > > >         return amdgpu_dm_connector->num_modes;
> > > > >  }
> > > > >
> > > > > +static const u32 supported_colorspaces =
> > > > > +       BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> > > > > +       BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> > > > > +       BIT(DRM_MODE_COLORIMETRY_BT2020) |
> > > > > +       BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> > > > > +
> > > > >  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > > > >                                      struct amdgpu_dm_connector *aconnector,
> > > > >                                      int connector_type,
> > > > > @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> > > > >                                 adev->mode_info.abm_level_property, 0);
> > > > >         }
> > > > >
> > > > > +       if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> > > > > +               if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
> > > > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > > > +       } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > > > > +                  connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > > > +               if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
> > > > > +                       drm_connector_attach_colorspace_property(&aconnector->base);
> > > > > +       }
> > > > > +
> > > > >         if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > > > >             connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > > > >             connector_type == DRM_MODE_CONNECTOR_eDP) {
> > > > > --
> > > > > 2.39.2
> > > > >    
> > >   
> >   
> 
> 
> 


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

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> On Thu, 16 Mar 2023 12:47:51 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > >   
> > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:  
> > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:    
> > > > > >
> > > > > > We want compositors to be able to set the output
> > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > caps reported from the receiver via EDID.    
> > > > > 
> > > > > About that... The documentation says that user space has to check the
> > > > > EDID for what the sink actually supports. So whatever is in
> > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > but doesn't actually indicate that the sink supports it.
> > > > > 
> > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > Not great at all. Something to remember for the new property.    
> > > > 
> > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > is since I can't immediately spot anything in CTA-861 to
> > > > forbid it :/  
> > > 
> > > Wouldn't the driver do the same EDID check before choosing whether it
> > > uses RGB or YCbCr signalling?  
> > 
> > I suppose it could. The modeset would then fail, which is perhaps
> 
> Could? What are they missing?

The fact that the new property that also affects the rgb->ycbcr matrix
doesn't even exist?

> 
> I mean, drivers are already automatically choosing between RGB and YCbCr
> signalling based on e.g. available bandwidth. Surely they already will
> not attempt to send a signal format to a monitor that does not say it
> supports that?

We just signal default/bt.709 colorimetry. There is nothing to
check for those IIRC.

> 
> > not a huge issue, except maybe for suspend+resume if we fail in
> > the resume path. Although I guess the EDID/etc. should not yet
> > be refreshed at that point so if the modeset worked before suspend
> > resume should be able to restore it without failures.
> 
> I assumed that if a monitor can be driven, and it supports any BT2020
> format, then it always supports the BT2020 format it is being driven
> in (RGB vs. YCbCr flavors). Bad assumption?

I didn't spot any rule that both must be there. But didn't look
too hard either.

-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Sebastian Wick]

On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > On Thu, 16 Mar 2023 12:47:51 +0200
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >
> > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > > >
> > > > > > > We want compositors to be able to set the output
> > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > caps reported from the receiver via EDID.
> > > > > >
> > > > > > About that... The documentation says that user space has to check the
> > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > but doesn't actually indicate that the sink supports it.
> > > > > >
> > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > Not great at all. Something to remember for the new property.
> > > > >
> > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > forbid it :/
> > > >
> > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > uses RGB or YCbCr signalling?
> > >
> > > I suppose it could. The modeset would then fail, which is perhaps
> >
> > Could? What are they missing?
>
> The fact that the new property that also affects the rgb->ycbcr matrix
> doesn't even exist?

I think the question was about the current Colorspace property.

> >
> > I mean, drivers are already automatically choosing between RGB and YCbCr
> > signalling based on e.g. available bandwidth. Surely they already will
> > not attempt to send a signal format to a monitor that does not say it
> > supports that?

That's exactly what they do. The drivers don't check the EDID for the
colorimetry the sink supports and the responsibility is punted off to
user space.

>
> We just signal default/bt.709 colorimetry. There is nothing to
> check for those IIRC.

You do support bt.2020, no?

> >
> > > not a huge issue, except maybe for suspend+resume if we fail in
> > > the resume path. Although I guess the EDID/etc. should not yet
> > > be refreshed at that point so if the modeset worked before suspend
> > > resume should be able to restore it without failures.
> >
> > I assumed that if a monitor can be driven, and it supports any BT2020
> > format, then it always supports the BT2020 format it is being driven
> > in (RGB vs. YCbCr flavors). Bad assumption?
>
> I didn't spot any rule that both must be there. But didn't look
> too hard either.

Didn't see anything like that either and I looked a bit harder as well.

>
> --
> Ville Syrjälä
> Intel
>

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > >
> > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > > > >
> > > > > > > > We want compositors to be able to set the output
> > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > caps reported from the receiver via EDID.
> > > > > > >
> > > > > > > About that... The documentation says that user space has to check the
> > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > >
> > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > Not great at all. Something to remember for the new property.
> > > > > >
> > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > forbid it :/
> > > > >
> > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > uses RGB or YCbCr signalling?
> > > >
> > > > I suppose it could. The modeset would then fail, which is perhaps
> > >
> > > Could? What are they missing?
> >
> > The fact that the new property that also affects the rgb->ycbcr matrix
> > doesn't even exist?
> 
> I think the question was about the current Colorspace property.
> 
> > >
> > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > signalling based on e.g. available bandwidth. Surely they already will
> > > not attempt to send a signal format to a monitor that does not say it
> > > supports that?
> 
> That's exactly what they do. The drivers don't check the EDID for the
> colorimetry the sink supports and the responsibility is punted off to
> user space.
> 
> >
> > We just signal default/bt.709 colorimetry. There is nothing to
> > check for those IIRC.
> 
> You do support bt.2020, no?

Not for rgb->ycbcr conversion.

> 
> > >
> > > > not a huge issue, except maybe for suspend+resume if we fail in
> > > > the resume path. Although I guess the EDID/etc. should not yet
> > > > be refreshed at that point so if the modeset worked before suspend
> > > > resume should be able to restore it without failures.
> > >
> > > I assumed that if a monitor can be driven, and it supports any BT2020
> > > format, then it always supports the BT2020 format it is being driven
> > > in (RGB vs. YCbCr flavors). Bad assumption?
> >
> > I didn't spot any rule that both must be there. But didn't look
> > too hard either.
> 
> Didn't see anything like that either and I looked a bit harder as well.
> 
> >
> > --
> > Ville Syrjälä
> > Intel
> >

-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Pekka Paalanen]

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

On Fri, 17 Mar 2023 01:01:38 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:  
> > >
> > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:  
> > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > >  
> > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:  
> > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > >  
> > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:  
> > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:  
> > > > > > > > >
> > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > caps reported from the receiver via EDID.  
> > > > > > > >
> > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > >
> > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > Not great at all. Something to remember for the new property.  
> > > > > > >
> > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > forbid it :/  
> > > > > >
> > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > uses RGB or YCbCr signalling?  
> > > > >
> > > > > I suppose it could. The modeset would then fail, which is perhaps  
> > > >
> > > > Could? What are they missing?  
> > >
> > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > doesn't even exist?  
> > 
> > I think the question was about the current Colorspace property.

Yes.

We need to be able to set ColourPrimaries infoframe field for the sink.
Only userspace knows what ColourPrimaries it uses, and the driver has
no need to care at all, other than tell the sink what we have.

When a driver chooses to use YCbCr, it needs to use the
MatrixCoefficients the sink expects.

If we send the infoframe to the sink telling the signal uses BT.2020
ColourPrimaries, does that same bit pattern also tell the sink we are
using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?

Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?

If they don't, then YCbCr BT.2020 has never worked, which is another
nail in the coffin for "Colorspace" property. But it still means that
RGB BT.2020 may have worked correctly, and then drivers would regress
if they started picking YCbCr for any reason where they previously used
RGB.

> > > >
> > > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > > signalling based on e.g. available bandwidth. Surely they already will
> > > > not attempt to send a signal format to a monitor that does not say it
> > > > supports that?  
> > 
> > That's exactly what they do. The drivers don't check the EDID for the
> > colorimetry the sink supports and the responsibility is punted off to
> > user space.

I suspect there are two different things:

- which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
- the supported MatrixCoefficients for each of the YCbCr

Surely drivers are already checking the former point?

I'm not surprised if they are not checking the latter point, but they
do need to, because it is the driver making the choice between RGB and
some YCbCr.

> > >
> > > We just signal default/bt.709 colorimetry. There is nothing to
> > > check for those IIRC.  
> > 
> > You do support bt.2020, no?  
> 
> Not for rgb->ycbcr conversion.

I see there is confusion about what "colorimetry" is.

Please, let's use the H.273 terminology to make the difference clear
between ColourPrimaries and MatrixCoefficients.


Thanks,
pq

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

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> On Fri, 17 Mar 2023 01:01:38 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:  
> > > >
> > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:  
> > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > >  
> > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:  
> > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > >  
> > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:  
> > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:  
> > > > > > > > > >
> > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > caps reported from the receiver via EDID.  
> > > > > > > > >
> > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > >
> > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > Not great at all. Something to remember for the new property.  
> > > > > > > >
> > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > forbid it :/  
> > > > > > >
> > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > uses RGB or YCbCr signalling?  
> > > > > >
> > > > > > I suppose it could. The modeset would then fail, which is perhaps  
> > > > >
> > > > > Could? What are they missing?  
> > > >
> > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > doesn't even exist?  
> > > 
> > > I think the question was about the current Colorspace property.
> 
> Yes.
> 
> We need to be able to set ColourPrimaries infoframe field for the sink.
> Only userspace knows what ColourPrimaries it uses, and the driver has
> no need to care at all, other than tell the sink what we have.
> 
> When a driver chooses to use YCbCr, it needs to use the
> MatrixCoefficients the sink expects.
> 
> If we send the infoframe to the sink telling the signal uses BT.2020
> ColourPrimaries, does that same bit pattern also tell the sink we are
> using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> 
> Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?

No. I think I've repeated this same line a thousand times already:
The current colorspace property *only* affects the infoframe/msa/sdp,
nothing else.

> 
> If they don't, then YCbCr BT.2020 has never worked, which is another
> nail in the coffin for "Colorspace" property.

That is the same nail we've been talking about all along I thought.

> But it still means that
> RGB BT.2020 may have worked correctly, and then drivers would regress
> if they started picking YCbCr for any reason where they previously used
> RGB.

The policy has been to use RGB if at all possible. Only falling back
to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
be used, or there's not enough bandwidth for 4:4:4, etc.). If the
behaviour suddenly changes then it probably means the driver was
doing something illegal before by using RGB 4:4:4.

> 
> > > > >
> > > > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > > > signalling based on e.g. available bandwidth. Surely they already will
> > > > > not attempt to send a signal format to a monitor that does not say it
> > > > > supports that?  
> > > 
> > > That's exactly what they do. The drivers don't check the EDID for the
> > > colorimetry the sink supports and the responsibility is punted off to
> > > user space.
> 
> I suspect there are two different things:
> 
> - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
> - the supported MatrixCoefficients for each of the YCbCr
> 
> Surely drivers are already checking the former point?

Yes.

> 
> I'm not surprised if they are not checking the latter point, but they
> do need to, because it is the driver making the choice between RGB and
> some YCbCr.

This point has been irrelevant since we always select BT.709
and there is no optional feature bit in EDID to check for that.
Presumaly it is mandatory for sinks to support both BT.601 and
BT.709 whenever they support YCbCr in general.

> 
> > > >
> > > > We just signal default/bt.709 colorimetry. There is nothing to
> > > > check for those IIRC.  
> > > 
> > > You do support bt.2020, no?  
> > 
> > Not for rgb->ycbcr conversion.
> 
> I see there is confusion about what "colorimetry" is.
> 
> Please, let's use the H.273 terminology to make the difference clear
> between ColourPrimaries and MatrixCoefficients.
> 
> 
> Thanks,
> pq



-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Pekka Paalanen]

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

On Fri, 17 Mar 2023 14:50:40 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > On Fri, 17 Mar 2023 01:01:38 +0200
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >   
> > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:  
> > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > <ville.syrjala@linux.intel.com> wrote:    
> > > > >
> > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:    
> > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > >    
> > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:    
> > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > >    
> > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:    
> > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:    
> > > > > > > > > > >
> > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > caps reported from the receiver via EDID.    
> > > > > > > > > >
> > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > >
> > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > Not great at all. Something to remember for the new property.    
> > > > > > > > >
> > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > forbid it :/    
> > > > > > > >
> > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > uses RGB or YCbCr signalling?    
> > > > > > >
> > > > > > > I suppose it could. The modeset would then fail, which is perhaps    
> > > > > >
> > > > > > Could? What are they missing?    
> > > > >
> > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > doesn't even exist?    
> > > > 
> > > > I think the question was about the current Colorspace property.  
> > 
> > Yes.
> > 
> > We need to be able to set ColourPrimaries infoframe field for the sink.
> > Only userspace knows what ColourPrimaries it uses, and the driver has
> > no need to care at all, other than tell the sink what we have.
> > 
> > When a driver chooses to use YCbCr, it needs to use the
> > MatrixCoefficients the sink expects.
> > 
> > If we send the infoframe to the sink telling the signal uses BT.2020
> > ColourPrimaries, does that same bit pattern also tell the sink we are
> > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > 
> > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?  
> 
> No. I think I've repeated this same line a thousand times already:
> The current colorspace property *only* affects the infoframe/msa/sdp,
> nothing else.

That's the problem. I don't know what that means.

Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
have been used?

And the driver will never use BT.2020 NCL MatrixCoefficients in any
circumstances?

See the conflict? The sink will be decoding the signal incorrectly,
because we are encoding it with the wrong MatrixCoefficients if the
driver happens to silently choose YCbCr and userspace wants to send
BT2020 ColourPrimaries indicated in the infoframe.

> 
> > 
> > If they don't, then YCbCr BT.2020 has never worked, which is another
> > nail in the coffin for "Colorspace" property.  
> 
> That is the same nail we've been talking about all along I thought.
> 
> > But it still means that
> > RGB BT.2020 may have worked correctly, and then drivers would regress
> > if they started picking YCbCr for any reason where they previously used
> > RGB.  
> 
> The policy has been to use RGB if at all possible. Only falling back
> to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
> be used, or there's not enough bandwidth for 4:4:4, etc.). If the
> behaviour suddenly changes then it probably means the driver was
> doing something illegal before by using RGB 4:4:4.

Ok.

> > > > > >
> > > > > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > > > > signalling based on e.g. available bandwidth. Surely they already will
> > > > > > not attempt to send a signal format to a monitor that does not say it
> > > > > > supports that?    
> > > > 
> > > > That's exactly what they do. The drivers don't check the EDID for the
> > > > colorimetry the sink supports and the responsibility is punted off to
> > > > user space.  
> > 
> > I suspect there are two different things:
> > 
> > - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
> > - the supported MatrixCoefficients for each of the YCbCr
> > 
> > Surely drivers are already checking the former point?  
> 
> Yes.
> 
> > 
> > I'm not surprised if they are not checking the latter point, but they
> > do need to, because it is the driver making the choice between RGB and
> > some YCbCr.  
> 
> This point has been irrelevant since we always select BT.709
> and there is no optional feature bit in EDID to check for that.
> Presumaly it is mandatory for sinks to support both BT.601 and
> BT.709 whenever they support YCbCr in general.

Ok, so BT.601 and BT.709 MatrixCoefficients are cool. How do you tell
the sink which one you used, btw?

What about BT.2020 MatrixCoefficients?


Thanks,
pq

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

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Joshua Ashton]

On 3/17/23 13:35, Pekka Paalanen wrote:
> On Fri, 17 Mar 2023 14:50:40 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
>> On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
>>> On Fri, 17 Mar 2023 01:01:38 +0200
>>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>>    
>>>> On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
>>>>> On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
>>>>> <ville.syrjala@linux.intel.com> wrote:
>>>>>>
>>>>>> On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
>>>>>>> On Thu, 16 Mar 2023 12:47:51 +0200
>>>>>>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>>>>>>     
>>>>>>>> On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
>>>>>>>>> On Thu, 16 Mar 2023 11:50:27 +0200
>>>>>>>>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>>>>>>>>     
>>>>>>>>>> On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
>>>>>>>>>>> On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> We want compositors to be able to set the output
>>>>>>>>>>>> colorspace on DP and HDMI outputs, based on the
>>>>>>>>>>>> caps reported from the receiver via EDID.
>>>>>>>>>>>
>>>>>>>>>>> About that... The documentation says that user space has to check the
>>>>>>>>>>> EDID for what the sink actually supports. So whatever is in
>>>>>>>>>>> supported_colorspaces is just what the driver/hardware is able to set
>>>>>>>>>>> but doesn't actually indicate that the sink supports it.
>>>>>>>>>>>
>>>>>>>>>>> So the only way to enable bt2020 is by checking if the sink supports
>>>>>>>>>>> both RGB and YUV variants because both could be used by the driver.
>>>>>>>>>>> Not great at all. Something to remember for the new property.
>>>>>>>>>>
>>>>>>>>>> Hmm. I wonder if that's even legal... Looks like maybe it
>>>>>>>>>> is since I can't immediately spot anything in CTA-861 to
>>>>>>>>>> forbid it :/
>>>>>>>>>
>>>>>>>>> Wouldn't the driver do the same EDID check before choosing whether it
>>>>>>>>> uses RGB or YCbCr signalling?
>>>>>>>>
>>>>>>>> I suppose it could. The modeset would then fail, which is perhaps
>>>>>>>
>>>>>>> Could? What are they missing?
>>>>>>
>>>>>> The fact that the new property that also affects the rgb->ycbcr matrix
>>>>>> doesn't even exist?
>>>>>
>>>>> I think the question was about the current Colorspace property.
>>>
>>> Yes.
>>>
>>> We need to be able to set ColourPrimaries infoframe field for the sink.
>>> Only userspace knows what ColourPrimaries it uses, and the driver has
>>> no need to care at all, other than tell the sink what we have.
>>>
>>> When a driver chooses to use YCbCr, it needs to use the
>>> MatrixCoefficients the sink expects.
>>>
>>> If we send the infoframe to the sink telling the signal uses BT.2020
>>> ColourPrimaries, does that same bit pattern also tell the sink we are
>>> using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
>>>
>>> Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?
>>
>> No. I think I've repeated this same line a thousand times already:
>> The current colorspace property *only* affects the infoframe/msa/sdp,
>> nothing else.

No, sorry, this is completely nonsensical.

Even with the current Colorspace property that we want to deprecate, 
drivers doing an implicit conversion from RGB -> to YCC should respect 
the colorspace property to pick the right matrix coefficients here.

Doing so simply introduces a useless mismatch that is unavoidable from 
userspace and makes absolutely no sense.

Arguing about this is kind of completely useless anyway... as we are 
deprecating this property... Let's pleeeease let it die.

I am not sure why these patches were re-submitted with my RB again after 
we had the discussion previously about making a new one that's actually 
going to get tested and have userspace consumers.

(FTR, I guess Gamescope *is* a userspace consumer for this broken 
property right now, but I am completely happy for AMDGPU upstream to 
never support this and to just move onto the new property and leave this 
one behind).

> 
> That's the problem. I don't know what that means.
> 
> Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> have been used?

Yes.

> 
> And the driver will never use BT.2020 NCL MatrixCoefficients in any
> circumstances?

That is what Ville is describing and what I disagree with, yes.

But whether or not Ville or I agree on that is kind of irrelevant as we 
are going to deprecate the property... right... right?

> 
> See the conflict? The sink will be decoding the signal incorrectly,
> because we are encoding it with the wrong MatrixCoefficients if the
> driver happens to silently choose YCbCr and userspace wants to send
> BT2020 ColourPrimaries indicated in the infoframe.

Yeah.

- Joshie 🐸✨

> 
>>
>>>
>>> If they don't, then YCbCr BT.2020 has never worked, which is another
>>> nail in the coffin for "Colorspace" property.
>>
>> That is the same nail we've been talking about all along I thought.
>>
>>> But it still means that
>>> RGB BT.2020 may have worked correctly, and then drivers would regress
>>> if they started picking YCbCr for any reason where they previously used
>>> RGB.
>>
>> The policy has been to use RGB if at all possible. Only falling back
>> to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
>> be used, or there's not enough bandwidth for 4:4:4, etc.). If the
>> behaviour suddenly changes then it probably means the driver was
>> doing something illegal before by using RGB 4:4:4.
> 
> Ok.
> 
>>>>>>>
>>>>>>> I mean, drivers are already automatically choosing between RGB and YCbCr
>>>>>>> signalling based on e.g. available bandwidth. Surely they already will
>>>>>>> not attempt to send a signal format to a monitor that does not say it
>>>>>>> supports that?
>>>>>
>>>>> That's exactly what they do. The drivers don't check the EDID for the
>>>>> colorimetry the sink supports and the responsibility is punted off to
>>>>> user space.
>>>
>>> I suspect there are two different things:
>>>
>>> - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
>>> - the supported MatrixCoefficients for each of the YCbCr
>>>
>>> Surely drivers are already checking the former point?
>>
>> Yes.
>>
>>>
>>> I'm not surprised if they are not checking the latter point, but they
>>> do need to, because it is the driver making the choice between RGB and
>>> some YCbCr.
>>
>> This point has been irrelevant since we always select BT.709
>> and there is no optional feature bit in EDID to check for that.
>> Presumaly it is mandatory for sinks to support both BT.601 and
>> BT.709 whenever they support YCbCr in general.
> 
> Ok, so BT.601 and BT.709 MatrixCoefficients are cool. How do you tell
> the sink which one you used, btw?
> 
> What about BT.2020 MatrixCoefficients?
> 
> 
> Thanks,
> pq

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> On Fri, 17 Mar 2023 14:50:40 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > >   
> > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:  
> > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > > <ville.syrjala@linux.intel.com> wrote:    
> > > > > >
> > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:    
> > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > >    
> > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:    
> > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > >    
> > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:    
> > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:    
> > > > > > > > > > > >
> > > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > > caps reported from the receiver via EDID.    
> > > > > > > > > > >
> > > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > > >
> > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > > Not great at all. Something to remember for the new property.    
> > > > > > > > > >
> > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > > forbid it :/    
> > > > > > > > >
> > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > > uses RGB or YCbCr signalling?    
> > > > > > > >
> > > > > > > > I suppose it could. The modeset would then fail, which is perhaps    
> > > > > > >
> > > > > > > Could? What are they missing?    
> > > > > >
> > > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > > doesn't even exist?    
> > > > > 
> > > > > I think the question was about the current Colorspace property.  
> > > 
> > > Yes.
> > > 
> > > We need to be able to set ColourPrimaries infoframe field for the sink.
> > > Only userspace knows what ColourPrimaries it uses, and the driver has
> > > no need to care at all, other than tell the sink what we have.
> > > 
> > > When a driver chooses to use YCbCr, it needs to use the
> > > MatrixCoefficients the sink expects.
> > > 
> > > If we send the infoframe to the sink telling the signal uses BT.2020
> > > ColourPrimaries, does that same bit pattern also tell the sink we are
> > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > > 
> > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?  
> > 
> > No. I think I've repeated this same line a thousand times already:
> > The current colorspace property *only* affects the infoframe/msa/sdp,
> > nothing else.
> 
> That's the problem. I don't know what that means.
> 
> Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> have been used?

Yes, assuming that is the colorspace property value you picked.

> 
> And the driver will never use BT.2020 NCL MatrixCoefficients in any
> circumstances?

Correct.

> 
> See the conflict? The sink will be decoding the signal incorrectly,
> because we are encoding it with the wrong MatrixCoefficients if the
> driver happens to silently choose YCbCr and userspace wants to send
> BT2020 ColourPrimaries indicated in the infoframe.

Yes. And hence I thought pretty much everyone already
agreed that a new property is needed.

To make sure we actually understand what we're implementing
I think it should start out very minimal. Eg just three values:
- unspecified RGB + BT.601 YCbCr
- unspecified RGB + BT.709 YCbCr
- BT.2020 RGB + BT.2020 YCbCr NCL

And that would control:
- basic colorimetry metadata transmitted to the sink
- MatrixCoefficients used for the potential RGB->YCbCr conversion

Transfer funcs, primaries, etc. would be left out (apart from
the potential metadata aspect).

> 
> > 
> > > 
> > > If they don't, then YCbCr BT.2020 has never worked, which is another
> > > nail in the coffin for "Colorspace" property.  
> > 
> > That is the same nail we've been talking about all along I thought.
> > 
> > > But it still means that
> > > RGB BT.2020 may have worked correctly, and then drivers would regress
> > > if they started picking YCbCr for any reason where they previously used
> > > RGB.  
> > 
> > The policy has been to use RGB if at all possible. Only falling back
> > to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
> > be used, or there's not enough bandwidth for 4:4:4, etc.). If the
> > behaviour suddenly changes then it probably means the driver was
> > doing something illegal before by using RGB 4:4:4.
> 
> Ok.
> 
> > > > > > >
> > > > > > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > > > > > signalling based on e.g. available bandwidth. Surely they already will
> > > > > > > not attempt to send a signal format to a monitor that does not say it
> > > > > > > supports that?    
> > > > > 
> > > > > That's exactly what they do. The drivers don't check the EDID for the
> > > > > colorimetry the sink supports and the responsibility is punted off to
> > > > > user space.  
> > > 
> > > I suspect there are two different things:
> > > 
> > > - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
> > > - the supported MatrixCoefficients for each of the YCbCr
> > > 
> > > Surely drivers are already checking the former point?  
> > 
> > Yes.
> > 
> > > 
> > > I'm not surprised if they are not checking the latter point, but they
> > > do need to, because it is the driver making the choice between RGB and
> > > some YCbCr.  
> > 
> > This point has been irrelevant since we always select BT.709
> > and there is no optional feature bit in EDID to check for that.
> > Presumaly it is mandatory for sinks to support both BT.601 and
> > BT.709 whenever they support YCbCr in general.
> 
> Ok, so BT.601 and BT.709 MatrixCoefficients are cool. How do you tell
> the sink which one you used, btw?

Through the same infoframe/msa/sdp stuff. But that only works
correctly if the colorspace property is left at the default value.

> 
> What about BT.2020 MatrixCoefficients?

It would have to work the same way, if we actually ever used
this.

-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Pekka Paalanen]

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

On Fri, 17 Mar 2023 16:14:38 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> > On Fri, 17 Mar 2023 14:50:40 +0200
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >   
> > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:  
> > > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > >     
> > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:    
> > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > > > <ville.syrjala@linux.intel.com> wrote:      
> > > > > > >
> > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:      
> > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > >      
> > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:      
> > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > >      
> > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:      
> > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:      
> > > > > > > > > > > > >
> > > > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > > > caps reported from the receiver via EDID.      
> > > > > > > > > > > >
> > > > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > > > >
> > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > > > Not great at all. Something to remember for the new property.      
> > > > > > > > > > >
> > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > > > forbid it :/      
> > > > > > > > > >
> > > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > > > uses RGB or YCbCr signalling?      
> > > > > > > > >
> > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps      
> > > > > > > >
> > > > > > > > Could? What are they missing?      
> > > > > > >
> > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > > > doesn't even exist?      
> > > > > > 
> > > > > > I think the question was about the current Colorspace property.    
> > > > 
> > > > Yes.
> > > > 
> > > > We need to be able to set ColourPrimaries infoframe field for the sink.
> > > > Only userspace knows what ColourPrimaries it uses, and the driver has
> > > > no need to care at all, other than tell the sink what we have.
> > > > 
> > > > When a driver chooses to use YCbCr, it needs to use the
> > > > MatrixCoefficients the sink expects.
> > > > 
> > > > If we send the infoframe to the sink telling the signal uses BT.2020
> > > > ColourPrimaries, does that same bit pattern also tell the sink we are
> > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > > > 
> > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?    
> > > 
> > > No. I think I've repeated this same line a thousand times already:
> > > The current colorspace property *only* affects the infoframe/msa/sdp,
> > > nothing else.  
> > 
> > That's the problem. I don't know what that means.
> > 
> > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> > have been used?  
> 
> Yes, assuming that is the colorspace property value you picked.
> 
> > 
> > And the driver will never use BT.2020 NCL MatrixCoefficients in any
> > circumstances?  
> 
> Correct.
> 
> > 
> > See the conflict? The sink will be decoding the signal incorrectly,
> > because we are encoding it with the wrong MatrixCoefficients if the
> > driver happens to silently choose YCbCr and userspace wants to send
> > BT2020 ColourPrimaries indicated in the infoframe.  
> 
> Yes. And hence I thought pretty much everyone already
> agreed that a new property is needed.

I think I was confused as well with the re-posting of this series,
thinking it could be salvageable somehow and tried to understand how.
Up to Harry, I think I've left enough annoying questions by now. :-)

> To make sure we actually understand what we're implementing
> I think it should start out very minimal. Eg just three values:
> - unspecified RGB + BT.601 YCbCr
> - unspecified RGB + BT.709 YCbCr
> - BT.2020 RGB + BT.2020 YCbCr NCL

ColourPrimaries + MatrixCoefficients, respectively. Sounds fine.

I recall hearing that DP spec actually has something like "unspecified"
while HDMI has only "default colorimetry" which is specified, but I'm
guessing that many monitors and TVs just don't implement it like they
should, so it's effectively unspecified.

"unspecified" in UAPI is ok as long as there will be another distinct
value for "HDMI default colorimetry" or such.

I'm not sure why anyone would want to use "unspecified" but I guess
it's necessary for UAPI backward compatibility.

> 
> And that would control:
> - basic colorimetry metadata transmitted to the sink
> - MatrixCoefficients used for the potential RGB->YCbCr conversion
> 
> Transfer funcs, primaries, etc. would be left out (apart from
> the potential metadata aspect).

Primaries left out? What are your "unspecified RGB" and "BT.2020 RGB"
above then?

Asking from another angle, using infoframes, is it possible to tell the
sink to use BT.2020 YCbCr NCL without *also* implying BT.2020
ColourPrimaries? Joshua seemed to be saying "no".


> > > > 
> > > > If they don't, then YCbCr BT.2020 has never worked, which is another
> > > > nail in the coffin for "Colorspace" property.    
> > > 
> > > That is the same nail we've been talking about all along I thought.
> > >   
> > > > But it still means that
> > > > RGB BT.2020 may have worked correctly, and then drivers would regress
> > > > if they started picking YCbCr for any reason where they previously used
> > > > RGB.    
> > > 
> > > The policy has been to use RGB if at all possible. Only falling back
> > > to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
> > > be used, or there's not enough bandwidth for 4:4:4, etc.). If the
> > > behaviour suddenly changes then it probably means the driver was
> > > doing something illegal before by using RGB 4:4:4.  
> > 
> > Ok.
> >   
> > > > > > > >
> > > > > > > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > > > > > > signalling based on e.g. available bandwidth. Surely they already will
> > > > > > > > not attempt to send a signal format to a monitor that does not say it
> > > > > > > > supports that?      
> > > > > > 
> > > > > > That's exactly what they do. The drivers don't check the EDID for the
> > > > > > colorimetry the sink supports and the responsibility is punted off to
> > > > > > user space.    
> > > > 
> > > > I suspect there are two different things:
> > > > 
> > > > - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
> > > > - the supported MatrixCoefficients for each of the YCbCr
> > > > 
> > > > Surely drivers are already checking the former point?    
> > > 
> > > Yes.
> > >   
> > > > 
> > > > I'm not surprised if they are not checking the latter point, but they
> > > > do need to, because it is the driver making the choice between RGB and
> > > > some YCbCr.    
> > > 
> > > This point has been irrelevant since we always select BT.709
> > > and there is no optional feature bit in EDID to check for that.
> > > Presumaly it is mandatory for sinks to support both BT.601 and
> > > BT.709 whenever they support YCbCr in general.  
> > 
> > Ok, so BT.601 and BT.709 MatrixCoefficients are cool. How do you tell
> > the sink which one you used, btw?  
> 
> Through the same infoframe/msa/sdp stuff. But that only works
> correctly if the colorspace property is left at the default value.
> 
> > 
> > What about BT.2020 MatrixCoefficients?  
> 
> It would have to work the same way, if we actually ever used
> this.

Good.


Thanks,
pq

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

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
> On Fri, 17 Mar 2023 16:14:38 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> > > On Fri, 17 Mar 2023 14:50:40 +0200
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > >   
> > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:  
> > > > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > >     
> > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:    
> > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > > > > <ville.syrjala@linux.intel.com> wrote:      
> > > > > > > >
> > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:      
> > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > >      
> > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:      
> > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > >      
> > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:      
> > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:      
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > > > > caps reported from the receiver via EDID.      
> > > > > > > > > > > > >
> > > > > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > > > > Not great at all. Something to remember for the new property.      
> > > > > > > > > > > >
> > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > > > > forbid it :/      
> > > > > > > > > > >
> > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > > > > uses RGB or YCbCr signalling?      
> > > > > > > > > >
> > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps      
> > > > > > > > >
> > > > > > > > > Could? What are they missing?      
> > > > > > > >
> > > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > > > > doesn't even exist?      
> > > > > > > 
> > > > > > > I think the question was about the current Colorspace property.    
> > > > > 
> > > > > Yes.
> > > > > 
> > > > > We need to be able to set ColourPrimaries infoframe field for the sink.
> > > > > Only userspace knows what ColourPrimaries it uses, and the driver has
> > > > > no need to care at all, other than tell the sink what we have.
> > > > > 
> > > > > When a driver chooses to use YCbCr, it needs to use the
> > > > > MatrixCoefficients the sink expects.
> > > > > 
> > > > > If we send the infoframe to the sink telling the signal uses BT.2020
> > > > > ColourPrimaries, does that same bit pattern also tell the sink we are
> > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > > > > 
> > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?    
> > > > 
> > > > No. I think I've repeated this same line a thousand times already:
> > > > The current colorspace property *only* affects the infoframe/msa/sdp,
> > > > nothing else.  
> > > 
> > > That's the problem. I don't know what that means.
> > > 
> > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> > > have been used?  
> > 
> > Yes, assuming that is the colorspace property value you picked.
> > 
> > > 
> > > And the driver will never use BT.2020 NCL MatrixCoefficients in any
> > > circumstances?  
> > 
> > Correct.
> > 
> > > 
> > > See the conflict? The sink will be decoding the signal incorrectly,
> > > because we are encoding it with the wrong MatrixCoefficients if the
> > > driver happens to silently choose YCbCr and userspace wants to send
> > > BT2020 ColourPrimaries indicated in the infoframe.  
> > 
> > Yes. And hence I thought pretty much everyone already
> > agreed that a new property is needed.
> 
> I think I was confused as well with the re-posting of this series,
> thinking it could be salvageable somehow and tried to understand how.
> Up to Harry, I think I've left enough annoying questions by now. :-)
> 
> > To make sure we actually understand what we're implementing
> > I think it should start out very minimal. Eg just three values:
> > - unspecified RGB + BT.601 YCbCr
> > - unspecified RGB + BT.709 YCbCr
> > - BT.2020 RGB + BT.2020 YCbCr NCL
> 
> ColourPrimaries + MatrixCoefficients, respectively. Sounds fine.
> 
> I recall hearing that DP spec actually has something like "unspecified"
> while HDMI has only "default colorimetry" which is specified, but I'm
> guessing that many monitors and TVs just don't implement it like they
> should, so it's effectively unspecified.

DP in theory might have default RGB (whatever that might mean) vs.
sRGB, although at some point I think it was just vague RGB vs. CEA RGB,
which I think in i915 we might be using to indicate limited vs. full
quantization range instead. I think that somehow fixed some monitors
(while many others still get the quantization range horrible wrong of
course).

HDMI/CTA-861-? IIRC didn't have anything but just "RGB", and in some
footnote CTA-861-? then goes on to talk about the sRGB bit in the EDID.
In the end it didn't seem to say anything definitive what the RGB
colorimetry really means.

> 
> "unspecified" in UAPI is ok as long as there will be another distinct
> value for "HDMI default colorimetry" or such.
> 
> I'm not sure why anyone would want to use "unspecified" but I guess
> it's necessary for UAPI backward compatibility.

Just because the specs don't really seem to specify anything
sensible. We could just call it "RGB" and leave it at that of
course.

> 
> > 
> > And that would control:
> > - basic colorimetry metadata transmitted to the sink
> > - MatrixCoefficients used for the potential RGB->YCbCr conversion
> > 
> > Transfer funcs, primaries, etc. would be left out (apart from
> > the potential metadata aspect).
> 
> Primaries left out? What are your "unspecified RGB" and "BT.2020 RGB"
> above then?

It all seems too open to interpretation to make it anything
but "undefined".

> 
> Asking from another angle, using infoframes, is it possible to tell the
> sink to use BT.2020 YCbCr NCL without *also* implying BT.2020
> ColourPrimaries? Joshua seemed to be saying "no".

I don't think so. The BT.2020 cases seems to be more strictrly
defined.

> 
> 
> > > > > 
> > > > > If they don't, then YCbCr BT.2020 has never worked, which is another
> > > > > nail in the coffin for "Colorspace" property.    
> > > > 
> > > > That is the same nail we've been talking about all along I thought.
> > > >   
> > > > > But it still means that
> > > > > RGB BT.2020 may have worked correctly, and then drivers would regress
> > > > > if they started picking YCbCr for any reason where they previously used
> > > > > RGB.    
> > > > 
> > > > The policy has been to use RGB if at all possible. Only falling back
> > > > to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
> > > > be used, or there's not enough bandwidth for 4:4:4, etc.). If the
> > > > behaviour suddenly changes then it probably means the driver was
> > > > doing something illegal before by using RGB 4:4:4.  
> > > 
> > > Ok.
> > >   
> > > > > > > > >
> > > > > > > > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > > > > > > > signalling based on e.g. available bandwidth. Surely they already will
> > > > > > > > > not attempt to send a signal format to a monitor that does not say it
> > > > > > > > > supports that?      
> > > > > > > 
> > > > > > > That's exactly what they do. The drivers don't check the EDID for the
> > > > > > > colorimetry the sink supports and the responsibility is punted off to
> > > > > > > user space.    
> > > > > 
> > > > > I suspect there are two different things:
> > > > > 
> > > > > - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
> > > > > - the supported MatrixCoefficients for each of the YCbCr
> > > > > 
> > > > > Surely drivers are already checking the former point?    
> > > > 
> > > > Yes.
> > > >   
> > > > > 
> > > > > I'm not surprised if they are not checking the latter point, but they
> > > > > do need to, because it is the driver making the choice between RGB and
> > > > > some YCbCr.    
> > > > 
> > > > This point has been irrelevant since we always select BT.709
> > > > and there is no optional feature bit in EDID to check for that.
> > > > Presumaly it is mandatory for sinks to support both BT.601 and
> > > > BT.709 whenever they support YCbCr in general.  
> > > 
> > > Ok, so BT.601 and BT.709 MatrixCoefficients are cool. How do you tell
> > > the sink which one you used, btw?  
> > 
> > Through the same infoframe/msa/sdp stuff. But that only works
> > correctly if the colorspace property is left at the default value.
> > 
> > > 
> > > What about BT.2020 MatrixCoefficients?  
> > 
> > It would have to work the same way, if we actually ever used
> > this.
> 
> Good.
> 
> 
> Thanks,
> pq



-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Sebastian Wick]

On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
> > On Fri, 17 Mar 2023 16:14:38 +0200
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >
> > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> > > > On Fri, 17 Mar 2023 14:50:40 +0200
> > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > > > > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > >
> > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > > > > > caps reported from the receiver via EDID.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > > > > > Not great at all. Something to remember for the new property.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > > > > > forbid it :/
> > > > > > > > > > > >
> > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > > > > > uses RGB or YCbCr signalling?
> > > > > > > > > > >
> > > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps
> > > > > > > > > >
> > > > > > > > > > Could? What are they missing?
> > > > > > > > >
> > > > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > > > > > doesn't even exist?
> > > > > > > >
> > > > > > > > I think the question was about the current Colorspace property.
> > > > > >
> > > > > > Yes.
> > > > > >
> > > > > > We need to be able to set ColourPrimaries infoframe field for the sink.
> > > > > > Only userspace knows what ColourPrimaries it uses, and the driver has
> > > > > > no need to care at all, other than tell the sink what we have.
> > > > > >
> > > > > > When a driver chooses to use YCbCr, it needs to use the
> > > > > > MatrixCoefficients the sink expects.
> > > > > >
> > > > > > If we send the infoframe to the sink telling the signal uses BT.2020
> > > > > > ColourPrimaries, does that same bit pattern also tell the sink we are
> > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > > > > >
> > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?
> > > > >
> > > > > No. I think I've repeated this same line a thousand times already:
> > > > > The current colorspace property *only* affects the infoframe/msa/sdp,
> > > > > nothing else.
> > > >
> > > > That's the problem. I don't know what that means.
> > > >
> > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> > > > have been used?
> > >
> > > Yes, assuming that is the colorspace property value you picked.
> > >
> > > >
> > > > And the driver will never use BT.2020 NCL MatrixCoefficients in any
> > > > circumstances?
> > >
> > > Correct.
> > >
> > > >
> > > > See the conflict? The sink will be decoding the signal incorrectly,
> > > > because we are encoding it with the wrong MatrixCoefficients if the
> > > > driver happens to silently choose YCbCr and userspace wants to send
> > > > BT2020 ColourPrimaries indicated in the infoframe.
> > >
> > > Yes. And hence I thought pretty much everyone already
> > > agreed that a new property is needed.
> >
> > I think I was confused as well with the re-posting of this series,
> > thinking it could be salvageable somehow and tried to understand how.
> > Up to Harry, I think I've left enough annoying questions by now. :-)
> >
> > > To make sure we actually understand what we're implementing
> > > I think it should start out very minimal. Eg just three values:
> > > - unspecified RGB + BT.601 YCbCr
> > > - unspecified RGB + BT.709 YCbCr
> > > - BT.2020 RGB + BT.2020 YCbCr NCL

It would be best to describe for every case both what the display and
what the driver expects as input.

> >
> > ColourPrimaries + MatrixCoefficients, respectively. Sounds fine.
> >
> > I recall hearing that DP spec actually has something like "unspecified"
> > while HDMI has only "default colorimetry" which is specified, but I'm
> > guessing that many monitors and TVs just don't implement it like they
> > should, so it's effectively unspecified.
>
> DP in theory might have default RGB (whatever that might mean) vs.
> sRGB, although at some point I think it was just vague RGB vs. CEA RGB,
> which I think in i915 we might be using to indicate limited vs. full
> quantization range instead. I think that somehow fixed some monitors
> (while many others still get the quantization range horrible wrong of
> course).
>
> HDMI/CTA-861-? IIRC didn't have anything but just "RGB", and in some
> footnote CTA-861-? then goes on to talk about the sRGB bit in the EDID.
> In the end it didn't seem to say anything definitive what the RGB
> colorimetry really means.

DP has "RGB unspecified color space (Legacy RGB mode)" without more explanation.

CTA-861 has, as I said in a previous mail on this series:

"If bits C0 and C1 are zero, the colorimetry shall correspond to the
default colorimetry defined in Section 5.1"

and in Section 5.1

"In all cases described above, the RGB color space used should be the
RGB color space the Sink declares in the Basic Display Parameters and
Feature Block of its EDID."

> >
> > "unspecified" in UAPI is ok as long as there will be another distinct
> > value for "HDMI default colorimetry" or such.
> >
> > I'm not sure why anyone would want to use "unspecified" but I guess
> > it's necessary for UAPI backward compatibility.
>
> Just because the specs don't really seem to specify anything
> sensible. We could just call it "RGB" and leave it at that of
> course.

I think unspecified and default RGB are both good enough. The spec
doesn't give us much better guarantees anyway. Unspecified might even
be better because we could then add a default RGB case if we ever get
a mode which guarantees us that the colorimetry of the EDID is in
effect.

> >
> > >
> > > And that would control:
> > > - basic colorimetry metadata transmitted to the sink
> > > - MatrixCoefficients used for the potential RGB->YCbCr conversion
> > >
> > > Transfer funcs, primaries, etc. would be left out (apart from
> > > the potential metadata aspect).
> >
> > Primaries left out? What are your "unspecified RGB" and "BT.2020 RGB"
> > above then?
>
> It all seems too open to interpretation to make it anything
> but "undefined".
>
> >
> > Asking from another angle, using infoframes, is it possible to tell the
> > sink to use BT.2020 YCbCr NCL without *also* implying BT.2020
> > ColourPrimaries? Joshua seemed to be saying "no".
>
> I don't think so. The BT.2020 cases seems to be more strictrly
> defined.

The Colorimetry gives us the primaries, white point, transfer
characteristics and conversion matrix if it is for YCC. The HDR
metadata can override the transfer characteristics.

Anyways, CTA-861 is still confusing me a lot.

It has "No Data" Colorimetry but is that the same as not sending the
InfoFrame at all? Either way, the colorimetry should be the one from
the EDID.

But the transfer characteristics change with the selected Colorimetry.
In the table is "RGB" the same as "No Data" and the same as sending no
InfoFrame? But then when is the transfer characteristics of the EDID
in effect and when bt.709 from the table?

There doesn't appear to be a default colorimetry for YCC. So how would
you even automatically fall back from RGB to YCC with the same
colorimetry?

I only see the colorimetry BT.709 and not BT.601. Some other
colorimetry uses the BT.601 conversion matrix so how would
"unspecified RGB + BT.709 YCbCr" even work?

> >
> >
> > > > > >
> > > > > > If they don't, then YCbCr BT.2020 has never worked, which is another
> > > > > > nail in the coffin for "Colorspace" property.
> > > > >
> > > > > That is the same nail we've been talking about all along I thought.
> > > > >
> > > > > > But it still means that
> > > > > > RGB BT.2020 may have worked correctly, and then drivers would regress
> > > > > > if they started picking YCbCr for any reason where they previously used
> > > > > > RGB.
> > > > >
> > > > > The policy has been to use RGB if at all possible. Only falling back
> > > > > to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
> > > > > be used, or there's not enough bandwidth for 4:4:4, etc.). If the
> > > > > behaviour suddenly changes then it probably means the driver was
> > > > > doing something illegal before by using RGB 4:4:4.
> > > >
> > > > Ok.
> > > >
> > > > > > > > > >
> > > > > > > > > > I mean, drivers are already automatically choosing between RGB and YCbCr
> > > > > > > > > > signalling based on e.g. available bandwidth. Surely they already will
> > > > > > > > > > not attempt to send a signal format to a monitor that does not say it
> > > > > > > > > > supports that?
> > > > > > > >
> > > > > > > > That's exactly what they do. The drivers don't check the EDID for the
> > > > > > > > colorimetry the sink supports and the responsibility is punted off to
> > > > > > > > user space.
> > > > > >
> > > > > > I suspect there are two different things:
> > > > > >
> > > > > > - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
> > > > > > - the supported MatrixCoefficients for each of the YCbCr
> > > > > >
> > > > > > Surely drivers are already checking the former point?
> > > > >
> > > > > Yes.
> > > > >
> > > > > >
> > > > > > I'm not surprised if they are not checking the latter point, but they
> > > > > > do need to, because it is the driver making the choice between RGB and
> > > > > > some YCbCr.
> > > > >
> > > > > This point has been irrelevant since we always select BT.709
> > > > > and there is no optional feature bit in EDID to check for that.
> > > > > Presumaly it is mandatory for sinks to support both BT.601 and
> > > > > BT.709 whenever they support YCbCr in general.
> > > >
> > > > Ok, so BT.601 and BT.709 MatrixCoefficients are cool. How do you tell
> > > > the sink which one you used, btw?
> > >
> > > Through the same infoframe/msa/sdp stuff. But that only works
> > > correctly if the colorspace property is left at the default value.
> > >
> > > >
> > > > What about BT.2020 MatrixCoefficients?
> > >
> > > It would have to work the same way, if we actually ever used
> > > this.
> >
> > Good.
> >
> >
> > Thanks,
> > pq
>
>
>
> --
> Ville Syrjälä
> Intel
>

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote:
> On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
> > > On Fri, 17 Mar 2023 16:14:38 +0200
> > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > >
> > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> > > > > On Fri, 17 Mar 2023 14:50:40 +0200
> > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > >
> > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > > > > > > caps reported from the receiver via EDID.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > > > > > > Not great at all. Something to remember for the new property.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > > > > > > forbid it :/
> > > > > > > > > > > > >
> > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > > > > > > uses RGB or YCbCr signalling?
> > > > > > > > > > > >
> > > > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps
> > > > > > > > > > >
> > > > > > > > > > > Could? What are they missing?
> > > > > > > > > >
> > > > > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > > > > > > doesn't even exist?
> > > > > > > > >
> > > > > > > > > I think the question was about the current Colorspace property.
> > > > > > >
> > > > > > > Yes.
> > > > > > >
> > > > > > > We need to be able to set ColourPrimaries infoframe field for the sink.
> > > > > > > Only userspace knows what ColourPrimaries it uses, and the driver has
> > > > > > > no need to care at all, other than tell the sink what we have.
> > > > > > >
> > > > > > > When a driver chooses to use YCbCr, it needs to use the
> > > > > > > MatrixCoefficients the sink expects.
> > > > > > >
> > > > > > > If we send the infoframe to the sink telling the signal uses BT.2020
> > > > > > > ColourPrimaries, does that same bit pattern also tell the sink we are
> > > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > > > > > >
> > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?
> > > > > >
> > > > > > No. I think I've repeated this same line a thousand times already:
> > > > > > The current colorspace property *only* affects the infoframe/msa/sdp,
> > > > > > nothing else.
> > > > >
> > > > > That's the problem. I don't know what that means.
> > > > >
> > > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> > > > > have been used?
> > > >
> > > > Yes, assuming that is the colorspace property value you picked.
> > > >
> > > > >
> > > > > And the driver will never use BT.2020 NCL MatrixCoefficients in any
> > > > > circumstances?
> > > >
> > > > Correct.
> > > >
> > > > >
> > > > > See the conflict? The sink will be decoding the signal incorrectly,
> > > > > because we are encoding it with the wrong MatrixCoefficients if the
> > > > > driver happens to silently choose YCbCr and userspace wants to send
> > > > > BT2020 ColourPrimaries indicated in the infoframe.
> > > >
> > > > Yes. And hence I thought pretty much everyone already
> > > > agreed that a new property is needed.
> > >
> > > I think I was confused as well with the re-posting of this series,
> > > thinking it could be salvageable somehow and tried to understand how.
> > > Up to Harry, I think I've left enough annoying questions by now. :-)
> > >
> > > > To make sure we actually understand what we're implementing
> > > > I think it should start out very minimal. Eg just three values:
> > > > - unspecified RGB + BT.601 YCbCr
> > > > - unspecified RGB + BT.709 YCbCr
> > > > - BT.2020 RGB + BT.2020 YCbCr NCL
> 
> It would be best to describe for every case both what the display and
> what the driver expects as input.

I don't want the uapi to make any claims about the display. Half the 
real world displays are going to interpret it some other way anyway.

So all I think we can promise is:
- exactly what colorimetry we will indicate to the display in the metadata
- exactly what MatrixCoefficients we will use for RGB->YCbCr conversion

After that it's between you and your god^W display vendor what happens.

> 
> > >
> > > ColourPrimaries + MatrixCoefficients, respectively. Sounds fine.
> > >
> > > I recall hearing that DP spec actually has something like "unspecified"
> > > while HDMI has only "default colorimetry" which is specified, but I'm
> > > guessing that many monitors and TVs just don't implement it like they
> > > should, so it's effectively unspecified.
> >
> > DP in theory might have default RGB (whatever that might mean) vs.
> > sRGB, although at some point I think it was just vague RGB vs. CEA RGB,
> > which I think in i915 we might be using to indicate limited vs. full
> > quantization range instead. I think that somehow fixed some monitors
> > (while many others still get the quantization range horrible wrong of
> > course).
> >
> > HDMI/CTA-861-? IIRC didn't have anything but just "RGB", and in some
> > footnote CTA-861-? then goes on to talk about the sRGB bit in the EDID.
> > In the end it didn't seem to say anything definitive what the RGB
> > colorimetry really means.
> 
> DP has "RGB unspecified color space (Legacy RGB mode)" without more explanation.
> 
> CTA-861 has, as I said in a previous mail on this series:
> 
> "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> default colorimetry defined in Section 5.1"
> 
> and in Section 5.1
> 
> "In all cases described above, the RGB color space used should be the
> RGB color space the Sink declares in the Basic Display Parameters and
> Feature Block of its EDID."
> 
> > >
> > > "unspecified" in UAPI is ok as long as there will be another distinct
> > > value for "HDMI default colorimetry" or such.
> > >
> > > I'm not sure why anyone would want to use "unspecified" but I guess
> > > it's necessary for UAPI backward compatibility.
> >
> > Just because the specs don't really seem to specify anything
> > sensible. We could just call it "RGB" and leave it at that of
> > course.
> 
> I think unspecified and default RGB are both good enough. The spec
> doesn't give us much better guarantees anyway. Unspecified might even
> be better because we could then add a default RGB case if we ever get
> a mode which guarantees us that the colorimetry of the EDID is in
> effect.
> 
> > >
> > > >
> > > > And that would control:
> > > > - basic colorimetry metadata transmitted to the sink
> > > > - MatrixCoefficients used for the potential RGB->YCbCr conversion
> > > >
> > > > Transfer funcs, primaries, etc. would be left out (apart from
> > > > the potential metadata aspect).
> > >
> > > Primaries left out? What are your "unspecified RGB" and "BT.2020 RGB"
> > > above then?
> >
> > It all seems too open to interpretation to make it anything
> > but "undefined".
> >
> > >
> > > Asking from another angle, using infoframes, is it possible to tell the
> > > sink to use BT.2020 YCbCr NCL without *also* implying BT.2020
> > > ColourPrimaries? Joshua seemed to be saying "no".
> >
> > I don't think so. The BT.2020 cases seems to be more strictrly
> > defined.
> 
> The Colorimetry gives us the primaries, white point, transfer
> characteristics and conversion matrix if it is for YCC. The HDR
> metadata can override the transfer characteristics.
> 
> Anyways, CTA-861 is still confusing me a lot.
> 
> It has "No Data" Colorimetry but is that the same as not sending the
> InfoFrame at all? Either way, the colorimetry should be the one from
> the EDID.
> 
> But the transfer characteristics change with the selected Colorimetry.
> In the table is "RGB" the same as "No Data" and the same as sending no
> InfoFrame? But then when is the transfer characteristics of the EDID
> in effect and when bt.709 from the table?
> 
> There doesn't appear to be a default colorimetry for YCC. So how would
> you even automatically fall back from RGB to YCC with the same
> colorimetry?
> 
> I only see the colorimetry BT.709 and not BT.601. Some other
> colorimetry uses the BT.601 conversion matrix so how would
> "unspecified RGB + BT.709 YCbCr" even work?

It just means:
- if we output RGB we the colorimetry signalled will be "no data"
  value (or whatever the "i don't know what anything means" value)
- if we output YCbCr the colorimetry signalled will be the BT.709
  value, and the YCbCr data will be produced using the BT.709
  MatrixCoefficients

Beyond that absolutely no promises about anything.

-- 
Ville Syrjälä
Intel

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Sebastian Wick]

On Fri, Mar 17, 2023 at 7:38 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote:
> > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
> > > > On Fri, 17 Mar 2023 16:14:38 +0200
> > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> > > > > > On Fri, 17 Mar 2023 14:50:40 +0200
> > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > >
> > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > >
> > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> > > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > > > > > > > caps reported from the receiver via EDID.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > > > > > > > Not great at all. Something to remember for the new property.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > > > > > > > forbid it :/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > > > > > > > uses RGB or YCbCr signalling?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps
> > > > > > > > > > > >
> > > > > > > > > > > > Could? What are they missing?
> > > > > > > > > > >
> > > > > > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > > > > > > > doesn't even exist?
> > > > > > > > > >
> > > > > > > > > > I think the question was about the current Colorspace property.
> > > > > > > >
> > > > > > > > Yes.
> > > > > > > >
> > > > > > > > We need to be able to set ColourPrimaries infoframe field for the sink.
> > > > > > > > Only userspace knows what ColourPrimaries it uses, and the driver has
> > > > > > > > no need to care at all, other than tell the sink what we have.
> > > > > > > >
> > > > > > > > When a driver chooses to use YCbCr, it needs to use the
> > > > > > > > MatrixCoefficients the sink expects.
> > > > > > > >
> > > > > > > > If we send the infoframe to the sink telling the signal uses BT.2020
> > > > > > > > ColourPrimaries, does that same bit pattern also tell the sink we are
> > > > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > > > > > > >
> > > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?
> > > > > > >
> > > > > > > No. I think I've repeated this same line a thousand times already:
> > > > > > > The current colorspace property *only* affects the infoframe/msa/sdp,
> > > > > > > nothing else.
> > > > > >
> > > > > > That's the problem. I don't know what that means.
> > > > > >
> > > > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> > > > > > have been used?
> > > > >
> > > > > Yes, assuming that is the colorspace property value you picked.
> > > > >
> > > > > >
> > > > > > And the driver will never use BT.2020 NCL MatrixCoefficients in any
> > > > > > circumstances?
> > > > >
> > > > > Correct.
> > > > >
> > > > > >
> > > > > > See the conflict? The sink will be decoding the signal incorrectly,
> > > > > > because we are encoding it with the wrong MatrixCoefficients if the
> > > > > > driver happens to silently choose YCbCr and userspace wants to send
> > > > > > BT2020 ColourPrimaries indicated in the infoframe.
> > > > >
> > > > > Yes. And hence I thought pretty much everyone already
> > > > > agreed that a new property is needed.
> > > >
> > > > I think I was confused as well with the re-posting of this series,
> > > > thinking it could be salvageable somehow and tried to understand how.
> > > > Up to Harry, I think I've left enough annoying questions by now. :-)
> > > >
> > > > > To make sure we actually understand what we're implementing
> > > > > I think it should start out very minimal. Eg just three values:
> > > > > - unspecified RGB + BT.601 YCbCr
> > > > > - unspecified RGB + BT.709 YCbCr
> > > > > - BT.2020 RGB + BT.2020 YCbCr NCL
> >
> > It would be best to describe for every case both what the display and
> > what the driver expects as input.
>
> I don't want the uapi to make any claims about the display. Half the
> real world displays are going to interpret it some other way anyway.
>
> So all I think we can promise is:
> - exactly what colorimetry we will indicate to the display in the metadata
> - exactly what MatrixCoefficients we will use for RGB->YCbCr conversion
>
> After that it's between you and your god^W display vendor what happens.

Sure, that's what I meant with "what the display expects" but "what we
indicate to the display" is more accurate indeed.

> >
> > > >
> > > > ColourPrimaries + MatrixCoefficients, respectively. Sounds fine.
> > > >
> > > > I recall hearing that DP spec actually has something like "unspecified"
> > > > while HDMI has only "default colorimetry" which is specified, but I'm
> > > > guessing that many monitors and TVs just don't implement it like they
> > > > should, so it's effectively unspecified.
> > >
> > > DP in theory might have default RGB (whatever that might mean) vs.
> > > sRGB, although at some point I think it was just vague RGB vs. CEA RGB,
> > > which I think in i915 we might be using to indicate limited vs. full
> > > quantization range instead. I think that somehow fixed some monitors
> > > (while many others still get the quantization range horrible wrong of
> > > course).
> > >
> > > HDMI/CTA-861-? IIRC didn't have anything but just "RGB", and in some
> > > footnote CTA-861-? then goes on to talk about the sRGB bit in the EDID.
> > > In the end it didn't seem to say anything definitive what the RGB
> > > colorimetry really means.
> >
> > DP has "RGB unspecified color space (Legacy RGB mode)" without more explanation.
> >
> > CTA-861 has, as I said in a previous mail on this series:
> >
> > "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> > default colorimetry defined in Section 5.1"
> >
> > and in Section 5.1
> >
> > "In all cases described above, the RGB color space used should be the
> > RGB color space the Sink declares in the Basic Display Parameters and
> > Feature Block of its EDID."
> >
> > > >
> > > > "unspecified" in UAPI is ok as long as there will be another distinct
> > > > value for "HDMI default colorimetry" or such.
> > > >
> > > > I'm not sure why anyone would want to use "unspecified" but I guess
> > > > it's necessary for UAPI backward compatibility.
> > >
> > > Just because the specs don't really seem to specify anything
> > > sensible. We could just call it "RGB" and leave it at that of
> > > course.
> >
> > I think unspecified and default RGB are both good enough. The spec
> > doesn't give us much better guarantees anyway. Unspecified might even
> > be better because we could then add a default RGB case if we ever get
> > a mode which guarantees us that the colorimetry of the EDID is in
> > effect.
> >
> > > >
> > > > >
> > > > > And that would control:
> > > > > - basic colorimetry metadata transmitted to the sink
> > > > > - MatrixCoefficients used for the potential RGB->YCbCr conversion
> > > > >
> > > > > Transfer funcs, primaries, etc. would be left out (apart from
> > > > > the potential metadata aspect).
> > > >
> > > > Primaries left out? What are your "unspecified RGB" and "BT.2020 RGB"
> > > > above then?
> > >
> > > It all seems too open to interpretation to make it anything
> > > but "undefined".
> > >
> > > >
> > > > Asking from another angle, using infoframes, is it possible to tell the
> > > > sink to use BT.2020 YCbCr NCL without *also* implying BT.2020
> > > > ColourPrimaries? Joshua seemed to be saying "no".
> > >
> > > I don't think so. The BT.2020 cases seems to be more strictrly
> > > defined.
> >
> > The Colorimetry gives us the primaries, white point, transfer
> > characteristics and conversion matrix if it is for YCC. The HDR
> > metadata can override the transfer characteristics.
> >
> > Anyways, CTA-861 is still confusing me a lot.
> >
> > It has "No Data" Colorimetry but is that the same as not sending the
> > InfoFrame at all? Either way, the colorimetry should be the one from
> > the EDID.
> >
> > But the transfer characteristics change with the selected Colorimetry.
> > In the table is "RGB" the same as "No Data" and the same as sending no
> > InfoFrame? But then when is the transfer characteristics of the EDID
> > in effect and when bt.709 from the table?
> >
> > There doesn't appear to be a default colorimetry for YCC. So how would
> > you even automatically fall back from RGB to YCC with the same
> > colorimetry?
> >
> > I only see the colorimetry BT.709 and not BT.601. Some other
> > colorimetry uses the BT.601 conversion matrix so how would
> > "unspecified RGB + BT.709 YCbCr" even work?
>
> It just means:
> - if we output RGB we the colorimetry signalled will be "no data"
>   value (or whatever the "i don't know what anything means" value)
> - if we output YCbCr the colorimetry signalled will be the BT.709
>   value, and the YCbCr data will be produced using the BT.709
>   MatrixCoefficients
>
> Beyond that absolutely no promises about anything.

Then we have different primary chromaticities depending on if the
kernel chose RGB or YCC.

When you signal the BT.709 colorimetry you're not only signalling the
conversion matrix, you're also signaling the expected primary
chromaticities and transfer characteristics as well and they will not
match the default/no-data/unspecified colorimetry.

> --
> Ville Syrjälä
> Intel
>

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Ville Syrjälä]

On Fri, Mar 17, 2023 at 07:47:52PM +0100, Sebastian Wick wrote:
> On Fri, Mar 17, 2023 at 7:38 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote:
> > > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
> > > > > On Fri, 17 Mar 2023 16:14:38 +0200
> > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> > > > > > > On Fri, 17 Mar 2023 14:50:40 +0200
> > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > >
> > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > > > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > >
> > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> > > > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > > > > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > > > > > > > > > > > > > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > We want compositors to be able to set the output
> > > > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the
> > > > > > > > > > > > > > > > > > caps reported from the receiver via EDID.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > About that... The documentation says that user space has to check the
> > > > > > > > > > > > > > > > > EDID for what the sink actually supports. So whatever is in
> > > > > > > > > > > > > > > > > supported_colorspaces is just what the driver/hardware is able to set
> > > > > > > > > > > > > > > > > but doesn't actually indicate that the sink supports it.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports
> > > > > > > > > > > > > > > > > both RGB and YUV variants because both could be used by the driver.
> > > > > > > > > > > > > > > > > Not great at all. Something to remember for the new property.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it
> > > > > > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 to
> > > > > > > > > > > > > > > > forbid it :/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it
> > > > > > > > > > > > > > > uses RGB or YCbCr signalling?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I suppose it could. The modeset would then fail, which is perhaps
> > > > > > > > > > > > >
> > > > > > > > > > > > > Could? What are they missing?
> > > > > > > > > > > >
> > > > > > > > > > > > The fact that the new property that also affects the rgb->ycbcr matrix
> > > > > > > > > > > > doesn't even exist?
> > > > > > > > > > >
> > > > > > > > > > > I think the question was about the current Colorspace property.
> > > > > > > > >
> > > > > > > > > Yes.
> > > > > > > > >
> > > > > > > > > We need to be able to set ColourPrimaries infoframe field for the sink.
> > > > > > > > > Only userspace knows what ColourPrimaries it uses, and the driver has
> > > > > > > > > no need to care at all, other than tell the sink what we have.
> > > > > > > > >
> > > > > > > > > When a driver chooses to use YCbCr, it needs to use the
> > > > > > > > > MatrixCoefficients the sink expects.
> > > > > > > > >
> > > > > > > > > If we send the infoframe to the sink telling the signal uses BT.2020
> > > > > > > > > ColourPrimaries, does that same bit pattern also tell the sink we are
> > > > > > > > > using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
> > > > > > > > >
> > > > > > > > > Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?
> > > > > > > >
> > > > > > > > No. I think I've repeated this same line a thousand times already:
> > > > > > > > The current colorspace property *only* affects the infoframe/msa/sdp,
> > > > > > > > nothing else.
> > > > > > >
> > > > > > > That's the problem. I don't know what that means.
> > > > > > >
> > > > > > > Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
> > > > > > > have been used?
> > > > > >
> > > > > > Yes, assuming that is the colorspace property value you picked.
> > > > > >
> > > > > > >
> > > > > > > And the driver will never use BT.2020 NCL MatrixCoefficients in any
> > > > > > > circumstances?
> > > > > >
> > > > > > Correct.
> > > > > >
> > > > > > >
> > > > > > > See the conflict? The sink will be decoding the signal incorrectly,
> > > > > > > because we are encoding it with the wrong MatrixCoefficients if the
> > > > > > > driver happens to silently choose YCbCr and userspace wants to send
> > > > > > > BT2020 ColourPrimaries indicated in the infoframe.
> > > > > >
> > > > > > Yes. And hence I thought pretty much everyone already
> > > > > > agreed that a new property is needed.
> > > > >
> > > > > I think I was confused as well with the re-posting of this series,
> > > > > thinking it could be salvageable somehow and tried to understand how.
> > > > > Up to Harry, I think I've left enough annoying questions by now. :-)
> > > > >
> > > > > > To make sure we actually understand what we're implementing
> > > > > > I think it should start out very minimal. Eg just three values:
> > > > > > - unspecified RGB + BT.601 YCbCr
> > > > > > - unspecified RGB + BT.709 YCbCr
> > > > > > - BT.2020 RGB + BT.2020 YCbCr NCL
> > >
> > > It would be best to describe for every case both what the display and
> > > what the driver expects as input.
> >
> > I don't want the uapi to make any claims about the display. Half the
> > real world displays are going to interpret it some other way anyway.
> >
> > So all I think we can promise is:
> > - exactly what colorimetry we will indicate to the display in the metadata
> > - exactly what MatrixCoefficients we will use for RGB->YCbCr conversion
> >
> > After that it's between you and your god^W display vendor what happens.
> 
> Sure, that's what I meant with "what the display expects" but "what we
> indicate to the display" is more accurate indeed.
> 
> > >
> > > > >
> > > > > ColourPrimaries + MatrixCoefficients, respectively. Sounds fine.
> > > > >
> > > > > I recall hearing that DP spec actually has something like "unspecified"
> > > > > while HDMI has only "default colorimetry" which is specified, but I'm
> > > > > guessing that many monitors and TVs just don't implement it like they
> > > > > should, so it's effectively unspecified.
> > > >
> > > > DP in theory might have default RGB (whatever that might mean) vs.
> > > > sRGB, although at some point I think it was just vague RGB vs. CEA RGB,
> > > > which I think in i915 we might be using to indicate limited vs. full
> > > > quantization range instead. I think that somehow fixed some monitors
> > > > (while many others still get the quantization range horrible wrong of
> > > > course).
> > > >
> > > > HDMI/CTA-861-? IIRC didn't have anything but just "RGB", and in some
> > > > footnote CTA-861-? then goes on to talk about the sRGB bit in the EDID.
> > > > In the end it didn't seem to say anything definitive what the RGB
> > > > colorimetry really means.
> > >
> > > DP has "RGB unspecified color space (Legacy RGB mode)" without more explanation.
> > >
> > > CTA-861 has, as I said in a previous mail on this series:
> > >
> > > "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> > > default colorimetry defined in Section 5.1"
> > >
> > > and in Section 5.1
> > >
> > > "In all cases described above, the RGB color space used should be the
> > > RGB color space the Sink declares in the Basic Display Parameters and
> > > Feature Block of its EDID."
> > >
> > > > >
> > > > > "unspecified" in UAPI is ok as long as there will be another distinct
> > > > > value for "HDMI default colorimetry" or such.
> > > > >
> > > > > I'm not sure why anyone would want to use "unspecified" but I guess
> > > > > it's necessary for UAPI backward compatibility.
> > > >
> > > > Just because the specs don't really seem to specify anything
> > > > sensible. We could just call it "RGB" and leave it at that of
> > > > course.
> > >
> > > I think unspecified and default RGB are both good enough. The spec
> > > doesn't give us much better guarantees anyway. Unspecified might even
> > > be better because we could then add a default RGB case if we ever get
> > > a mode which guarantees us that the colorimetry of the EDID is in
> > > effect.
> > >
> > > > >
> > > > > >
> > > > > > And that would control:
> > > > > > - basic colorimetry metadata transmitted to the sink
> > > > > > - MatrixCoefficients used for the potential RGB->YCbCr conversion
> > > > > >
> > > > > > Transfer funcs, primaries, etc. would be left out (apart from
> > > > > > the potential metadata aspect).
> > > > >
> > > > > Primaries left out? What are your "unspecified RGB" and "BT.2020 RGB"
> > > > > above then?
> > > >
> > > > It all seems too open to interpretation to make it anything
> > > > but "undefined".
> > > >
> > > > >
> > > > > Asking from another angle, using infoframes, is it possible to tell the
> > > > > sink to use BT.2020 YCbCr NCL without *also* implying BT.2020
> > > > > ColourPrimaries? Joshua seemed to be saying "no".
> > > >
> > > > I don't think so. The BT.2020 cases seems to be more strictrly
> > > > defined.
> > >
> > > The Colorimetry gives us the primaries, white point, transfer
> > > characteristics and conversion matrix if it is for YCC. The HDR
> > > metadata can override the transfer characteristics.
> > >
> > > Anyways, CTA-861 is still confusing me a lot.
> > >
> > > It has "No Data" Colorimetry but is that the same as not sending the
> > > InfoFrame at all? Either way, the colorimetry should be the one from
> > > the EDID.
> > >
> > > But the transfer characteristics change with the selected Colorimetry.
> > > In the table is "RGB" the same as "No Data" and the same as sending no
> > > InfoFrame? But then when is the transfer characteristics of the EDID
> > > in effect and when bt.709 from the table?
> > >
> > > There doesn't appear to be a default colorimetry for YCC. So how would
> > > you even automatically fall back from RGB to YCC with the same
> > > colorimetry?
> > >
> > > I only see the colorimetry BT.709 and not BT.601. Some other
> > > colorimetry uses the BT.601 conversion matrix so how would
> > > "unspecified RGB + BT.709 YCbCr" even work?
> >
> > It just means:
> > - if we output RGB we the colorimetry signalled will be "no data"
> >   value (or whatever the "i don't know what anything means" value)
> > - if we output YCbCr the colorimetry signalled will be the BT.709
> >   value, and the YCbCr data will be produced using the BT.709
> >   MatrixCoefficients
> >
> > Beyond that absolutely no promises about anything.
> 
> Then we have different primary chromaticities depending on if the
> kernel chose RGB or YCC.

Does the display actualy care? No idea.

> 
> When you signal the BT.709 colorimetry you're not only signalling the
> conversion matrix, you're also signaling the expected primary
> chromaticities and transfer characteristics as well and they will not
> match the default/no-data/unspecified colorimetry.

Well then, maybe there's no proper way to do what we want do
(automagic RGB vs.YCbCr selection). But even the improper way
seems to work well enough in practie for some people.

-- 
Ville Syrjälä
Intel

Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace

[Harry Wentland]

On 3/8/23 03:59, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:52 -0500
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> From: Joshua Ashton <joshua@froggi.es>
>>
>> To match the other enums, and add more information about these values.
>>
>> v2:
>>  - Specify where an enum entry comes from
>>  - Clarify DEFAULT and NO_DATA behavior
>>  - BT.2020 CYCC is "constant luminance"
>>  - correct type for BT.601
>>
>> Signed-off-by: Joshua Ashton <joshua@froggi.es>
>> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
>> Reviewed-by: Harry Wentland <harry.wentland@amd.com>
> 
> Hi,
> 
> this effort is really good, but of course I still find things to
> nitpick about. If there is no answer to my questions, then I would
> prefer the documentation to spell out the unknowns and ambiguities.
> 

Finally finding time to look at this again and want to make sure I
try to address your comments as best as I can. I'm terribly at tracking
emails, so if anything was clarified already I apologize.

>> Cc: Pekka Paalanen <ppaalanen@gmail.com>
>> Cc: Sebastian Wick <sebastian.wick@redhat.com>
>> Cc: Vitaly.Prosyak@amd.com
>> Cc: Uma Shankar <uma.shankar@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Joshua Ashton <joshua@froggi.es>
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: amd-gfx@lists.freedesktop.org
>> ---
>>  include/drm/drm_connector.h | 67 +++++++++++++++++++++++++++++++++++--
>>  1 file changed, 65 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 6d6a53a6b010..bb078666dc34 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
>>  	PRIVACY_SCREEN_ENABLED_LOCKED,
>>  };
>>  
>> -/*
>> - * This is a consolidated colorimetry list supported by HDMI and
>> +/**
>> + * enum drm_colorspace - color space
>> + *
>> + * This enum is a consolidated colorimetry list supported by HDMI and
>>   * DP protocol standard. The respective connectors will register
>>   * a property with the subset of this list (supported by that
>>   * respective protocol). Userspace will set the colorspace through
>>   * a colorspace property which will be created and exposed to
>>   * userspace.
>> + *
>> + * DP definitions come from the DP v2.0 spec
>> + * HDMI definitions come from the CTA-861-H spec
>> + *
>> + * @DRM_MODE_COLORIMETRY_DEFAULT:
>> + *   Driver specific behavior.
>> + *   For DP:
>> + *   	RGB encoded: sRGB (IEC 61966-2-1)
>> + *   	YCbCr encoded: ITU-R BT.601 colorimetry format
> 
> Does this mean that HDMI behavior is driver-specific while DP behavior
> is as defined?
> 

I should drop the bits that specify what this means for DP. I really
just took the 0h value for the colorimetry of the VSC SDP packet
(SDP = DP infoframe).

> Is it intentional that YCbCr encoding also uses different RGB-primaries
> than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
> 
> Or do you need to be more explicit on which parts of each spec apply
> (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> CICP parlance)?
> 
> E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.
> 
>> + * @DRM_MODE_COLORIMETRY_NO_DATA:
>> + *   Driver specific behavior.
>> + *   For HDMI:
>> + * 	Sets "No Data" in infoframe
> 
> Does DEFAULT mean that something else than "No Data" may be set in the
> HDMI infoframe?
> 
> If so, since these two have the same value, where is the difference? Is
> DEFAULT purely an UAPI token, and NO_DATA used internally? Or NO_DATA
> used only when crafting actual infoframe packets?
> 
> Should NO_DATA be documented to be a strictly driver-internal value,
> and not documented with UAPI?
> 

I don't think I have an answer for you. I will remove the "For HDMI"
bit to avoid confusion.

> I am unclear if userspace is using these enum values directly, or do
> they use the string names only.
> 

Userspace is using these enum values directly.

>> + * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
>> + *   (HDMI)
>> + *   SMPTE ST 170M colorimetry format
> 
> Does "colorimetry format" mean that the spec is used in full, for all
> of ColourPrimaries, TransferCharacteristics and MatrixCoefficients?
> 
> If yes, good. If not, the wording misleads me.
> 
>> + * @DRM_MODE_COLORIMETRY_BT709_YCC:
>> + *   (HDMI, DP)
>> + *   ITU-R BT.709 colorimetry format
>> + * @DRM_MODE_COLORIMETRY_XVYCC_601:
>> + *   (HDMI, DP)
>> + *   xvYCC601 colorimetry format
>> + * @DRM_MODE_COLORIMETRY_XVYCC_709:
>> + *   (HDMI, DP)
>> + *   xvYCC709 colorimetry format
> 
> Btw. xvYCC are funny because they require limited quantization range
> encoding, but use the foot- and headroom to encode out-of-nominal-range
> values in order to expand the color gamut with negative and greater
> than unity values.
> 
> Just for curiosity, is it in any way possible today to make use of that
> extended color gamut through KMS? Has it ever been possible?
> 
> I mean, the KMS color pipeline assumes full-range RGB, so I don't see
> any way to make use of xvYCC.
> 

I don't know it's possible. I wasn't the one to write the original
API for this. I think this API defines things that have never been
well understood. But since it's there I'll leave it as-is. The comments
(as requested) are trying to clarify things a bit. I think there
will be gaps if someone wants to actually implement it, even with
drivers that currently advertise support for the whole set.

>> + * @DRM_MODE_COLORIMETRY_SYCC_601:
>> + *   (HDMI, DP)
>> + *   sYCC601 colorimetry format
>> + * @DRM_MODE_COLORIMETRY_OPYCC_601:
>> + *   (HDMI, DP)
>> + *   opYCC601 colorimetry format
>> + * @DRM_MODE_COLORIMETRY_OPRGB:
>> + *   (HDMI, DP)
>> + *   opRGB colorimetry format
>> + * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
>> + *   (HDMI, DP)
>> + *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
>> + * @DRM_MODE_COLORIMETRY_BT2020_RGB:
>> + *   (HDMI, DP)
>> + *   ITU-R BT.2020 R' G' B' colorimetry format
>> + * @DRM_MODE_COLORIMETRY_BT2020_YCC:
>> + *   (HDMI, DP)
>> + *   ITU-R BT.2020 Y' C'b C'r colorimetry format
>> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
>> + *   (HDMI)
>> + *   SMPTE ST 2113 P3D65 colorimetry format
>> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
>> + *   (HDMI)
>> + *   SMPTE ST 2113 P3DCI colorimetry format
>> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
>> + *   (DP)
>> + *   RGB wide gamut fixed point colorimetry format
>> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
>> + *   (DP)
>> + *   RGB wide gamut floating point
>> + *   (scRGB (IEC 61966-2-2)) colorimetry format
> 
> Again, there is no way to actually make use of WIDE since the KMS color
> pipeline is limited to the unit range color values, right? Or is it
> possible by setting all color pipeline KMS properties to pass-through
> and using a floating-point FB?
> 
> I suppose the FIXED vs. FLOAT has the exact same problems as BT2020_YCC
> vs. BT2020_RGB, but I would be surprised if anyone cared.
> 

Again, I think pulling the actual enum values from the HDMI infoframes and
DP SDP packets into API was a mistake.

Harry

>> + * @DRM_MODE_COLORIMETRY_BT601_YCC:
>> + *   (DP)
>> + *   ITU-R BT.601 colorimetry format
>> + *   The DP spec does not say whether this is the 525 or the 625
>> + *   line version.
> 
> Good to note that ambiguity here. :-)
> 
> Or maybe the DP spec writer was thinking about BT.709 ColourPrimaries
> and BT.601 MatrixCoefficients...
> 
>>   */
>>  enum drm_colorspace {
>>  	/* For Default case, driver will set the colorspace */
> 
> 
> Thanks,
> pq

Re: [PATCH v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Harry Wentland]

On 3/8/23 04:09, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:53 -0500
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> From: Joshua Ashton <joshua@froggi.es>
>>
>> Userspace has no way of controlling or knowing the pixel encoding
>> currently, so there is no way for it to ever get the right values here.
>>
>> When we do add pixel_encoding control from userspace,we can pick the
>> right value for the colorimetry packet based on the
>> pixel_encoding + the colorspace.
>>
>> Let's deprecate these values, and have one BT.2020 colorspace entry
>> that userspace can use.
>>
>> v2:
>>  - leave CYCC alone for now; it serves a purpose
>>  - leave BT2020_RGB the new default BT2020
>>
>> Signed-off-by: Joshua Ashton <joshua@froggi.es>
>> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
>> Reviewed-by: Harry Wentland <harry.wentland@amd.com>
>>
>> Cc: Pekka Paalanen <ppaalanen@gmail.com>
>> Cc: Sebastian Wick <sebastian.wick@redhat.com>
>> Cc: Vitaly.Prosyak@amd.com
>> Cc: Uma Shankar <uma.shankar@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Joshua Ashton <joshua@froggi.es>
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: amd-gfx@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/display/drm_hdmi_helper.c |  7 +++----
>>  drivers/gpu/drm/drm_connector.c           |  8 ++++----
>>  drivers/gpu/drm/i915/display/intel_dp.c   | 14 +++++++-------
>>  include/drm/drm_connector.h               | 15 +++++++++------
>>  4 files changed, 23 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c b/drivers/gpu/drm/display/drm_hdmi_helper.c
>> index faf5e9efa7d3..05a0d03ffcda 100644
>> --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
>> +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
>> @@ -97,8 +97,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>>  #define HDMI_COLORIMETRY_OPYCC_601		(C(3) | EC(3) | ACE(0))
>>  #define HDMI_COLORIMETRY_OPRGB			(C(3) | EC(4) | ACE(0))
>>  #define HDMI_COLORIMETRY_BT2020_CYCC		(C(3) | EC(5) | ACE(0))
>> -#define HDMI_COLORIMETRY_BT2020_RGB		(C(3) | EC(6) | ACE(0))
>> -#define HDMI_COLORIMETRY_BT2020_YCC		(C(3) | EC(6) | ACE(0))
>> +#define HDMI_COLORIMETRY_BT2020			(C(3) | EC(6) | ACE(0))
>>  #define HDMI_COLORIMETRY_DCI_P3_RGB_D65		(C(3) | EC(7) | ACE(0))
>>  #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER	(C(3) | EC(7) | ACE(1))
>>  
>> @@ -112,8 +111,8 @@ static const u32 hdmi_colorimetry_val[] = {
>>  	[DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
>>  	[DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
>>  	[DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
>> -	[DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
>> -	[DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
>> +	[DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = HDMI_COLORIMETRY_BT2020,
>> +	[DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
>>  };
>>  
>>  #undef C
>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> index 61c29ce74b03..fe7eab15f727 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1031,9 +1031,9 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
>>  	/* Colorimetry based on ITU-R BT.2020 */
>>  	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>>  	/* Colorimetry based on ITU-R BT.2020 */
>> -	{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
>>  	/* Colorimetry based on ITU-R BT.2020 */
>> -	{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
>>  	/* Added as part of Additional Colorimetry Extension in 861.G */
>>  	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
>>  	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
>> @@ -1054,7 +1054,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>  	/* Colorimetry based on SMPTE RP 431-2 */
>>  	{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
>>  	/* Colorimetry based on ITU-R BT.2020 */
>> -	{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +	{ DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
>>  	{ DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
>>  	{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
>>  	/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> @@ -1068,7 +1068,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>>  	/* Colorimetry based on ITU-R BT.2020 */
>>  	{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>>  	/* Colorimetry based on ITU-R BT.2020 */
>> -	{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +	{ DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> 
> Let's hope no-one complains about missing the old string names in UABI. :-)
> 

As discussed at the hackfest, I'll drop this patch.

Harry

> Actually, you should write in the commit message why removing old names
> is fine.
> 
>>  };
>>  
>>  /**
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>> index c9be61d2348e..be100a193bf5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -1766,11 +1766,11 @@ static void intel_dp_compute_vsc_colorimetry(const struct intel_crtc_state *crtc
>>  	case DRM_MODE_COLORIMETRY_BT2020_CYCC:
>>  		vsc->colorimetry = DP_COLORIMETRY_BT2020_CYCC;
>>  		break;
>> -	case DRM_MODE_COLORIMETRY_BT2020_RGB:
>> -		vsc->colorimetry = DP_COLORIMETRY_BT2020_RGB;
>> -		break;
>> -	case DRM_MODE_COLORIMETRY_BT2020_YCC:
>> -		vsc->colorimetry = DP_COLORIMETRY_BT2020_YCC;
>> +	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
>> +	case DRM_MODE_COLORIMETRY_BT2020:
>> +		vsc->colorimetry = vsc->pixelformat == DP_PIXELFORMAT_RGB
>> +			? DP_COLORIMETRY_BT2020_RGB
>> +			: DP_COLORIMETRY_BT2020_YCC;
>>  		break;
>>  	case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
>>  	case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
>> @@ -3043,9 +3043,9 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
>>  	switch (conn_state->colorspace) {
>>  	case DRM_MODE_COLORIMETRY_SYCC_601:
>>  	case DRM_MODE_COLORIMETRY_OPYCC_601:
>> -	case DRM_MODE_COLORIMETRY_BT2020_YCC:
>> -	case DRM_MODE_COLORIMETRY_BT2020_RGB:
>>  	case DRM_MODE_COLORIMETRY_BT2020_CYCC:
>> +	case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
>> +	case DRM_MODE_COLORIMETRY_BT2020:
>>  		return true;
>>  	default:
>>  		break;
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index bb078666dc34..3e2e1bc7aa04 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -409,12 +409,15 @@ enum drm_privacy_screen_status {
>>   * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
>>   *   (HDMI, DP)
>>   *   ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
>> - * @DRM_MODE_COLORIMETRY_BT2020_RGB:
>> + * @DRM_MODE_COLORIMETRY_BT2020:
>>   *   (HDMI, DP)
>> - *   ITU-R BT.2020 R' G' B' colorimetry format
>> - * @DRM_MODE_COLORIMETRY_BT2020_YCC:
>> + *   ITU-R BT.2020 [R' G' B'] or
>> + * 	 ITU-R BT.2020 [Y' C'b C'r] or
>> + *   ITU-R BT.2020 [Y'c C'bc C'rc] (linear)
> 
> Drop the constant luminance variant from this value's doc.
> 
>> + *   colorimetry format
>> + * @DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
>>   *   (HDMI, DP)
>> - *   ITU-R BT.2020 Y' C'b C'r colorimetry format
>> + *   deprecated; same as DRM_MODE_COLORIMETRY_BT2020
>>   * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
>>   *   (HDMI)
>>   *   SMPTE ST 2113 P3D65 colorimetry format
>> @@ -448,8 +451,8 @@ enum drm_colorspace {
>>  	DRM_MODE_COLORIMETRY_OPYCC_601		= 6,
>>  	DRM_MODE_COLORIMETRY_OPRGB		= 7,
>>  	DRM_MODE_COLORIMETRY_BT2020_CYCC	= 8,
>> -	DRM_MODE_COLORIMETRY_BT2020_RGB		= 9,
>> -	DRM_MODE_COLORIMETRY_BT2020_YCC		= 10,
>> +	DRM_MODE_COLORIMETRY_BT2020		= 9,
>> +	DRM_MODE_COLORIMETRY_BT2020_DEPRECATED	= 10,
>>  	/* Additional Colorimetry extension added as part of CTA 861.G */
>>  	DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65	= 11,
>>  	DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER	= 12,
> 
> With the caveat noted and nitpick fixed:
> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> 
> 
> Thanks,
> pq

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Harry Wentland]

On 3/8/23 04:24, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:59 -0500
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> We want compositors to be able to set the output
>> colorspace on DP and HDMI outputs, based on the
>> caps reported from the receiver via EDID.
>>
>> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
>> Cc: Pekka Paalanen <ppaalanen@gmail.com>
>> Cc: Sebastian Wick <sebastian.wick@redhat.com>
>> Cc: Vitaly.Prosyak@amd.com
>> Cc: Joshua Ashton <joshua@froggi.es>
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: amd-gfx@lists.freedesktop.org
>> Reviewed-By: Joshua Ashton <joshua@froggi.es>
>> ---
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++++++++++++++
>>  1 file changed, 15 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 f91b2ea13d96..2d883c6dae90 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
>>  	return amdgpu_dm_connector->num_modes;
>>  }
>>  
>> +static const u32 supported_colorspaces =
>> +	BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
>> +	BIT(DRM_MODE_COLORIMETRY_OPRGB) |
>> +	BIT(DRM_MODE_COLORIMETRY_BT2020) |
>> +	BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> 
> No DEFAULT?

DEFAULT is always added in drm_mode_create_colorspace_property.

> No BT.709 RGB, i.e. sRGB?
> 

No RGB variants for BT.709 or sRGB are explicitly defined in the API
(which is based on the infoframe values). Not trying to change things
up here.

You'll probably want to select "DEFAULT" if you want sRGB.

Harry

> Doesn't DRM core reject enum uint values that are not listed in the enum
> property?
> 
> 
> Thanks,
> pq
> 
>> +
>>  void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>>  				     struct amdgpu_dm_connector *aconnector,
>>  				     int connector_type,
>> @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
>>  				adev->mode_info.abm_level_property, 0);
>>  	}
>>  
>> +	if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
>> +		if (!drm_mode_create_hdmi_colorspace_property(&aconnector->base, supported_colorspaces))
>> +			drm_connector_attach_colorspace_property(&aconnector->base);
>> +	} else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>> +		   connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +		if (!drm_mode_create_dp_colorspace_property(&aconnector->base, supported_colorspaces))
>> +			drm_connector_attach_colorspace_property(&aconnector->base);
>> +	}
>> +
>>  	if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>>  	    connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>>  	    connector_type == DRM_MODE_CONNECTOR_eDP) {
> 

Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI

[Harry Wentland]

On 3/17/23 09:53, Joshua Ashton wrote:
> 
> 
> On 3/17/23 13:35, Pekka Paalanen wrote:
>> On Fri, 17 Mar 2023 14:50:40 +0200
>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>
>>> On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
>>>> On Fri, 17 Mar 2023 01:01:38 +0200
>>>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>>>   
>>>>> On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
>>>>>> On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
>>>>>> <ville.syrjala@linux.intel.com> wrote:
>>>>>>>
>>>>>>> On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
>>>>>>>> On Thu, 16 Mar 2023 12:47:51 +0200
>>>>>>>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>>>>>>>    
>>>>>>>>> On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
>>>>>>>>>> On Thu, 16 Mar 2023 11:50:27 +0200
>>>>>>>>>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>>>>>>>>>    
>>>>>>>>>>> On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
>>>>>>>>>>>> On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland <harry.wentland@amd.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> We want compositors to be able to set the output
>>>>>>>>>>>>> colorspace on DP and HDMI outputs, based on the
>>>>>>>>>>>>> caps reported from the receiver via EDID.
>>>>>>>>>>>>
>>>>>>>>>>>> About that... The documentation says that user space has to check the
>>>>>>>>>>>> EDID for what the sink actually supports. So whatever is in
>>>>>>>>>>>> supported_colorspaces is just what the driver/hardware is able to set
>>>>>>>>>>>> but doesn't actually indicate that the sink supports it.
>>>>>>>>>>>>
>>>>>>>>>>>> So the only way to enable bt2020 is by checking if the sink supports
>>>>>>>>>>>> both RGB and YUV variants because both could be used by the driver.
>>>>>>>>>>>> Not great at all. Something to remember for the new property.
>>>>>>>>>>>
>>>>>>>>>>> Hmm. I wonder if that's even legal... Looks like maybe it
>>>>>>>>>>> is since I can't immediately spot anything in CTA-861 to
>>>>>>>>>>> forbid it :/
>>>>>>>>>>
>>>>>>>>>> Wouldn't the driver do the same EDID check before choosing whether it
>>>>>>>>>> uses RGB or YCbCr signalling?
>>>>>>>>>
>>>>>>>>> I suppose it could. The modeset would then fail, which is perhaps
>>>>>>>>
>>>>>>>> Could? What are they missing?
>>>>>>>
>>>>>>> The fact that the new property that also affects the rgb->ycbcr matrix
>>>>>>> doesn't even exist?
>>>>>>
>>>>>> I think the question was about the current Colorspace property.
>>>>
>>>> Yes.
>>>>
>>>> We need to be able to set ColourPrimaries infoframe field for the sink.
>>>> Only userspace knows what ColourPrimaries it uses, and the driver has
>>>> no need to care at all, other than tell the sink what we have.
>>>>
>>>> When a driver chooses to use YCbCr, it needs to use the
>>>> MatrixCoefficients the sink expects.
>>>>
>>>> If we send the infoframe to the sink telling the signal uses BT.2020
>>>> ColourPrimaries, does that same bit pattern also tell the sink we are
>>>> using the BT.2020 NCL MatrixCoefficients if the driver chooses YCbCr?
>>>>
>>>> Do drivers actually use BT.2020 NCL MatrixCoefficients in that case?
>>>
>>> No. I think I've repeated this same line a thousand times already:
>>> The current colorspace property *only* affects the infoframe/msa/sdp,
>>> nothing else.
> 
> No, sorry, this is completely nonsensical.
> 
> Even with the current Colorspace property that we want to deprecate, drivers doing an implicit conversion from RGB -> to YCC should respect the colorspace property to pick the right matrix coefficients here.
> 
> Doing so simply introduces a useless mismatch that is unavoidable from userspace and makes absolutely no sense.
> 
> Arguing about this is kind of completely useless anyway... as we are deprecating this property... Let's pleeeease let it die.
> 
> I am not sure why these patches were re-submitted with my RB again after we had the discussion previously about making a new one that's actually going to get tested and have userspace consumers.
> 

Apologies for that. I must've mis-read thins. Dropping them from the
next version of this set.

Based on the hackfest discussions I'll iterate on this with the hopes
to unblock the Colorspace property on AMD HW. A more thorough API will
require more work and rushing it would be unwise. In the meantime we
do really need something on AMD HW.

Harry

> (FTR, I guess Gamescope *is* a userspace consumer for this broken property right now, but I am completely happy for AMDGPU upstream to never support this and to just move onto the new property and leave this one behind).
> 
>>
>> That's the problem. I don't know what that means.
>>
>> Does it mean that the sink expects BT.2020 NCL MatrixCoefficients to
>> have been used?
> 
> Yes.
> 
>>
>> And the driver will never use BT.2020 NCL MatrixCoefficients in any
>> circumstances?
> 
> That is what Ville is describing and what I disagree with, yes.
> 
> But whether or not Ville or I agree on that is kind of irrelevant as we are going to deprecate the property... right... right?
> 
>>
>> See the conflict? The sink will be decoding the signal incorrectly,
>> because we are encoding it with the wrong MatrixCoefficients if the
>> driver happens to silently choose YCbCr and userspace wants to send
>> BT2020 ColourPrimaries indicated in the infoframe.
> 
> Yeah.
> 
> - Joshie 🐸✨
> 
>>
>>>
>>>>
>>>> If they don't, then YCbCr BT.2020 has never worked, which is another
>>>> nail in the coffin for "Colorspace" property.
>>>
>>> That is the same nail we've been talking about all along I thought.
>>>
>>>> But it still means that
>>>> RGB BT.2020 may have worked correctly, and then drivers would regress
>>>> if they started picking YCbCr for any reason where they previously used
>>>> RGB.
>>>
>>> The policy has been to use RGB if at all possible. Only falling back
>>> to YCbCr 4:2:0 if absolutely necessary (eg. EDID says 4:2:0 must
>>> be used, or there's not enough bandwidth for 4:4:4, etc.). If the
>>> behaviour suddenly changes then it probably means the driver was
>>> doing something illegal before by using RGB 4:4:4.
>>
>> Ok.
>>
>>>>>>>>
>>>>>>>> I mean, drivers are already automatically choosing between RGB and YCbCr
>>>>>>>> signalling based on e.g. available bandwidth. Surely they already will
>>>>>>>> not attempt to send a signal format to a monitor that does not say it
>>>>>>>> supports that?
>>>>>>
>>>>>> That's exactly what they do. The drivers don't check the EDID for the
>>>>>> colorimetry the sink supports and the responsibility is punted off to
>>>>>> user space.
>>>>
>>>> I suspect there are two different things:
>>>>
>>>> - which of RGB, YCbCr 4:4:4, YCbCr 4:2:0 can the sink take
>>>> - the supported MatrixCoefficients for each of the YCbCr
>>>>
>>>> Surely drivers are already checking the former point?
>>>
>>> Yes.
>>>
>>>>
>>>> I'm not surprised if they are not checking the latter point, but they
>>>> do need to, because it is the driver making the choice between RGB and
>>>> some YCbCr.
>>>
>>> This point has been irrelevant since we always select BT.709
>>> and there is no optional feature bit in EDID to check for that.
>>> Presumaly it is mandatory for sinks to support both BT.601 and
>>> BT.709 whenever they support YCbCr in general.
>>
>> Ok, so BT.601 and BT.709 MatrixCoefficients are cool. How do you tell
>> the sink which one you used, btw?
>>
>> What about BT.2020 MatrixCoefficients?
>>
>>
>> Thanks,
>> pq