[PATCH v3 0/3] CRTC background color

[PATCH v3 0/3] CRTC background color

[Matt Roper]

Third version of the series previously posted here:
  https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.html

This version incorporates review feedback from Ville and Sean Paul.

The first patch here can be merged whenever it receives review approval.
The second and third patches still need to wait for opensource userspace
to be ready before merging (there's ChromeOS work underway).

Cc: dri-devel@lists.freedesktop.org
Cc: Wei C Li <wei.c.li@intel.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>

Matt Roper (3):
  drm/i915: Force background color to black for gen9+ (v2)
  drm: Add CRTC background color property (v2)
  drm/i915/gen9+: Add support for pipe background color (v3)

 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
 drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
 drivers/gpu/drm/drm_mode_config.c         |  6 +++++
 drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
 drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
 drivers/gpu/drm/i915/intel_display.c      | 40 +++++++++++++++++++++++++++++++
 include/drm/drm_blend.h                   |  1 +
 include/drm/drm_crtc.h                    | 17 +++++++++++++
 include/drm/drm_mode_config.h             |  5 ++++
 include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++
 11 files changed, 136 insertions(+), 3 deletions(-)

-- 
2.14.4

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

[PATCH v3 1/3] drm/i915: Force background color to black for gen9+ (v2)

[Matt Roper]

We don't yet allow userspace to control the CRTC background color, but
we should manually program the color to black to ensure the BIOS didn't
leave us with some other color.  We should also set the pipe gamma and
pipe CSC bits so that the background color goes through the same color
management transformations that a plane with black pixels would.

v2: Rename register to SKL_BOTTOM_COLOR to more closely follow
    bspec naming.  (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h      |  6 ++++++
 drivers/gpu/drm/i915/intel_display.c | 19 +++++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 94ba86018a4f..7cfae3425bc2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5663,6 +5663,12 @@ enum {
 #define   PIPEMISC_DITHER_TYPE_SP	(0 << 2)
 #define PIPEMISC(pipe)			_MMIO_PIPE2(pipe, _PIPE_MISC_A)
 
+/* Skylake+ pipe bottom (background) color */
+#define _SKL_BOTTOM_COLOR_A		0x70034
+#define   SKL_BOTTOM_COLOR_GAMMA_ENABLE	(1 << 31)
+#define   SKL_BOTTOM_COLOR_CSC_ENABLE	(1 << 30)
+#define SKL_BOTTOM_COLOR(pipe)		_MMIO_PIPE2(pipe, _SKL_BOTTOM_COLOR_A)
+
 #define VLV_DPFLIPSTAT				_MMIO(VLV_DISPLAY_BASE + 0x70028)
 #define   PIPEB_LINE_COMPARE_INT_EN		(1 << 29)
 #define   PIPEB_HLINE_INT_EN			(1 << 28)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 132e978227fb..7fe11f9a0dbe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3868,6 +3868,16 @@ static void intel_update_pipe_config(const struct intel_crtc_state *old_crtc_sta
 		else if (old_crtc_state->pch_pfit.enabled)
 			ironlake_pfit_disable(old_crtc_state);
 	}
+
+	/*
+	 * We don't (yet) allow userspace to control the pipe background color,
+	 * so force it to black, but apply pipe gamma and CSC so that its
+	 * handling will match how we program our planes.
+	 */
+	if (INTEL_GEN(dev_priv) >= 9)
+		I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
+			   SKL_BOTTOM_COLOR_GAMMA_ENABLE |
+			   SKL_BOTTOM_COLOR_CSC_ENABLE);
 }
 
 static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -15356,6 +15366,15 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
 			    plane->base.type != DRM_PLANE_TYPE_PRIMARY)
 				intel_plane_disable_noatomic(crtc, plane);
 		}
+
+		/*
+		 * Disable any background color set by the BIOS, but enable the
+		 * gamma and CSC to match how we program our planes.
+		 */
+		if (INTEL_GEN(dev_priv) >= 9)
+			I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
+				   SKL_BOTTOM_COLOR_GAMMA_ENABLE |
+				   SKL_BOTTOM_COLOR_CSC_ENABLE);
 	}
 
 	/* Adjust the state of the output pipe according to whether we
-- 
2.14.4

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

[PATCH v3 2/3] drm: Add CRTC background color property (v2)

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

v2:
 - Swap internal representation's blue and red bits to make it easier
   to read if printed out.  (Ville)
 - Document bgcolor property in drm_blend.c.  (Sean Paul)
 - s/background_color/bgcolor/ for consistency between property name and
   value storage field.  (Sean Paul)
 - Add a convenience function to attach property to a given crtc.

v3:
 - Restructure ARGB component extraction macros to be easier to
   understand and enclose the parameters in () to avoid problems if
   expressions are passed.  (Sean Paul)
 - s/rgba/argb/ in helper function/macro names.  Even though the idea is
   to not worry about the internal representation of the u64, it can
   still be confusing to look at code that uses 'rgba' terminology, but
   stores values with argb ordering.  (Ville)

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c.li@intel.com
Cc: harish.krupo.kps@intel.com
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Sean Paul <sean@poorly.run>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by(v2): Sean Paul <sean@poorly.run>
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c         |  5 +++++
 drivers/gpu/drm/drm_blend.c               | 21 ++++++++++++++++++---
 drivers/gpu/drm/drm_mode_config.c         |  6 ++++++
 include/drm/drm_blend.h                   |  1 +
 include/drm/drm_crtc.h                    | 17 +++++++++++++++++
 include/drm/drm_mode_config.h             |  5 +++++
 include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++++++++
 8 files changed, 81 insertions(+), 3 deletions(-)

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 86ac33922b09..b95a55a778e2 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->bgcolor = 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->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 0c78ca386cbe..7da28c0cb74d 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,16 @@
  *		 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).
+ * The property extensions described above all apply to the plane.  Drivers
+ * may also expose the following crtc property extension:
+ *
+ * bgcolor:
+ *	Background color is setup with drm_crtc_add_bgcolor_property().  It
+ *	controls the RGB color of a full-screen, fully-opaque 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.
  */
 
 /**
@@ -593,3 +600,11 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 	return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
+
+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 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_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 b21437bc95bf..8f13d485df60 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;
 
+	/**
+	 * @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 5dbeabdbaf91..f31ce517c70d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -813,6 +813,11 @@ struct drm_mode_config {
 	 */
 	struct drm_property *writeback_out_fence_ptr_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 d3e0fe31efc5..47088cae69e7 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -888,6 +888,34 @@ struct drm_mode_revoke_lease {
 	__u32 lessee_id;
 };
 
+/*
+ * 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.14.4

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

[PATCH v3 2/3] drm: Add CRTC background color property (v3)

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

v2:
 - Swap internal representation's blue and red bits to make it easier
   to read if printed out.  (Ville)
 - Document bgcolor property in drm_blend.c.  (Sean Paul)
 - s/background_color/bgcolor/ for consistency between property name and
   value storage field.  (Sean Paul)
 - Add a convenience function to attach property to a given crtc.

v3:
 - Restructure ARGB component extraction macros to be easier to
   understand and enclose the parameters in () to avoid calculations
   if expressions are passed.  (Sean Paul)
 - s/rgba/argb/ in helper function/macro names.  Even though the idea is
   to not worry about the internal representation of the u64, it can
   still be confusing to look at code that uses 'rgba' terminology, but
   stores values with argb ordering.  (Ville)

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c.li@intel.com
Cc: harish.krupo.kps@intel.com
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Sean Paul <sean@poorly.run>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by(v2): Sean Paul <sean@poorly.run>
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c         |  5 +++++
 drivers/gpu/drm/drm_blend.c               | 21 ++++++++++++++++++---
 drivers/gpu/drm/drm_mode_config.c         |  6 ++++++
 include/drm/drm_blend.h                   |  1 +
 include/drm/drm_crtc.h                    | 17 +++++++++++++++++
 include/drm/drm_mode_config.h             |  5 +++++
 include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++++++++
 8 files changed, 81 insertions(+), 3 deletions(-)

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 86ac33922b09..b95a55a778e2 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->bgcolor = 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->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 0c78ca386cbe..7da28c0cb74d 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,16 @@
  *		 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).
+ * The property extensions described above all apply to the plane.  Drivers
+ * may also expose the following crtc property extension:
+ *
+ * bgcolor:
+ *	Background color is setup with drm_crtc_add_bgcolor_property().  It
+ *	controls the RGB color of a full-screen, fully-opaque 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.
  */
 
 /**
@@ -593,3 +600,11 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
 	return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
+
+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 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_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 b21437bc95bf..8f13d485df60 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;
 
+	/**
+	 * @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 5dbeabdbaf91..f31ce517c70d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -813,6 +813,11 @@ struct drm_mode_config {
 	 */
 	struct drm_property *writeback_out_fence_ptr_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 d3e0fe31efc5..47088cae69e7 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -888,6 +888,34 @@ struct drm_mode_revoke_lease {
 	__u32 lessee_id;
 };
 
+/*
+ * 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.14.4

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

Re: [Intel-gfx] [PATCH v3 2/3] drm: Add CRTC background color property (v3)

[Brian Starkey]

Hi Matt,

On Thu, Nov 15, 2018 at 02:13:45PM -0800, 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.
>
>v2:
> - Swap internal representation's blue and red bits to make it easier
>   to read if printed out.  (Ville)
> - Document bgcolor property in drm_blend.c.  (Sean Paul)
> - s/background_color/bgcolor/ for consistency between property name and
>   value storage field.  (Sean Paul)
> - Add a convenience function to attach property to a given crtc.
>
>v3:
> - Restructure ARGB component extraction macros to be easier to
>   understand and enclose the parameters in () to avoid calculations
>   if expressions are passed.  (Sean Paul)
> - s/rgba/argb/ in helper function/macro names.  Even though the idea is
>   to not worry about the internal representation of the u64, it can
>   still be confusing to look at code that uses 'rgba' terminology, but
>   stores values with argb ordering.  (Ville)
>
>Cc: dri-devel@lists.freedesktop.org
>Cc: wei.c.li@intel.com
>Cc: harish.krupo.kps@intel.com
>Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>Cc: Sean Paul <sean@poorly.run>
>Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>Reviewed-by(v2): Sean Paul <sean@poorly.run>
>---
> drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> drivers/gpu/drm/drm_atomic_uapi.c         |  5 +++++
> drivers/gpu/drm/drm_blend.c               | 21 ++++++++++++++++++---
> drivers/gpu/drm/drm_mode_config.c         |  6 ++++++
> include/drm/drm_blend.h                   |  1 +
> include/drm/drm_crtc.h                    | 17 +++++++++++++++++
> include/drm/drm_mode_config.h             |  5 +++++
> include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++++++++
> 8 files changed, 81 insertions(+), 3 deletions(-)
>
>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 86ac33922b09..b95a55a778e2 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->bgcolor = 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->bgcolor;

The docs say it's always opaque - so perhaps override alpha to all
'1's here, or reject values which aren't opaque?

> 	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 0c78ca386cbe..7da28c0cb74d 100644
>--- a/drivers/gpu/drm/drm_blend.c
>+++ b/drivers/gpu/drm/drm_blend.c
>@@ -175,9 +175,16 @@
>  *		 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).
>+ * The property extensions described above all apply to the plane.  Drivers
>+ * may also expose the following crtc property extension:
>+ *
>+ * bgcolor:

That should be "BACKGROUND_COLOR" shouldn't it?

>+ *	Background color is setup with drm_crtc_add_bgcolor_property().  It
>+ *	controls the RGB color of a full-screen, fully-opaque 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.

Might be worth explicitly mentioning that this value is used as-is,
without any gamma/gamut conversion before blending, i.e. it's assumed
to already be in whatever blend-space the CRTC is using (at least I
assume that's the case?). As we start making the color pipe more
complicated/explicit, the details matter more.

>  */
>
> /**
>@@ -593,3 +600,11 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane,
> 	return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
>+
>+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 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_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 b21437bc95bf..8f13d485df60 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;

On the back of Ville's comment on v2, I think I'd rather have these
flags being the exception rather than the norm. I mean, I think
color_mgmt_changed can be worthwhile, because an update might be
expensive - however changing the bg color I'd expect to be ~1 register
write on most hardware, so the flag hardly seems worth it. Happy to
hear different opinions though.

>
> 	/**
> 	 * @no_vblank:
>@@ -274,6 +279,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 5dbeabdbaf91..f31ce517c70d 100644
>--- a/include/drm/drm_mode_config.h
>+++ b/include/drm/drm_mode_config.h
>@@ -813,6 +813,11 @@ struct drm_mode_config {
> 	 */
> 	struct drm_property *writeback_out_fence_ptr_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 d3e0fe31efc5..47088cae69e7 100644
>--- a/include/uapi/drm/drm_mode.h
>+++ b/include/uapi/drm/drm_mode.h
>@@ -888,6 +888,34 @@ struct drm_mode_revoke_lease {
> 	__u32 lessee_id;
> };
>
>+/*
>+ * 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.
>+ */

It's a bit of a future problem - but I wonder if we shouldn't have a
bit more "future-proof" representation here. scRGB and extended-range
sRGB are things, which allow values outside the range 0-1.

I'm also thinking of Android where the layer solid color values in
HWComposer got changed from 8-bit uints to floats in 'P'. If we could
just have one color representation in the kernel API that might be
nice.

