On Thu, Jun 10, 2021 at 9:55 AM Pekka Paalanen ppaalanen@gmail.com wrote:

On Tue, 8 Jun 2021 19:43:15 +0200 Werner Sembach wse@tuxedocomputers.com wrote:

...

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

Maybe "bit depth per pixel" -> "bit depth per pixel color component" for slightly more clarity?

...

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

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

Signed-off-by: Werner Sembach wse@tuxedocomputers.com

drivers/gpu/drm/drm_atomic_uapi.c | 2 ++ drivers/gpu/drm/drm_connector.c | 41 +++++++++++++++++++++++++++++++ include/drm/drm_connector.h | 15 +++++++++++ 3 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 268bb69c2e2f..7ae4e40936b5 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector, *val = 0; } else if (property == connector->max_bpc_property) { *val = state->max_requested_bpc;

• } else if (property == connector->active_bpc_property) {
  

•         *val = state->active_bpc;
  } else if (connector->funcs->atomic_get_property) {
          return connector->funcs->atomic_get_property(connector,
                          state, property, val);
  

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 7631f76e7f34..c0c3c09bfed0 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1195,6 +1195,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {

• drm_connector_attach_max_bpc_property() to create and attach the
• property to the connector during initialization.

• • active bpc:
• • This read-only range property tells userspace the pixel color bit depth
• • actually used by the hardware display engine on "the cable" on a
• • connector. The chosen value depends on hardware capabilities, both
• • display engine and connected monitor, and the "max bpc" property.
• • Drivers shall use drm_connector_attach_active_bpc_property() to install
• • this property.

This description is now clear to me, but I wonder, is it also how others understand it wrt. dithering?

Dithering done on monitor is irrelevant, because we are talking about "on the cable" pixels. But since we are talking about "on the cable" pixels, also dithering done by the display engine must not factor in. Should the dithering done by display engine result in higher "active bpc" number than what is actually transmitted on the cable?

I cannot guess what userspace would want exactly. I think the strict "on the cable" interpretation is a safe bet, because it then gives a lower limit on observed bpc. Dithering settings should be exposed with other KMS properties, so userspace can factor those in. But to be absolutely sure, we'd have to ask some color management experts.

Cc'ing Mario in case he has an opinion.

Thanks. I like this a lot, in fact such a connector property was on my todo list / wish list for something like that!

I agree with the "active bpc" definition here in this patch and Pekka's comments. I want what goes out over the cable, not including any effects of dithering. At least AMD's amdpu-kms driver exposes "active bpc" already as a per-connector property in debugfs, and i use reported output from there a lot to debug problems with respect to HDR display or high color precision output, and to verify i'm not fooling myself wrt. what goes out, compared to what dithering may "fake" on top of it.

Software like mine would greatly benefit from getting this directly off the connector, ie. as a RandR output property, just like with "max bpc", as mapping X11 output names to driver output names is a guessing game, directing regular users to those debugfs files is tedious and error prone, and many regular users don't have root permissions anyway.

Sometimes one wants to prioritize "active bpc" over resolution or refresh rate, and especially on now more common HDR displays, and actual bit depth also changes depending on bandwidth requirements vs. availability, and how well DP link training went with a flaky or loose cable, like only getting 10 bpc for HDR-10 when running on less than maximum resolution or refresh rate, and the cable "just right". This can be very puzzling without actual feedback over true "active bpc".

It would also be very beneficial to also have reporting and control over gpu dithering state via a read/write property. Some drivers like nouveau-kms have that, and i think some older non-atomic amd drivers had it at some point in time iirc, which was useful, also for debugging of dithering induced issues, when one wants to pass-through a 8 bpc framebuffer unmodified to special display equipment, and dithering silently kicked in and is messing things up.

And a read only property for DSC active would be good to account for the future.

Since "active bpc" is related to "max bpc", the both should follow the same definition. Do they do that now?

Maybe a clarifying note about interaction with dithering would still be good to have here.

+1

I recall reading some comments from you about having problems with making this immutable. Is it properly immutable now?

That is, drm_info reports the property as "(immutable)". https://github.com/ascent12/drm_info

If we are not sure if DSC could result in lower observed bpc than "active bpc", then DSC state would need to be exposed as a KMS property too, with a note that it invalidates what "active bpc" shows. Or maybe "active bpc" should be "unknown" in that case?

Yes. Or could we have some way of disabling DSC per connector in the future? I'm not familiar with current implementations, but i'd very much would like to have a selectable tradeoff if i want a "pure" video signal and maybe not get some high resolution / refresh rate modes on low-bandwidth cables, or if i want max resolution/refresh but some lossy perceptual compression.

thanks, -mario

Thanks, pq

...

• Connectors also have one standardized atomic property:
• CRTC_ID:

@@ -2150,6 +2158,39 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector, } EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);

