[PATCH 1/2] drm: Add CRTC background color property

[PATCH 1/2] drm: Add CRTC background color property

[Matt Roper]

Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes).  Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.

To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value.  Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c.li@intel.com
Cc: harish.krupo.kps@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c         |  5 +++++
 drivers/gpu/drm/drm_mode_config.c         |  6 ++++++
 include/drm/drm_crtc.h                    | 17 +++++++++++++++++
 include/drm/drm_mode_config.h             |  5 +++++
 include/uapi/drm/drm_mode.h               | 26 ++++++++++++++++++++++++++
 6 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 3ba996069d69..2f8c55668089 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -101,6 +101,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
 	state->planes_changed = false;
 	state->connectors_changed = false;
 	state->color_mgmt_changed = false;
+	state->bgcolor_changed = false;
 	state->zpos_changed = false;
 	state->commit = NULL;
 	state->event = NULL;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..399f0ead5370 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -467,6 +467,9 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
 			return -EFAULT;
 
 		set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+	} else if (property == config->bgcolor_property) {
+		state->background_color = val;
+		state->bgcolor_changed = true;
 	} else if (crtc->funcs->atomic_set_property) {
 		return crtc->funcs->atomic_set_property(crtc, state, property, val);
 	} else {
@@ -499,6 +502,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
 		*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
 	else if (property == config->prop_out_fence_ptr)
 		*val = 0;
+	else if (property == config->bgcolor_property)
+		*val = state->background_color;
 	else if (crtc->funcs->atomic_get_property)
 		return crtc->funcs->atomic_get_property(crtc, state, property, val);
 	else
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..75e376755176 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -352,6 +352,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.modifiers_property = prop;
 
+	prop = drm_property_create_range(dev, 0, "BACKGROUND_COLOR",
+					 0, GENMASK_ULL(63, 0));
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.bgcolor_property = prop;
+
 	return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b21437bc95bf..ddfdad9ccecb 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -168,6 +168,11 @@ struct drm_crtc_state {
 	 * drivers to steer the atomic commit control flow.
 	 */
 	bool color_mgmt_changed : 1;
+	/**
+	 * @bgcolor_changed: Background color value has changed.  Used by
+	 * drivers to steer the atomic commit control flow.
+	 */
+	bool bgcolor_changed : 1;
 
 	/**
 	 * @no_vblank:
@@ -274,6 +279,18 @@ struct drm_crtc_state {
 	 */
 	struct drm_property_blob *gamma_lut;
 
+	/**
+	 * @background_color:
+	 *
+	 * RGB value representing the pipe's background color.  The background
+	 * color (aka "canvas color") of a pipe is the color that will be used
+	 * for pixels not covered by a plane, or covered by transparent pixels
+	 * of a plane.  The value here should be built via drm_rgba();
+	 * individual color components can be extracted with desired precision
+	 * via the DRM_RGBA_*() macros.
+	 */
+	u64 background_color;
+
 	/**
 	 * @target_vblank:
 	 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 928e4172a0bb..c3f57a9e5b31 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -807,6 +807,11 @@ struct drm_mode_config {
 	 */
 	struct drm_property *writeback_out_fence_ptr_property;
 
+	/**
+	 * @bgcolor_property: RGBA background color for CRTC.
+	 */
+	struct drm_property *bgcolor_property;
+
 	/* dumb ioctl parameters */
 	uint32_t preferred_depth, prefer_shadow;
 	bool quirk_addfb_prefer_xbgr_30bpp;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index d3e0fe31efc5..66e2e2c2630e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -888,6 +888,32 @@ struct drm_mode_revoke_lease {
 	__u32 lessee_id;
 };
 
+/*
+ * Put RGBA values into a standard 64-bit representation that can be used
+ * for ioctl parameters, inter-driver commmunication, etc.  If the component
+ * values being provided contain less than 16 bits of precision, they'll
+ * be shifted into the most significant bits.
+ */
+static inline __u64
+drm_rgba(__u8 bpc, __u16 red, __u16 green, __u16 blue, __u16 alpha)
+{
+	int msb_shift = 16 - bpc;
+
+	return (__u64)alpha << msb_shift << 48 |
+	       (__u64)blue  << msb_shift << 32 |
+	       (__u64)green << msb_shift << 16 |
+	       (__u64)red   << msb_shift;
+}
+
+/*
+ * Extract the specified number of bits of a specific color component from a
+ * standard 64-bit RGBA value.
+ */
+#define DRM_RGBA_RED(c, numbits)   (__u16)((c & 0xFFFFull)     >> (16-numbits))
+#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xFFFFull<<16) >> (32-numbits))
+#define DRM_RGBA_BLUE(c, numbits)  (__u16)((c & 0xFFFFull<<32) >> (48-numbits))
+#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xFFFFull<<48) >> (64-numbits))
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.14.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/2] drm: Add CRTC background color property

[Ville Syrjälä]

On Wed, Oct 10, 2018 at 04:50:50PM -0700, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes).  Compositors that want a UI with
> a solid color background can potentially save memory bandwidth by
> setting the CRTC background property and using smaller planes to display
> the rest of the content.
> 
> To avoid confusion between different ways of encoding RGB data, we
> define a standard 64-bit format that should be used for this property's
> value.  Helper functions and macros are provided to generate and dissect
> values in this standard format with varying component precision values.
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: wei.c.li@intel.com
> Cc: harish.krupo.kps@intel.com
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c         |  5 +++++
>  drivers/gpu/drm/drm_mode_config.c         |  6 ++++++
>  include/drm/drm_crtc.h                    | 17 +++++++++++++++++
>  include/drm/drm_mode_config.h             |  5 +++++
>  include/uapi/drm/drm_mode.h               | 26 ++++++++++++++++++++++++++
>  6 files changed, 60 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 3ba996069d69..2f8c55668089 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -101,6 +101,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
>  	state->planes_changed = false;
>  	state->connectors_changed = false;
>  	state->color_mgmt_changed = false;
> +	state->bgcolor_changed = false;
>  	state->zpos_changed = false;
>  	state->commit = NULL;
>  	state->event = NULL;
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..399f0ead5370 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -467,6 +467,9 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>  			return -EFAULT;
>  
>  		set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> +	} else if (property == config->bgcolor_property) {
> +		state->background_color = val;
> +		state->bgcolor_changed = true;
>  	} else if (crtc->funcs->atomic_set_property) {
>  		return crtc->funcs->atomic_set_property(crtc, state, property, val);
>  	} else {
> @@ -499,6 +502,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>  		*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>  	else if (property == config->prop_out_fence_ptr)
>  		*val = 0;
> +	else if (property == config->bgcolor_property)
> +		*val = state->background_color;
>  	else if (crtc->funcs->atomic_get_property)
>  		return crtc->funcs->atomic_get_property(crtc, state, property, val);
>  	else
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..75e376755176 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -352,6 +352,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
>  		return -ENOMEM;
>  	dev->mode_config.modifiers_property = prop;
>  
> +	prop = drm_property_create_range(dev, 0, "BACKGROUND_COLOR",
> +					 0, GENMASK_ULL(63, 0));
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.bgcolor_property = prop;
> +
>  	return 0;
>  }
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..ddfdad9ccecb 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -168,6 +168,11 @@ struct drm_crtc_state {
>  	 * drivers to steer the atomic commit control flow.
>  	 */
>  	bool color_mgmt_changed : 1;
> +	/**
> +	 * @bgcolor_changed: Background color value has changed.  Used by
> +	 * drivers to steer the atomic commit control flow.
> +	 */
> +	bool bgcolor_changed : 1;
>  
>  	/**
>  	 * @no_vblank:
> @@ -274,6 +279,18 @@ struct drm_crtc_state {
>  	 */
>  	struct drm_property_blob *gamma_lut;
>  
> +	/**
> +	 * @background_color:
> +	 *
> +	 * RGB value representing the pipe's background color.  The background
> +	 * color (aka "canvas color") of a pipe is the color that will be used
> +	 * for pixels not covered by a plane, or covered by transparent pixels
> +	 * of a plane.  The value here should be built via drm_rgba();
> +	 * individual color components can be extracted with desired precision
> +	 * via the DRM_RGBA_*() macros.
> +	 */
> +	u64 background_color;
> +
>  	/**
>  	 * @target_vblank:
>  	 *
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 928e4172a0bb..c3f57a9e5b31 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -807,6 +807,11 @@ struct drm_mode_config {
>  	 */
>  	struct drm_property *writeback_out_fence_ptr_property;
>  
> +	/**
> +	 * @bgcolor_property: RGBA background color for CRTC.
> +	 */
> +	struct drm_property *bgcolor_property;
> +
>  	/* dumb ioctl parameters */
>  	uint32_t preferred_depth, prefer_shadow;
>  	bool quirk_addfb_prefer_xbgr_30bpp;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index d3e0fe31efc5..66e2e2c2630e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -888,6 +888,32 @@ struct drm_mode_revoke_lease {
>  	__u32 lessee_id;
>  };
>  
> +/*
> + * Put RGBA values into a standard 64-bit representation that can be used
> + * for ioctl parameters, inter-driver commmunication, etc.  If the component
> + * values being provided contain less than 16 bits of precision, they'll
> + * be shifted into the most significant bits.
> + */
> +static inline __u64
> +drm_rgba(__u8 bpc, __u16 red, __u16 green, __u16 blue, __u16 alpha)
> +{
> +	int msb_shift = 16 - bpc;
> +
> +	return (__u64)alpha << msb_shift << 48 |
> +	       (__u64)blue  << msb_shift << 32 |
> +	       (__u64)green << msb_shift << 16 |
> +	       (__u64)red   << msb_shift;

I would still call that abgr in drm terminology (eg. when compared
to the fourccs). And I'd still prefer the argb order as it's what
our hardware expects anyway :) Would make me less confused when
looking at a 64bit hex color value at least.


> +}
> +
> +/*
> + * Extract the specified number of bits of a specific color component from a
> + * standard 64-bit RGBA value.
> + */
> +#define DRM_RGBA_RED(c, numbits)   (__u16)((c & 0xFFFFull)     >> (16-numbits))
> +#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xFFFFull<<16) >> (32-numbits))
> +#define DRM_RGBA_BLUE(c, numbits)  (__u16)((c & 0xFFFFull<<32) >> (48-numbits))
> +#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xFFFFull<<48) >> (64-numbits))
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> -- 
> 2.14.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/2] drm: add crtc background color property

[Raphael GALLAIS-POU - foss]

Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes).  Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.

To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value.  Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
 drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
 drivers/gpu/drm/drm_mode_config.c         |  6 ++++
 include/drm/drm_blend.h                   |  1 +
 include/drm/drm_crtc.h                    | 12 ++++++++
 include/drm/drm_mode_config.h             |  5 ++++
 include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
 8 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index ddcf5c2c8e6a..1b95a4ecdb2b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -72,6 +72,7 @@ __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
 				     struct drm_crtc *crtc)
 {
 	crtc_state->crtc = crtc;
+	crtc_state->bgcolor = drm_argb(16, 0xffff, 0, 0, 0);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 438e9585b225..fea68f8f17f8 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -483,6 +483,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
 		set_out_fence_for_crtc(state->state, crtc, fence_ptr);
 	} else if (property == crtc->scaling_filter_property) {
 		state->scaling_filter = val;
+	} else if (property == config->bgcolor_property) {
+		state->bgcolor = val;
 	} else if (crtc->funcs->atomic_set_property) {
 		return crtc->funcs->atomic_set_property(crtc, state, property, val);
 	} else {
@@ -520,6 +522,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
 		*val = 0;
 	else if (property == crtc->scaling_filter_property)
 		*val = state->scaling_filter;
+	else if (property == config->bgcolor_property)
+		*val = state->bgcolor;
 	else if (crtc->funcs->atomic_get_property)
 		return crtc->funcs->atomic_get_property(crtc, state, property, val);
 	else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index ec37cbfabb50..6692d6a6db22 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -186,8 +186,7 @@
  *		 assumed to be 1.0
  *
  * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
+ * plane or the CRTC.
  *
  * SCALING_FILTER:
  *     Indicates scaling filter to be used for plane scaler
@@ -201,6 +200,21 @@
  *
  * Drivers can set up this property for a plane by calling
  * drm_plane_create_scaling_filter_property
+ *
+ * BACKGROUND_COLOR:
+ *	Defines the ARGB color of a full-screen layer that exists below all
+ *	planes.  This color will be used for pixels not covered by any plane
+ *	and may also be blended with plane contents as allowed by a plane's
+ *	alpha values.  The background color defaults to black, and is assumed
+ *	to be black for drivers that do not expose this property.  Although
+ *	background color isn't a plane, it is assumed that the color provided
+ *	here undergoes the same pipe-level degamma/CSC/gamma transformations
+ *	that planes undergo.  Note that the color value provided here includes
+ *	an alpha channel...non-opaque background color values are allowed,
+ *	but are generally only honored in special cases (e.g., when a memory
+ *	writeback connector is in use).
+ *
+ *	This property is setup with drm_crtc_add_bgcolor_property().
  */
 
 /**
@@ -616,3 +630,19 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 	return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
+
+/**
+ * drm_crtc_add_bgcolor_property - add background color property
+ * @crtc: drm crtc
+ *
+ * Adds the background color property to @crtc.  The property defaults to
+ * solid black and will accept 64-bit ARGB values in the format generated by
+ * drm_argb().
+ */
+void drm_crtc_add_bgcolor_property(struct drm_crtc *crtc)
+{
+	drm_object_attach_property(&crtc->base,
+				   crtc->dev->mode_config.bgcolor_property,
+				   drm_argb(16, 0xffff, 0, 0, 0));
+}
+EXPORT_SYMBOL(drm_crtc_add_bgcolor_property);
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 37b4b9f0e468..d62d6585399b 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -371,6 +371,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.modifiers_property = prop;
 
+	prop = drm_property_create_range(dev, 0, "BACKGROUND_COLOR",
+					 0, GENMASK_ULL(63, 0));
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.bgcolor_property = prop;
+
 	return 0;
 }
 
diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 88bdfec3bd88..9e2538dd7b9a 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -58,4 +58,5 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
 			      struct drm_atomic_state *state);
 int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 					 unsigned int supported_modes);