Thanks,
-Brian

>+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.14.4
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: Add CRTC background color property (v3)

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 3153 bytes --]

Brian Starkey <Brian.Starkey@arm.com> writes:

> Hi Matt,
>
> On Thu, Nov 15, 2018 at 02:13:45PM -0800, 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.
>>
>>v2:
>> - Swap internal representation's blue and red bits to make it easier
>>   to read if printed out.  (Ville)
>> - Document bgcolor property in drm_blend.c.  (Sean Paul)
>> - s/background_color/bgcolor/ for consistency between property name and
>>   value storage field.  (Sean Paul)
>> - Add a convenience function to attach property to a given crtc.
>>
>>v3:
>> - Restructure ARGB component extraction macros to be easier to
>>   understand and enclose the parameters in () to avoid calculations
>>   if expressions are passed.  (Sean Paul)
>> - s/rgba/argb/ in helper function/macro names.  Even though the idea is
>>   to not worry about the internal representation of the u64, it can
>>   still be confusing to look at code that uses 'rgba' terminology, but
>>   stores values with argb ordering.  (Ville)
>>
>>Cc: dri-devel@lists.freedesktop.org
>>Cc: wei.c.li@intel.com
>>Cc: harish.krupo.kps@intel.com
>>Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>Cc: Sean Paul <sean@poorly.run>
>>Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>Reviewed-by(v2): Sean Paul <sean@poorly.run>
>>---

>
>>+ *	Background color is setup with drm_crtc_add_bgcolor_property().  It
>>+ *	controls the RGB color of a full-screen, fully-opaque 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.
>
> Might be worth explicitly mentioning that this value is used as-is,
> without any gamma/gamut conversion before blending, i.e. it's assumed
> to already be in whatever blend-space the CRTC is using (at least I
> assume that's the case?). As we start making the color pipe more
> complicated/explicit, the details matter more.

Raspberry Pi should be able to do background color as well, but the
question of where this property is in the pipeline (particularly for CTM
and gamma) also came up for me.  My background color would apply at the
same stage as plane composition, so before gamma and CTM.

FWIW, my background color on the writeback connector (the only one where
the value would be relevant) can have alpha.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

[PATCH v3 3/3] drm/i915/gen9+: Add support for pipe background color (v3)

[Matt Roper]

Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes.  Let's expose this for use by
compositors.

v2:
 - Split out bgcolor sanitization and programming of csc/gamma bits to a
   separate patch that we can land before the ABI changes are ready to
   go in.  (Ville)
 - Change a temporary variable name to be more consistent with
   other similar functions.  (Ville)
 - Change register name to SKL_CANVAS for consistency with the
   CHV_CANVAS register.

v3:
 - Switch register name back to SKL_BOTTOM_COLOR.  (Ville)
 - Use non-_FW register write.  (Ville)
 - Minor parameter rename for consistency.  (Ville)

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c.li@intel.com
Cc: harish.krupo.kps@intel.com
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  9 +++++++++
 drivers/gpu/drm/i915/intel_display.c | 37 ++++++++++++++++++++++++++++--------
 2 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 670db5073d70..05465f06e132 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3254,6 +3254,15 @@ static int i915_display_info(struct seq_file *m, void *unused)
 			intel_plane_info(m, crtc);
 		}
 
+		if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+			uint64_t background = pipe_config->base.bgcolor;
+
+			seq_printf(m, "\tbackground color (10bpc): r=%x g=%x b=%x\n",
+				   DRM_ARGB_RED(background, 10),
+				   DRM_ARGB_GREEN(background, 10),
+				   DRM_ARGB_BLUE(background, 10));
+		}
+
 		seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
 			   yesno(!crtc->cpu_fifo_underrun_disabled),
 			   yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 7fe11f9a0dbe..6763ad52d53e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3834,6 +3834,28 @@ void intel_finish_reset(struct drm_i915_private *dev_priv)
 	clear_bit(I915_RESET_MODESET, &dev_priv->gpu_error.flags);
 }
 
+static void
+skl_update_background_color(const struct intel_crtc_state *crtc_state)
+{
+	struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+	uint64_t propval = crtc_state->base.bgcolor;
+	uint32_t tmp;
+
+	/* Hardware is programmed with 10 bits of precision */
+	tmp = DRM_ARGB_RED(propval, 10) << 20
+	    | DRM_ARGB_GREEN(propval, 10) << 10
+	    | DRM_ARGB_BLUE(propval, 10);
+
+	/*
+	 * Set CSC and gamma for bottom color to ensure background pixels
+	 * receive the same color transformations as plane content.
+	 */
+	tmp |= SKL_BOTTOM_COLOR_CSC_ENABLE | SKL_BOTTOM_COLOR_GAMMA_ENABLE;
+
+	I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), tmp);
+}
+
 static void intel_update_pipe_config(const struct intel_crtc_state *old_crtc_state,
 				     const struct intel_crtc_state *new_crtc_state)
 {
@@ -3869,15 +3891,8 @@ static void intel_update_pipe_config(const struct intel_crtc_state *old_crtc_sta
 			ironlake_pfit_disable(old_crtc_state);
 	}
 
-	/*
-	 * We don't (yet) allow userspace to control the pipe background color,
-	 * so force it to black, but apply pipe gamma and CSC so that its
-	 * handling will match how we program our planes.
-	 */
 	if (INTEL_GEN(dev_priv) >= 9)
-		I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
-			   SKL_BOTTOM_COLOR_GAMMA_ENABLE |
-			   SKL_BOTTOM_COLOR_CSC_ENABLE);
+		skl_update_background_color(new_crtc_state);
 }
 
 static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -10897,6 +10912,9 @@ static int intel_crtc_atomic_check(struct drm_crtc *crtc,
 		crtc_state->planes_changed = true;
 	}
 
+	if (crtc_state->bgcolor_changed)
+		pipe_config->update_pipe = true;
+
 	ret = 0;
 	if (dev_priv->display.compute_pipe_wm) {
 		ret = dev_priv->display.compute_pipe_wm(pipe_config);
@@ -14036,6 +14054,9 @@ static int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe)
 
 	WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
 
+	if (INTEL_GEN(dev_priv) >= 9)
+		drm_crtc_add_bgcolor_property(&intel_crtc->base);
+
 	return 0;
 
 fail:
-- 
2.14.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH i-g-t v3] tests/kms_crtc_background_color: overhaul for latest ABI proposal (v3)

[Matt Roper]

CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them.  However the
corresponding IGT test did get merged and has basically been dead code
ever since.

A couple years later we may finally be getting closer to landing the
kernel patches (there's some interest in this functionality now from
both the ChromeOS and Weston camps), so lets update the IGT test to
match the latest proposed ABI, and to remove some of the cruft from the
original test that wouldn't actually work.

It's worth noting that we don't seem to be able to test this feature
with CRC's.  Originally we wanted to draw a color into a plane's FB
(with Cairo) and then compare the CRC to turning off all planes and just
setting the CRTC background to the same color.  However the precision
and rounding of the color components causes the CRC's to come out
differently, even though the end result is visually identical.  So at
the moment this test is mainly useful for visual inspection in
interactive mode.

v2:
 - Swap red and blue ordering in property value to reflect change
   in v2 of kernel series.

v3:
 - Minor updates to proposed uapi helpers (s/rgba/argb/).

Cc: igt-dev@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 lib/igt_kms.c                     |   2 +-
 tests/kms_crtc_background_color.c | 223 +++++++++++++++++++++-----------------
 2 files changed, 122 insertions(+), 103 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index d806ccc1..33d6a6fb 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -180,7 +180,7 @@ const char * const igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
 };
 
 const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
-	[IGT_CRTC_BACKGROUND] = "background_color",
+	[IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
 	[IGT_CRTC_CTM] = "CTM",
 	[IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
 	[IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
diff --git a/tests/kms_crtc_background_color.c b/tests/kms_crtc_background_color.c
index 3df3401f..a9d99864 100644
--- a/tests/kms_crtc_background_color.c
+++ b/tests/kms_crtc_background_color.c
@@ -25,164 +25,183 @@
 #include "igt.h"
 #include <math.h>
 
-
 IGT_TEST_DESCRIPTION("Test crtc background color feature");
 
+/*
+ * The original idea was to paint a desired color into a full-screen primary
+ * plane and then compare that CRC with turning off all planes and setting the
+ * CRTC background to the same color.  Unforunately, the rounding and precision
+ * of color values as rendered by cairo vs created by the display controller
+ * are slightly different and give different CRC's, even though they're
+ * visually identical.
+ *
+ * Since we can't really use CRC's for testing, this test is mainly useful for
+ * visual inspection in interactive mode at the moment.
+ */
+
 typedef struct {
 	int gfx_fd;
-	igt_display_t display;
-	struct igt_fb fb;
-	igt_crc_t ref_crc;
-	igt_pipe_crc_t *pipe_crc;
+	igt_output_t *output;
+	drmModeModeInfo *mode;
 } data_t;
 
-#define BLACK      0x000000           /* BGR 8bpc */
-#define CYAN       0xFFFF00           /* BGR 8bpc */
-#define PURPLE     0xFF00FF           /* BGR 8bpc */
-#define WHITE      0xFFFFFF           /* BGR 8bpc */
-
-#define BLACK64    0x000000000000     /* BGR 16bpc */
-#define CYAN64     0xFFFFFFFF0000     /* BGR 16bpc */
-#define PURPLE64   0xFFFF0000FFFF     /* BGR 16bpc */
-#define YELLOW64   0x0000FFFFFFFF     /* BGR 16bpc */
-#define WHITE64    0xFFFFFFFFFFFF     /* BGR 16bpc */
-#define RED64      0x00000000FFFF     /* BGR 16bpc */
-#define GREEN64    0x0000FFFF0000     /* BGR 16bpc */
-#define BLUE64     0xFFFF00000000     /* BGR 16bpc */
+/*
+ * Local copy of proposed kernel uapi
+ */
+static inline __u64
+local_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;
+}
+#define LOCAL_ARGB_COMP(c, shift, numbits) \
+       (__u16)(((c) & 0xFFFFull << (shift)) >> ((shift) + 16 - (numbits)))
+#define LOCAL_ARGB_BLUE(c, numbits)  DRM_ARGB_COMP(c, 0, numbits)
+#define LOCAL_ARGB_GREEN(c, numbits) DRM_ARGB_COMP(c, 16, numbits)
+#define LOCAL_ARGB_RED(c, numbits)   DRM_ARGB_COMP(c, 32, numbits)
+#define LOCAL_ARGB_ALPHA(c, numbits) DRM_ARGB_COMP(c, 48, numbits)
+
+
+/* 8bpc values */
+#define BLACK      local_argb(8, 0xff,    0,    0,    0)
+#define RED        local_argb(8, 0xff, 0xff,    0,    0)
+#define GREEN      local_argb(8, 0xff,    0, 0xff,    0)
+#define BLUE       local_argb(8, 0xff,    0,    0, 0xff)
+#define YELLOW     local_argb(8, 0xff, 0xff, 0xff,    0)
+#define WHITE      local_argb(8, 0xff, 0xff, 0xff, 0xff)
+
+/* 16bpc values */
+#define BLACK64    local_argb(16, 0xffff,      0,      0,      0)
+#define RED64      local_argb(16, 0xffff, 0xffff,      0,      0)
+#define GREEN64    local_argb(16, 0xffff,      0, 0xffff,      0)
+#define BLUE64     local_argb(16, 0xffff,      0,      0, 0xffff)
+#define YELLOW64   local_argb(16, 0xffff, 0xffff, 0xffff,      0)
+#define WHITE64    local_argb(16, 0xffff, 0xffff, 0xffff, 0xffff)
+
+#if 0
 static void
-paint_background(data_t *data, struct igt_fb *fb, drmModeModeInfo *mode,
-		uint32_t background, double alpha)
+paint_fb(data_t *data, struct igt_fb *fb, drmModeModeInfo *mode,
+	 uint64_t color, int prec)
 {
 	cairo_t *cr;
-	int w, h;
+	int w = mode->hdisplay;
+	int h = mode->vdisplay;
 	double r, g, b;
 
-	w = mode->hdisplay;
-	h = mode->vdisplay;
+	igt_create_fb(data->gfx_fd, w, h, DRM_FORMAT_XRGB8888,
+		      LOCAL_DRM_FORMAT_MOD_NONE, fb);
 
-	cr = igt_get_cairo_ctx(data->gfx_fd, &data->fb);
+	cr = igt_get_cairo_ctx(data->gfx_fd, fb);
 
-	/* Paint with background color */
-	r = (double) (background & 0xFF) / 255.0;
-	g = (double) ((background & 0xFF00) >> 8) / 255.0;
-	b = (double) ((background & 0xFF0000) >> 16) / 255.0;
-	igt_paint_color_alpha(cr, 0, 0, w, h, r, g, b, alpha);
+	/*
+	 * Grab color (with appropriate bits of precision) and paint a
+	 * framebuffer with it.
+	 */
+	r = (double)LOCAL_ARGB_RED(color, prec) / ((1<<prec) - 1);
+	g = (double)LOCAL_ARGB_GREEN(color, prec) / ((1<<prec) - 1);
+	b = (double)LOCAL_ARGB_BLUE(color, prec) / ((1<<prec) - 1);
+	igt_paint_color_alpha(cr, 0, 0, w, h, r, g, b, 1.0);
 
-	igt_put_cairo_ctx(data->gfx_fd, &data->fb, cr);
+	igt_put_cairo_ctx(data->gfx_fd, fb, cr);
 }
+#endif
 
-static void prepare_crtc(data_t *data, igt_output_t *output, enum pipe pipe,
-			igt_plane_t *plane, int opaque_buffer, int plane_color,
-			uint64_t pipe_background_color)
+static void prepare_crtc(igt_display_t *display, data_t *data,
+			 igt_output_t *output, enum pipe pipe)
 {
-	drmModeModeInfo *mode;
-	igt_display_t *display = &data->display;
-	int fb_id;
-	double alpha;
-
 	igt_output_set_pipe(output, pipe);
-
-	/* create the pipe_crc object for this pipe */
-	igt_pipe_crc_free(data->pipe_crc);
-	data->pipe_crc = igt_pipe_crc_new(data->gfx_fd, pipe, INTEL_PIPE_CRC_SOURCE_AUTO);
-
-	mode = igt_output_get_mode(output);
-
-	fb_id = igt_create_fb(data->gfx_fd,
-			mode->hdisplay, mode->vdisplay,
-			DRM_FORMAT_XRGB8888,
-			LOCAL_DRM_FORMAT_MOD_NONE, /* tiled */
-			&data->fb);
-	igt_assert(fb_id);
-
-	/* To make FB pixel win with background color, set alpha as full opaque */
-	igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, pipe_background_color);
-	if (opaque_buffer)
-		alpha = 1.0;    /* alpha 1 is fully opque */
-	else
-		alpha = 0.0;    /* alpha 0 is fully transparent */
-	paint_background(data, &data->fb, mode, plane_color, alpha);
-
-	igt_plane_set_fb(plane, &data->fb);
-	igt_display_commit2(display, COMMIT_UNIVERSAL);
+	igt_display_commit2(display, COMMIT_ATOMIC);
+	data->output = output;
+	data->mode = igt_output_get_mode(output);
 }
 
-static void cleanup_crtc(data_t *data, igt_output_t *output, igt_plane_t *plane)
+static void cleanup_crtc(igt_display_t *display, data_t *data,
+			 igt_output_t *output)
 {
-	igt_display_t *display = &data->display;
-
-	igt_pipe_crc_free(data->pipe_crc);
-	data->pipe_crc = NULL;
-
-	igt_remove_fb(data->gfx_fd, &data->fb);
-
-	igt_pipe_obj_set_prop_value(plane->pipe, IGT_CRTC_BACKGROUND, BLACK64);
-	igt_plane_set_fb(plane, NULL);
 	igt_output_set_pipe(output, PIPE_ANY);
-
-	igt_display_commit2(display, COMMIT_UNIVERSAL);
+	igt_display_commit2(display, COMMIT_ATOMIC);
 }
 
-static void test_crtc_background(data_t *data)
+static void test_crtc_background(igt_display_t *display, data_t *data)
 {
-	igt_display_t *display = &data->display;
 	igt_output_t *output;
 	enum pipe pipe;
 	int valid_tests = 0;
 
-	for_each_pipe_with_valid_output(display, pipe, output) {
+	for_each_pipe_with_single_output(display, pipe, output) {
 		igt_plane_t *plane;
 
-		igt_output_set_pipe(output, pipe);
-
-		plane = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
 		igt_require(igt_pipe_has_prop(display, pipe, IGT_CRTC_BACKGROUND));
 
-		prepare_crtc(data, output, pipe, plane, 1, PURPLE, BLACK64);
+		prepare_crtc(display, data, output, pipe);
+		plane = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
 
-		/* Now set background without using a plane, i.e.,
-		 * Disable the plane to let hw background color win blend. */
+		/*
+		 * Turn off the primary plane (default bgcolor should be black
+		 * unless a previous drm master changed it to something else).
+		 */
 		igt_plane_set_fb(plane, NULL);
-		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, PURPLE64);
-		igt_display_commit2(display, COMMIT_UNIVERSAL);
-
-		/* Try few other background colors */
-		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, CYAN64);
-		igt_display_commit2(display, COMMIT_UNIVERSAL);
-
-		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, YELLOW64);
-		igt_display_commit2(display, COMMIT_UNIVERSAL);
-
+		igt_display_commit2(display, COMMIT_ATOMIC);
+
+		/* Explicitly set black as bg color */
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, BLACK64);
+		igt_display_commit2(display, COMMIT_ATOMIC);
+
+		/*
+		 * Test several more colors and precisions.  Unfortunately the
+		 * CRC's won't match between a cairo-drawn fb and a display
+		 * controller bgcolor setting, but these can at least be
+		 * visually verified in interactive mode to ensure the colors
+		 * look good.
+		 */
 		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, RED64);