+/**

• • drm_connector_attach_active_bpc_property - attach "active bpc" property
• • @connector: connector to attach active bpc property on.
• • @min: The minimum bit depth supported by the connector.
• • @max: The maximum bit depth supported by the connector.
• • This is used to check the applied bit depth on a connector.
• • Returns:
• • Zero on success, negative errno on failure.
• */

+int drm_connector_attach_active_bpc_property(struct drm_connector *connector,

•                                   int min, int max)
  

+{

• struct drm_device *dev = connector->dev;
  

• struct drm_property *prop;
  

• prop = connector->active_bpc_property;
  

• if (!prop) {
  

•         prop = drm_property_create_range(dev, 0, "active bpc", min, max);
  

•         if (!prop)
  

•                 return -ENOMEM;
  

•         connector->active_bpc_property = prop;
  

• }
  

• drm_object_attach_property(&connector->base, prop, 0);
  

• connector->state->active_bpc = 0;
  

• return 0;
  

+} +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);

/**

• drm_connector_set_vrr_capable_property - sets the variable refresh rate
• capable property for a connector

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index 1922b278ffad..c58cba2b6afe 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -781,6 +781,13 @@ struct drm_connector_state { */ u8 max_bpc;

• /**
  

•  * @active_bpc: Read only property set by the GPU driver to the actually
  

•  * applied bit depth of the pixels after evaluating all hardware
  

•  * limitations.
  

•  */
  

• u8 active_bpc;
  

• /**
   * @hdr_output_metadata:
   * DRM blob property for HDR output metadata
  

@@ -1380,6 +1387,12 @@ struct drm_connector { */ struct drm_property *max_bpc_property;

• /**
  

•  * @active_bpc_property: Default connector property for the active bpc
  

•  * to be driven out of the connector.
  

•  */
  

• struct drm_property *active_bpc_property;
  

#define DRM_CONNECTOR_POLL_HPD (1 << 0) #define DRM_CONNECTOR_POLL_CONNECT (1 << 1) #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2) @@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_with_quirk( int width, int height); int drm_connector_attach_max_bpc_property(struct drm_connector *connector, int min, int max); +int drm_connector_attach_active_bpc_property(struct drm_connector *connector,

•                                   int min, int max);
  
  

/**

• struct drm_tile_group - Tile group metadata

On Thu, Jun 10, 2021 at 02:50:36PM +0200, Maxime Ripard wrote:

Hi

On Tue, Jun 08, 2021 at 07:43:17PM +0200, Werner Sembach wrote:

...

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

Signed-off-by: Werner Sembach wse@tuxedocomputers.com

drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++ drivers/gpu/drm/i915/display/intel_dp.c | 8 ++++++-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++- drivers/gpu/drm/i915/display/intel_hdmi.c | 4 +++- 4 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 64e9107d70f7..50c11b8770a7 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -10388,6 +10388,9 @@ static int intel_atomic_commit(struct drm_device *dev, { struct intel_atomic_state *state = to_intel_atomic_state(_state); struct drm_i915_private *dev_priv = to_i915(dev);

• struct drm_connector *connector;

• struct drm_connector_state *new_conn_state;

• int i; int ret = 0;

  state->wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);

@@ -10456,6 +10459,17 @@ static int intel_atomic_commit(struct drm_device *dev, intel_shared_dpll_swap_state(state); intel_atomic_track_fbs(state);

• /* Extract information from crtc to communicate it to userspace as connector properties */
• for_each_new_connector_in_state(&state->base, connector, new_conn_state, i) {

• struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
  

• if (crtc) {
  

• 	struct intel_crtc_state *new_crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
  

• 	new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 3;
  

• }
  

• else
  

• 	new_conn_state->active_bpc = 0;
  

• }

This seems fairly intrusive, but also commit / commit_tail might not be the best place to put this, we want to support it at the connector level.

Indeed, this will cause some issue if your HDMI output is a bridge for example, where the commit will be in an entirely different driver that has no dependency on the HDMI controller one.