+void drm_crtc_add_bgcolor_property(struct drm_crtc *crtc);
 #endif
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 13eeba2a750a..12601eb63c45 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -288,6 +288,18 @@ struct drm_crtc_state {
 	 */
 	struct drm_property_blob *gamma_lut;
 
+	/**
+	 * @bgcolor:
+	 *
+	 * RGB value representing the pipe's background color.  The background
+	 * color (aka "canvas color") of a pipe is the color that will be used
+	 * for pixels not covered by a plane, or covered by transparent pixels
+	 * of a plane.  The value here should be built via drm_argb();
+	 * individual color components can be extracted with desired precision
+	 * via the DRM_ARGB_*() macros.
+	 */
+	u64 bgcolor;
+
 	/**
 	 * @target_vblank:
 	 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 1ddf7783fdf7..76c491d10d8d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -867,6 +867,11 @@ struct drm_mode_config {
 	 */
 	struct drm_property *hdcp_content_type_property;
 
+	/**
+	 * @bgcolor_property: RGB background color for CRTC.
+	 */
+	struct drm_property *bgcolor_property;
+
 	/* dumb ioctl parameters */
 	uint32_t preferred_depth, prefer_shadow;
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 98bf130feda5..035f06c6750e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1154,6 +1154,34 @@ struct drm_mode_rect {
 	__s32 y2;
 };
 
+/*
+ * Put ARGB values into a standard 64-bit representation that can be used
+ * for ioctl parameters, inter-driver commmunication, etc.  If the component
+ * values being provided contain less than 16 bits of precision, they'll
+ * be shifted into the most significant bits.
+ */
+static inline __u64
+drm_argb(__u8 bpc, __u16 alpha, __u16 red, __u16 green, __u16 blue)
+{
+	int msb_shift = 16 - bpc;
+
+	return (__u64)alpha << msb_shift << 48 |
+	       (__u64)red   << msb_shift << 32 |
+	       (__u64)green << msb_shift << 16 |
+	       (__u64)blue  << msb_shift;
+}
+
+/*
+ * Extract the specified number of bits of a specific color component from a
+ * standard 64-bit ARGB value.
+ */
+#define DRM_ARGB_COMP(c, shift, numbits) \
+	((__u16)(((c) & 0xFFFFull << (shift)) >> ((shift) + 16 - (numbits))))
+#define DRM_ARGB_BLUE(c, numbits)  DRM_ARGB_COMP(c, 0, numbits)
+#define DRM_ARGB_GREEN(c, numbits) DRM_ARGB_COMP(c, 16, numbits)
+#define DRM_ARGB_RED(c, numbits)   DRM_ARGB_COMP(c, 32, numbits)
+#define DRM_ARGB_ALPHA(c, numbits) DRM_ARGB_COMP(c, 48, numbits)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.17.1

Re: [PATCH 1/2] drm: add crtc background color property

[Pekka Paalanen]

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

On Wed, 7 Jul 2021 08:48:47 +0000
Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:

> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes).  Compositors that want a UI with
> a solid color background can potentially save memory bandwidth by
> setting the CRTC background property and using smaller planes to display
> the rest of the content.
> 
> To avoid confusion between different ways of encoding RGB data, we
> define a standard 64-bit format that should be used for this property's
> value.  Helper functions and macros are provided to generate and dissect
> values in this standard format with varying component precision values.
> 
> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
>  drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
>  drivers/gpu/drm/drm_mode_config.c         |  6 ++++
>  include/drm/drm_blend.h                   |  1 +
>  include/drm/drm_crtc.h                    | 12 ++++++++
>  include/drm/drm_mode_config.h             |  5 ++++
>  include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
>  8 files changed, 89 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index ddcf5c2c8e6a..1b95a4ecdb2b 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -72,6 +72,7 @@ __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
>  				     struct drm_crtc *crtc)
>  {
>  	crtc_state->crtc = crtc;
> +	crtc_state->bgcolor = drm_argb(16, 0xffff, 0, 0, 0);
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
>  
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index 438e9585b225..fea68f8f17f8 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -483,6 +483,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>  		set_out_fence_for_crtc(state->state, crtc, fence_ptr);
>  	} else if (property == crtc->scaling_filter_property) {
>  		state->scaling_filter = val;
> +	} else if (property == config->bgcolor_property) {
> +		state->bgcolor = val;
>  	} else if (crtc->funcs->atomic_set_property) {
>  		return crtc->funcs->atomic_set_property(crtc, state, property, val);
>  	} else {
> @@ -520,6 +522,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>  		*val = 0;
>  	else if (property == crtc->scaling_filter_property)
>  		*val = state->scaling_filter;
> +	else if (property == config->bgcolor_property)
> +		*val = state->bgcolor;
>  	else if (crtc->funcs->atomic_get_property)
>  		return crtc->funcs->atomic_get_property(crtc, state, property, val);
>  	else
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index ec37cbfabb50..6692d6a6db22 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -186,8 +186,7 @@
>   *		 assumed to be 1.0
>   *
>   * Note that all the property extensions described here apply either to the
> - * plane or the CRTC (e.g. for the background color, which currently is not
> - * exposed and assumed to be black).
> + * plane or the CRTC.
>   *
>   * SCALING_FILTER:
>   *     Indicates scaling filter to be used for plane scaler
> @@ -201,6 +200,21 @@
>   *
>   * Drivers can set up this property for a plane by calling
>   * drm_plane_create_scaling_filter_property
> + *

Hi,

I assume the below block is the UAPI documentation of this new property
and that it would appear with the other UAPI docs.

> + * BACKGROUND_COLOR:
> + *	Defines the ARGB color of a full-screen layer that exists below all
> + *	planes.  This color will be used for pixels not covered by any plane
> + *	and may also be blended with plane contents as allowed by a plane's
> + *	alpha values.  The background color defaults to black, and is assumed
> + *	to be black for drivers that do not expose this property.

All good up to here.

>  Although
> + *	background color isn't a plane, it is assumed that the color provided
> + *	here undergoes the same pipe-level degamma/CSC/gamma transformations
> + *	that planes undergo.

This sounds to me like it refers to the per-plane degamma/csc/gamma
which are new properties in development. I believe you do not mean
that, but you mean the CRTC degamma/csc/gamma and everything else which
apply *after* the blending of planes. So the wording here would need
clarification.

>  Note that the color value provided here includes
> + *	an alpha channel...non-opaque background color values are allowed,
> + *	but are generally only honored in special cases (e.g., when a memory
> + *	writeback connector is in use).

This could be read as: if you use a non-opaque color value, it will
usually be completely ignored (and the background will be e.g. black
instead). Is that your intention?

I think a more useful definition would be that the alpha is used in
blending as always, but because we do not yet have physically
transparent monitors, the final alpha value may not reach the video
sink or the video sink may ignore it.

> + *
> + *	This property is setup with drm_crtc_add_bgcolor_property().

You forgot to document the value format of this property. The ARGB color
format needs to be defined at least to the same detail as all pixel
formats in drm_fourcc.h are. If there is a suitable DRM_FORMAT_*
definition already, simply saying the color is in that format would be
enough.

Another thing to document is whether this color value is alpha
pre-multiplied or not. Planes can have the property "pixel blend mode",
but because the background color is not on a plane, that property
cannot apply here.

The difference it makes is that if background color is both non-opaque
and pre-multiplied, then the question arises what pixel values will
actually be transmitted to video sink for the background. Will the
alpha pre-multiplication be undone?

Btw. note that "pixel blend mode" property does not document the use of
background alpha at all. So if the background color can have non-opaque
alpha, then you need to document the behavior in "pixel blend mode". It
also does not document what alpha value will result from blending, for
blending the next plane.

The question about full vs. limited range seems unnecessary to me, as
the background color will be used as-is in the blending stage, so
userspace can just program the correct value that fits the pipeline it
is setting up.

One more question is, as HDR exists, could we need background colors
with component values greater than 1.0?

Scanout of FP16 formats exists.

>   */


Thanks,
pq

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

Re: [PATCH 1/2] drm: add crtc background color property

[Raphael Gallais-Pou]

On 7/9/21 10:04 AM, Pekka Paalanen wrote:
> On Wed, 7 Jul 2021 08:48:47 +0000
> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
>
>> Some display controllers can be programmed to present non-black colors
>> for pixels not covered by any plane (or pixels covered by the
>> transparent regions of higher planes).  Compositors that want a UI with
>> a solid color background can potentially save memory bandwidth by
>> setting the CRTC background property and using smaller planes to display
>> the rest of the content.
>>
>> To avoid confusion between different ways of encoding RGB data, we
>> define a standard 64-bit format that should be used for this property's
>> value.  Helper functions and macros are provided to generate and dissect
>> values in this standard format with varying component precision values.
>>
>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>> ---
>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
>>   include/drm/drm_blend.h                   |  1 +
>>   include/drm/drm_crtc.h                    | 12 ++++++++
>>   include/drm/drm_mode_config.h             |  5 ++++
>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
>>   8 files changed, 89 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
>> index ddcf5c2c8e6a..1b95a4ecdb2b 100644
>> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
>> @@ -72,6 +72,7 @@ __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
>>   				     struct drm_crtc *crtc)
>>   {
>>   	crtc_state->crtc = crtc;
>> +	crtc_state->bgcolor = drm_argb(16, 0xffff, 0, 0, 0);
>>   }
>>   EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
>>   
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 438e9585b225..fea68f8f17f8 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -483,6 +483,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>>   		set_out_fence_for_crtc(state->state, crtc, fence_ptr);
>>   	} else if (property == crtc->scaling_filter_property) {
>>   		state->scaling_filter = val;
>> +	} else if (property == config->bgcolor_property) {
>> +		state->bgcolor = val;
>>   	} else if (crtc->funcs->atomic_set_property) {
>>   		return crtc->funcs->atomic_set_property(crtc, state, property, val);
>>   	} else {
>> @@ -520,6 +522,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>>   		*val = 0;
>>   	else if (property == crtc->scaling_filter_property)
>>   		*val = state->scaling_filter;
>> +	else if (property == config->bgcolor_property)
>> +		*val = state->bgcolor;
>>   	else if (crtc->funcs->atomic_get_property)
>>   		return crtc->funcs->atomic_get_property(crtc, state, property, val);
>>   	else
>> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
>> index ec37cbfabb50..6692d6a6db22 100644
>> --- a/drivers/gpu/drm/drm_blend.c
>> +++ b/drivers/gpu/drm/drm_blend.c
>> @@ -186,8 +186,7 @@
>>    *		 assumed to be 1.0
>>    *
>>    * Note that all the property extensions described here apply either to the
>> - * plane or the CRTC (e.g. for the background color, which currently is not
>> - * exposed and assumed to be black).
>> + * plane or the CRTC.
>>    *
>>    * SCALING_FILTER:
>>    *     Indicates scaling filter to be used for plane scaler
>> @@ -201,6 +200,21 @@
>>    *
>>    * Drivers can set up this property for a plane by calling
>>    * drm_plane_create_scaling_filter_property
>> + *
> Hi,


Hi Pekka,


Many thanks for your feedback, your comments are taken into account for 
a v2.


>
> I assume the below block is the UAPI documentation of this new property
> and that it would appear with the other UAPI docs.
>
>> + * BACKGROUND_COLOR:
>> + *	Defines the ARGB color of a full-screen layer that exists below all
>> + *	planes.  This color will be used for pixels not covered by any plane
>> + *	and may also be blended with plane contents as allowed by a plane's
>> + *	alpha values.  The background color defaults to black, and is assumed
>> + *	to be black for drivers that do not expose this property.
> All good up to here.
>
>>   Although
>> + *	background color isn't a plane, it is assumed that the color provided
>> + *	here undergoes the same pipe-level degamma/CSC/gamma transformations
>> + *	that planes undergo.
> This sounds to me like it refers to the per-plane degamma/csc/gamma
> which are new properties in development. I believe you do not mean
> that, but you mean the CRTC degamma/csc/gamma and everything else which
> apply *after* the blending of planes. So the wording here would need
> clarification.


Yes, I was not sure about this, but it is effectively the general CRTC 
color correction which is applicable to the background color.

>
>>   Note that the color value provided here includes
>> + *	an alpha channel...non-opaque background color values are allowed,
>> + *	but are generally only honored in special cases (e.g., when a memory
>> + *	writeback connector is in use).
> This could be read as: if you use a non-opaque color value, it will
> usually be completely ignored (and the background will be e.g. black
> instead). Is that your intention?
>
> I think a more useful definition would be that the alpha is used in
> blending as always, but because we do not yet have physically
> transparent monitors, the final alpha value may not reach the video
> sink or the video sink may ignore it.

In our case, the hardware does not support alpha channel (as you can see 
the DRM_ARGB_TO_LTDC_RGB24 macro in the second patch).

For chip vendors who does support this feature, the video sink would get 
this transparency parameter. In the case where it is not, alpha channel 
would be ignored.


>> + *
>> + *	This property is setup with drm_crtc_add_bgcolor_property().
> You forgot to document the value format of this property. The ARGB color
> format needs to be defined at least to the same detail as all pixel
> formats in drm_fourcc.h are. If there is a suitable DRM_FORMAT_*
> definition already, simply saying the color is in that format would be
> enough.


Will do ! :)

I was thinking about the FourCC AR4H format. Have you something else in 
mind ?

>
> Another thing to document is whether this color value is alpha
> pre-multiplied or not. Planes can have the property "pixel blend mode",
> but because the background color is not on a plane, that property
> cannot apply here.
>
> The difference it makes is that if background color is both non-opaque
> and pre-multiplied, then the question arises what pixel values will
> actually be transmitted to video sink for the background. Will the
> alpha pre-multiplication be undone?
>
> Btw. note that "pixel blend mode" property does not document the use of
> background alpha at all. So if the background color can have non-opaque
> alpha, then you need to document the behavior in "pixel blend mode". It
> also does not document what alpha value will result from blending, for
> blending the next plane.

Those are questions that did not crossed my mind at all.

What would you suggest ? Instinctively I would say that in the case 
where there is a non-opaque background color,

alpha pre-multiplication would not be taken into account, although it is 
maybe not the best solution.

As I am not quite sure, I will lookup for this.


>
> The question about full vs. limited range seems unnecessary to me, as
> the background color will be used as-is in the blending stage, so
> userspace can just program the correct value that fits the pipeline it
> is setting up.
>
> One more question is, as HDR exists, could we need background colors
> with component values greater than 1.0?

AR4H color format should cover that case, isn't it ?



Regards,

Raphaël

>
> Scanout of FP16 formats exists.
>
>>    */
>
> Thanks,
> pq

Re: [PATCH 1/2] drm: add crtc background color property

[Pekka Paalanen]

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

On Fri, 9 Jul 2021 18:23:26 +0200
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:

> On 7/9/21 10:04 AM, Pekka Paalanen wrote:
> > On Wed, 7 Jul 2021 08:48:47 +0000
> > Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
> >  
> >> Some display controllers can be programmed to present non-black colors
> >> for pixels not covered by any plane (or pixels covered by the
> >> transparent regions of higher planes).  Compositors that want a UI with
> >> a solid color background can potentially save memory bandwidth by
> >> setting the CRTC background property and using smaller planes to display
> >> the rest of the content.
> >>
> >> To avoid confusion between different ways of encoding RGB data, we
> >> define a standard 64-bit format that should be used for this property's
> >> value.  Helper functions and macros are provided to generate and dissect
> >> values in this standard format with varying component precision values.
> >>
> >> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> >> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >> ---
> >>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
> >>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
> >>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
> >>   include/drm/drm_blend.h                   |  1 +
> >>   include/drm/drm_crtc.h                    | 12 ++++++++
> >>   include/drm/drm_mode_config.h             |  5 ++++
> >>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
> >>   8 files changed, 89 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> index ddcf5c2c8e6a..1b95a4ecdb2b 100644
> >> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> @@ -72,6 +72,7 @@ __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
> >>   				     struct drm_crtc *crtc)
> >>   {
> >>   	crtc_state->crtc = crtc;
> >> +	crtc_state->bgcolor = drm_argb(16, 0xffff, 0, 0, 0);
> >>   }
> >>   EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
> >>   
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 438e9585b225..fea68f8f17f8 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -483,6 +483,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> >>   		set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> >>   	} else if (property == crtc->scaling_filter_property) {
> >>   		state->scaling_filter = val;
> >> +	} else if (property == config->bgcolor_property) {
> >> +		state->bgcolor = val;
> >>   	} else if (crtc->funcs->atomic_set_property) {
> >>   		return crtc->funcs->atomic_set_property(crtc, state, property, val);
> >>   	} else {
> >> @@ -520,6 +522,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> >>   		*val = 0;
> >>   	else if (property == crtc->scaling_filter_property)
> >>   		*val = state->scaling_filter;
> >> +	else if (property == config->bgcolor_property)
> >> +		*val = state->bgcolor;
> >>   	else if (crtc->funcs->atomic_get_property)
> >>   		return crtc->funcs->atomic_get_property(crtc, state, property, val);
> >>   	else
> >> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >> index ec37cbfabb50..6692d6a6db22 100644
> >> --- a/drivers/gpu/drm/drm_blend.c
> >> +++ b/drivers/gpu/drm/drm_blend.c
> >> @@ -186,8 +186,7 @@
> >>    *		 assumed to be 1.0
> >>    *
> >>    * Note that all the property extensions described here apply either to the
> >> - * plane or the CRTC (e.g. for the background color, which currently is not
> >> - * exposed and assumed to be black).
> >> + * plane or the CRTC.
> >>    *
> >>    * SCALING_FILTER:
> >>    *     Indicates scaling filter to be used for plane scaler
> >> @@ -201,6 +200,21 @@
> >>    *
> >>    * Drivers can set up this property for a plane by calling
> >>    * drm_plane_create_scaling_filter_property
> >> + *  
> > Hi,  
> 
> 
> Hi Pekka,
> 
> 
> Many thanks for your feedback, your comments are taken into account for 
> a v2.
> 
> 
> >
> > I assume the below block is the UAPI documentation of this new property
> > and that it would appear with the other UAPI docs.
> >  
> >> + * BACKGROUND_COLOR:
> >> + *	Defines the ARGB color of a full-screen layer that exists below all
> >> + *	planes.  This color will be used for pixels not covered by any plane
> >> + *	and may also be blended with plane contents as allowed by a plane's
> >> + *	alpha values.  The background color defaults to black, and is assumed
> >> + *	to be black for drivers that do not expose this property.  
> > All good up to here.
> >  
> >>   Although
> >> + *	background color isn't a plane, it is assumed that the color provided
> >> + *	here undergoes the same pipe-level degamma/CSC/gamma transformations
> >> + *	that planes undergo.  
> > This sounds to me like it refers to the per-plane degamma/csc/gamma
> > which are new properties in development. I believe you do not mean
> > that, but you mean the CRTC degamma/csc/gamma and everything else which
> > apply *after* the blending of planes. So the wording here would need
> > clarification.  
> 
> 
> Yes, I was not sure about this, but it is effectively the general CRTC 
> color correction which is applicable to the background color.
> 
> >  
> >>   Note that the color value provided here includes
> >> + *	an alpha channel...non-opaque background color values are allowed,
> >> + *	but are generally only honored in special cases (e.g., when a memory
> >> + *	writeback connector is in use).  
> > This could be read as: if you use a non-opaque color value, it will
> > usually be completely ignored (and the background will be e.g. black
> > instead). Is that your intention?
> >
> > I think a more useful definition would be that the alpha is used in
> > blending as always, but because we do not yet have physically
> > transparent monitors, the final alpha value may not reach the video
> > sink or the video sink may ignore it.  
> 
> In our case, the hardware does not support alpha channel (as you can see 
> the DRM_ARGB_TO_LTDC_RGB24 macro in the second patch).
> 
> For chip vendors who does support this feature, the video sink would get 
> this transparency parameter. In the case where it is not, alpha channel 
> would be ignored.
> 
> 
> >> + *
> >> + *	This property is setup with drm_crtc_add_bgcolor_property().  
> > You forgot to document the value format of this property. The ARGB color
> > format needs to be defined at least to the same detail as all pixel
> > formats in drm_fourcc.h are. If there is a suitable DRM_FORMAT_*
> > definition already, simply saying the color is in that format would be
> > enough.  
> 
> 
> Will do ! :)
> 
> I was thinking about the FourCC AR4H format. Have you something else in 
> mind ?

Hi,

if you mean DRM_FORMAT_ARGB16161616F then that is not what you are
using right now. That is a floating-point format using 16-bit floats
(half float). It has only 10 bits precision IIRC.

As C compilers do not(?) have built-in support for halfs, using this
format would be inconvenient for userspace (and the kernel?). Since
it's just for one pixel value, I think using a format that is
convenient to craft would be good.


> > Another thing to document is whether this color value is alpha
> > pre-multiplied or not. Planes can have the property "pixel blend mode",
> > but because the background color is not on a plane, that property
> > cannot apply here.
> >
> > The difference it makes is that if background color is both non-opaque
> > and pre-multiplied, then the question arises what pixel values will
> > actually be transmitted to video sink for the background. Will the
> > alpha pre-multiplication be undone?
> >
> > Btw. note that "pixel blend mode" property does not document the use of
> > background alpha at all. So if the background color can have non-opaque
> > alpha, then you need to document the behavior in "pixel blend mode". It
> > also does not document what alpha value will result from blending, for
> > blending the next plane.  
> 
> Those are questions that did not crossed my mind at all.
> 
> What would you suggest ? Instinctively I would say that in the case 
> where there is a non-opaque background color,
> 
> alpha pre-multiplication would not be taken into account, although it is 
> maybe not the best solution.
> 
> As I am not quite sure, I will lookup for this.

Right now, I would suggest to just dodge the whole question: define the
background color to be opaque. Either drop the alpha channel, or
specify that alpha must be 1.0 for now (fail ioctl if not).

Let the people who actually need alpha in the background color figure
out all the details. They would know what they want, while we don't. We
also can't come up with a proper userspace for non-opaque alpha to
prove that the design works.

If you specify that alpha channel exists but must be 1.0, then someone
else could later add another property that defines how the alpha would
be used if it was less than 1.0. The existence of that other property
would then tell userspace that non-1.0 alpha is supported and also
define what it does. Userspace that does not understand that will just
keep using alpha 1.0, meaning it doesn't matter what value the other
new property has. So this seems quite future-proof to me.

> > The question about full vs. limited range seems unnecessary to me, as
> > the background color will be used as-is in the blending stage, so
> > userspace can just program the correct value that fits the pipeline it
> > is setting up.
> >
> > One more question is, as HDR exists, could we need background colors
> > with component values greater than 1.0?  
> 
> AR4H color format should cover that case, isn't it ?

Yes, but with the inconvenience I mentioned.

This is a genuine question though, would anyone actually need
background color values > 1.0. I don't know of any case yet where it
would be required. It would imply that plane blending happens in a
color space where >1.0 values are meaningful. I'm not even sure if any
hardware supporting that exists.

Maybe it would be best to assume that only [0.0, 1.0] pixel value range
is useful, and mention in the commit message that if someone really
needs values outside of that, they should create another background
color property. Then, you can pick a simple unsigned integer pixel
format, too. (I didn't see any 16 bit-per-channel formats like that in
drm_fourcc.h though.)


Thanks,
pq

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

Re: [PATCH 1/2] drm: add crtc background color property

[Harry Wentland]

On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
> On Fri, 9 Jul 2021 18:23:26 +0200
> Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:
> 
>> On 7/9/21 10:04 AM, Pekka Paalanen wrote:
>>> On Wed, 7 Jul 2021 08:48:47 +0000
>>> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
>>>  
>>>> Some display controllers can be programmed to present non-black colors
>>>> for pixels not covered by any plane (or pixels covered by the
>>>> transparent regions of higher planes).  Compositors that want a UI with
>>>> a solid color background can potentially save memory bandwidth by
>>>> setting the CRTC background property and using smaller planes to display
>>>> the rest of the content.
>>>>
>>>> To avoid confusion between different ways of encoding RGB data, we
>>>> define a standard 64-bit format that should be used for this property's
>>>> value.  Helper functions and macros are provided to generate and dissect
>>>> values in this standard format with varying component precision values.
>>>>
>>>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
>>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>>> ---
>>>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>>>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
>>>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
>>>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
>>>>   include/drm/drm_blend.h                   |  1 +
>>>>   include/drm/drm_crtc.h                    | 12 ++++++++
>>>>   include/drm/drm_mode_config.h             |  5 ++++
>>>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
>>>>   8 files changed, 89 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
>>>> index ddcf5c2c8e6a..1b95a4ecdb2b 100644
>>>> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
>>>> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
>>>> @@ -72,6 +72,7 @@ __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
>>>>   				     struct drm_crtc *crtc)
>>>>   {
>>>>   	crtc_state->crtc = crtc;
>>>> +	crtc_state->bgcolor = drm_argb(16, 0xffff, 0, 0, 0);
>>>>   }
>>>>   EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
>>>>   
>>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>>>> index 438e9585b225..fea68f8f17f8 100644
>>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>>>> @@ -483,6 +483,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>>>>   		set_out_fence_for_crtc(state->state, crtc, fence_ptr);
>>>>   	} else if (property == crtc->scaling_filter_property) {
>>>>   		state->scaling_filter = val;
>>>> +	} else if (property == config->bgcolor_property) {
>>>> +		state->bgcolor = val;
>>>>   	} else if (crtc->funcs->atomic_set_property) {
>>>>   		return crtc->funcs->atomic_set_property(crtc, state, property, val);
>>>>   	} else {
>>>> @@ -520,6 +522,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>>>>   		*val = 0;
>>>>   	else if (property == crtc->scaling_filter_property)
>>>>   		*val = state->scaling_filter;
>>>> +	else if (property == config->bgcolor_property)
>>>> +		*val = state->bgcolor;
>>>>   	else if (crtc->funcs->atomic_get_property)
>>>>   		return crtc->funcs->atomic_get_property(crtc, state, property, val);
>>>>   	else
>>>> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
>>>> index ec37cbfabb50..6692d6a6db22 100644
>>>> --- a/drivers/gpu/drm/drm_blend.c
>>>> +++ b/drivers/gpu/drm/drm_blend.c
>>>> @@ -186,8 +186,7 @@
>>>>    *		 assumed to be 1.0
>>>>    *
>>>>    * Note that all the property extensions described here apply either to the
>>>> - * plane or the CRTC (e.g. for the background color, which currently is not
>>>> - * exposed and assumed to be black).
>>>> + * plane or the CRTC.
>>>>    *
>>>>    * SCALING_FILTER:
>>>>    *     Indicates scaling filter to be used for plane scaler
>>>> @@ -201,6 +200,21 @@
>>>>    *
>>>>    * Drivers can set up this property for a plane by calling
>>>>    * drm_plane_create_scaling_filter_property
>>>> + *  
>>> Hi,  
>>
>>
>> Hi Pekka,
>>
>>
>> Many thanks for your feedback, your comments are taken into account for 
>> a v2.
>>
>>
>>>
>>> I assume the below block is the UAPI documentation of this new property
>>> and that it would appear with the other UAPI docs.
>>>  
>>>> + * BACKGROUND_COLOR:
>>>> + *	Defines the ARGB color of a full-screen layer that exists below all
>>>> + *	planes.  This color will be used for pixels not covered by any plane
>>>> + *	and may also be blended with plane contents as allowed by a plane's
>>>> + *	alpha values.  The background color defaults to black, and is assumed
>>>> + *	to be black for drivers that do not expose this property.  
>>> All good up to here.
>>>  
>>>>   Although
>>>> + *	background color isn't a plane, it is assumed that the color provided
>>>> + *	here undergoes the same pipe-level degamma/CSC/gamma transformations
>>>> + *	that planes undergo.  
>>> This sounds to me like it refers to the per-plane degamma/csc/gamma
>>> which are new properties in development. I believe you do not mean
>>> that, but you mean the CRTC degamma/csc/gamma and everything else which
>>> apply *after* the blending of planes. So the wording here would need
>>> clarification.  
>>
>>
>> Yes, I was not sure about this, but it is effectively the general CRTC 
>> color correction which is applicable to the background color.
>>
>>>  
>>>>   Note that the color value provided here includes
>>>> + *	an alpha channel...non-opaque background color values are allowed,
>>>> + *	but are generally only honored in special cases (e.g., when a memory
>>>> + *	writeback connector is in use).  
>>> This could be read as: if you use a non-opaque color value, it will
>>> usually be completely ignored (and the background will be e.g. black
>>> instead). Is that your intention?
>>>
>>> I think a more useful definition would be that the alpha is used in
>>> blending as always, but because we do not yet have physically
>>> transparent monitors, the final alpha value may not reach the video
>>> sink or the video sink may ignore it.  
>>
>> In our case, the hardware does not support alpha channel (as you can see 
>> the DRM_ARGB_TO_LTDC_RGB24 macro in the second patch).
>>
>> For chip vendors who does support this feature, the video sink would get 
>> this transparency parameter. In the case where it is not, alpha channel 
>> would be ignored.
>>
>>
>>>> + *
>>>> + *	This property is setup with drm_crtc_add_bgcolor_property().  
>>> You forgot to document the value format of this property. The ARGB color
>>> format needs to be defined at least to the same detail as all pixel
>>> formats in drm_fourcc.h are. If there is a suitable DRM_FORMAT_*
>>> definition already, simply saying the color is in that format would be
>>> enough.  
>>
>>
>> Will do ! :)
>>
>> I was thinking about the FourCC AR4H format. Have you something else in 
>> mind ?
> 
> Hi,
> 
> if you mean DRM_FORMAT_ARGB16161616F then that is not what you are
> using right now. That is a floating-point format using 16-bit floats
> (half float). It has only 10 bits precision IIRC.
> 
> As C compilers do not(?) have built-in support for halfs, using this
> format would be inconvenient for userspace (and the kernel?). Since
> it's just for one pixel value, I think using a format that is
> convenient to craft would be good.
> 
> 
>>> Another thing to document is whether this color value is alpha
>>> pre-multiplied or not. Planes can have the property "pixel blend mode",
>>> but because the background color is not on a plane, that property
>>> cannot apply here.
>>>
>>> The difference it makes is that if background color is both non-opaque
>>> and pre-multiplied, then the question arises what pixel values will
>>> actually be transmitted to video sink for the background. Will the
>>> alpha pre-multiplication be undone?
>>>
>>> Btw. note that "pixel blend mode" property does not document the use of
>>> background alpha at all. So if the background color can have non-opaque
>>> alpha, then you need to document the behavior in "pixel blend mode". It
>>> also does not document what alpha value will result from blending, for
>>> blending the next plane.  
>>
>> Those are questions that did not crossed my mind at all.
>>
>> What would you suggest ? Instinctively I would say that in the case 
>> where there is a non-opaque background color,
>>
>> alpha pre-multiplication would not be taken into account, although it is 
>> maybe not the best solution.
>>
>> As I am not quite sure, I will lookup for this.
> 
> Right now, I would suggest to just dodge the whole question: define the
> background color to be opaque. Either drop the alpha channel, or
> specify that alpha must be 1.0 for now (fail ioctl if not).
> 
> Let the people who actually need alpha in the background color figure
> out all the details. They would know what they want, while we don't. We
> also can't come up with a proper userspace for non-opaque alpha to
> prove that the design works.
> 
> If you specify that alpha channel exists but must be 1.0, then someone
> else could later add another property that defines how the alpha would
> be used if it was less than 1.0. The existence of that other property
> would then tell userspace that non-1.0 alpha is supported and also
> define what it does. Userspace that does not understand that will just
> keep using alpha 1.0, meaning it doesn't matter what value the other
> new property has. So this seems quite future-proof to me.
> 
>>> The question about full vs. limited range seems unnecessary to me, as
>>> the background color will be used as-is in the blending stage, so
>>> userspace can just program the correct value that fits the pipeline it
>>> is setting up.
>>>
>>> One more question is, as HDR exists, could we need background colors
>>> with component values greater than 1.0?  
>>
>> AR4H color format should cover that case, isn't it ?
> 
> Yes, but with the inconvenience I mentioned.
> 
> This is a genuine question though, would anyone actually need
> background color values > 1.0. I don't know of any case yet where it
> would be required. It would imply that plane blending happens in a
> color space where >1.0 values are meaningful. I'm not even sure if any
> hardware supporting that exists.
> 
> Maybe it would be best to assume that only [0.0, 1.0] pixel value range
> is useful, and mention in the commit message that if someone really
> needs values outside of that, they should create another background
> color property. Then, you can pick a simple unsigned integer pixel
> format, too. (I didn't see any 16 bit-per-channel formats like that in
> drm_fourcc.h though.)
> 

I don't think we should artificially limit this to [0.0, 1.0]. As you
mentioned above when talking about full vs limited, the userspace
understands what's the correct value that fits the pipeline. If that
pipeline is FP16 with > 1.0 values then it would make sense that the
background color can be > 1.0.

Harry

> 
> Thanks,
> pq
> 

Re: [PATCH 1/2] drm: add crtc background color property

[Pekka Paalanen]

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

On Mon, 12 Jul 2021 12:15:59 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
> > On Fri, 9 Jul 2021 18:23:26 +0200
> > Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:
> >   
> >> On 7/9/21 10:04 AM, Pekka Paalanen wrote:  
> >>> On Wed, 7 Jul 2021 08:48:47 +0000
> >>> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
> >>>    
> >>>> Some display controllers can be programmed to present non-black colors
> >>>> for pixels not covered by any plane (or pixels covered by the
> >>>> transparent regions of higher planes).  Compositors that want a UI with
> >>>> a solid color background can potentially save memory bandwidth by
> >>>> setting the CRTC background property and using smaller planes to display
> >>>> the rest of the content.
> >>>>
> >>>> To avoid confusion between different ways of encoding RGB data, we
> >>>> define a standard 64-bit format that should be used for this property's
> >>>> value.  Helper functions and macros are provided to generate and dissect
> >>>> values in this standard format with varying component precision values.
> >>>>
> >>>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> >>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >>>> ---
> >>>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >>>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
> >>>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
> >>>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
> >>>>   include/drm/drm_blend.h                   |  1 +
> >>>>   include/drm/drm_crtc.h                    | 12 ++++++++
> >>>>   include/drm/drm_mode_config.h             |  5 ++++
> >>>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
> >>>>   8 files changed, 89 insertions(+), 2 deletions(-)

...

> >>> The question about full vs. limited range seems unnecessary to me, as
> >>> the background color will be used as-is in the blending stage, so
> >>> userspace can just program the correct value that fits the pipeline it
> >>> is setting up.
> >>>
> >>> One more question is, as HDR exists, could we need background colors
> >>> with component values greater than 1.0?    
> >>
> >> AR4H color format should cover that case, isn't it ?  
> > 
> > Yes, but with the inconvenience I mentioned.
> > 
> > This is a genuine question though, would anyone actually need
> > background color values > 1.0. I don't know of any case yet where it
> > would be required. It would imply that plane blending happens in a
> > color space where >1.0 values are meaningful. I'm not even sure if any
> > hardware supporting that exists.
> > 
> > Maybe it would be best to assume that only [0.0, 1.0] pixel value range
> > is useful, and mention in the commit message that if someone really
> > needs values outside of that, they should create another background
> > color property. Then, you can pick a simple unsigned integer pixel
> > format, too. (I didn't see any 16 bit-per-channel formats like that in
> > drm_fourcc.h though.)
> >   
> 
> I don't think we should artificially limit this to [0.0, 1.0]. As you
> mentioned above when talking about full vs limited, the userspace
> understands what's the correct value that fits the pipeline. If that
> pipeline is FP16 with > 1.0 values then it would make sense that the
> background color can be > 1.0.

Ok. The standard FP32 format then for ease of use and guaranteed enough
range and precision for far into the future?

Or do you want to keep it in 64 bits total, so the UABI can pack
everything into a u64 instead of needing to create a blob?

I don't mind as long as it's clearly documented what it is and how it
works, and it carries enough precision.

But FP16 with its 10 bits of precision might be too little for integer
12-16 bpc pipelines and sinks?

If the values can go beyond [0.0, 1.0] range, then does the blending
hardware and the degamma/ctm/gamma coming afterwards cope with them, or
do they get clamped anyway?


Thanks,
pq

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

Re: [PATCH 1/2] drm: add crtc background color property

[Harry Wentland]

On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:
> On Mon, 12 Jul 2021 12:15:59 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
>>> On Fri, 9 Jul 2021 18:23:26 +0200
>>> Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:
>>>   
>>>> On 7/9/21 10:04 AM, Pekka Paalanen wrote:  
>>>>> On Wed, 7 Jul 2021 08:48:47 +0000
>>>>> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
>>>>>    
>>>>>> Some display controllers can be programmed to present non-black colors
>>>>>> for pixels not covered by any plane (or pixels covered by the
>>>>>> transparent regions of higher planes).  Compositors that want a UI with
>>>>>> a solid color background can potentially save memory bandwidth by
>>>>>> setting the CRTC background property and using smaller planes to display
>>>>>> the rest of the content.
>>>>>>
>>>>>> To avoid confusion between different ways of encoding RGB data, we
>>>>>> define a standard 64-bit format that should be used for this property's
>>>>>> value.  Helper functions and macros are provided to generate and dissect
>>>>>> values in this standard format with varying component precision values.
>>>>>>
>>>>>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
>>>>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>>>>> ---
>>>>>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>>>>>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
>>>>>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
>>>>>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
>>>>>>   include/drm/drm_blend.h                   |  1 +
>>>>>>   include/drm/drm_crtc.h                    | 12 ++++++++
>>>>>>   include/drm/drm_mode_config.h             |  5 ++++
>>>>>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
>>>>>>   8 files changed, 89 insertions(+), 2 deletions(-)
> 
> ...
> 
>>>>> The question about full vs. limited range seems unnecessary to me, as
>>>>> the background color will be used as-is in the blending stage, so
>>>>> userspace can just program the correct value that fits the pipeline it
>>>>> is setting up.
>>>>>
>>>>> One more question is, as HDR exists, could we need background colors
>>>>> with component values greater than 1.0?    
>>>>
>>>> AR4H color format should cover that case, isn't it ?  
>>>
>>> Yes, but with the inconvenience I mentioned.
>>>
>>> This is a genuine question though, would anyone actually need
>>> background color values > 1.0. I don't know of any case yet where it
>>> would be required. It would imply that plane blending happens in a
>>> color space where >1.0 values are meaningful. I'm not even sure if any
>>> hardware supporting that exists.
>>>
>>> Maybe it would be best to assume that only [0.0, 1.0] pixel value range
>>> is useful, and mention in the commit message that if someone really
>>> needs values outside of that, they should create another background
>>> color property. Then, you can pick a simple unsigned integer pixel
>>> format, too. (I didn't see any 16 bit-per-channel formats like that in
>>> drm_fourcc.h though.)
>>>   
>>
>> I don't think we should artificially limit this to [0.0, 1.0]. As you
>> mentioned above when talking about full vs limited, the userspace
>> understands what's the correct value that fits the pipeline. If that
>> pipeline is FP16 with > 1.0 values then it would make sense that the
>> background color can be > 1.0.
> 
> Ok. The standard FP32 format then for ease of use and guaranteed enough
> range and precision for far into the future?
> 

I don't have a strong preference for FP16 vs FP32. My understanding is
that FP16 is enough to represent linearly encoded data in a way that
looks smooth to humans.

scRGB uses FP16 with linear encoding in a range of [-0.5, 7.4999].

> Or do you want to keep it in 64 bits total, so the UABI can pack
> everything into a u64 instead of needing to create a blob?
> 
> I don't mind as long as it's clearly documented what it is and how it
> works, and it carries enough precision.
> 
> But FP16 with its 10 bits of precision might be too little for integer
> 12-16 bpc pipelines and sinks?
> 
> If the values can go beyond [0.0, 1.0] range, then does the blending
> hardware and the degamma/ctm/gamma coming afterwards cope with them, or
> do they get clamped anyway?
> 

That probably depends on the HW and how it's configured. AMD HW can handle
values above and below [0.0, 1.0].

Harry

> 
> Thanks,
> pq
> 

Re: [PATCH 1/2] drm: add crtc background color property

[Pekka Paalanen]

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

On Tue, 13 Jul 2021 09:54:35 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:
> > On Mon, 12 Jul 2021 12:15:59 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >   
> >> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:  
> >>> On Fri, 9 Jul 2021 18:23:26 +0200
> >>> Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:
> >>>     
> >>>> On 7/9/21 10:04 AM, Pekka Paalanen wrote:    
> >>>>> On Wed, 7 Jul 2021 08:48:47 +0000
> >>>>> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
> >>>>>      
> >>>>>> Some display controllers can be programmed to present non-black colors
> >>>>>> for pixels not covered by any plane (or pixels covered by the
> >>>>>> transparent regions of higher planes).  Compositors that want a UI with
> >>>>>> a solid color background can potentially save memory bandwidth by
> >>>>>> setting the CRTC background property and using smaller planes to display
> >>>>>> the rest of the content.
> >>>>>>
> >>>>>> To avoid confusion between different ways of encoding RGB data, we
> >>>>>> define a standard 64-bit format that should be used for this property's
> >>>>>> value.  Helper functions and macros are provided to generate and dissect
> >>>>>> values in this standard format with varying component precision values.
> >>>>>>
> >>>>>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> >>>>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >>>>>> ---
> >>>>>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >>>>>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
> >>>>>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
> >>>>>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
> >>>>>>   include/drm/drm_blend.h                   |  1 +
> >>>>>>   include/drm/drm_crtc.h                    | 12 ++++++++
> >>>>>>   include/drm/drm_mode_config.h             |  5 ++++
> >>>>>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
> >>>>>>   8 files changed, 89 insertions(+), 2 deletions(-)  
> > 
> > ...
> >   
> >>>>> The question about full vs. limited range seems unnecessary to me, as
> >>>>> the background color will be used as-is in the blending stage, so
> >>>>> userspace can just program the correct value that fits the pipeline it
> >>>>> is setting up.
> >>>>>
> >>>>> One more question is, as HDR exists, could we need background colors
> >>>>> with component values greater than 1.0?      
> >>>>
> >>>> AR4H color format should cover that case, isn't it ?    
> >>>
> >>> Yes, but with the inconvenience I mentioned.
> >>>
> >>> This is a genuine question though, would anyone actually need
> >>> background color values > 1.0. I don't know of any case yet where it
> >>> would be required. It would imply that plane blending happens in a
> >>> color space where >1.0 values are meaningful. I'm not even sure if any
> >>> hardware supporting that exists.
> >>>
> >>> Maybe it would be best to assume that only [0.0, 1.0] pixel value range
> >>> is useful, and mention in the commit message that if someone really
> >>> needs values outside of that, they should create another background
> >>> color property. Then, you can pick a simple unsigned integer pixel
> >>> format, too. (I didn't see any 16 bit-per-channel formats like that in
> >>> drm_fourcc.h though.)
> >>>     
> >>
> >> I don't think we should artificially limit this to [0.0, 1.0]. As you
> >> mentioned above when talking about full vs limited, the userspace
> >> understands what's the correct value that fits the pipeline. If that
> >> pipeline is FP16 with > 1.0 values then it would make sense that the
> >> background color can be > 1.0.  
> > 
> > Ok. The standard FP32 format then for ease of use and guaranteed enough
> > range and precision for far into the future?
> >   
> 
> I don't have a strong preference for FP16 vs FP32. My understanding is
> that FP16 is enough to represent linearly encoded data in a way that
> looks smooth to humans.
> 
> scRGB uses FP16 with linear encoding in a range of [-0.5, 7.4999].
> 
> > Or do you want to keep it in 64 bits total, so the UABI can pack
> > everything into a u64 instead of needing to create a blob?
> > 
> > I don't mind as long as it's clearly documented what it is and how it
> > works, and it carries enough precision.
> > 
> > But FP16 with its 10 bits of precision might be too little for integer
> > 12-16 bpc pipelines and sinks?

The 10 bits worries me still.

If you have a pipeline that works in [0.0, 1.0] range only, then FP16
limits precision to 10 bits (in the upper half of the range?).

> > 
> > If the values can go beyond [0.0, 1.0] range, then does the blending
> > hardware and the degamma/ctm/gamma coming afterwards cope with them, or
> > do they get clamped anyway?
> >   
> 
> That probably depends on the HW and how it's configured. AMD HW can handle
> values above and below [0.0, 1.0].

Right, so how would userspace know what will happen?

Or do we need to specify that while values outside that unit range are
expressable, it is hardware-specific on how they will behave, so
generic userspace should not attempt to use values outside of the unit
range?

I guess this caveat should be documented for everything, not just for
background color? LUT inputs and outputs, CTM input and output ranges,
FB formats...


Thanks,
pq

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

Re: [PATCH 1/2] drm: add crtc background color property

[Harry Wentland]