-		igt_display_commit2(display, COMMIT_UNIVERSAL);
+		igt_display_commit2(display, COMMIT_ATOMIC);
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, RED);
+		igt_display_commit2(display, COMMIT_ATOMIC);
 
 		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, GREEN64);
-		igt_display_commit2(display, COMMIT_UNIVERSAL);
+		igt_display_commit2(display, COMMIT_ATOMIC);
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, GREEN);
+		igt_display_commit2(display, COMMIT_ATOMIC);
 
 		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, BLUE64);
-		igt_display_commit2(display, COMMIT_UNIVERSAL);
+		igt_display_commit2(display, COMMIT_ATOMIC);
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, BLUE);
+		igt_display_commit2(display, COMMIT_ATOMIC);
+
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, YELLOW64);
+		igt_display_commit2(display, COMMIT_ATOMIC);
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, YELLOW);
+		igt_display_commit2(display, COMMIT_ATOMIC);
 
 		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, WHITE64);
-		igt_display_commit2(display, COMMIT_UNIVERSAL);
+		igt_display_commit2(display, COMMIT_ATOMIC);
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, WHITE);
+		igt_display_commit2(display, COMMIT_ATOMIC);
 
 		valid_tests++;
-		cleanup_crtc(data, output, plane);
+
+		igt_pipe_set_prop_value(display, pipe, IGT_CRTC_BACKGROUND, BLACK64);
+		cleanup_crtc(display, data, output);
 	}
 	igt_require_f(valid_tests, "no valid crtc/connector combinations found\n");
 }
 
 igt_simple_main
 {
+	igt_display_t display;
 	data_t data = {};
 
 	igt_skip_on_simulation();
 
 	data.gfx_fd = drm_open_driver(DRIVER_INTEL);
-	igt_require_pipe_crc(data.gfx_fd);
-	igt_display_require(&data.display, data.gfx_fd);
+	igt_display_require(&display, data.gfx_fd);
 
-	test_crtc_background(&data);
+	test_crtc_background(&display, &data);
 
-	igt_display_fini(&data.display);
+	igt_display_fini(&display);
 }
-- 
2.14.4

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

✗ Fi.CI.CHECKPATCH: warning for CRTC background color (rev3)

[Patchwork]

== Series Details ==

Series: CRTC background color (rev3)
URL   : https://patchwork.freedesktop.org/series/50834/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8424c4b432e2 drm/i915: Force background color to black for gen9+ (v2)
05fa1ef11dab drm: Add CRTC background color property (v2)
-:156: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield.  Prefer bool bitfields as unsigned int or u<8|16|32>
#156: FILE: include/drm/drm_crtc.h:175:
+	bool bgcolor_changed : 1;

-:224: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'shift' - possible side-effects?
#224: FILE: include/uapi/drm/drm_mode.h:912:
+#define DRM_ARGB_COMP(c, shift, numbits) \
+	(__u16)(((c) & 0xFFFFull << (shift)) >> ((shift) + 16 - (numbits)))

total: 0 errors, 1 warnings, 1 checks, 145 lines checked
8772f8932af9 drm/i915/gen9+: Add support for pipe background color (v3)

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

✓ Fi.CI.BAT: success for CRTC background color (rev3)

[Patchwork]

== Series Details ==

Series: CRTC background color (rev3)
URL   : https://patchwork.freedesktop.org/series/50834/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_5147 -> Patchwork_10834 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/50834/revisions/3/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_10834:

  === IGT changes ===

    ==== Possible regressions ====

    {igt@runner@aborted}:
      fi-cfl-8109u:       NOTRUN -> FAIL

    