I think it would be best to do that assignment in atomic_check. That way, if the userspace does a commit with DRM_MODE_ATOMIC_TEST_ONLY it would know what the output state would have been like.

DRM_MODE_ATOMIC_TEST_ONLY isn't allowed to change anything.

On Tue, 8 Jun 2021 19:43:18 +0200 Werner Sembach wse@tuxedocomputers.com wrote:

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

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

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

Signed-off-by: Werner Sembach wse@tuxedocomputers.com

drivers/gpu/drm/drm_atomic_uapi.c | 2 ++ drivers/gpu/drm/drm_connector.c | 46 +++++++++++++++++++++++++++++++ include/drm/drm_connector.h | 13 +++++++++ 3 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 7ae4e40936b5..bb78da2405f9 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -875,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector, *val = state->max_requested_bpc; } else if (property == connector->active_bpc_property) { *val = state->active_bpc;

• } else if (property == connector->active_color_format_property) {

• *val = state->active_color_format;
  

  } else if (connector->funcs->atomic_get_property) { return connector->funcs->atomic_get_property(connector, state, property, val);

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index c0c3c09bfed0..f4f35c4117b6 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -887,6 +887,14 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = { { DRM_MODE_SUBCONNECTOR_Native, "Native" }, /* DP */ };

+static const struct drm_prop_enum_list drm_color_format_enum_list[] = {

• { 0, "none" },
• { DRM_COLOR_FORMAT_RGB444, "rgb" },
• { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
• { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
• { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },

+};

DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name, drm_dp_subconnector_enum_list)

@@ -1202,6 +1210,14 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {

• display engine and connected monitor, and the "max bpc" property.
• Drivers shall use drm_connector_attach_active_bpc_property() to install
• this property.

• • active color format:
• • This read-only property tells userspace the color format actually used
• • by the hardware display engine on "the cable" on a connector. The chosen
• • value depends on hardware capabilities, both display engine and
• • connected monitor. Drivers shall use
• • drm_connector_attach_active_color_format_property() to install this
• • property.

Hi,

I think also the enum values should be documented in the UAPI docs. Or listed at the very least. Otherwise userspace developers "do not know" what strings to decode.

Thanks, pq

• Connectors also have one standardized atomic property:

@@ -2191,6 +2207,36 @@ int drm_connector_attach_active_bpc_property(struct drm_connector *connector, } EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);

+/**

• • drm_connector_attach_active_color_format_property - attach "active color format" property
• • @connector: connector to attach active color format property on.
• • This is used to check the applied color format on a connector.
• • Returns:
• • Zero on success, negative errno on failure.
• */

+int drm_connector_attach_active_color_format_property(struct drm_connector *connector) +{

• struct drm_device *dev = connector->dev;
• struct drm_property *prop;
• prop = connector->active_color_format_property;
• if (!prop) {

• prop = drm_property_create_enum(dev, 0, "active color format", drm_color_format_enum_list, ARRAY_SIZE(drm_color_format_enum_list));
  

• if (!prop)
  

• 	return -ENOMEM;
  

• connector->active_color_format_property = prop;
  

• }
• drm_object_attach_property(&connector->base, prop, 0);
• connector->state->active_color_format = 0;
• return 0;

+} +EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);

/**

• drm_connector_set_vrr_capable_property - sets the variable refresh rate
• capable property for a connector

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index c58cba2b6afe..167cd36129ae 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -788,6 +788,12 @@ struct drm_connector_state { */ u8 active_bpc;

• /**

• * active_color_format: Read only property set by the GPU driver to the
  

• * actually used color format after evaluating all hardware limitations.
  

• */
  

• u32 active_color_format;
• /**
  • @hdr_output_metadata:
  • DRM blob property for HDR output metadata

@@ -1393,6 +1399,12 @@ struct drm_connector { */ struct drm_property *active_bpc_property;

• /**

• * @active_color_format_property: Default connector property for the
  

• * active color format to be driven out of the connector.
  

• */
  

• struct drm_property *active_color_format_property;

#define DRM_CONNECTOR_POLL_HPD (1 << 0) #define DRM_CONNECTOR_POLL_CONNECT (1 << 1) #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2) @@ -1713,6 +1725,7 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector, int min, int max); int drm_connector_attach_active_bpc_property(struct drm_connector *connector, int min, int max); +int drm_connector_attach_active_color_format_property(struct drm_connector *connector);

/**

• struct drm_tile_group - Tile group metadata