On 2021-07-14 3:35 a.m., Pekka Paalanen wrote:
> On Tue, 13 Jul 2021 09:54:35 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:
>>> On Mon, 12 Jul 2021 12:15:59 -0400
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>   
>>>> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:  
>>>>> On Fri, 9 Jul 2021 18:23:26 +0200
>>>>> Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:
>>>>>     
>>>>>> On 7/9/21 10:04 AM, Pekka Paalanen wrote:    
>>>>>>> On Wed, 7 Jul 2021 08:48:47 +0000
>>>>>>> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
>>>>>>>      
>>>>>>>> Some display controllers can be programmed to present non-black colors
>>>>>>>> for pixels not covered by any plane (or pixels covered by the
>>>>>>>> transparent regions of higher planes).  Compositors that want a UI with
>>>>>>>> a solid color background can potentially save memory bandwidth by
>>>>>>>> setting the CRTC background property and using smaller planes to display
>>>>>>>> the rest of the content.
>>>>>>>>
>>>>>>>> To avoid confusion between different ways of encoding RGB data, we
>>>>>>>> define a standard 64-bit format that should be used for this property's
>>>>>>>> value.  Helper functions and macros are provided to generate and dissect
>>>>>>>> values in this standard format with varying component precision values.
>>>>>>>>
>>>>>>>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
>>>>>>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>>>>>>> ---
>>>>>>>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>>>>>>>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
>>>>>>>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
>>>>>>>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
>>>>>>>>   include/drm/drm_blend.h                   |  1 +
>>>>>>>>   include/drm/drm_crtc.h                    | 12 ++++++++
>>>>>>>>   include/drm/drm_mode_config.h             |  5 ++++
>>>>>>>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
>>>>>>>>   8 files changed, 89 insertions(+), 2 deletions(-)  
>>>
>>> ...
>>>   
>>>>>>> The question about full vs. limited range seems unnecessary to me, as
>>>>>>> the background color will be used as-is in the blending stage, so
>>>>>>> userspace can just program the correct value that fits the pipeline it
>>>>>>> is setting up.
>>>>>>>
>>>>>>> One more question is, as HDR exists, could we need background colors
>>>>>>> with component values greater than 1.0?      
>>>>>>
>>>>>> AR4H color format should cover that case, isn't it ?    
>>>>>
>>>>> Yes, but with the inconvenience I mentioned.
>>>>>
>>>>> This is a genuine question though, would anyone actually need
>>>>> background color values > 1.0. I don't know of any case yet where it
>>>>> would be required. It would imply that plane blending happens in a
>>>>> color space where >1.0 values are meaningful. I'm not even sure if any
>>>>> hardware supporting that exists.
>>>>>
>>>>> Maybe it would be best to assume that only [0.0, 1.0] pixel value range
>>>>> is useful, and mention in the commit message that if someone really
>>>>> needs values outside of that, they should create another background
>>>>> color property. Then, you can pick a simple unsigned integer pixel
>>>>> format, too. (I didn't see any 16 bit-per-channel formats like that in
>>>>> drm_fourcc.h though.)
>>>>>     
>>>>
>>>> I don't think we should artificially limit this to [0.0, 1.0]. As you
>>>> mentioned above when talking about full vs limited, the userspace
>>>> understands what's the correct value that fits the pipeline. If that
>>>> pipeline is FP16 with > 1.0 values then it would make sense that the
>>>> background color can be > 1.0.  
>>>
>>> Ok. The standard FP32 format then for ease of use and guaranteed enough
>>> range and precision for far into the future?
>>>   
>>
>> I don't have a strong preference for FP16 vs FP32. My understanding is
>> that FP16 is enough to represent linearly encoded data in a way that
>> looks smooth to humans.
>>
>> scRGB uses FP16 with linear encoding in a range of [-0.5, 7.4999].
>>
>>> Or do you want to keep it in 64 bits total, so the UABI can pack
>>> everything into a u64 instead of needing to create a blob?
>>>
>>> I don't mind as long as it's clearly documented what it is and how it
>>> works, and it carries enough precision.
>>>
>>> But FP16 with its 10 bits of precision might be too little for integer
>>> 12-16 bpc pipelines and sinks?
> 
> The 10 bits worries me still.
> 
> If you have a pipeline that works in [0.0, 1.0] range only, then FP16
> limits precision to 10 bits (in the upper half of the range?).
> 
>>>
>>> If the values can go beyond [0.0, 1.0] range, then does the blending
>>> hardware and the degamma/ctm/gamma coming afterwards cope with them, or
>>> do they get clamped anyway?
>>>   
>>
>> That probably depends on the HW and how it's configured. AMD HW can handle
>> values above and below [0.0, 1.0].
> 
> Right, so how would userspace know what will happen?
> 
> Or do we need to specify that while values outside that unit range are
> expressable, it is hardware-specific on how they will behave, so
> generic userspace should not attempt to use values outside of the unit
> range?
> 
> I guess this caveat should be documented for everything, not just for
> background color? LUT inputs and outputs, CTM input and output ranges,
> FB formats...
> 

I'm not sure we should artificially limit the interface at this point, or
document hypotheticals. At this point I don't even know whether going beyond
[0.0, 1.0] would be a challenge for any HW that supports floating point
formats.

Harry

> 
> Thanks,
> pq
> 

Re: [PATCH 1/2] drm: add crtc background color property

[Pekka Paalanen]

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

On Wed, 14 Jul 2021 12:13:58 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2021-07-14 3:35 a.m., Pekka Paalanen wrote:
> > On Tue, 13 Jul 2021 09:54:35 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >   
> >> On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:  
> >>> On Mon, 12 Jul 2021 12:15:59 -0400
> >>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>     
> >>>> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:    
> >>>>> On Fri, 9 Jul 2021 18:23:26 +0200
> >>>>> Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:
> >>>>>       
> >>>>>> On 7/9/21 10:04 AM, Pekka Paalanen wrote:      
> >>>>>>> On Wed, 7 Jul 2021 08:48:47 +0000
> >>>>>>> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
> >>>>>>>        
> >>>>>>>> Some display controllers can be programmed to present non-black colors
> >>>>>>>> for pixels not covered by any plane (or pixels covered by the
> >>>>>>>> transparent regions of higher planes).  Compositors that want a UI with
> >>>>>>>> a solid color background can potentially save memory bandwidth by
> >>>>>>>> setting the CRTC background property and using smaller planes to display
> >>>>>>>> the rest of the content.
> >>>>>>>>
> >>>>>>>> To avoid confusion between different ways of encoding RGB data, we
> >>>>>>>> define a standard 64-bit format that should be used for this property's
> >>>>>>>> value.  Helper functions and macros are provided to generate and dissect
> >>>>>>>> values in this standard format with varying component precision values.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> >>>>>>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >>>>>>>> ---
> >>>>>>>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >>>>>>>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
> >>>>>>>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
> >>>>>>>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
> >>>>>>>>   include/drm/drm_blend.h                   |  1 +
> >>>>>>>>   include/drm/drm_crtc.h                    | 12 ++++++++
> >>>>>>>>   include/drm/drm_mode_config.h             |  5 ++++
> >>>>>>>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
> >>>>>>>>   8 files changed, 89 insertions(+), 2 deletions(-)    
> >>>
> >>> ...
> >>>     
> >>>>>>> The question about full vs. limited range seems unnecessary to me, as
> >>>>>>> the background color will be used as-is in the blending stage, so
> >>>>>>> userspace can just program the correct value that fits the pipeline it
> >>>>>>> is setting up.
> >>>>>>>
> >>>>>>> One more question is, as HDR exists, could we need background colors
> >>>>>>> with component values greater than 1.0?        
> >>>>>>
> >>>>>> AR4H color format should cover that case, isn't it ?      
> >>>>>
> >>>>> Yes, but with the inconvenience I mentioned.
> >>>>>
> >>>>> This is a genuine question though, would anyone actually need
> >>>>> background color values > 1.0. I don't know of any case yet where it
> >>>>> would be required. It would imply that plane blending happens in a
> >>>>> color space where >1.0 values are meaningful. I'm not even sure if any
> >>>>> hardware supporting that exists.
> >>>>>
> >>>>> Maybe it would be best to assume that only [0.0, 1.0] pixel value range
> >>>>> is useful, and mention in the commit message that if someone really
> >>>>> needs values outside of that, they should create another background
> >>>>> color property. Then, you can pick a simple unsigned integer pixel
> >>>>> format, too. (I didn't see any 16 bit-per-channel formats like that in
> >>>>> drm_fourcc.h though.)
> >>>>>       
> >>>>
> >>>> I don't think we should artificially limit this to [0.0, 1.0]. As you
> >>>> mentioned above when talking about full vs limited, the userspace
> >>>> understands what's the correct value that fits the pipeline. If that
> >>>> pipeline is FP16 with > 1.0 values then it would make sense that the
> >>>> background color can be > 1.0.    
> >>>
> >>> Ok. The standard FP32 format then for ease of use and guaranteed enough
> >>> range and precision for far into the future?
> >>>     
> >>
> >> I don't have a strong preference for FP16 vs FP32. My understanding is
> >> that FP16 is enough to represent linearly encoded data in a way that
> >> looks smooth to humans.
> >>
> >> scRGB uses FP16 with linear encoding in a range of [-0.5, 7.4999].
> >>  
> >>> Or do you want to keep it in 64 bits total, so the UABI can pack
> >>> everything into a u64 instead of needing to create a blob?
> >>>
> >>> I don't mind as long as it's clearly documented what it is and how it
> >>> works, and it carries enough precision.
> >>>
> >>> But FP16 with its 10 bits of precision might be too little for integer
> >>> 12-16 bpc pipelines and sinks?  
> > 
> > The 10 bits worries me still.
> > 
> > If you have a pipeline that works in [0.0, 1.0] range only, then FP16
> > limits precision to 10 bits (in the upper half of the range?).
> >   
> >>>
> >>> If the values can go beyond [0.0, 1.0] range, then does the blending
> >>> hardware and the degamma/ctm/gamma coming afterwards cope with them, or
> >>> do they get clamped anyway?
> >>>     
> >>
> >> That probably depends on the HW and how it's configured. AMD HW can handle
> >> values above and below [0.0, 1.0].  
> > 
> > Right, so how would userspace know what will happen?
> > 
> > Or do we need to specify that while values outside that unit range are
> > expressable, it is hardware-specific on how they will behave, so
> > generic userspace should not attempt to use values outside of the unit
> > range?
> > 
> > I guess this caveat should be documented for everything, not just for
> > background color? LUT inputs and outputs, CTM input and output ranges,
> > FB formats...
> >   
> 
> I'm not sure we should artificially limit the interface at this point, or
> document hypotheticals. At this point I don't even know whether going beyond
> [0.0, 1.0] would be a challenge for any HW that supports floating point
> formats.

Exactly, we don't know. Yet we have to document how background color
works. If background color can express values outside of [0.0, 1.0],
the documentation must say something about it.

If there is no way to know, then documentation must say you don't know
(or that it is hardware-specific, which to generic userspace is the
same thing).

If userspace does not know what happens, then obviously it will avoid
using values it does not know what happens with.

For example, let's say that blending can produce values outside of
[0.0, 1.0]. The next step in the pipeline is DEGAMMA, which is a 1D
LUT. How do you sample a 1D LUT with input values beyond [0.0, 1.0]? Do
you clamp them to the unit range? Does the clamping still happen even
when the LUT is in pass-through mode?

And in general, how big or how negative values will actually go through
the pipeline?

Of course the background color property should not document everything
above, but it must say something, like "The handling of values outside
of [0.0, 1.0] depends on the capabilities of the hardware blending
engine." That makes the handling unknown to generic userspace, but
userspace drivers could make use of it.

The important bit is to understand that the background color values may
sometimes (when?) not reach the sink unmodified even if userspace has
configured the KMS pipeline to not modify them.

I would expect that values in [0.0, 1.0] have no problem passing
through the KMS pipeline unharmed, and there are obvious expectations
about how a LUT or a CTM processes them. But as soon as values outside
of that range are possible, a whole slew of questions arises. The
documentation must not be silent, it must set expectations like "it's
hardware specific" if that's what it is.


Thanks,
pq

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

Re: [PATCH 1/2] drm: add crtc background color property

[Harry Wentland]

On 2021-07-15 5:34 a.m., Pekka Paalanen wrote:
> On Wed, 14 Jul 2021 12:13:58 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> On 2021-07-14 3:35 a.m., Pekka Paalanen wrote:
>>> On Tue, 13 Jul 2021 09:54:35 -0400
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>   
>>>> On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:  
>>>>> On Mon, 12 Jul 2021 12:15:59 -0400
>>>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>>>     
>>>>>> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:    
>>>>>>> On Fri, 9 Jul 2021 18:23:26 +0200
>>>>>>> Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> wrote:
>>>>>>>       
>>>>>>>> On 7/9/21 10:04 AM, Pekka Paalanen wrote:      
>>>>>>>>> On Wed, 7 Jul 2021 08:48:47 +0000
>>>>>>>>> Raphael GALLAIS-POU - foss <raphael.gallais-pou@foss.st.com> wrote:
>>>>>>>>>        
>>>>>>>>>> Some display controllers can be programmed to present non-black colors
>>>>>>>>>> for pixels not covered by any plane (or pixels covered by the
>>>>>>>>>> transparent regions of higher planes).  Compositors that want a UI with
>>>>>>>>>> a solid color background can potentially save memory bandwidth by
>>>>>>>>>> setting the CRTC background property and using smaller planes to display
>>>>>>>>>> the rest of the content.
>>>>>>>>>>
>>>>>>>>>> To avoid confusion between different ways of encoding RGB data, we
>>>>>>>>>> define a standard 64-bit format that should be used for this property's
>>>>>>>>>> value.  Helper functions and macros are provided to generate and dissect
>>>>>>>>>> values in this standard format with varying component precision values.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
>>>>>>>>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>>>>>>>>> ---
>>>>>>>>>>   drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>>>>>>>>>>   drivers/gpu/drm/drm_atomic_uapi.c         |  4 +++
>>>>>>>>>>   drivers/gpu/drm/drm_blend.c               | 34 +++++++++++++++++++++--
>>>>>>>>>>   drivers/gpu/drm/drm_mode_config.c         |  6 ++++
>>>>>>>>>>   include/drm/drm_blend.h                   |  1 +
>>>>>>>>>>   include/drm/drm_crtc.h                    | 12 ++++++++
>>>>>>>>>>   include/drm/drm_mode_config.h             |  5 ++++
>>>>>>>>>>   include/uapi/drm/drm_mode.h               | 28 +++++++++++++++++++
>>>>>>>>>>   8 files changed, 89 insertions(+), 2 deletions(-)    
>>>>>
>>>>> ...
>>>>>     
>>>>>>>>> The question about full vs. limited range seems unnecessary to me, as
>>>>>>>>> the background color will be used as-is in the blending stage, so
>>>>>>>>> userspace can just program the correct value that fits the pipeline it
>>>>>>>>> is setting up.
>>>>>>>>>
>>>>>>>>> One more question is, as HDR exists, could we need background colors
>>>>>>>>> with component values greater than 1.0?        
>>>>>>>>
>>>>>>>> AR4H color format should cover that case, isn't it ?      
>>>>>>>
>>>>>>> Yes, but with the inconvenience I mentioned.
>>>>>>>
>>>>>>> This is a genuine question though, would anyone actually need
>>>>>>> background color values > 1.0. I don't know of any case yet where it
>>>>>>> would be required. It would imply that plane blending happens in a
>>>>>>> color space where >1.0 values are meaningful. I'm not even sure if any
>>>>>>> hardware supporting that exists.
>>>>>>>
>>>>>>> Maybe it would be best to assume that only [0.0, 1.0] pixel value range
>>>>>>> is useful, and mention in the commit message that if someone really
>>>>>>> needs values outside of that, they should create another background
>>>>>>> color property. Then, you can pick a simple unsigned integer pixel
>>>>>>> format, too. (I didn't see any 16 bit-per-channel formats like that in
>>>>>>> drm_fourcc.h though.)
>>>>>>>       
>>>>>>
>>>>>> I don't think we should artificially limit this to [0.0, 1.0]. As you
>>>>>> mentioned above when talking about full vs limited, the userspace
>>>>>> understands what's the correct value that fits the pipeline. If that
>>>>>> pipeline is FP16 with > 1.0 values then it would make sense that the
>>>>>> background color can be > 1.0.    
>>>>>
>>>>> Ok. The standard FP32 format then for ease of use and guaranteed enough
>>>>> range and precision for far into the future?
>>>>>     
>>>>
>>>> I don't have a strong preference for FP16 vs FP32. My understanding is
>>>> that FP16 is enough to represent linearly encoded data in a way that
>>>> looks smooth to humans.
>>>>
>>>> scRGB uses FP16 with linear encoding in a range of [-0.5, 7.4999].
>>>>  
>>>>> Or do you want to keep it in 64 bits total, so the UABI can pack
>>>>> everything into a u64 instead of needing to create a blob?
>>>>>
>>>>> I don't mind as long as it's clearly documented what it is and how it
>>>>> works, and it carries enough precision.
>>>>>
>>>>> But FP16 with its 10 bits of precision might be too little for integer
>>>>> 12-16 bpc pipelines and sinks?  
>>>
>>> The 10 bits worries me still.
>>>
>>> If you have a pipeline that works in [0.0, 1.0] range only, then FP16
>>> limits precision to 10 bits (in the upper half of the range?).
>>>   
>>>>>
>>>>> If the values can go beyond [0.0, 1.0] range, then does the blending
>>>>> hardware and the degamma/ctm/gamma coming afterwards cope with them, or
>>>>> do they get clamped anyway?
>>>>>     
>>>>
>>>> That probably depends on the HW and how it's configured. AMD HW can handle
>>>> values above and below [0.0, 1.0].  
>>>
>>> Right, so how would userspace know what will happen?
>>>
>>> Or do we need to specify that while values outside that unit range are
>>> expressable, it is hardware-specific on how they will behave, so
>>> generic userspace should not attempt to use values outside of the unit
>>> range?
>>>
>>> I guess this caveat should be documented for everything, not just for
>>> background color? LUT inputs and outputs, CTM input and output ranges,
>>> FB formats...
>>>   
>>
>> I'm not sure we should artificially limit the interface at this point, or
>> document hypotheticals. At this point I don't even know whether going beyond
>> [0.0, 1.0] would be a challenge for any HW that supports floating point
>> formats.
> 
> Exactly, we don't know. Yet we have to document how background color
> works. If background color can express values outside of [0.0, 1.0],
> the documentation must say something about it.
> 
> If there is no way to know, then documentation must say you don't know
> (or that it is hardware-specific, which to generic userspace is the
> same thing).
> 
> If userspace does not know what happens, then obviously it will avoid
> using values it does not know what happens with.
> 
> For example, let's say that blending can produce values outside of
> [0.0, 1.0]. The next step in the pipeline is DEGAMMA, which is a 1D
> LUT. How do you sample a 1D LUT with input values beyond [0.0, 1.0]? Do
> you clamp them to the unit range? Does the clamping still happen even
> when the LUT is in pass-through mode?
> 
> And in general, how big or how negative values will actually go through
> the pipeline?
> 
> Of course the background color property should not document everything
> above, but it must say something, like "The handling of values outside
> of [0.0, 1.0] depends on the capabilities of the hardware blending
> engine." That makes the handling unknown to generic userspace, but
> userspace drivers could make use of it.
> 
> The important bit is to understand that the background color values may
> sometimes (when?) not reach the sink unmodified even if userspace has
> configured the KMS pipeline to not modify them.
> 
> I would expect that values in [0.0, 1.0] have no problem passing
> through the KMS pipeline unharmed, and there are obvious expectations
> about how a LUT or a CTM processes them. But as soon as values outside
> of that range are possible, a whole slew of questions arises. The
> documentation must not be silent, it must set expectations like "it's
> hardware specific" if that's what it is.
> 

Agreed. I think ultimately we don't know because we haven't gotten to
use-cases like that.

I'm fine with documentation stating "The handling of values outside
of [0.0, 1.0] depends on the capabilities of the hardware blending
engine." or "Handling of values outside [0.0, 1.0] is currently
undefined."

Harry

> 
> Thanks,
> pq
> 

[PATCH 0/2] Introduce BACKGROUND_COLOR DRM CRTC property

[Cristian Ciocaltea]

Some display controllers can be hardware-configured to present non-black
colors for pixels which are not covered by any plane (or are exposed
through transparent regions of higher planes).

The first patch of the series introduces the BACKGROUND_COLOR DRM
property that can be attached to a CRTC via a dedicated helper function.
A 64-bit ARGB color value format is also defined and can be manipulated
with the help of a few utility macros.

Note this is a reworked version of the patch [1] submitted (many) years
ago by Matt Roper.  The main changes are:

* Dropped drm_arg() in favor of drm_argb64() to get rid of the bpc
  parameter and the related shifting for more flexibility in operation,
  e.g. when user-space cannot make use of the helper and/or when it
  doesn't now the actual precision supported by the HW.  This also
  simplifies the property verification/validation testing (see below).
  It works by extracting the specified number of least-significant bits
  from each color component.
* Renamed DRM_ARGB_*() to DRM_ARGB64_*_LSB() while providing convenience
  wrappers to extract all 16 bits of a specific color via DRM_ARGB64_*()
* Replaced GENMASK_ULL(63, 0) with U64_MAX when calling
  drm_property_create_range() to create the BACKGROUND_COLOR property
* Moved crtc_state->bgcolor initialization from
  __drm_atomic_helper_crtc_reset() to
  __drm_atomic_helper_crtc_state_reset()
* Replaced '*bgcolor*' occurrences to '*background_color*' for
  consistency with the actual property name in both storage field and
  helper functions names

The second patch adds background color support to the VOP2 display
controller used in the RK3568, RK3576, and RK3588 Rockchip SoC families.

For the moment this has been validated using a modetest wrapper script
[2], which is able to execute several tests - see an example of a
generated report at the end.  Proper support in Weston is currently in
development, and I will provide a reference once it becomes available.

The tests were performed on the Radxa boards listed below.  Please note
that as of next-20250901, there are a few known regressions; for each
case, I mentioned the actual problem and its related fix/workaround
accordingly:

* ROCK 3A (RK3568)
 - issue: broken networking
 - fix: revert commit da114122b831 ("net: ethernet: stmmac: dwmac-rk: Make
   the clk_phy could be used for external phy")

* ROCK 4D (RK3576)
 - issue: random freezes right after booting
 - fix: add regulator_ignore_unused to kernel cmdline

* ROCK 5B (RK3588)
 - issue: broken networking
 - fix: apply patch [3]

[1] https://lore.kernel.org/all/20190930224707.14904-2-matthew.d.roper@intel.com/
[2] https://gitlab.collabora.com/cristicc/linux-next/-/commits/drm-vop2-bgcolor-test
[3] https://lore.kernel.org/all/20250827230943.17829-1-inochiama@gmail.com/

Validation report on ROCK 5B
============================

$ tools/testing/rk-bgcol-test.sh

---------------------------------------------------------------
 Available Rockchip display connectors
---------------------------------------------------------------
id	type	status	crtc_id	plane_id
85	11	2	0	34
88	11	1	83	40

Selected connector: id=88 crtc=83 plane=40

---------------------------------------------------------------
 Check initial state
---------------------------------------------------------------
Read BACKGROUND_COLOR prop (ARGB64): 0xffff000000000000
    Connector: HDMI-A-2
	background color (10bpc): r=0 g=0 b=0

---------------------------------------------------------------
 Set/get DRM property
---------------------------------------------------------------
Changing prop value to: 0xffff00000000ffff
opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
Read BACKGROUND_COLOR prop (ARGB64): 0xffff00000000ffff
    Connector: HDMI-A-2
	background color (10bpc): r=0 g=0 b=ffff

---------------------------------------------------------------
 Plane display test 40@83:960x540+480+270
---------------------------------------------------------------

Changing prop value to 0xffffffff00000000
Press ENTER to continue..
opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
testing 960x540@XR24 overlay plane 40

Read BACKGROUND_COLOR prop (ARGB64): 0xffffffff00000000
    Connector: HDMI-A-2
	background color (10bpc): r=ffff g=0 b=0

Changing prop value to 0xffff0000ffff0000
Press ENTER to continue..
opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
testing 960x540@XR24 overlay plane 40

Read BACKGROUND_COLOR prop (ARGB64): 0xffff0000ffff0000
    Connector: HDMI-A-2
	background color (10bpc): r=0 g=ffff b=0

Changing prop value to 0xffff00000000ffff
Press ENTER to continue..
opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
testing 960x540@XR24 overlay plane 40

Read BACKGROUND_COLOR prop (ARGB64): 0xffff00000000ffff
    Connector: HDMI-A-2
	background color (10bpc): r=0 g=0 b=ffff

---------------------------------------------------------------
 Restoring state
---------------------------------------------------------------
Changing prop value to: 0xffff000000000000
opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
Read BACKGROUND_COLOR prop (ARGB64): 0xffff000000000000
    Connector: HDMI-A-2
	background color (10bpc): r=0 g=0 b=0

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Cristian Ciocaltea (2):
      drm: Add CRTC background color property
      drm/rockchip: vop2: Support setting custom background color

 drivers/gpu/drm/drm_atomic_state_helper.c    |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c            |  4 +++
 drivers/gpu/drm/drm_blend.c                  | 37 +++++++++++++++++++++++++---
 drivers/gpu/drm/drm_mode_config.c            |  6 +++++
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 13 +++++++++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h |  4 +++
 include/drm/drm_blend.h                      |  4 ++-
 include/drm/drm_crtc.h                       | 12 +++++++++
 include/drm/drm_mode_config.h                |  5 ++++
 include/uapi/drm/drm_mode.h                  | 30 ++++++++++++++++++++++
 10 files changed, 110 insertions(+), 6 deletions(-)
---
base-commit: d0630b758e593506126e8eda6c3d56097d1847c5
change-id: 20250829-rk3588-bgcolor-c1a7b9a507bc

[PATCH 1/2] drm: Add CRTC background color property

[Cristian Ciocaltea]

Some display controllers can be hardware programmed to show non-black
colors for pixels that are either not covered by any plane or are
exposed through transparent regions of higher planes.  This feature can
help reduce memory bandwidth usage, e.g. in compositors managing a UI
with a solid background color while using smaller planes to render the
remaining content.

To support this capability, introduce the BACKGROUND_COLOR standard DRM
mode property, which can be attached to a CRTC through the
drm_crtc_attach_background_color_property() helper function.

Additionally, define a 64-bit ARGB format value to be built with the
help of a dedicated drm_argb64() utility macro.  Individual color
components can be extracted with desired precision using the
corresponding DRM_ARGB64_*() macros.

Co-developed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c         |  4 ++++
 drivers/gpu/drm/drm_blend.c               | 37 +++++++++++++++++++++++++++----
 drivers/gpu/drm/drm_mode_config.c         |  6 +++++
 include/drm/drm_blend.h                   |  4 +++-
 include/drm/drm_crtc.h                    | 12 ++++++++++
 include/drm/drm_mode_config.h             |  5 +++++
 include/uapi/drm/drm_mode.h               | 30 +++++++++++++++++++++++++
 8 files changed, 94 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 7142e163e618ea0d7d9d828e1bd9ff2a6ec0dfeb..359264cf467c5270b77f0b04548073bc92cb812e 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -75,6 +75,7 @@ __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
 				     struct drm_crtc *crtc)
 {
 	crtc_state->crtc = crtc;
+	crtc_state->background_color = drm_argb64(0xffff, 0, 0, 0);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 85dbdaa4a2e25878c953b9b41539c8566d55c6d9..a447cb119aaa6cd11348be77b39f342a1386836d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -407,6 +407,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
 					&replaced);
 		state->color_mgmt_changed |= replaced;
 		return ret;
+	} else if (property == config->background_color_property) {
+		state->background_color = val;
 	} else if (property == config->prop_out_fence_ptr) {
 		s32 __user *fence_ptr = u64_to_user_ptr(val);
 
@@ -452,6 +454,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
 		*val = (state->ctm) ? state->ctm->base.id : 0;
 	else if (property == config->gamma_lut_property)
 		*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+	else if (property == config->background_color_property)
+		*val = state->background_color;
 	else if (property == config->prop_out_fence_ptr)
 		*val = 0;
 	else if (property == crtc->scaling_filter_property)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 6852d73c931ce32e62062e2b8f8c5e38612d5210..5a287d12685b007a2732f510f62675f500e53727 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -191,10 +191,6 @@
  *		 plane does not expose the "alpha" property, then this is
  *		 assumed to be 1.0
  *
- * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
- *
  * SCALING_FILTER:
  *     Indicates scaling filter to be used for plane scaler
  *
@@ -207,6 +203,23 @@
  *
  * Drivers can set up this property for a plane by calling
  * drm_plane_create_scaling_filter_property
+ *
+ * The property extensions described above all apply to the plane.  Drivers
+ * may also expose the following crtc property extension:
+ *
+ * BACKGROUND_COLOR:
+ *	Background color is set via drm_crtc_attach_background_color_property().
+ *	It controls the ARGB color of a full-screen layer that exists below all
+ *	planes.  This color will be used for pixels not covered by any plane and
+ *	may also be blended with plane contents as allowed by a plane's alpha
+ *	values.  The background color defaults to black, and is assumed to be
+ *	black for drivers that do not expose this property.  Although background
+ *	color isn't a plane, it is assumed that the color provided here
+ *	undergoes the same pipe-level degamma/CSC/gamma transformations that
+ *	planes undergo.  Note that the color value provided here includes an
+ *	alpha channel, hence non-opaque background color values are allowed, but
+ *	are generally only honored in special cases (e.g. when a memory
+ *	writeback connector is in use).
  */
 
 /**
@@ -621,3 +634,19 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 	return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
+
+/**
+ * drm_crtc_attach_background_color_property - attach background color property
+ * @crtc: drm crtc
+ *
+ * Attaches the background color property to @crtc.  The property defaults to
+ * solid black and will accept 64-bit ARGB values in the format generated by
+ * drm_argb64().
+ */
+void drm_crtc_attach_background_color_property(struct drm_crtc *crtc)
+{
+	drm_object_attach_property(&crtc->base,
+				   crtc->dev->mode_config.background_color_property,
+				   drm_argb64(0xffff, 0, 0, 0));
+}
+EXPORT_SYMBOL(drm_crtc_attach_background_color_property);
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 25f376869b3a41d47bbe72b0df3e35cad142f3e6..6d70bfab45ca2bb81ed3ca1940fd1cd85e8cc58e 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -375,6 +375,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.gamma_lut_size_property = prop;
 
+	prop = drm_property_create_range(dev, 0,
+					 "BACKGROUND_COLOR", 0, U64_MAX);
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.background_color_property = prop;
+
 	prop = drm_property_create(dev,
 				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
 				   "IN_FORMATS", 0);
diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 88bdfec3bd8848acd1ef5742aaaa23483b332a2e..c7e888767c81c2745cd3cce88c10db4bbe305d1e 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -31,8 +31,9 @@
 #define DRM_MODE_BLEND_COVERAGE		1
 #define DRM_MODE_BLEND_PIXEL_NONE	2
 
-struct drm_device;
 struct drm_atomic_state;
+struct drm_crtc;
+struct drm_device;
 struct drm_plane;
 
 static inline bool drm_rotation_90_or_270(unsigned int rotation)
@@ -58,4 +59,5 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
 			      struct drm_atomic_state *state);
 int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 					 unsigned int supported_modes);
+void drm_crtc_attach_background_color_property(struct drm_crtc *crtc);
 #endif
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index caa56e039da2a748cf40ebf45b37158acda439d9..4653dacc1077b9ed8fb4cf27cc84530ba1706f6a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -274,6 +274,18 @@ struct drm_crtc_state {
 	 */
 	struct drm_property_blob *gamma_lut;
 
+	/**
+	 * @background_color:
+	 *
+	 * RGB value representing the pipe's background color.  The background
+	 * color (aka "canvas color") of a pipe is the color that will be used
+	 * for pixels not covered by a plane, or covered by transparent pixels
+	 * of a plane.  The value here should be built using drm_argb64(), while
+	 * the individual color components can be extracted with desired
+	 * precision via the DRM_ARGB64_*() macros.
+	 */
+	u64 background_color;
+
 	/**
 	 * @target_vblank:
 	 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 2e848b816218584eb077ed887bf97705f012a622..ea422afec5c4108a223dc872e1b6835ffc596cc3 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -814,6 +814,11 @@ struct drm_mode_config {
 	 * gamma LUT as supported by the driver (read-only).
 	 */
 	struct drm_property *gamma_lut_size_property;
+	/**
+	 * @background_color_property: Optional CRTC property to set the
+	 * background color.
+	 */
+	struct drm_property *background_color_property;
 
 	/**
 	 * @suggested_x_property: Optional connector property with a hint for
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index a122bea2559387576150236e3a88f99c24ad3138..4bd6a8ca8868109bcbe21f9f6e9864519c9d03ec 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1363,6 +1363,36 @@ struct drm_mode_closefb {
 	__u32 pad;
 };
 
+/*
+ * Put 16-bit ARGB values into a standard 64-bit representation that
+ * can be used for ioctl parameters, inter-driver communication, etc.
+ */
+static inline __u64
+drm_argb64(__u16 alpha, __u16 red, __u16 green, __u16 blue)
+{
+	return (__u64)alpha << 48 | (__u64)red << 32 | (__u64)green << 16 | blue;
+}
+
+/*
+ * Extract the specified number of least-significant bits of a specific
+ * color component from a standard 64-bit ARGB value.
+ */
+#define DRM_ARGB64_COMP(c, shift, numlsb) \
+	((__u16)(((c) >> (shift)) & ((1UL << (numlsb) % 17) - 1)))
+#define DRM_ARGB64_ALPHA_LSB(c, numlsb) DRM_ARGB64_COMP(c, 48, numlsb)
+#define DRM_ARGB64_RED_LSB(c, numlsb)   DRM_ARGB64_COMP(c, 32, numlsb)
+#define DRM_ARGB64_GREEN_LSB(c, numlsb) DRM_ARGB64_COMP(c, 16, numlsb)
+#define DRM_ARGB64_BLUE_LSB(c, numlsb)  DRM_ARGB64_COMP(c, 0, numlsb)
+
+/*
+ * Convenience wrappers to extract all 16 bits of a specific color
+ * component from a standard 64-bit ARGB value.
+ */
+#define DRM_ARGB64_ALPHA(c)		DRM_ARGB64_ALPHA_LSB(c, 16)
+#define DRM_ARGB64_RED(c)		DRM_ARGB64_RED_LSB(c, 16)
+#define DRM_ARGB64_GREEN(c)		DRM_ARGB64_GREEN_LSB(c, 16)
+#define DRM_ARGB64_BLUE(c)		DRM_ARGB64_BLUE_LSB(c, 16)
+
 #if defined(__cplusplus)
 }
 #endif

-- 
2.51.0

[PATCH 2/2] drm/rockchip: vop2: Support setting custom background color

[Cristian Ciocaltea]

VOP2 allows configuring the background color of each video output port.

Since a previous patch introduced the BACKGROUND_COLOR CRTC property,
which defaults to solid black, take it into account when programming the
hardware.

Note that only the 10 least significant bits of each color component are
used, as this is the maximum precision supported by the display
controller.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 13 ++++++++++++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h |  4 ++++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index b50927a824b4020a7ffd57974070ed202cd8b838..7fe060e7e58297d583b1396cf606b7ba580b8e79 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1548,6 +1548,7 @@ static void vop2_post_config(struct drm_crtc *crtc)
 	struct vop2_video_port *vp = to_vop2_video_port(crtc);
 	struct vop2 *vop2 = vp->vop2;
 	struct drm_display_mode *mode = &crtc->state->adjusted_mode;
+	u64 bgcolor = crtc->state->background_color;
 	u16 vtotal = mode->crtc_vtotal;
 	u16 hdisplay = mode->crtc_hdisplay;
 	u16 hact_st = mode->crtc_htotal - mode->crtc_hsync_start;
@@ -1593,7 +1594,11 @@ static void vop2_post_config(struct drm_crtc *crtc)
 		vop2_vp_write(vp, RK3568_VP_POST_DSP_VACT_INFO_F1, val);
 	}
 
-	vop2_vp_write(vp, RK3568_VP_DSP_BG, 0);
+	/* Background color is programmed with 10 bits of precision */
+	val = FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_RED, DRM_ARGB64_RED(bgcolor));
+	val |= FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_GREEN, DRM_ARGB64_GREEN(bgcolor));
+	val |= FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_BLUE, DRM_ARGB64_BLUE(bgcolor));
+	vop2_vp_write(vp, RK3568_VP_DSP_BG, val);
 }
 
 static int us_to_vertical_line(struct drm_display_mode *mode, int us)
@@ -1972,6 +1977,10 @@ static int vop2_crtc_state_dump(struct drm_crtc *crtc, struct seq_file *s)
 		   drm_get_bus_format_name(vcstate->bus_format));
 	seq_printf(s, "\toutput_mode[%x]", vcstate->output_mode);
 	seq_printf(s, " color_space[%d]\n", vcstate->color_space);
+	seq_printf(s, "\tbackground color (10bpc): r=%x g=%x b=%x\n",
+		   DRM_ARGB64_RED(cstate->background_color),
+		   DRM_ARGB64_GREEN(cstate->background_color),
+		   DRM_ARGB64_BLUE(cstate->background_color));
 	seq_printf(s, "    Display mode: %dx%d%s%d\n",
 		   mode->hdisplay, mode->vdisplay, interlaced ? "i" : "p",
 		   drm_mode_vrefresh(mode));
@@ -2461,6 +2470,8 @@ static int vop2_create_crtcs(struct vop2 *vop2)
 			return dev_err_probe(drm->dev, ret,
 					     "crtc init for video_port%d failed\n", i);
 
+		drm_crtc_attach_background_color_property(&vp->crtc);
+
 		drm_crtc_helper_add(&vp->crtc, &vop2_crtc_helper_funcs);
 		if (vop2->lut_regs) {
 			const struct vop2_video_port_data *vp_data = &vop2_data->vp[vp->id];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
index fa5c56f16047e3493e82fbedaced221459696dcc..596558adc1207e837eb8eca49b35d7a55d693f88 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
@@ -659,6 +659,10 @@ enum dst_factor_mode {
 #define RK3588_VP_CLK_CTRL__DCLK_OUT_DIV		GENMASK(3, 2)
 #define RK3588_VP_CLK_CTRL__DCLK_CORE_DIV		GENMASK(1, 0)
 
+#define RK3568_VP_DSP_BG__DSP_BG_RED			GENMASK(29, 20)
+#define RK3568_VP_DSP_BG__DSP_BG_GREEN			GENMASK(19, 10)
+#define RK3568_VP_DSP_BG__DSP_BG_BLUE			GENMASK(9, 0)
+
 #define RK3568_VP_POST_SCL_CTRL__VSCALEDOWN		BIT(1)
 #define RK3568_VP_POST_SCL_CTRL__HSCALEDOWN		BIT(0)
 

-- 
2.51.0

Re: [PATCH 0/2] Introduce BACKGROUND_COLOR DRM CRTC property

[Raphael Gallais-Pou]

On 9/2/25 11:27, Cristian Ciocaltea wrote:
> Some display controllers can be hardware-configured to present non-black
> colors for pixels which are not covered by any plane (or are exposed
> through transparent regions of higher planes).
>
> The first patch of the series introduces the BACKGROUND_COLOR DRM
> property that can be attached to a CRTC via a dedicated helper function.
> A 64-bit ARGB color value format is also defined and can be manipulated
> with the help of a few utility macros.

Hi Cristian,

Thanks for this work ! :)

FWIW I sent a series also based on Matt's work four years ago:
https://lore.kernel.org/dri-devel/20210707084557.22443-2-raphael.gallais-pou@foss.st.com/

IIRC at the time there was some questions around the pixel format used for the
property, and non-opaque color vs alpha pre-multiplication.
Mind that on STM32MP platforms alpha channel for the background color is not
supported.

Hope the thread can bring some insights.

Best regards,
Raphaël
>
> Note this is a reworked version of the patch [1] submitted (many) years
> ago by Matt Roper.  The main changes are:
>
> * Dropped drm_arg() in favor of drm_argb64() to get rid of the bpc
>   parameter and the related shifting for more flexibility in operation,
>   e.g. when user-space cannot make use of the helper and/or when it
>   doesn't now the actual precision supported by the HW.  This also
>   simplifies the property verification/validation testing (see below).
>   It works by extracting the specified number of least-significant bits
>   from each color component.
> * Renamed DRM_ARGB_*() to DRM_ARGB64_*_LSB() while providing convenience
>   wrappers to extract all 16 bits of a specific color via DRM_ARGB64_*()
> * Replaced GENMASK_ULL(63, 0) with U64_MAX when calling
>   drm_property_create_range() to create the BACKGROUND_COLOR property
> * Moved crtc_state->bgcolor initialization from
>   __drm_atomic_helper_crtc_reset() to
>   __drm_atomic_helper_crtc_state_reset()
> * Replaced '*bgcolor*' occurrences to '*background_color*' for
>   consistency with the actual property name in both storage field and
>   helper functions names
>
> The second patch adds background color support to the VOP2 display
> controller used in the RK3568, RK3576, and RK3588 Rockchip SoC families.
>
> For the moment this has been validated using a modetest wrapper script
> [2], which is able to execute several tests - see an example of a
> generated report at the end.  Proper support in Weston is currently in
> development, and I will provide a reference once it becomes available.
>
> The tests were performed on the Radxa boards listed below.  Please note
> that as of next-20250901, there are a few known regressions; for each
> case, I mentioned the actual problem and its related fix/workaround
> accordingly:
>
> * ROCK 3A (RK3568)
>  - issue: broken networking
>  - fix: revert commit da114122b831 ("net: ethernet: stmmac: dwmac-rk: Make
>    the clk_phy could be used for external phy")
>
> * ROCK 4D (RK3576)
>  - issue: random freezes right after booting
>  - fix: add regulator_ignore_unused to kernel cmdline
>
> * ROCK 5B (RK3588)
>  - issue: broken networking
>  - fix: apply patch [3]
>
> [1] https://lore.kernel.org/all/20190930224707.14904-2-matthew.d.roper@intel.com/
> [2] https://gitlab.collabora.com/cristicc/linux-next/-/commits/drm-vop2-bgcolor-test
> [3] https://lore.kernel.org/all/20250827230943.17829-1-inochiama@gmail.com/
>
> Validation report on ROCK 5B
> ============================
>
> $ tools/testing/rk-bgcol-test.sh
>
> ---------------------------------------------------------------
>  Available Rockchip display connectors
> ---------------------------------------------------------------
> id	type	status	crtc_id	plane_id
> 85	11	2	0	34
> 88	11	1	83	40
>
> Selected connector: id=88 crtc=83 plane=40
>
> ---------------------------------------------------------------
>  Check initial state
> ---------------------------------------------------------------
> Read BACKGROUND_COLOR prop (ARGB64): 0xffff000000000000
>     Connector: HDMI-A-2
> 	background color (10bpc): r=0 g=0 b=0
>
> ---------------------------------------------------------------
>  Set/get DRM property
> ---------------------------------------------------------------
> Changing prop value to: 0xffff00000000ffff
> opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
> Read BACKGROUND_COLOR prop (ARGB64): 0xffff00000000ffff
>     Connector: HDMI-A-2
> 	background color (10bpc): r=0 g=0 b=ffff
>
> ---------------------------------------------------------------
>  Plane display test 40@83:960x540+480+270
> ---------------------------------------------------------------
>
> Changing prop value to 0xffffffff00000000
> Press ENTER to continue..
> opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
> testing 960x540@XR24 overlay plane 40
>
> Read BACKGROUND_COLOR prop (ARGB64): 0xffffffff00000000
>     Connector: HDMI-A-2
> 	background color (10bpc): r=ffff g=0 b=0
>
> Changing prop value to 0xffff0000ffff0000
> Press ENTER to continue..
> opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
> testing 960x540@XR24 overlay plane 40
>
> Read BACKGROUND_COLOR prop (ARGB64): 0xffff0000ffff0000
>     Connector: HDMI-A-2
> 	background color (10bpc): r=0 g=ffff b=0
>
> Changing prop value to 0xffff00000000ffff
> Press ENTER to continue..
> opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
> testing 960x540@XR24 overlay plane 40
>
> Read BACKGROUND_COLOR prop (ARGB64): 0xffff00000000ffff
>     Connector: HDMI-A-2
> 	background color (10bpc): r=0 g=0 b=ffff
>
> ---------------------------------------------------------------
>  Restoring state
> ---------------------------------------------------------------
> Changing prop value to: 0xffff000000000000
> opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0)
> Read BACKGROUND_COLOR prop (ARGB64): 0xffff000000000000
>     Connector: HDMI-A-2
> 	background color (10bpc): r=0 g=0 b=0
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Cristian Ciocaltea (2):
>       drm: Add CRTC background color property
>       drm/rockchip: vop2: Support setting custom background color
>
>  drivers/gpu/drm/drm_atomic_state_helper.c    |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c            |  4 +++
>  drivers/gpu/drm/drm_blend.c                  | 37 +++++++++++++++++++++++++---
>  drivers/gpu/drm/drm_mode_config.c            |  6 +++++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 13 +++++++++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.h |  4 +++
>  include/drm/drm_blend.h                      |  4 ++-
>  include/drm/drm_crtc.h                       | 12 +++++++++
>  include/drm/drm_mode_config.h                |  5 ++++
>  include/uapi/drm/drm_mode.h                  | 30 ++++++++++++++++++++++
>  10 files changed, 110 insertions(+), 6 deletions(-)
> ---
> base-commit: d0630b758e593506126e8eda6c3d56097d1847c5
> change-id: 20250829-rk3588-bgcolor-c1a7b9a507bc
>

Re: [PATCH 1/2] drm: Add CRTC background color property

[Ville Syrjälä]

On Tue, Sep 02, 2025 at 12:27:56PM +0300, Cristian Ciocaltea wrote:
> Some display controllers can be hardware programmed to show non-black
> colors for pixels that are either not covered by any plane or are
> exposed through transparent regions of higher planes.  This feature can
> help reduce memory bandwidth usage, e.g. in compositors managing a UI
> with a solid background color while using smaller planes to render the
> remaining content.
> 
> To support this capability, introduce the BACKGROUND_COLOR standard DRM
> mode property, which can be attached to a CRTC through the
> drm_crtc_attach_background_color_property() helper function.
> 
> Additionally, define a 64-bit ARGB format value to be built with the
> help of a dedicated drm_argb64() utility macro.  Individual color
> components can be extracted with desired precision using the
> corresponding DRM_ARGB64_*() macros.
> 
> Co-developed-by: Matt Roper <matthew.d.roper@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c         |  4 ++++
>  drivers/gpu/drm/drm_blend.c               | 37 +++++++++++++++++++++++++++----
>  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
>  include/drm/drm_blend.h                   |  4 +++-
>  include/drm/drm_crtc.h                    | 12 ++++++++++
>  include/drm/drm_mode_config.h             |  5 +++++
>  include/uapi/drm/drm_mode.h               | 30 +++++++++++++++++++++++++
>  8 files changed, 94 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 7142e163e618ea0d7d9d828e1bd9ff2a6ec0dfeb..359264cf467c5270b77f0b04548073bc92cb812e 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -75,6 +75,7 @@ __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
>  				     struct drm_crtc *crtc)
>  {
>  	crtc_state->crtc = crtc;
> +	crtc_state->background_color = drm_argb64(0xffff, 0, 0, 0);
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
>  
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index 85dbdaa4a2e25878c953b9b41539c8566d55c6d9..a447cb119aaa6cd11348be77b39f342a1386836d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -407,6 +407,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>  					&replaced);
>  		state->color_mgmt_changed |= replaced;
>  		return ret;
> +	} else if (property == config->background_color_property) {
> +		state->background_color = val;
>  	} else if (property == config->prop_out_fence_ptr) {
>  		s32 __user *fence_ptr = u64_to_user_ptr(val);
>  
> @@ -452,6 +454,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>  		*val = (state->ctm) ? state->ctm->base.id : 0;
>  	else if (property == config->gamma_lut_property)
>  		*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> +	else if (property == config->background_color_property)
> +		*val = state->background_color;
>  	else if (property == config->prop_out_fence_ptr)
>  		*val = 0;
>  	else if (property == crtc->scaling_filter_property)
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 6852d73c931ce32e62062e2b8f8c5e38612d5210..5a287d12685b007a2732f510f62675f500e53727 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -191,10 +191,6 @@
>   *		 plane does not expose the "alpha" property, then this is
>   *		 assumed to be 1.0
>   *
> - * Note that all the property extensions described here apply either to the
> - * plane or the CRTC (e.g. for the background color, which currently is not
> - * exposed and assumed to be black).
> - *
>   * SCALING_FILTER:
>   *     Indicates scaling filter to be used for plane scaler
>   *
> @@ -207,6 +203,23 @@
>   *
>   * Drivers can set up this property for a plane by calling
>   * drm_plane_create_scaling_filter_property
> + *
> + * The property extensions described above all apply to the plane.  Drivers
> + * may also expose the following crtc property extension:
> + *
> + * BACKGROUND_COLOR:
> + *	Background color is set via drm_crtc_attach_background_color_property().
> + *	It controls the ARGB color of a full-screen layer that exists below all
> + *	planes.  This color will be used for pixels not covered by any plane and
> + *	may also be blended with plane contents as allowed by a plane's alpha
> + *	values.  The background color defaults to black, and is assumed to be
> + *	black for drivers that do not expose this property.  Although background
> + *	color isn't a plane, it is assumed that the color provided here
> + *	undergoes the same pipe-level degamma/CSC/gamma transformations that
> + *	planes undergo.  Note that the color value provided here includes an
> + *	alpha channel, hence non-opaque background color values are allowed, but
> + *	are generally only honored in special cases (e.g. when a memory
> + *	writeback connector is in use).
>   */
>  
>  /**
> @@ -621,3 +634,19 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
>  	return 0;
>  }
>  EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
> +
> +/**
> + * drm_crtc_attach_background_color_property - attach background color property
> + * @crtc: drm crtc
> + *
> + * Attaches the background color property to @crtc.  The property defaults to
> + * solid black and will accept 64-bit ARGB values in the format generated by
> + * drm_argb64().
> + */
> +void drm_crtc_attach_background_color_property(struct drm_crtc *crtc)
> +{
> +	drm_object_attach_property(&crtc->base,
> +				   crtc->dev->mode_config.background_color_property,
> +				   drm_argb64(0xffff, 0, 0, 0));
> +}
> +EXPORT_SYMBOL(drm_crtc_attach_background_color_property);
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 25f376869b3a41d47bbe72b0df3e35cad142f3e6..6d70bfab45ca2bb81ed3ca1940fd1cd85e8cc58e 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -375,6 +375,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
>  		return -ENOMEM;
>  	dev->mode_config.gamma_lut_size_property = prop;
>  
> +	prop = drm_property_create_range(dev, 0,
> +					 "BACKGROUND_COLOR", 0, U64_MAX);
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.background_color_property = prop;
> +
>  	prop = drm_property_create(dev,
>  				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
>  				   "IN_FORMATS", 0);
> diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
> index 88bdfec3bd8848acd1ef5742aaaa23483b332a2e..c7e888767c81c2745cd3cce88c10db4bbe305d1e 100644
> --- a/include/drm/drm_blend.h
> +++ b/include/drm/drm_blend.h
> @@ -31,8 +31,9 @@
>  #define DRM_MODE_BLEND_COVERAGE		1
>  #define DRM_MODE_BLEND_PIXEL_NONE	2
>  
> -struct drm_device;
>  struct drm_atomic_state;
> +struct drm_crtc;
> +struct drm_device;
>  struct drm_plane;
>  
>  static inline bool drm_rotation_90_or_270(unsigned int rotation)
> @@ -58,4 +59,5 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
>  			      struct drm_atomic_state *state);
>  int drm_plane_create_blend_mode_property(struct drm_plane *plane,
>  					 unsigned int supported_modes);
> +void drm_crtc_attach_background_color_property(struct drm_crtc *crtc);
>  #endif
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index caa56e039da2a748cf40ebf45b37158acda439d9..4653dacc1077b9ed8fb4cf27cc84530ba1706f6a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -274,6 +274,18 @@ struct drm_crtc_state {
>  	 */
>  	struct drm_property_blob *gamma_lut;
>  
> +	/**
> +	 * @background_color:
> +	 *
> +	 * RGB value representing the pipe's background color.  The background
> +	 * color (aka "canvas color") of a pipe is the color that will be used
> +	 * for pixels not covered by a plane, or covered by transparent pixels
> +	 * of a plane.  The value here should be built using drm_argb64(), while
> +	 * the individual color components can be extracted with desired
> +	 * precision via the DRM_ARGB64_*() macros.
> +	 */
> +	u64 background_color;
> +
>  	/**
>  	 * @target_vblank:
>  	 *
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 2e848b816218584eb077ed887bf97705f012a622..ea422afec5c4108a223dc872e1b6835ffc596cc3 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -814,6 +814,11 @@ struct drm_mode_config {
>  	 * gamma LUT as supported by the driver (read-only).
>  	 */
>  	struct drm_property *gamma_lut_size_property;
> +	/**
> +	 * @background_color_property: Optional CRTC property to set the
> +	 * background color.
> +	 */
> +	struct drm_property *background_color_property;
>  
>  	/**
>  	 * @suggested_x_property: Optional connector property with a hint for
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index a122bea2559387576150236e3a88f99c24ad3138..4bd6a8ca8868109bcbe21f9f6e9864519c9d03ec 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1363,6 +1363,36 @@ struct drm_mode_closefb {
>  	__u32 pad;
>  };
>  
> +/*
> + * Put 16-bit ARGB values into a standard 64-bit representation that
> + * can be used for ioctl parameters, inter-driver communication, etc.
> + */
> +static inline __u64
> +drm_argb64(__u16 alpha, __u16 red, __u16 green, __u16 blue)
> +{
> +	return (__u64)alpha << 48 | (__u64)red << 32 | (__u64)green << 16 | blue;
> +}
> +
> +/*
> + * Extract the specified number of least-significant bits of a specific
> + * color component from a standard 64-bit ARGB value.

Why would you ever want the least significant bits?

> + */
> +#define DRM_ARGB64_COMP(c, shift, numlsb) \
> +	((__u16)(((c) >> (shift)) & ((1UL << (numlsb) % 17) - 1)))
> +#define DRM_ARGB64_ALPHA_LSB(c, numlsb) DRM_ARGB64_COMP(c, 48, numlsb)
> +#define DRM_ARGB64_RED_LSB(c, numlsb)   DRM_ARGB64_COMP(c, 32, numlsb)
> +#define DRM_ARGB64_GREEN_LSB(c, numlsb) DRM_ARGB64_COMP(c, 16, numlsb)
> +#define DRM_ARGB64_BLUE_LSB(c, numlsb)  DRM_ARGB64_COMP(c, 0, numlsb)
> +
> +/*
> + * Convenience wrappers to extract all 16 bits of a specific color
> + * component from a standard 64-bit ARGB value.
> + */
> +#define DRM_ARGB64_ALPHA(c)		DRM_ARGB64_ALPHA_LSB(c, 16)
> +#define DRM_ARGB64_RED(c)		DRM_ARGB64_RED_LSB(c, 16)
> +#define DRM_ARGB64_GREEN(c)		DRM_ARGB64_GREEN_LSB(c, 16)
> +#define DRM_ARGB64_BLUE(c)		DRM_ARGB64_BLUE_LSB(c, 16)
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> 
> -- 
> 2.51.0

-- 
Ville Syrjälä
Intel

Re: [PATCH 0/2] Introduce BACKGROUND_COLOR DRM CRTC property

[Cristian Ciocaltea]

Hi Raphael,

On 9/2/25 4:19 PM, Raphael Gallais-Pou wrote:
> 
> 
> On 9/2/25 11:27, Cristian Ciocaltea wrote:
>> Some display controllers can be hardware-configured to present non-black
>> colors for pixels which are not covered by any plane (or are exposed
>> through transparent regions of higher planes).
>>
>> The first patch of the series introduces the BACKGROUND_COLOR DRM
>> property that can be attached to a CRTC via a dedicated helper function.
>> A 64-bit ARGB color value format is also defined and can be manipulated
>> with the help of a few utility macros.
> 
> Hi Cristian,
> 
> Thanks for this work ! :)
> 
> FWIW I sent a series also based on Matt's work four years ago:
> https://lore.kernel.org/dri-devel/20210707084557.22443-2-raphael.gallais-pou@foss.st.com/
> 
> IIRC at the time there was some questions around the pixel format used for the
> property, and non-opaque color vs alpha pre-multiplication.
> Mind that on STM32MP platforms alpha channel for the background color is not
> supported.
> 
> Hope the thread can bring some insights.

Thanks for pointing this out, I will consider it for v2.

Regards,
Cristian

Re: [PATCH 1/2] drm: Add CRTC background color property

[Cristian Ciocaltea]

On 9/2/25 4:36 PM, Ville Syrjälä wrote:
> On Tue, Sep 02, 2025 at 12:27:56PM +0300, Cristian Ciocaltea wrote:
>> Some display controllers can be hardware programmed to show non-black
>> colors for pixels that are either not covered by any plane or are
>> exposed through transparent regions of higher planes.  This feature can
>> help reduce memory bandwidth usage, e.g. in compositors managing a UI
>> with a solid background color while using smaller planes to render the
>> remaining content.
>>
>> To support this capability, introduce the BACKGROUND_COLOR standard DRM
>> mode property, which can be attached to a CRTC through the
>> drm_crtc_attach_background_color_property() helper function.
>>
>> Additionally, define a 64-bit ARGB format value to be built with the
>> help of a dedicated drm_argb64() utility macro.  Individual color
>> components can be extracted with desired precision using the
>> corresponding DRM_ARGB64_*() macros.
>>
>> Co-developed-by: Matt Roper <matthew.d.roper@intel.com>
>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>>  drivers/gpu/drm/drm_atomic_uapi.c         |  4 ++++
>>  drivers/gpu/drm/drm_blend.c               | 37 +++++++++++++++++++++++++++----
>>  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
>>  include/drm/drm_blend.h                   |  4 +++-
>>  include/drm/drm_crtc.h                    | 12 ++++++++++
>>  include/drm/drm_mode_config.h             |  5 +++++
>>  include/uapi/drm/drm_mode.h               | 30 +++++++++++++++++++++++++
>>  8 files changed, 94 insertions(+), 5 deletions(-)

[...]

>> +/*
>> + * Put 16-bit ARGB values into a standard 64-bit representation that
>> + * can be used for ioctl parameters, inter-driver communication, etc.
>> + */
>> +static inline __u64
>> +drm_argb64(__u16 alpha, __u16 red, __u16 green, __u16 blue)
>> +{
>> +	return (__u64)alpha << 48 | (__u64)red << 32 | (__u64)green << 16 | blue;
>> +}
>> +
>> +/*
>> + * Extract the specified number of least-significant bits of a specific
>> + * color component from a standard 64-bit ARGB value.
> 
> Why would you ever want the least significant bits?

Right, that's useless - will replace with proper helpers dealing with custom
precision.

Thanks,
Cristian

>> + */
>> +#define DRM_ARGB64_COMP(c, shift, numlsb) \
>> +	((__u16)(((c) >> (shift)) & ((1UL << (numlsb) % 17) - 1)))
>> +#define DRM_ARGB64_ALPHA_LSB(c, numlsb) DRM_ARGB64_COMP(c, 48, numlsb)
>> +#define DRM_ARGB64_RED_LSB(c, numlsb)   DRM_ARGB64_COMP(c, 32, numlsb)
>> +#define DRM_ARGB64_GREEN_LSB(c, numlsb) DRM_ARGB64_COMP(c, 16, numlsb)
>> +#define DRM_ARGB64_BLUE_LSB(c, numlsb)  DRM_ARGB64_COMP(c, 0, numlsb)
>> +
>> +/*
>> + * Convenience wrappers to extract all 16 bits of a specific color
>> + * component from a standard 64-bit ARGB value.
>> + */
>> +#define DRM_ARGB64_ALPHA(c)		DRM_ARGB64_ALPHA_LSB(c, 16)
>> +#define DRM_ARGB64_RED(c)		DRM_ARGB64_RED_LSB(c, 16)
>> +#define DRM_ARGB64_GREEN(c)		DRM_ARGB64_GREEN_LSB(c, 16)
>> +#define DRM_ARGB64_BLUE(c)		DRM_ARGB64_BLUE_LSB(c, 16)
>> +
>>  #if defined(__cplusplus)
>>  }
>>  #endif
>>
>> -- 
>> 2.51.0
>