== Known issues ==

  Here are the changes found in Patchwork_10834 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_selftest@live_hangcheck:
      fi-skl-6700k2:      PASS -> INCOMPLETE (fdo#108744)

    igt@kms_chamelium@common-hpd-after-suspend:
      fi-skl-6700k2:      PASS -> FAIL (fdo#103841)

    igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
      fi-byt-clapper:     PASS -> FAIL (fdo#103191, fdo#107362)

    
    ==== Possible fixes ====

    igt@gem_ctx_create@basic-files:
      fi-bsw-kefka:       FAIL (fdo#108656) -> PASS

    igt@kms_frontbuffer_tracking@basic:
      fi-hsw-peppy:       DMESG-WARN (fdo#102614) -> PASS

    igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
      fi-byt-clapper:     FAIL (fdo#103191, fdo#107362) -> PASS +2

    igt@pm_rpm@module-reload:
      fi-skl-6770hq:      DMESG-WARN (fdo#105541) -> PASS

    
    ==== Warnings ====

    igt@drv_selftest@live_contexts:
      fi-icl-u:           DMESG-FAIL (fdo#108569) -> INCOMPLETE (fdo#108315)

    
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#105541 https://bugs.freedesktop.org/show_bug.cgi?id=105541
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#108315 https://bugs.freedesktop.org/show_bug.cgi?id=108315
  fdo#108569 https://bugs.freedesktop.org/show_bug.cgi?id=108569
  fdo#108656 https://bugs.freedesktop.org/show_bug.cgi?id=108656
  fdo#108744 https://bugs.freedesktop.org/show_bug.cgi?id=108744


== Participating hosts (51 -> 44) ==

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-snb-2520m fi-ctg-p8600 


== Build changes ==

    * Linux: CI_DRM_5147 -> Patchwork_10834

  CI_DRM_5147: 7d2b7a6073309f870689b91fa4c4a30120ccbe00 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4715: 111593c49d812a4f4ff9ab0ef053a3ab88a6f73f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10834: 8772f8932af9341b06ac3082608e2629de3f4bef @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8772f8932af9 drm/i915/gen9+: Add support for pipe background color (v3)
05fa1ef11dab drm: Add CRTC background color property (v2)
8424c4b432e2 drm/i915: Force background color to black for gen9+ (v2)

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10834/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for CRTC background color (rev3)

[Patchwork]

== Series Details ==

Series: CRTC background color (rev3)
URL   : https://patchwork.freedesktop.org/series/50834/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_5147_full -> Patchwork_10834_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

  Here are the changes found in Patchwork_10834_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_suspend@shrink:
      shard-skl:          NOTRUN -> INCOMPLETE (fdo#106886)

    igt@drv_suspend@sysfs-reader:
      shard-skl:          PASS -> INCOMPLETE (fdo#104108)

    igt@gem_ppgtt@blt-vs-render-ctx0:
      shard-skl:          PASS -> TIMEOUT (fdo#108039)

    igt@kms_color@pipe-b-legacy-gamma:
      shard-apl:          PASS -> FAIL (fdo#104782)

    igt@kms_cursor_crc@cursor-64x21-sliding:
      shard-apl:          PASS -> FAIL (fdo#103232) +3

    igt@kms_cursor_crc@cursor-64x64-offscreen:
      shard-skl:          NOTRUN -> FAIL (fdo#103232)

    igt@kms_flip@flip-vs-expired-vblank:
      shard-kbl:          PASS -> FAIL (fdo#102887, fdo#105363)

    igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
      shard-skl:          NOTRUN -> FAIL (fdo#105683)

    igt@kms_plane@pixel-format-pipe-b-planes:
      shard-skl:          NOTRUN -> DMESG-WARN (fdo#106885)

    igt@kms_plane@pixel-format-pipe-c-planes:
      shard-apl:          PASS -> FAIL (fdo#103166)

    igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
      shard-skl:          NOTRUN -> FAIL (fdo#108145)

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)

    igt@perf_pmu@invalid-init:
      shard-glk:          PASS -> DMESG-WARN (fdo#105763, fdo#106538) +1

    
    ==== Possible fixes ====

    igt@gem_eio@in-flight-suspend:
      shard-kbl:          INCOMPLETE (fdo#106702, fdo#103665) -> PASS

    igt@gem_exec_nop@basic-series:
      shard-apl:          INCOMPLETE (fdo#103927) -> PASS

    igt@kms_busy@extended-pageflip-hang-newfb-render-c:
      shard-glk:          DMESG-WARN (fdo#107956) -> PASS

    igt@kms_chv_cursor_fail@pipe-a-128x128-top-edge:
      shard-apl:          DMESG-WARN (fdo#105602, fdo#103558) -> PASS +3

    igt@kms_color@pipe-b-degamma:
      shard-apl:          FAIL (fdo#104782) -> PASS

    igt@kms_cursor_crc@cursor-128x128-suspend:
      shard-apl:          FAIL (fdo#103232, fdo#103191) -> PASS

    igt@kms_cursor_crc@cursor-256x256-dpms:
      shard-apl:          FAIL (fdo#103232) -> PASS +3

    igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled:
      shard-skl:          FAIL (fdo#103184) -> PASS

    igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled:
      shard-skl:          FAIL (fdo#103232, fdo#103184) -> PASS

    igt@kms_fbcon_fbt@fbc-suspend:
      shard-skl:          INCOMPLETE (fdo#107773, fdo#104108) -> PASS

    igt@kms_flip@flip-vs-expired-vblank:
      shard-skl:          FAIL (fdo#105363) -> PASS

    igt@kms_flip_tiling@flip-to-x-tiled:
      shard-skl:          FAIL (fdo#108134) -> PASS

    igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
      shard-apl:          FAIL (fdo#103167) -> PASS

    igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary:
      shard-skl:          FAIL (fdo#105682) -> PASS

    igt@kms_plane@pixel-format-pipe-a-planes:
      shard-apl:          FAIL (fdo#103166) -> PASS

    igt@kms_plane@plane-position-covered-pipe-c-planes:
      shard-glk:          FAIL (fdo#103166) -> PASS

    igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
      shard-skl:          FAIL (fdo#107815, fdo#108145) -> PASS

    igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
      shard-skl:          FAIL (fdo#107815) -> PASS

    igt@kms_vblank@pipe-c-ts-continuation-suspend:
      shard-hsw:          FAIL (fdo#104894) -> PASS

    igt@pm_rpm@basic-rte:
      shard-skl:          INCOMPLETE (fdo#107807) -> PASS

    igt@pm_rpm@gem-execbuf-stress:
      shard-skl:          INCOMPLETE (fdo#107807, fdo#107803) -> PASS

    igt@pm_rpm@system-suspend-modeset:
      shard-skl:          INCOMPLETE (fdo#107807, fdo#104108) -> PASS

    
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
  fdo#104782 https://bugs.freedesktop.org/show_bug.cgi?id=104782
  fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105682 https://bugs.freedesktop.org/show_bug.cgi?id=105682
  fdo#105683 https://bugs.freedesktop.org/show_bug.cgi?id=105683
  fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
  fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
  fdo#106702 https://bugs.freedesktop.org/show_bug.cgi?id=106702
  fdo#106885 https://bugs.freedesktop.org/show_bug.cgi?id=106885
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773
  fdo#107803 https://bugs.freedesktop.org/show_bug.cgi?id=107803
  fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807
  fdo#107815 https://bugs.freedesktop.org/show_bug.cgi?id=107815
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#108039 https://bugs.freedesktop.org/show_bug.cgi?id=108039
  fdo#108134 https://bugs.freedesktop.org/show_bug.cgi?id=108134
  fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (7 -> 6) ==

  Missing    (1): shard-iclb 


== Build changes ==

    * Linux: CI_DRM_5147 -> Patchwork_10834

  CI_DRM_5147: 7d2b7a6073309f870689b91fa4c4a30120ccbe00 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4715: 111593c49d812a4f4ff9ab0ef053a3ab88a6f73f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10834: 8772f8932af9341b06ac3082608e2629de3f4bef @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10834/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

Hey,

Is there anything missing on the Chrome side to move forward with this series?

Stéphane

On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <matthew.d.roper@intel.com> wrote:
>
> Third version of the series previously posted here:
>   https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.html
>
> This version incorporates review feedback from Ville and Sean Paul.
>
> The first patch here can be merged whenever it receives review approval.
> The second and third patches still need to wait for opensource userspace
> to be ready before merging (there's ChromeOS work underway).
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Wei C Li <wei.c.li@intel.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Matt Roper (3):
>   drm/i915: Force background color to black for gen9+ (v2)
>   drm: Add CRTC background color property (v2)
>   drm/i915/gen9+: Add support for pipe background color (v3)
>
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
>  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
>  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
>  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
>  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
>  drivers/gpu/drm/i915/intel_display.c      | 40 +++++++++++++++++++++++++++++++
>  include/drm/drm_blend.h                   |  1 +
>  include/drm/drm_crtc.h                    | 17 +++++++++++++
>  include/drm/drm_mode_config.h             |  5 ++++
>  include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++
>  11 files changed, 136 insertions(+), 3 deletions(-)
>
> --
> 2.14.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] CRTC background color

[Li, Wei C]

Matt,

Is that possible for you to get some time to review https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 and confirm the FROMLIST change if it looks good to you so we could move forward?

BTW, I've backported your kernel patch into Chrome OS and verified it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook with KBL graphics. 

Thanks,
Wei

-----Original Message-----
From: Stéphane Marchesin [mailto:marcheu@chromium.org] 
Sent: Thursday, December 27, 2018 3:27 PM
To: Roper, Matthew D <matthew.d.roper@intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

Hey,

Is there anything missing on the Chrome side to move forward with this series?

Stéphane

On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <matthew.d.roper@intel.com> wrote:
>
> Third version of the series previously posted here:
>   
> https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> html
>
> This version incorporates review feedback from Ville and Sean Paul.
>
> The first patch here can be merged whenever it receives review approval.
> The second and third patches still need to wait for opensource 
> userspace to be ready before merging (there's ChromeOS work underway).
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Wei C Li <wei.c.li@intel.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Matt Roper (3):
>   drm/i915: Force background color to black for gen9+ (v2)
>   drm: Add CRTC background color property (v2)
>   drm/i915/gen9+: Add support for pipe background color (v3)
>
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
>  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
>  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
>  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
>  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
>  drivers/gpu/drm/i915/intel_display.c      | 40 +++++++++++++++++++++++++++++++
>  include/drm/drm_blend.h                   |  1 +
>  include/drm/drm_crtc.h                    | 17 +++++++++++++
>  include/drm/drm_mode_config.h             |  5 ++++
>  include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++
>  11 files changed, 136 insertions(+), 3 deletions(-)
>
> --
> 2.14.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
>
> Matt,
>
> Is that possible for you to get some time to review https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 and confirm the FROMLIST change if it looks good to you so we could move forward?
>

To be more precise, I am trying to assess what's needed before this
patch goes usptream, and in particular, I'd like to know if we are
blocked on any Chrome-side thing.

Stéphane


> BTW, I've backported your kernel patch into Chrome OS and verified it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook with KBL graphics.
>
> Thanks,
> Wei
>
> -----Original Message-----
> From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> Sent: Thursday, December 27, 2018 3:27 PM
> To: Roper, Matthew D <matthew.d.roper@intel.com>
> Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
>
> Hey,
>
> Is there anything missing on the Chrome side to move forward with this series?
>
> Stéphane
>
> On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <matthew.d.roper@intel.com> wrote:
> >
> > Third version of the series previously posted here:
> >
> > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > html
> >
> > This version incorporates review feedback from Ville and Sean Paul.
> >
> > The first patch here can be merged whenever it receives review approval.
> > The second and third patches still need to wait for opensource
> > userspace to be ready before merging (there's ChromeOS work underway).
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Wei C Li <wei.c.li@intel.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Matt Roper (3):
> >   drm/i915: Force background color to black for gen9+ (v2)
> >   drm: Add CRTC background color property (v2)
> >   drm/i915/gen9+: Add support for pipe background color (v3)
> >
> >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> >  drivers/gpu/drm/i915/intel_display.c      | 40 +++++++++++++++++++++++++++++++
> >  include/drm/drm_blend.h                   |  1 +
> >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> >  include/drm/drm_mode_config.h             |  5 ++++
> >  include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++
> >  11 files changed, 136 insertions(+), 3 deletions(-)
> >
> > --
> > 2.14.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v3 0/3] CRTC background color

[Matt Roper]

On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
> >
> > Matt,
> >
> > Is that possible for you to get some time to review https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 and confirm the FROMLIST change if it looks good to you so we could move forward?
> >
> 
> To be more precise, I am trying to assess what's needed before this
> patch goes usptream, and in particular, I'd like to know if we are
> blocked on any Chrome-side thing.
> 
> Stéphane
> 

Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
from the ChromeOS userspace team on the ABI, plus a pointer to where the
final, reviewed userspace patches are that correspond to it (mailing
list link or gerrit or whatever).  I have an old gerrit link to some
in-development chromium/ozone patches for this from November 2nd, but
I'm not sure if there's a newer one now.
 
Aside from satisfying the ABI/userspace requirements, we still need all
the patches to get reviewed by the upstream kernel devs.  An older
version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
been accepted yet.  Actually it looks like I never sent the latest
version of my series that incorporates some additional feedback from
Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
people are still out on holiday vacation at the moment, so if necessary
I'll start pinging IRC for reviews in a week or two when people are back
in office.


Matt

> 
> > BTW, I've backported your kernel patch into Chrome OS and verified it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook with KBL graphics.
> >
> > Thanks,
> > Wei
> >
> > -----Original Message-----
> > From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> > Sent: Thursday, December 27, 2018 3:27 PM
> > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> >
> > Hey,
> >
> > Is there anything missing on the Chrome side to move forward with this series?
> >
> > Stéphane
> >
> > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <matthew.d.roper@intel.com> wrote:
> > >
> > > Third version of the series previously posted here:
> > >
> > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > html
> > >
> > > This version incorporates review feedback from Ville and Sean Paul.
> > >
> > > The first patch here can be merged whenever it receives review approval.
> > > The second and third patches still need to wait for opensource
> > > userspace to be ready before merging (there's ChromeOS work underway).
> > >
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Wei C Li <wei.c.li@intel.com>
> > > Cc: Sean Paul <sean@poorly.run>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > Matt Roper (3):
> > >   drm/i915: Force background color to black for gen9+ (v2)
> > >   drm: Add CRTC background color property (v2)
> > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > >
> > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > >  drivers/gpu/drm/i915/intel_display.c      | 40 +++++++++++++++++++++++++++++++
> > >  include/drm/drm_blend.h                   |  1 +
> > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > >  include/drm/drm_mode_config.h             |  5 ++++
> > >  include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++
> > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > >
> > > --
> > > 2.14.4
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 4:45 PM Matt Roper <matthew.d.roper@intel.com> wrote:
>
> On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
> > >
> > > Matt,
> > >
> > > Is that possible for you to get some time to review https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 and confirm the FROMLIST change if it looks good to you so we could move forward?
> > >
> >
> > To be more precise, I am trying to assess what's needed before this
> > patch goes usptream, and in particular, I'd like to know if we are
> > blocked on any Chrome-side thing.
> >
> > Stéphane
> >
>
> Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> from the ChromeOS userspace team on the ABI, plus a pointer to where the
> final, reviewed userspace patches are that correspond to it (mailing
> list link or gerrit or whatever).  I have an old gerrit link to some
> in-development chromium/ozone patches for this from November 2nd, but
> I'm not sure if there's a newer one now.

IMO from user space the ABI is good. I think the question is more
whether other hw would be fine with it. For example if we notice that
other platforms can only do black as a background color, how can we
make this API standard. Hopefully other folks can chime in here about
other hw capabilities.

Stéphane


>
> Aside from satisfying the ABI/userspace requirements, we still need all
> the patches to get reviewed by the upstream kernel devs.  An older
> version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> been accepted yet.  Actually it looks like I never sent the latest
> version of my series that incorporates some additional feedback from
> Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> people are still out on holiday vacation at the moment, so if necessary
> I'll start pinging IRC for reviews in a week or two when people are back
> in office.
>
>
> Matt
>
> >
> > > BTW, I've backported your kernel patch into Chrome OS and verified it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook with KBL graphics.
> > >
> > > Thanks,
> > > Wei
> > >
> > > -----Original Message-----
> > > From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> > > Sent: Thursday, December 27, 2018 3:27 PM
> > > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > > Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > >
> > > Hey,
> > >
> > > Is there anything missing on the Chrome side to move forward with this series?
> > >
> > > Stéphane
> > >
> > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <matthew.d.roper@intel.com> wrote:
> > > >
> > > > Third version of the series previously posted here:
> > > >
> > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > html
> > > >
> > > > This version incorporates review feedback from Ville and Sean Paul.
> > > >
> > > > The first patch here can be merged whenever it receives review approval.
> > > > The second and third patches still need to wait for opensource
> > > > userspace to be ready before merging (there's ChromeOS work underway).
> > > >
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: Wei C Li <wei.c.li@intel.com>
> > > > Cc: Sean Paul <sean@poorly.run>
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > Matt Roper (3):
> > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > >   drm: Add CRTC background color property (v2)
> > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > >
> > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > > >  drivers/gpu/drm/i915/intel_display.c      | 40 +++++++++++++++++++++++++++++++
> > > >  include/drm/drm_blend.h                   |  1 +
> > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > > >  include/drm/drm_mode_config.h             |  5 ++++
> > > >  include/uapi/drm/drm_mode.h               | 28 ++++++++++++++++++++++
> > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > >
> > > > --
> > > > 2.14.4
> > > >
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] CRTC background color

[Daniel Vetter]

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

Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin <marcheu@chromium.org> 
geschrieben:
> On Thu, Dec 27, 2018 at 4:45 PM Matt Roper <matthew.d.roper@intel.com> 
> wrote:
> >
> > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
> > > >
> > > > Matt,
> > > >
> > > > Is that possible for you to get some time to review 
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 
> and confirm the FROMLIST change if it looks good to you so we could move 
> forward?
> > > >
> > >
> > > To be more precise, I am trying to assess what's needed before this
> > > patch goes usptream, and in particular, I'd like to know if we are
> > > blocked on any Chrome-side thing.
> > >
> > > Stéphane
> > >
> >
> > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> > from the ChromeOS userspace team on the ABI, plus a pointer to where the
> > final, reviewed userspace patches are that correspond to it (mailing
> > list link or gerrit or whatever).  I have an old gerrit link to some
> > in-development chromium/ozone patches for this from November 2nd, but
> > I'm not sure if there's a newer one now.
>
> IMO from user space the ABI is good. I think the question is more
> whether other hw would be fine with it. For example if we notice that
> other platforms can only do black as a background color, how can we
> make this API standard. Hopefully other folks can chime in here about
> other hw capabilities.

black background is already the default, so "no prop" = "black
background". The problem is a bit figuring out whether you can make the
primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for
userspace. We've discussed some "can_scale" and "can_position" properties
for that, but aside from reworking the helpers to check plane updates
nothing happened.
-Daniel
>
> Stéphane
>
>
> >
> > Aside from satisfying the ABI/userspace requirements, we still need all
> > the patches to get reviewed by the upstream kernel devs.  An older
> > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> > been accepted yet.  Actually it looks like I never sent the latest
> > version of my series that incorporates some additional feedback from
> > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> > people are still out on holiday vacation at the moment, so if necessary
> > I'll start pinging IRC for reviews in a week or two when people are back
> > in office.
>


>
> >
> > Matt
> >
> > >
> > > > BTW, I've backported your kernel patch into Chrome OS and verified 
> it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google 
> Pixelbook with KBL graphics.
> > > >
> > > > Thanks,
> > > > Wei
> > > >
> > > > -----Original Message-----
> > > > From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> > > > Sent: Thursday, December 27, 2018 3:27 PM
> > > > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > > > Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <
> wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > > >
> > > > Hey,
> > > >
> > > > Is there anything missing on the Chrome side to move forward with 
> this series?
> > > >
> > > > Stéphane
> > > >
> > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <
> matthew.d.roper@intel.com> wrote:
> > > > >
> > > > > Third version of the series previously posted here:
> > > > >
> > > > > 
> https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > > html
> > > > >
> > > > > This version incorporates review feedback from Ville and Sean Paul.
> > > > >
> > > > > The first patch here can be merged whenever it receives review 
> approval.
> > > > > The second and third patches still need to wait for opensource
> > > > > userspace to be ready before merging (there's ChromeOS work 
> underway).
> > > > >
> > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > Cc: Wei C Li <wei.c.li@intel.com>
> > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > >
> > > > > Matt Roper (3):
> > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > > >   drm: Add CRTC background color property (v2)
> > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > > >
> > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > > > >  drivers/gpu/drm/i915/intel_display.c      | 40 
> +++++++++++++++++++++++++++++++
> > > > >  include/drm/drm_blend.h                   |  1 +
> > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > > > >  include/drm/drm_mode_config.h             |  5 ++++
> > > > >  include/uapi/drm/drm_mode.h               | 28 
> ++++++++++++++++++++++
> > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > > >
> > > > > --
> > > > > 2.14.4
> > > > >
> > > > > _______________________________________________
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > IoTG Platform Enabling & Development
> > Intel Corporation
> > (916) 356-2795
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[-- Attachment #2: Type: text/html, Size: 8847 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v3 0/3] CRTC background color

[Matt Roper]

On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote:
> Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin <marcheu@chromium.org> 
> geschrieben:
> > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper <matthew.d.roper@intel.com> 
> > wrote:
> > >
> > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
> > > > >
> > > > > Matt,
> > > > >
> > > > > Is that possible for you to get some time to review 
> > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 
> > and confirm the FROMLIST change if it looks good to you so we could move 
> > forward?
> > > > >
> > > >
> > > > To be more precise, I am trying to assess what's needed before this
> > > > patch goes usptream, and in particular, I'd like to know if we are
> > > > blocked on any Chrome-side thing.
> > > >
> > > > Stéphane
> > > >
> > >
> > > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> > > from the ChromeOS userspace team on the ABI, plus a pointer to where the
> > > final, reviewed userspace patches are that correspond to it (mailing
> > > list link or gerrit or whatever).  I have an old gerrit link to some
> > > in-development chromium/ozone patches for this from November 2nd, but
> > > I'm not sure if there's a newer one now.
> >
> > IMO from user space the ABI is good. I think the question is more
> > whether other hw would be fine with it. For example if we notice that
> > other platforms can only do black as a background color, how can we
> > make this API standard. Hopefully other folks can chime in here about
> > other hw capabilities.
> 
> black background is already the default, so "no prop" = "black
> background". The problem is a bit figuring out whether you can make the
> primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for
> userspace. We've discussed some "can_scale" and "can_position" properties
> for that, but aside from reworking the helpers to check plane updates
> nothing happened.
> -Daniel

Based on feedback from Brian and Eric, it sounds like the thing we need
to get better clarity on is whether all hardware can apply pipe-level
degamma/csc/gamma to the background color the same way it does to plane
content (even for platforms where the background color is always a
non-programmable black).

My initial assumption (which I'll clarify in the kerneldoc) is that
background color should be treated the same way as a plane filled with
that solid color; i.e., it should go through the same pipe-level color
transformations.  Based on Eric's email, it sounds like Raspberry Pi
matches my assumption.  For Intel hardware, we have register bits that
specify whether color management should be applied to the background
color or not (they're not set today for gen9+, which I consider that a
bug since it seems like inconsistent behavior; the first patch of my
series addresses that).

If there are any platforms that don't/can't apply degamma/csc/gamma to
the background color (regardless of whether that background color is
programmable or always fixed at black), we should probably find some way
to make that known to userspace (maybe some extra immutable property?).


Matt

> >
> > Stéphane
> >
> >
> > >
> > > Aside from satisfying the ABI/userspace requirements, we still need all
> > > the patches to get reviewed by the upstream kernel devs.  An older
> > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> > > been accepted yet.  Actually it looks like I never sent the latest
> > > version of my series that incorporates some additional feedback from
> > > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> > > people are still out on holiday vacation at the moment, so if necessary
> > > I'll start pinging IRC for reviews in a week or two when people are back
> > > in office.
> >
> 
> 
> >
> > >
> > > Matt
> > >
> > > >
> > > > > BTW, I've backported your kernel patch into Chrome OS and verified 
> > it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google 
> > Pixelbook with KBL graphics.
> > > > >
> > > > > Thanks,
> > > > > Wei
> > > > >
> > > > > -----Original Message-----
> > > > > From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> > > > > Sent: Thursday, December 27, 2018 3:27 PM
> > > > > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > > > > Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <
> > wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> > > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > > > >
> > > > > Hey,
> > > > >
> > > > > Is there anything missing on the Chrome side to move forward with 
> > this series?
> > > > >
> > > > > Stéphane
> > > > >
> > > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <
> > matthew.d.roper@intel.com> wrote:
> > > > > >
> > > > > > Third version of the series previously posted here:
> > > > > >
> > > > > > 
> > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > > > html
> > > > > >
> > > > > > This version incorporates review feedback from Ville and Sean Paul.
> > > > > >
> > > > > > The first patch here can be merged whenever it receives review 
> > approval.
> > > > > > The second and third patches still need to wait for opensource
> > > > > > userspace to be ready before merging (there's ChromeOS work 
> > underway).
> > > > > >
> > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > Cc: Wei C Li <wei.c.li@intel.com>
> > > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > >
> > > > > > Matt Roper (3):
> > > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > > > >   drm: Add CRTC background color property (v2)
> > > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > > > >
> > > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > > > > >  drivers/gpu/drm/i915/intel_display.c      | 40 
> > +++++++++++++++++++++++++++++++
> > > > > >  include/drm/drm_blend.h                   |  1 +
> > > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > > > > >  include/drm/drm_mode_config.h             |  5 ++++
> > > > > >  include/uapi/drm/drm_mode.h               | 28 
> > ++++++++++++++++++++++
> > > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > --
> > > > > > 2.14.4
> > > > > >
> > > > > > _______________________________________________
> > > > > > Intel-gfx mailing list
> > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Matt Roper
> > > Graphics Software Engineer
> > > IoTG Platform Enabling & Development
> > > Intel Corporation
> > > (916) 356-2795
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >

>    Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin
>    <[1]marcheu@chromium.org> geschrieben:
> 
>      On Thu, Dec 27, 2018 at 4:45 PM Matt Roper
>      <[2]matthew.d.roper@intel.com> wrote:
>      >
>      > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
>      > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <[3]wei.c.li@intel.com>
>      wrote:
>      > > >
>      > > > Matt,
>      > > >
>      > > > Is that possible for you to get some time to review
>      [4]https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
>      and confirm the FROMLIST change if it looks good to you so we could move
>      forward?
>      > > >
>      > >
>      > > To be more precise, I am trying to assess what's needed before this
>      > > patch goes usptream, and in particular, I'd like to know if we are
>      > > blocked on any Chrome-side thing.
>      > >
>      > > Stéphane
>      > >
>      >
>      > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
>      > from the ChromeOS userspace team on the ABI, plus a pointer to where
>      the
>      > final, reviewed userspace patches are that correspond to it (mailing
>      > list link or gerrit or whatever).  I have an old gerrit link to some
>      > in-development chromium/ozone patches for this from November 2nd, but
>      > I'm not sure if there's a newer one now.
> 
>      IMO from user space the ABI is good. I think the question is more
>      whether other hw would be fine with it. For example if we notice that
>      other platforms can only do black as a background color, how can we
>      make this API standard. Hopefully other folks can chime in here about
>      other hw capabilities.
> 
>      Stéphane
> 
>      >
>      > Aside from satisfying the ABI/userspace requirements, we still need
>      all
>      > the patches to get reviewed by the upstream kernel devs.  An older
>      > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
>      > been accepted yet.  Actually it looks like I never sent the latest
>      > version of my series that incorporates some additional feedback from
>      > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
>      > people are still out on holiday vacation at the moment, so if
>      necessary
>      > I'll start pinging IRC for reviews in a week or two when people are
>      back
>      > in office.
> 
>      >
>      >
>      > Matt
>      >
>      > >
>      > > > BTW, I've backported your kernel patch into Chrome OS and verified
>      it using the TEST=drm-tests/atomictest -t crtc_background_color on a
>      Google Pixelbook with KBL graphics.
>      > > >
>      > > > Thanks,
>      > > > Wei
>      > > >
>      > > > -----Original Message-----
>      > > > From: Stéphane Marchesin [mailto:[5]marcheu@chromium.org]
>      > > > Sent: Thursday, December 27, 2018 3:27 PM
>      > > > To: Roper, Matthew D <[6]matthew.d.roper@intel.com>
>      > > > Cc: intel-gfx <[7]intel-gfx@lists.freedesktop.org>; Li, Wei C
>      <[8]wei.c.li@intel.com>; dri-devel <[9]dri-devel@lists.freedesktop.org>
>      > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
>      > > >
>      > > > Hey,
>      > > >
>      > > > Is there anything missing on the Chrome side to move forward with
>      this series?
>      > > >
>      > > > Stéphane
>      > > >
>      > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper
>      <[10]matthew.d.roper@intel.com> wrote:
>      > > > >
>      > > > > Third version of the series previously posted here:
>      > > > >
>      > > > >
>      [11]https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
>      > > > > html
>      > > > >
>      > > > > This version incorporates review feedback from Ville and Sean
>      Paul.
>      > > > >
>      > > > > The first patch here can be merged whenever it receives review
>      approval.
>      > > > > The second and third patches still need to wait for opensource
>      > > > > userspace to be ready before merging (there's ChromeOS work
>      underway).
>      > > > >
>      > > > > Cc: [12]dri-devel@lists.freedesktop.org
>      > > > > Cc: Wei C Li <[13]wei.c.li@intel.com>
>      > > > > Cc: Sean Paul <sean@poorly.run>
>      > > > > Cc: Ville Syrjälä <[14]ville.syrjala@linux.intel.com>
>      > > > >
>      > > > > Matt Roper (3):
>      > > > >   drm/i915: Force background color to black for gen9+ (v2)
>      > > > >   drm: Add CRTC background color property (v2)
>      > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
>      > > > >
>      > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>      > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
>      > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
>      > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
>      > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
>      > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
>      > > > >  drivers/gpu/drm/i915/intel_display.c      | 40
>      +++++++++++++++++++++++++++++++
>      > > > >  include/drm/drm_blend.h                   |  1 +
>      > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
>      > > > >  include/drm/drm_mode_config.h             |  5 ++++
>      > > > >  include/uapi/drm/drm_mode.h               | 28
>      ++++++++++++++++++++++
>      > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
>      > > > >
>      > > > > --
>      > > > > 2.14.4
>      > > > >
>      > > > > _______________________________________________
>      > > > > Intel-gfx mailing list
>      > > > > [15]Intel-gfx@lists.freedesktop.org
>      > > > > [16]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>      >
>      > --
>      > Matt Roper
>      > Graphics Software Engineer
>      > IoTG Platform Enabling & Development
>      > Intel Corporation
>      > (916) 356-2795
>      _______________________________________________
>      dri-devel mailing list
>      [17]dri-devel@lists.freedesktop.org
>      [18]https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> References
> 
>    Visible links
>    1. mailto:marcheu@chromium.org
>    2. mailto:matthew.d.roper@intel.com
>    3. mailto:wei.c.li@intel.com
>    4. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
>    5. mailto:marcheu@chromium.org
>    6. mailto:matthew.d.roper@intel.com
>    7. mailto:intel-gfx@lists.freedesktop.org
>    8. mailto:wei.c.li@intel.com
>    9. mailto:dri-devel@lists.freedesktop.org
>   10. mailto:matthew.d.roper@intel.com
>   11. https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777
>   12. mailto:dri-devel@lists.freedesktop.org
>   13. mailto:wei.c.li@intel.com
>   14. mailto:ville.syrjala@linux.intel.com
>   15. mailto:Intel-gfx@lists.freedesktop.org
>   16. https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>   17. mailto:dri-devel@lists.freedesktop.org
>   18. https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v3 0/3] CRTC background color

[Daniel Vetter]

On Fri, Dec 28, 2018 at 5:35 PM Matt Roper <matthew.d.roper@intel.com> wrote:
>
> On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote:
> > Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin <marcheu@chromium.org>
> > geschrieben:
> > > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper <matthew.d.roper@intel.com>
> > > wrote:
> > > >
> > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
> > > > > >
> > > > > > Matt,
> > > > > >
> > > > > > Is that possible for you to get some time to review
> > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > > and confirm the FROMLIST change if it looks good to you so we could move
> > > forward?
> > > > > >
> > > > >
> > > > > To be more precise, I am trying to assess what's needed before this
> > > > > patch goes usptream, and in particular, I'd like to know if we are
> > > > > blocked on any Chrome-side thing.
> > > > >
> > > > > Stéphane
> > > > >
> > > >
> > > > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> > > > from the ChromeOS userspace team on the ABI, plus a pointer to where the
> > > > final, reviewed userspace patches are that correspond to it (mailing
> > > > list link or gerrit or whatever).  I have an old gerrit link to some
> > > > in-development chromium/ozone patches for this from November 2nd, but
> > > > I'm not sure if there's a newer one now.
> > >
> > > IMO from user space the ABI is good. I think the question is more
> > > whether other hw would be fine with it. For example if we notice that
> > > other platforms can only do black as a background color, how can we
> > > make this API standard. Hopefully other folks can chime in here about
> > > other hw capabilities.
> >
> > black background is already the default, so "no prop" = "black
> > background". The problem is a bit figuring out whether you can make the
> > primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for
> > userspace. We've discussed some "can_scale" and "can_position" properties
> > for that, but aside from reworking the helpers to check plane updates
> > nothing happened.
> > -Daniel
>
> Based on feedback from Brian and Eric, it sounds like the thing we need
> to get better clarity on is whether all hardware can apply pipe-level
> degamma/csc/gamma to the background color the same way it does to plane
> content (even for platforms where the background color is always a
> non-programmable black).
>
> My initial assumption (which I'll clarify in the kerneldoc) is that
> background color should be treated the same way as a plane filled with
> that solid color; i.e., it should go through the same pipe-level color
> transformations.  Based on Eric's email, it sounds like Raspberry Pi
> matches my assumption.  For Intel hardware, we have register bits that
> specify whether color management should be applied to the background
> color or not (they're not set today for gen9+, which I consider that a
> bug since it seems like inconsistent behavior; the first patch of my
> series addresses that).
>
> If there are any platforms that don't/can't apply degamma/csc/gamma to
> the background color (regardless of whether that background color is
> programmable or always fixed at black), we should probably find some way
> to make that known to userspace (maybe some extra immutable property?).

Nah, I'd say since most hw seems to have the background color before
the CRTC degamma/ctm/gamma stuff we can just require that the odd one
out manually feed the background color through the color stuff before
writing it to hardware. And updating it every time the gamma tables
change again ofc. We could even do a little helper for this and store
the post-color_mgmt background in the crtc_state. Offloading that to
userspace seems silly to me.
-Daniel

>
>
> Matt
>
> > >
> > > Stéphane
> > >
> > >
> > > >
> > > > Aside from satisfying the ABI/userspace requirements, we still need all
> > > > the patches to get reviewed by the upstream kernel devs.  An older
> > > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> > > > been accepted yet.  Actually it looks like I never sent the latest
> > > > version of my series that incorporates some additional feedback from
> > > > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> > > > people are still out on holiday vacation at the moment, so if necessary
> > > > I'll start pinging IRC for reviews in a week or two when people are back
> > > > in office.
> > >
> >
> >
> > >
> > > >
> > > > Matt
> > > >
> > > > >
> > > > > > BTW, I've backported your kernel patch into Chrome OS and verified
> > > it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google
> > > Pixelbook with KBL graphics.
> > > > > >
> > > > > > Thanks,
> > > > > > Wei
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> > > > > > Sent: Thursday, December 27, 2018 3:27 PM
> > > > > > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > > > > > Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <
> > > wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> > > > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > > > > >
> > > > > > Hey,
> > > > > >
> > > > > > Is there anything missing on the Chrome side to move forward with
> > > this series?
> > > > > >
> > > > > > Stéphane
> > > > > >
> > > > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <
> > > matthew.d.roper@intel.com> wrote:
> > > > > > >
> > > > > > > Third version of the series previously posted here:
> > > > > > >
> > > > > > >
> > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > > > > html
> > > > > > >
> > > > > > > This version incorporates review feedback from Ville and Sean Paul.
> > > > > > >
> > > > > > > The first patch here can be merged whenever it receives review
> > > approval.
> > > > > > > The second and third patches still need to wait for opensource
> > > > > > > userspace to be ready before merging (there's ChromeOS work
> > > underway).
> > > > > > >
> > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > Cc: Wei C Li <wei.c.li@intel.com>
> > > > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > >
> > > > > > > Matt Roper (3):
> > > > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > > > > >   drm: Add CRTC background color property (v2)
> > > > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > > > > >
> > > > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > > > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > > > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > > > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > > > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > > > > > >  drivers/gpu/drm/i915/intel_display.c      | 40
> > > +++++++++++++++++++++++++++++++
> > > > > > >  include/drm/drm_blend.h                   |  1 +
> > > > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > > > > > >  include/drm/drm_mode_config.h             |  5 ++++
> > > > > > >  include/uapi/drm/drm_mode.h               | 28
> > > ++++++++++++++++++++++
> > > > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > --
> > > > > > > 2.14.4
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Intel-gfx mailing list
> > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
> > > > --
> > > > Matt Roper
> > > > Graphics Software Engineer
> > > > IoTG Platform Enabling & Development
> > > > Intel Corporation
> > > > (916) 356-2795
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
>
> >    Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin
> >    <[1]marcheu@chromium.org> geschrieben:
> >
> >      On Thu, Dec 27, 2018 at 4:45 PM Matt Roper
> >      <[2]matthew.d.roper@intel.com> wrote:
> >      >
> >      > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> >      > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <[3]wei.c.li@intel.com>
> >      wrote:
> >      > > >
> >      > > > Matt,
> >      > > >
> >      > > > Is that possible for you to get some time to review
> >      [4]https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> >      and confirm the FROMLIST change if it looks good to you so we could move
> >      forward?
> >      > > >
> >      > >
> >      > > To be more precise, I am trying to assess what's needed before this
> >      > > patch goes usptream, and in particular, I'd like to know if we are
> >      > > blocked on any Chrome-side thing.
> >      > >
> >      > > Stéphane
> >      > >
> >      >
> >      > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> >      > from the ChromeOS userspace team on the ABI, plus a pointer to where
> >      the
> >      > final, reviewed userspace patches are that correspond to it (mailing
> >      > list link or gerrit or whatever).  I have an old gerrit link to some
> >      > in-development chromium/ozone patches for this from November 2nd, but
> >      > I'm not sure if there's a newer one now.
> >
> >      IMO from user space the ABI is good. I think the question is more
> >      whether other hw would be fine with it. For example if we notice that
> >      other platforms can only do black as a background color, how can we
> >      make this API standard. Hopefully other folks can chime in here about
> >      other hw capabilities.
> >
> >      Stéphane
> >
> >      >
> >      > Aside from satisfying the ABI/userspace requirements, we still need
> >      all
> >      > the patches to get reviewed by the upstream kernel devs.  An older
> >      > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> >      > been accepted yet.  Actually it looks like I never sent the latest
> >      > version of my series that incorporates some additional feedback from
> >      > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> >      > people are still out on holiday vacation at the moment, so if
> >      necessary
> >      > I'll start pinging IRC for reviews in a week or two when people are
> >      back
> >      > in office.
> >
> >      >
> >      >
> >      > Matt
> >      >
> >      > >
> >      > > > BTW, I've backported your kernel patch into Chrome OS and verified
> >      it using the TEST=drm-tests/atomictest -t crtc_background_color on a
> >      Google Pixelbook with KBL graphics.
> >      > > >
> >      > > > Thanks,
> >      > > > Wei
> >      > > >
> >      > > > -----Original Message-----
> >      > > > From: Stéphane Marchesin [mailto:[5]marcheu@chromium.org]
> >      > > > Sent: Thursday, December 27, 2018 3:27 PM
> >      > > > To: Roper, Matthew D <[6]matthew.d.roper@intel.com>
> >      > > > Cc: intel-gfx <[7]intel-gfx@lists.freedesktop.org>; Li, Wei C
> >      <[8]wei.c.li@intel.com>; dri-devel <[9]dri-devel@lists.freedesktop.org>
> >      > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> >      > > >
> >      > > > Hey,
> >      > > >
> >      > > > Is there anything missing on the Chrome side to move forward with
> >      this series?
> >      > > >
> >      > > > Stéphane
> >      > > >
> >      > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper
> >      <[10]matthew.d.roper@intel.com> wrote:
> >      > > > >
> >      > > > > Third version of the series previously posted here:
> >      > > > >
> >      > > > >
> >      [11]https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> >      > > > > html
> >      > > > >
> >      > > > > This version incorporates review feedback from Ville and Sean
> >      Paul.
> >      > > > >
> >      > > > > The first patch here can be merged whenever it receives review
> >      approval.
> >      > > > > The second and third patches still need to wait for opensource
> >      > > > > userspace to be ready before merging (there's ChromeOS work
> >      underway).
> >      > > > >
> >      > > > > Cc: [12]dri-devel@lists.freedesktop.org
> >      > > > > Cc: Wei C Li <[13]wei.c.li@intel.com>
> >      > > > > Cc: Sean Paul <sean@poorly.run>
> >      > > > > Cc: Ville Syrjälä <[14]ville.syrjala@linux.intel.com>
> >      > > > >
> >      > > > > Matt Roper (3):
> >      > > > >   drm/i915: Force background color to black for gen9+ (v2)
> >      > > > >   drm: Add CRTC background color property (v2)
> >      > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> >      > > > >
> >      > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >      > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> >      > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> >      > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> >      > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> >      > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> >      > > > >  drivers/gpu/drm/i915/intel_display.c      | 40
> >      +++++++++++++++++++++++++++++++
> >      > > > >  include/drm/drm_blend.h                   |  1 +
> >      > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> >      > > > >  include/drm/drm_mode_config.h             |  5 ++++
> >      > > > >  include/uapi/drm/drm_mode.h               | 28
> >      ++++++++++++++++++++++
> >      > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> >      > > > >
> >      > > > > --
> >      > > > > 2.14.4
> >      > > > >
> >      > > > > _______________________________________________
> >      > > > > Intel-gfx mailing list
> >      > > > > [15]Intel-gfx@lists.freedesktop.org
> >      > > > > [16]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >      >
> >      > --
> >      > Matt Roper
> >      > Graphics Software Engineer
> >      > IoTG Platform Enabling & Development
> >      > Intel Corporation
> >      > (916) 356-2795
> >      _______________________________________________
> >      dri-devel mailing list
> >      [17]dri-devel@lists.freedesktop.org
> >      [18]https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > References
> >
> >    Visible links
> >    1. mailto:marcheu@chromium.org
> >    2. mailto:matthew.d.roper@intel.com
> >    3. mailto:wei.c.li@intel.com
> >    4. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> >    5. mailto:marcheu@chromium.org
> >    6. mailto:matthew.d.roper@intel.com
> >    7. mailto:intel-gfx@lists.freedesktop.org
> >    8. mailto:wei.c.li@intel.com
> >    9. mailto:dri-devel@lists.freedesktop.org
> >   10. mailto:matthew.d.roper@intel.com
> >   11. https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777
> >   12. mailto:dri-devel@lists.freedesktop.org
> >   13. mailto:wei.c.li@intel.com
> >   14. mailto:ville.syrjala@linux.intel.com
> >   15. mailto:Intel-gfx@lists.freedesktop.org
> >   16. https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >   17. mailto:dri-devel@lists.freedesktop.org
> >   18. https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Matt Roper]

On Fri, Dec 28, 2018 at 06:14:40PM +0100, Daniel Vetter wrote:
> On Fri, Dec 28, 2018 at 5:35 PM Matt Roper <matthew.d.roper@intel.com> wrote:
> >
> > On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote:
> > > Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin <marcheu@chromium.org>
> > > geschrieben:
> > > > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper <matthew.d.roper@intel.com>
> > > > wrote:
> > > > >
> > > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > > > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
> > > > > > >
> > > > > > > Matt,
> > > > > > >
> > > > > > > Is that possible for you to get some time to review
> > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > > > and confirm the FROMLIST change if it looks good to you so we could move
> > > > forward?
> > > > > > >
> > > > > >
> > > > > > To be more precise, I am trying to assess what's needed before this
> > > > > > patch goes usptream, and in particular, I'd like to know if we are
> > > > > > blocked on any Chrome-side thing.
> > > > > >
> > > > > > Stéphane
> > > > > >
> > > > >
> > > > > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> > > > > from the ChromeOS userspace team on the ABI, plus a pointer to where the
> > > > > final, reviewed userspace patches are that correspond to it (mailing
> > > > > list link or gerrit or whatever).  I have an old gerrit link to some
> > > > > in-development chromium/ozone patches for this from November 2nd, but
> > > > > I'm not sure if there's a newer one now.
> > > >
> > > > IMO from user space the ABI is good. I think the question is more
> > > > whether other hw would be fine with it. For example if we notice that
> > > > other platforms can only do black as a background color, how can we
> > > > make this API standard. Hopefully other folks can chime in here about
> > > > other hw capabilities.
> > >
> > > black background is already the default, so "no prop" = "black
> > > background". The problem is a bit figuring out whether you can make the
> > > primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for
> > > userspace. We've discussed some "can_scale" and "can_position" properties
> > > for that, but aside from reworking the helpers to check plane updates
> > > nothing happened.
> > > -Daniel
> >
> > Based on feedback from Brian and Eric, it sounds like the thing we need
> > to get better clarity on is whether all hardware can apply pipe-level
> > degamma/csc/gamma to the background color the same way it does to plane
> > content (even for platforms where the background color is always a
> > non-programmable black).
> >
> > My initial assumption (which I'll clarify in the kerneldoc) is that
> > background color should be treated the same way as a plane filled with
> > that solid color; i.e., it should go through the same pipe-level color
> > transformations.  Based on Eric's email, it sounds like Raspberry Pi
> > matches my assumption.  For Intel hardware, we have register bits that
> > specify whether color management should be applied to the background
> > color or not (they're not set today for gen9+, which I consider that a
> > bug since it seems like inconsistent behavior; the first patch of my
> > series addresses that).
> >
> > If there are any platforms that don't/can't apply degamma/csc/gamma to
> > the background color (regardless of whether that background color is
> > programmable or always fixed at black), we should probably find some way
> > to make that known to userspace (maybe some extra immutable property?).
> 
> Nah, I'd say since most hw seems to have the background color before
> the CRTC degamma/ctm/gamma stuff we can just require that the odd one
> out manually feed the background color through the color stuff before
> writing it to hardware. And updating it every time the gamma tables
> change again ofc. We could even do a little helper for this and store
> the post-color_mgmt background in the crtc_state. Offloading that to
> userspace seems silly to me.
> -Daniel

I think the only problem would be if we come across hardware that has a
non-programmable (always black) background colors that also doesn't pass
its background black through the gamma/csc pipeline.


Matt

> 
> >
> >
> > Matt
> >
> > > >
> > > > Stéphane
> > > >
> > > >
> > > > >
> > > > > Aside from satisfying the ABI/userspace requirements, we still need all
> > > > > the patches to get reviewed by the upstream kernel devs.  An older
> > > > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> > > > > been accepted yet.  Actually it looks like I never sent the latest
> > > > > version of my series that incorporates some additional feedback from
> > > > > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> > > > > people are still out on holiday vacation at the moment, so if necessary
> > > > > I'll start pinging IRC for reviews in a week or two when people are back
> > > > > in office.
> > > >
> > >
> > >
> > > >
> > > > >
> > > > > Matt
> > > > >
> > > > > >
> > > > > > > BTW, I've backported your kernel patch into Chrome OS and verified
> > > > it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google
> > > > Pixelbook with KBL graphics.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Wei
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> > > > > > > Sent: Thursday, December 27, 2018 3:27 PM
> > > > > > > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > > > > > > Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <
> > > > wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> > > > > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > > > > > >
> > > > > > > Hey,
> > > > > > >
> > > > > > > Is there anything missing on the Chrome side to move forward with
> > > > this series?
> > > > > > >
> > > > > > > Stéphane
> > > > > > >
> > > > > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <
> > > > matthew.d.roper@intel.com> wrote:
> > > > > > > >
> > > > > > > > Third version of the series previously posted here:
> > > > > > > >
> > > > > > > >
> > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > > > > > html
> > > > > > > >
> > > > > > > > This version incorporates review feedback from Ville and Sean Paul.
> > > > > > > >
> > > > > > > > The first patch here can be merged whenever it receives review
> > > > approval.
> > > > > > > > The second and third patches still need to wait for opensource
> > > > > > > > userspace to be ready before merging (there's ChromeOS work
> > > > underway).
> > > > > > > >
> > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > Cc: Wei C Li <wei.c.li@intel.com>
> > > > > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > >
> > > > > > > > Matt Roper (3):
> > > > > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > > > > > >   drm: Add CRTC background color property (v2)
> > > > > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > > > > > >
> > > > > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > > > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > > > > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > > > > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > > > > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > > > > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > > > > > > >  drivers/gpu/drm/i915/intel_display.c      | 40
> > > > +++++++++++++++++++++++++++++++
> > > > > > > >  include/drm/drm_blend.h                   |  1 +
> > > > > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > > > > > > >  include/drm/drm_mode_config.h             |  5 ++++
> > > > > > > >  include/uapi/drm/drm_mode.h               | 28
> > > > ++++++++++++++++++++++
> > > > > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.14.4
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Intel-gfx mailing list
> > > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > >
> > > > > --
> > > > > Matt Roper
> > > > > Graphics Software Engineer
> > > > > IoTG Platform Enabling & Development
> > > > > Intel Corporation
> > > > > (916) 356-2795
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> >
> > >    Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin
> > >    <[1]marcheu@chromium.org> geschrieben:
> > >
> > >      On Thu, Dec 27, 2018 at 4:45 PM Matt Roper
> > >      <[2]matthew.d.roper@intel.com> wrote:
> > >      >
> > >      > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > >      > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <[3]wei.c.li@intel.com>
> > >      wrote:
> > >      > > >
> > >      > > > Matt,
> > >      > > >
> > >      > > > Is that possible for you to get some time to review
> > >      [4]https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > >      and confirm the FROMLIST change if it looks good to you so we could move
> > >      forward?
> > >      > > >
> > >      > >
> > >      > > To be more precise, I am trying to assess what's needed before this
> > >      > > patch goes usptream, and in particular, I'd like to know if we are
> > >      > > blocked on any Chrome-side thing.
> > >      > >
> > >      > > Stéphane
> > >      > >
> > >      >
> > >      > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> > >      > from the ChromeOS userspace team on the ABI, plus a pointer to where
> > >      the
> > >      > final, reviewed userspace patches are that correspond to it (mailing
> > >      > list link or gerrit or whatever).  I have an old gerrit link to some
> > >      > in-development chromium/ozone patches for this from November 2nd, but
> > >      > I'm not sure if there's a newer one now.
> > >
> > >      IMO from user space the ABI is good. I think the question is more
> > >      whether other hw would be fine with it. For example if we notice that
> > >      other platforms can only do black as a background color, how can we
> > >      make this API standard. Hopefully other folks can chime in here about
> > >      other hw capabilities.
> > >
> > >      Stéphane
> > >
> > >      >
> > >      > Aside from satisfying the ABI/userspace requirements, we still need
> > >      all
> > >      > the patches to get reviewed by the upstream kernel devs.  An older
> > >      > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> > >      > been accepted yet.  Actually it looks like I never sent the latest
> > >      > version of my series that incorporates some additional feedback from
> > >      > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> > >      > people are still out on holiday vacation at the moment, so if
> > >      necessary
> > >      > I'll start pinging IRC for reviews in a week or two when people are
> > >      back
> > >      > in office.
> > >
> > >      >
> > >      >
> > >      > Matt
> > >      >
> > >      > >
> > >      > > > BTW, I've backported your kernel patch into Chrome OS and verified
> > >      it using the TEST=drm-tests/atomictest -t crtc_background_color on a
> > >      Google Pixelbook with KBL graphics.
> > >      > > >
> > >      > > > Thanks,
> > >      > > > Wei
> > >      > > >
> > >      > > > -----Original Message-----
> > >      > > > From: Stéphane Marchesin [mailto:[5]marcheu@chromium.org]
> > >      > > > Sent: Thursday, December 27, 2018 3:27 PM
> > >      > > > To: Roper, Matthew D <[6]matthew.d.roper@intel.com>
> > >      > > > Cc: intel-gfx <[7]intel-gfx@lists.freedesktop.org>; Li, Wei C
> > >      <[8]wei.c.li@intel.com>; dri-devel <[9]dri-devel@lists.freedesktop.org>
> > >      > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > >      > > >
> > >      > > > Hey,
> > >      > > >
> > >      > > > Is there anything missing on the Chrome side to move forward with
> > >      this series?
> > >      > > >
> > >      > > > Stéphane
> > >      > > >
> > >      > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper
> > >      <[10]matthew.d.roper@intel.com> wrote:
> > >      > > > >
> > >      > > > > Third version of the series previously posted here:
> > >      > > > >
> > >      > > > >
> > >      [11]https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > >      > > > > html
> > >      > > > >
> > >      > > > > This version incorporates review feedback from Ville and Sean
> > >      Paul.
> > >      > > > >
> > >      > > > > The first patch here can be merged whenever it receives review
> > >      approval.
> > >      > > > > The second and third patches still need to wait for opensource
> > >      > > > > userspace to be ready before merging (there's ChromeOS work
> > >      underway).
> > >      > > > >
> > >      > > > > Cc: [12]dri-devel@lists.freedesktop.org
> > >      > > > > Cc: Wei C Li <[13]wei.c.li@intel.com>
> > >      > > > > Cc: Sean Paul <sean@poorly.run>
> > >      > > > > Cc: Ville Syrjälä <[14]ville.syrjala@linux.intel.com>
> > >      > > > >
> > >      > > > > Matt Roper (3):
> > >      > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > >      > > > >   drm: Add CRTC background color property (v2)
> > >      > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > >      > > > >
> > >      > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > >      > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > >      > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > >      > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > >      > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > >      > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > >      > > > >  drivers/gpu/drm/i915/intel_display.c      | 40
> > >      +++++++++++++++++++++++++++++++
> > >      > > > >  include/drm/drm_blend.h                   |  1 +
> > >      > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > >      > > > >  include/drm/drm_mode_config.h             |  5 ++++
> > >      > > > >  include/uapi/drm/drm_mode.h               | 28
> > >      ++++++++++++++++++++++
> > >      > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > >      > > > >
> > >      > > > > --
> > >      > > > > 2.14.4
> > >      > > > >
> > >      > > > > _______________________________________________
> > >      > > > > Intel-gfx mailing list
> > >      > > > > [15]Intel-gfx@lists.freedesktop.org
> > >      > > > > [16]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >      >
> > >      > --
> > >      > Matt Roper
> > >      > Graphics Software Engineer
> > >      > IoTG Platform Enabling & Development
> > >      > Intel Corporation
> > >      > (916) 356-2795
> > >      _______________________________________________
> > >      dri-devel mailing list
> > >      [17]dri-devel@lists.freedesktop.org
> > >      [18]https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > References
> > >
> > >    Visible links
> > >    1. mailto:marcheu@chromium.org
> > >    2. mailto:matthew.d.roper@intel.com
> > >    3. mailto:wei.c.li@intel.com
> > >    4. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > >    5. mailto:marcheu@chromium.org
> > >    6. mailto:matthew.d.roper@intel.com
> > >    7. mailto:intel-gfx@lists.freedesktop.org
> > >    8. mailto:wei.c.li@intel.com
> > >    9. mailto:dri-devel@lists.freedesktop.org
> > >   10. mailto:matthew.d.roper@intel.com
> > >   11. https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777
> > >   12. mailto:dri-devel@lists.freedesktop.org
> > >   13. mailto:wei.c.li@intel.com
> > >   14. mailto:ville.syrjala@linux.intel.com
> > >   15. mailto:Intel-gfx@lists.freedesktop.org
> > >   16. https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >   17. mailto:dri-devel@lists.freedesktop.org
> > >   18. https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > IoTG Platform Enabling & Development
> > Intel Corporation
> > (916) 356-2795
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Daniel Vetter]

On Fri, Dec 28, 2018 at 6:19 PM Matt Roper <matthew.d.roper@intel.com> wrote:
>
> On Fri, Dec 28, 2018 at 06:14:40PM +0100, Daniel Vetter wrote:
> > On Fri, Dec 28, 2018 at 5:35 PM Matt Roper <matthew.d.roper@intel.com> wrote:
> > >
> > > On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote:
> > > > Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin <marcheu@chromium.org>
> > > > geschrieben:
> > > > > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper <matthew.d.roper@intel.com>
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > > > > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <wei.c.li@intel.com> wrote:
> > > > > > > >
> > > > > > > > Matt,
> > > > > > > >
> > > > > > > > Is that possible for you to get some time to review
> > > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > > > > and confirm the FROMLIST change if it looks good to you so we could move
> > > > > forward?
> > > > > > > >
> > > > > > >
> > > > > > > To be more precise, I am trying to assess what's needed before this
> > > > > > > patch goes usptream, and in particular, I'd like to know if we are
> > > > > > > blocked on any Chrome-side thing.
> > > > > > >
> > > > > > > Stéphane
> > > > > > >
> > > > > >
> > > > > > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> > > > > > from the ChromeOS userspace team on the ABI, plus a pointer to where the
> > > > > > final, reviewed userspace patches are that correspond to it (mailing
> > > > > > list link or gerrit or whatever).  I have an old gerrit link to some
> > > > > > in-development chromium/ozone patches for this from November 2nd, but
> > > > > > I'm not sure if there's a newer one now.
> > > > >
> > > > > IMO from user space the ABI is good. I think the question is more
> > > > > whether other hw would be fine with it. For example if we notice that
> > > > > other platforms can only do black as a background color, how can we
> > > > > make this API standard. Hopefully other folks can chime in here about
> > > > > other hw capabilities.
> > > >
> > > > black background is already the default, so "no prop" = "black
> > > > background". The problem is a bit figuring out whether you can make the
> > > > primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for
> > > > userspace. We've discussed some "can_scale" and "can_position" properties
> > > > for that, but aside from reworking the helpers to check plane updates
> > > > nothing happened.
> > > > -Daniel
> > >
> > > Based on feedback from Brian and Eric, it sounds like the thing we need
> > > to get better clarity on is whether all hardware can apply pipe-level
> > > degamma/csc/gamma to the background color the same way it does to plane
> > > content (even for platforms where the background color is always a
> > > non-programmable black).
> > >
> > > My initial assumption (which I'll clarify in the kerneldoc) is that
> > > background color should be treated the same way as a plane filled with
> > > that solid color; i.e., it should go through the same pipe-level color
> > > transformations.  Based on Eric's email, it sounds like Raspberry Pi
> > > matches my assumption.  For Intel hardware, we have register bits that
> > > specify whether color management should be applied to the background
> > > color or not (they're not set today for gen9+, which I consider that a
> > > bug since it seems like inconsistent behavior; the first patch of my
> > > series addresses that).
> > >
> > > If there are any platforms that don't/can't apply degamma/csc/gamma to
> > > the background color (regardless of whether that background color is
> > > programmable or always fixed at black), we should probably find some way
> > > to make that known to userspace (maybe some extra immutable property?).
> >
> > Nah, I'd say since most hw seems to have the background color before
> > the CRTC degamma/ctm/gamma stuff we can just require that the odd one
> > out manually feed the background color through the color stuff before
> > writing it to hardware. And updating it every time the gamma tables
> > change again ofc. We could even do a little helper for this and store
> > the post-color_mgmt background in the crtc_state. Offloading that to
> > userspace seems silly to me.
> > -Daniel
>
> I think the only problem would be if we come across hardware that has a
> non-programmable (always black) background colors that also doesn't pass
> its background black through the gamma/csc pipeline.

That just sounds broken. I guess in that case you don't get to use
both the color mgmt pipeline and have a non-fullscreen primary plane.
Mea culpa, build better hw :-)
-Daniel

>
>
> Matt
>
> >
> > >
> > >
> > > Matt
> > >
> > > > >
> > > > > Stéphane
> > > > >
> > > > >
> > > > > >
> > > > > > Aside from satisfying the ABI/userspace requirements, we still need all
> > > > > > the patches to get reviewed by the upstream kernel devs.  An older
> > > > > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> > > > > > been accepted yet.  Actually it looks like I never sent the latest
> > > > > > version of my series that incorporates some additional feedback from
> > > > > > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> > > > > > people are still out on holiday vacation at the moment, so if necessary
> > > > > > I'll start pinging IRC for reviews in a week or two when people are back
> > > > > > in office.
> > > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > > >
> > > > > > > > BTW, I've backported your kernel patch into Chrome OS and verified
> > > > > it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google
> > > > > Pixelbook with KBL graphics.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Wei
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Stéphane Marchesin [mailto:marcheu@chromium.org]
> > > > > > > > Sent: Thursday, December 27, 2018 3:27 PM
> > > > > > > > To: Roper, Matthew D <matthew.d.roper@intel.com>
> > > > > > > > Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; Li, Wei C <
> > > > > wei.c.li@intel.com>; dri-devel <dri-devel@lists.freedesktop.org>
> > > > > > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > > > > > > >
> > > > > > > > Hey,
> > > > > > > >
> > > > > > > > Is there anything missing on the Chrome side to move forward with
> > > > > this series?
> > > > > > > >
> > > > > > > > Stéphane
> > > > > > > >
> > > > > > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper <
> > > > > matthew.d.roper@intel.com> wrote:
> > > > > > > > >
> > > > > > > > > Third version of the series previously posted here:
> > > > > > > > >
> > > > > > > > >
> > > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > > > > > > html
> > > > > > > > >
> > > > > > > > > This version incorporates review feedback from Ville and Sean Paul.
> > > > > > > > >
> > > > > > > > > The first patch here can be merged whenever it receives review
> > > > > approval.
> > > > > > > > > The second and third patches still need to wait for opensource
> > > > > > > > > userspace to be ready before merging (there's ChromeOS work
> > > > > underway).
> > > > > > > > >
> > > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > Cc: Wei C Li <wei.c.li@intel.com>
> > > > > > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > >
> > > > > > > > > Matt Roper (3):
> > > > > > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > > > > > > >   drm: Add CRTC background color property (v2)
> > > > > > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > > > > > > >
> > > > > > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > > > > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > > > > > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > > > > > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > > > > > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > > > > > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > > > > > > > >  drivers/gpu/drm/i915/intel_display.c      | 40
> > > > > +++++++++++++++++++++++++++++++
> > > > > > > > >  include/drm/drm_blend.h                   |  1 +
> > > > > > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > > > > > > > >  include/drm/drm_mode_config.h             |  5 ++++
> > > > > > > > >  include/uapi/drm/drm_mode.h               | 28
> > > > > ++++++++++++++++++++++
> > > > > > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 2.14.4
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Intel-gfx mailing list
> > > > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > >
> > > > > > --
> > > > > > Matt Roper
> > > > > > Graphics Software Engineer
> > > > > > IoTG Platform Enabling & Development
> > > > > > Intel Corporation
> > > > > > (916) 356-2795
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > >
> > >
> > > >    Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin
> > > >    <[1]marcheu@chromium.org> geschrieben:
> > > >
> > > >      On Thu, Dec 27, 2018 at 4:45 PM Matt Roper
> > > >      <[2]matthew.d.roper@intel.com> wrote:
> > > >      >
> > > >      > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > > >      > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C <[3]wei.c.li@intel.com>
> > > >      wrote:
> > > >      > > >
> > > >      > > > Matt,
> > > >      > > >
> > > >      > > > Is that possible for you to get some time to review
> > > >      [4]https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > > >      and confirm the FROMLIST change if it looks good to you so we could move
> > > >      forward?
> > > >      > > >
> > > >      > >
> > > >      > > To be more precise, I am trying to assess what's needed before this
> > > >      > > patch goes usptream, and in particular, I'd like to know if we are
> > > >      > > blocked on any Chrome-side thing.
> > > >      > >
> > > >      > > Stéphane
> > > >      > >
> > > >      >
> > > >      > Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> > > >      > from the ChromeOS userspace team on the ABI, plus a pointer to where
> > > >      the
> > > >      > final, reviewed userspace patches are that correspond to it (mailing
> > > >      > list link or gerrit or whatever).  I have an old gerrit link to some
> > > >      > in-development chromium/ozone patches for this from November 2nd, but
> > > >      > I'm not sure if there's a newer one now.
> > > >
> > > >      IMO from user space the ABI is good. I think the question is more
> > > >      whether other hw would be fine with it. For example if we notice that
> > > >      other platforms can only do black as a background color, how can we
> > > >      make this API standard. Hopefully other folks can chime in here about
> > > >      other hw capabilities.
> > > >
> > > >      Stéphane
> > > >
> > > >      >
> > > >      > Aside from satisfying the ABI/userspace requirements, we still need
> > > >      all
> > > >      > the patches to get reviewed by the upstream kernel devs.  An older
> > > >      > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> > > >      > been accepted yet.  Actually it looks like I never sent the latest
> > > >      > version of my series that incorporates some additional feedback from
> > > >      > Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> > > >      > people are still out on holiday vacation at the moment, so if
> > > >      necessary
> > > >      > I'll start pinging IRC for reviews in a week or two when people are
> > > >      back
> > > >      > in office.
> > > >
> > > >      >
> > > >      >
> > > >      > Matt
> > > >      >
> > > >      > >
> > > >      > > > BTW, I've backported your kernel patch into Chrome OS and verified
> > > >      it using the TEST=drm-tests/atomictest -t crtc_background_color on a
> > > >      Google Pixelbook with KBL graphics.
> > > >      > > >
> > > >      > > > Thanks,
> > > >      > > > Wei
> > > >      > > >
> > > >      > > > -----Original Message-----
> > > >      > > > From: Stéphane Marchesin [mailto:[5]marcheu@chromium.org]
> > > >      > > > Sent: Thursday, December 27, 2018 3:27 PM
> > > >      > > > To: Roper, Matthew D <[6]matthew.d.roper@intel.com>
> > > >      > > > Cc: intel-gfx <[7]intel-gfx@lists.freedesktop.org>; Li, Wei C
> > > >      <[8]wei.c.li@intel.com>; dri-devel <[9]dri-devel@lists.freedesktop.org>
> > > >      > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > > >      > > >
> > > >      > > > Hey,
> > > >      > > >
> > > >      > > > Is there anything missing on the Chrome side to move forward with
> > > >      this series?
> > > >      > > >
> > > >      > > > Stéphane
> > > >      > > >
> > > >      > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper
> > > >      <[10]matthew.d.roper@intel.com> wrote:
> > > >      > > > >
> > > >      > > > > Third version of the series previously posted here:
> > > >      > > > >
> > > >      > > > >
> > > >      [11]https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > >      > > > > html
> > > >      > > > >
> > > >      > > > > This version incorporates review feedback from Ville and Sean
> > > >      Paul.
> > > >      > > > >
> > > >      > > > > The first patch here can be merged whenever it receives review
> > > >      approval.
> > > >      > > > > The second and third patches still need to wait for opensource
> > > >      > > > > userspace to be ready before merging (there's ChromeOS work
> > > >      underway).
> > > >      > > > >
> > > >      > > > > Cc: [12]dri-devel@lists.freedesktop.org
> > > >      > > > > Cc: Wei C Li <[13]wei.c.li@intel.com>
> > > >      > > > > Cc: Sean Paul <sean@poorly.run>
> > > >      > > > > Cc: Ville Syrjälä <[14]ville.syrjala@linux.intel.com>
> > > >      > > > >
> > > >      > > > > Matt Roper (3):
> > > >      > > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > >      > > > >   drm: Add CRTC background color property (v2)
> > > >      > > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > >      > > > >
> > > >      > > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > >      > > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  5 ++++
> > > >      > > > >  drivers/gpu/drm/drm_blend.c               | 21 +++++++++++++---
> > > >      > > > >  drivers/gpu/drm/drm_mode_config.c         |  6 +++++
> > > >      > > > >  drivers/gpu/drm/i915/i915_debugfs.c       |  9 +++++++
> > > >      > > > >  drivers/gpu/drm/i915/i915_reg.h           |  6 +++++
> > > >      > > > >  drivers/gpu/drm/i915/intel_display.c      | 40
> > > >      +++++++++++++++++++++++++++++++
> > > >      > > > >  include/drm/drm_blend.h                   |  1 +
> > > >      > > > >  include/drm/drm_crtc.h                    | 17 +++++++++++++
> > > >      > > > >  include/drm/drm_mode_config.h             |  5 ++++
> > > >      > > > >  include/uapi/drm/drm_mode.h               | 28
> > > >      ++++++++++++++++++++++
> > > >      > > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > >      > > > >
> > > >      > > > > --
> > > >      > > > > 2.14.4
> > > >      > > > >
> > > >      > > > > _______________________________________________
> > > >      > > > > Intel-gfx mailing list
> > > >      > > > > [15]Intel-gfx@lists.freedesktop.org
> > > >      > > > > [16]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >      >
> > > >      > --
> > > >      > Matt Roper
> > > >      > Graphics Software Engineer
> > > >      > IoTG Platform Enabling & Development
> > > >      > Intel Corporation
> > > >      > (916) 356-2795
> > > >      _______________________________________________
> > > >      dri-devel mailing list
> > > >      [17]dri-devel@lists.freedesktop.org
> > > >      [18]https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > > References
> > > >
> > > >    Visible links
> > > >    1. mailto:marcheu@chromium.org
> > > >    2. mailto:matthew.d.roper@intel.com
> > > >    3. mailto:wei.c.li@intel.com
> > > >    4. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > > >    5. mailto:marcheu@chromium.org
> > > >    6. mailto:matthew.d.roper@intel.com
> > > >    7. mailto:intel-gfx@lists.freedesktop.org
> > > >    8. mailto:wei.c.li@intel.com
> > > >    9. mailto:dri-devel@lists.freedesktop.org
> > > >   10. mailto:matthew.d.roper@intel.com
> > > >   11. https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777
> > > >   12. mailto:dri-devel@lists.freedesktop.org
> > > >   13. mailto:wei.c.li@intel.com
> > > >   14. mailto:ville.syrjala@linux.intel.com
> > > >   15. mailto:Intel-gfx@lists.freedesktop.org
> > > >   16. https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >   17. mailto:dri-devel@lists.freedesktop.org
> > > >   18. https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > >
> > > --
> > > Matt Roper
> > > Graphics Software Engineer
> > > IoTG Platform Enabling & Development
> > > Intel Corporation
> > > (916) 356-2795
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel