* ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface (rev10)
2019-01-30 12:54 [v10 0/3] Add Colorspace connector property interface Uma Shankar
@ 2019-01-30 12:52 ` Patchwork
2019-01-30 12:54 ` [v10 1/3] drm: Add HDMI colorspace property Uma Shankar
` (4 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: Patchwork @ 2019-01-30 12:52 UTC (permalink / raw)
To: Uma Shankar; +Cc: intel-gfx
== Series Details ==
Series: Add Colorspace connector property interface (rev10)
URL : https://patchwork.freedesktop.org/series/47132/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9a1100d27d47 drm: Add HDMI colorspace property
a82fbbf3881e drm: Add DP colorspace property
-:64: CHECK:LINE_SPACING: Please don't use multiple blank lines
#64: FILE: drivers/gpu/drm/drm_connector.c:875:
+
+
total: 0 errors, 0 warnings, 1 checks, 43 lines checked
8cffc8dcba5a drm/i915: Attach colorspace property and enable modeset
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* [v10 0/3] Add Colorspace connector property interface
@ 2019-01-30 12:54 Uma Shankar
2019-01-30 12:52 ` ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface (rev10) Patchwork
` (5 more replies)
0 siblings, 6 replies; 17+ messages in thread
From: Uma Shankar @ 2019-01-30 12:54 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: ville.syrjala, maarten.lankhorst
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scenarios, a
particular colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
- This property is just to inform sink what colorspace
source is trying to drive.
Have tested this using xrandr by using below command:
xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"
v2: Addressed Ville and Maarten's review comments. Merged the 2nd
and 3rd patch into one common logical patch.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
default to an unset state where driver will assign the colorspace
when not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
v5: Modified the colorspace property creation helper to take
platform specific enum list based on the capabilities of the
platform as suggested by Shashank. With this there is no need
for segregation between DP and HDMI.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the kernel doc as well with more details.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Addressed Maarten' review comment, updated the RB from Maarten
and Jani Nikula's ack. Also fixed sparse warnings and checkpatch
complaints.
Uma Shankar (3):
drm: Add HDMI colorspace property
drm: Add DP colorspace property
drm/i915: Attach colorspace property and enable modeset
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 104 +++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_atomic.c | 1 +
drivers/gpu/drm/i915/intel_connector.c | 8 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 25 ++++++++
include/drm/drm_connector.h | 46 +++++++++++++++
7 files changed, 189 insertions(+)
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* [v10 1/3] drm: Add HDMI colorspace property
2019-01-30 12:54 [v10 0/3] Add Colorspace connector property interface Uma Shankar
2019-01-30 12:52 ` ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface (rev10) Patchwork
@ 2019-01-30 12:54 ` Uma Shankar
2019-02-01 18:50 ` Ville Syrjälä
2019-01-30 12:54 ` [v10 2/3] drm: Add DP " Uma Shankar
` (3 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Uma Shankar @ 2019-01-30 12:54 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: ville.syrjala, maarten.lankhorst
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 75 +++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 46 ++++++++++++++++++++++++
3 files changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8475396..ed10dd9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1548,6 +1572,57 @@ int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
/**
+ * DOC: standard connector properties
+ *
+ * Colorspace:
+ * drm_mode_create_colorspace_property - create colorspace property
+ * This property helps select a suitable colorspace based on the sink
+ * capability. Modern sink devices support wider gamut like BT2020.
+ * This helps switch to BT2020 mode if the BT2020 encoded video stream
+ * is being played by the user, same for any other colorspace. Thereby
+ * giving a good visual experience to users.
+ *
+ * The expectation from userspace is that it should parse the EDID
+ * and get supported colorspaces. Use this property and switch to the
+ * one supported. Sink supported colorspaces should be retrieved by
+ * userspace from EDID and driver will not explicitly expose them.
+ *
+ * Basically the expectation from userspace is:
+ * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
+ * colorspace
+ * - Set this new property to let the sink know what it
+ * converted the CRTC output to.
+ * - This property is just to inform sink what colorspace
+ * source is trying to drive.
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_colorspace_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+
+ if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace",
+ hdmi_colorspaces,
+ ARRAY_SIZE(hdmi_colorspaces));
+ if (!prop)
+ return -ENOMEM;
+ } else {
+ DRM_DEBUG_KMS("Colorspace property not supported\n");
+ return 0;
+ }
+
+ connector->colorspace_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_colorspace_property);
+
+/**
* drm_mode_create_content_type_property - create content type property
* @dev: DRM device
*
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 9941613..29495b3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -253,6 +253,38 @@ enum drm_panel_orientation {
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+/*
+ * This is a consolidated colorimetry list supported by HDMI and
+ * DP protocol standard. The respective connectors will register
+ * a property with the subset of this list (supported by that
+ * respective protocol). Userspace will set the colorspace through
+ * a colorspace property which will be created and exposed to
+ * userspace.
+ */
+
+/* For Default case, driver will set the colorspace */
+#define DRM_MODE_COLORIMETRY_DEFAULT 0
+/* CEA 861 Normal Colorimetry options */
+#define DRM_MODE_COLORIMETRY_ITU_601 1
+#define DRM_MODE_COLORIMETRY_ITU_709 2
+/* CEA 861 Extended Colorimetry Options */
+#define DRM_MODE_COLORIMETRY_XV_YCC_601 3
+#define DRM_MODE_COLORIMETRY_XV_YCC_709 4
+#define DRM_MODE_COLORIMETRY_S_YCC_601 5
+#define DRM_MODE_COLORIMETRY_OPYCC_601 6
+#define DRM_MODE_COLORIMETRY_OPRGB 7
+#define DRM_MODE_COLORIMETRY_BT2020_RGB 8
+#define DRM_MODE_COLORIMETRY_BT2020_YCC 9
+#define DRM_MODE_COLORIMETRY_BT2020_CYCC 10
+/* DP MSA Colorimetry Options */
+#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601 11
+#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709 12
+#define DRM_MODE_DP_COLORIMETRY_SRGB 13
+#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 14
+#define DRM_MODE_DP_COLORIMETRY_SCRGB 15
+#define DRM_MODE_DP_COLORIMETRY_DCI_P3 16
+#define DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17
+
/**
* struct drm_display_info - runtime data about the connected sink
*
@@ -503,6 +535,13 @@ struct drm_connector_state {
unsigned int content_protection;
/**
+ * @colorspace: State variable for Connector property to request
+ * colorspace change on Sink. This is most commonly used to switch
+ * to wider color gamuts like BT2020.
+ */
+ u32 colorspace;
+
+ /**
* @writeback_job: Writeback job for writeback connectors
*
* Holds the framebuffer and out-fence for a writeback connector. As
@@ -995,6 +1034,12 @@ struct drm_connector {
struct drm_property *content_protection_property;
/**
+ * @colorspace_property: Connector property to set the suitable
+ * colorspace supported by the sink.
+ */
+ struct drm_property *colorspace_property;
+
+ /**
* @path_blob_ptr:
*
* DRM blob property data for the DP MST path property. This should only
@@ -1269,6 +1314,7 @@ int drm_connector_attach_vrr_capable_property(
int drm_connector_attach_content_protection_property(
struct drm_connector *connector);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
+int drm_mode_create_colorspace_property(struct drm_connector *connector);
int drm_mode_create_content_type_property(struct drm_device *dev);
void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame,
const struct drm_connector_state *conn_state);
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [v10 2/3] drm: Add DP colorspace property
2019-01-30 12:54 [v10 0/3] Add Colorspace connector property interface Uma Shankar
2019-01-30 12:52 ` ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface (rev10) Patchwork
2019-01-30 12:54 ` [v10 1/3] drm: Add HDMI colorspace property Uma Shankar
@ 2019-01-30 12:54 ` Uma Shankar
2019-02-01 19:17 ` Ville Syrjälä
2019-01-30 12:54 ` [v10 3/3] drm/i915: Attach colorspace property and enable modeset Uma Shankar
` (2 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Uma Shankar @ 2019-01-30 12:54 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: ville.syrjala, emil.l.velikov, Uma Shankar, maarten.lankhorst
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Split the changes to have separate colorspace property for
DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
drivers/gpu/drm/drm_connector.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ed10dd9..b331be8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
};
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* DP MSA Colorimetry */
+ { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
+ { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
+ { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
+ { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
+ { DRM_MODE_DP_COLORIMETRY_DCI_P3, "DCI-P3" },
+ { DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Profile" },
+};
+
+
/**
* DOC: standard connector properties
*
@@ -1611,6 +1634,14 @@ int drm_mode_create_colorspace_property(struct drm_connector *connector)
ARRAY_SIZE(hdmi_colorspaces));
if (!prop)
return -ENOMEM;
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace", dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
+
+ if (!prop)
+ return -ENOMEM;
} else {
DRM_DEBUG_KMS("Colorspace property not supported\n");
return 0;
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [v10 3/3] drm/i915: Attach colorspace property and enable modeset
2019-01-30 12:54 [v10 0/3] Add Colorspace connector property interface Uma Shankar
` (2 preceding siblings ...)
2019-01-30 12:54 ` [v10 2/3] drm: Add DP " Uma Shankar
@ 2019-01-30 12:54 ` Uma Shankar
2019-02-01 19:01 ` Ville Syrjälä
2019-01-30 13:10 ` ✓ Fi.CI.BAT: success for Add Colorspace connector property interface (rev10) Patchwork
2019-01-30 16:00 ` ✓ Fi.CI.IGT: " Patchwork
5 siblings, 1 reply; 17+ messages in thread
From: Uma Shankar @ 2019-01-30 12:54 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: ville.syrjala, maarten.lankhorst
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed a checkpatch complaint, Addressed Maarten' review
comment, updated the RB from Maarten and Jani's ack.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
drivers/gpu/drm/i915/intel_atomic.c | 1 +
drivers/gpu/drm/i915/intel_connector.c | 8 ++++++++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 25 +++++++++++++++++++++++++
4 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..a4bb906 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_conn_state->base.colorspace != old_conn_state->base.colorspace ||
new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..8352d0b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
}
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+ if (!drm_mode_create_colorspace_property(connector))
+ drm_object_attach_property(&connector->base,
+ connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85b913e..5178a9a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct drm_connector *connector,
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 97a98e1..5c5009d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
+ /* Set ITU 709 as default for HDMI */
+ frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;
+ } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XV_YCC_601) {
+ frame.avi.colorimetry = conn_state->colorspace;
+ } else {
+ frame.avi.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ /*
+ * Starting from extended list where COLORIMETRY_XV_YCC_601
+ * is the first extended mode and its value is 0 as per HDMI
+ * specification.
+ * TODO: This needs to be extended for LSPCON implementation
+ * as well. Will be implemented separately.
+ */
+ frame.avi.extended_colorimetry = conn_state->colorspace -
+ DRM_MODE_COLORIMETRY_XV_YCC_601;
+ }
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi,
conn_state->connector,
adjusted_mode,
@@ -2143,10 +2161,17 @@ static void intel_hdmi_destroy(struct drm_connector *connector)
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_digital_port *intel_dig_port =
+ hdmi_to_dig_port(intel_hdmi);
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+
+ /* Attach Colorspace property for Non LSPCON based device */
+ if (!intel_dig_port->lspcon.active)
+ intel_attach_colorspace_property(connector);
+
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread
* ✓ Fi.CI.BAT: success for Add Colorspace connector property interface (rev10)
2019-01-30 12:54 [v10 0/3] Add Colorspace connector property interface Uma Shankar
` (3 preceding siblings ...)
2019-01-30 12:54 ` [v10 3/3] drm/i915: Attach colorspace property and enable modeset Uma Shankar
@ 2019-01-30 13:10 ` Patchwork
2019-01-30 16:00 ` ✓ Fi.CI.IGT: " Patchwork
5 siblings, 0 replies; 17+ messages in thread
From: Patchwork @ 2019-01-30 13:10 UTC (permalink / raw)
To: Uma Shankar; +Cc: intel-gfx
== Series Details ==
Series: Add Colorspace connector property interface (rev10)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5508 -> Patchwork_12087
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47132/revisions/10/mbox/
Known issues
------------
Here are the changes found in Patchwork_12087 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998] +1
#### Possible fixes ####
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: {SKIP} [fdo#109271] / [fdo#109278] -> PASS +2
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-kbl-7560u: INCOMPLETE [fdo#108767] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: {SKIP} [fdo#109271] -> PASS +33
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (45 -> 39)
------------------------------
Missing (6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-gdg-551 fi-byt-clapper
Build changes
-------------
* Linux: CI_DRM_5508 -> Patchwork_12087
CI_DRM_5508: 2621b0168c75d062f272dd50f5073ad35dfdd946 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4799: 4177d0d6a40fe96e3d859be0413bf66ef9a8a606 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12087: 8cffc8dcba5a656d621a2b614335b5abb1410f1f @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8cffc8dcba5a drm/i915: Attach colorspace property and enable modeset
a82fbbf3881e drm: Add DP colorspace property
9a1100d27d47 drm: Add HDMI colorspace property
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12087/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* ✓ Fi.CI.IGT: success for Add Colorspace connector property interface (rev10)
2019-01-30 12:54 [v10 0/3] Add Colorspace connector property interface Uma Shankar
` (4 preceding siblings ...)
2019-01-30 13:10 ` ✓ Fi.CI.BAT: success for Add Colorspace connector property interface (rev10) Patchwork
@ 2019-01-30 16:00 ` Patchwork
5 siblings, 0 replies; 17+ messages in thread
From: Patchwork @ 2019-01-30 16:00 UTC (permalink / raw)
To: Uma Shankar; +Cc: intel-gfx
== Series Details ==
Series: Add Colorspace connector property interface (rev10)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5508_full -> Patchwork_12087_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_12087_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-glk: PASS -> FAIL [fdo#106641]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-snb: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-alpha-transparent:
- shard-snb: NOTRUN -> FAIL [fdo#109350]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: PASS -> FAIL [fdo#103166]
#### Possible fixes ####
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_flip@flip-vs-expired-vblank:
- shard-kbl: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_plane@pixel-format-pipe-c-planes:
- shard-glk: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-glk: FAIL [fdo#108145] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#106641]: https://bugs.freedesktop.org/show_bug.cgi?id=106641
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
------------------------------
Missing (2): shard-skl shard-iclb
Build changes
-------------
* Linux: CI_DRM_5508 -> Patchwork_12087
CI_DRM_5508: 2621b0168c75d062f272dd50f5073ad35dfdd946 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4799: 4177d0d6a40fe96e3d859be0413bf66ef9a8a606 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12087: 8cffc8dcba5a656d621a2b614335b5abb1410f1f @ 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_12087/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [v10 1/3] drm: Add HDMI colorspace property
2019-01-30 12:54 ` [v10 1/3] drm: Add HDMI colorspace property Uma Shankar
@ 2019-02-01 18:50 ` Ville Syrjälä
2019-02-04 15:25 ` Ville Syrjälä
0 siblings, 1 reply; 17+ messages in thread
From: Ville Syrjälä @ 2019-02-01 18:50 UTC (permalink / raw)
To: Uma Shankar; +Cc: intel-gfx, ville.syrjala, maarten.lankhorst, dri-devel
On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> Create a new connector property to program colorspace to sink
> devices. Modern sink devices support more than 1 type of
> colorspace like 601, 709, BT2020 etc. This helps to switch
> based on content type which is to be displayed. The decision
> lies with compositors as to in which scenarios, a particular
> colorspace will be picked.
>
> This will be helpful mostly to switch to higher gamut colorspaces
> like BT2020 when the media content is encoded as BT2020. Thereby
> giving a good visual experience to users.
>
> The expectation from userspace is that it should parse the EDID
> and get supported colorspaces. Use this property and switch to the
> one supported. Sink supported colorspaces should be retrieved by
> userspace from EDID and driver will not explicitly expose them.
>
> Basically the expectation from userspace is:
> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> colorspace
> - Set this new property to let the sink know what it
> converted the CRTC output to.
>
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to incorporate both HDMI and DP supported
> colorspaces. Also, added a default option for colorspace.
>
> v3: Removed Adobe references from enum definitions as per
> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> Default to an unset state where driver will assign the colorspace
> is not chosen by user, suggested by Ville and Maarten. Addressed
> other misc review comments from Maarten. Split the changes to
> have separate colorspace property for DP and HDMI.
>
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard.
>
> v5: Made the property creation helper accept enum list based on
> platform capabilties as suggested by Shashank. Consolidated HDMI
> and DP property creation in the common helper.
>
> v6: Addressed Shashank's review comments.
>
> v7: Added defines instead of enum in uapi as per Brian Starkey's
> suggestion in order to go with string matching at userspace. Updated
> the commit message to add more details as well kernel docs.
>
> v8: Addressed Maarten's review comments.
>
> v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> Stone's comments and moved to drm include file. Moved back to older
> design with exposing all HDMI colorspaces to userspace since infoframe
> capability is there even on legacy platforms, as per Ville's review
> comments.
>
> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 75 +++++++++++++++++++++++++++++++++++++++
> include/drm/drm_connector.h | 46 ++++++++++++++++++++++++
> 3 files changed, 125 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9a1f41a..9b5d44f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == connector->colorspace_property) {
> + state->colorspace = val;
> } else if (property == config->writeback_fb_id_property) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, val);
> int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> *val = state->picture_aspect_ratio;
> } else if (property == config->content_type_property) {
> *val = state->content_type;
> + } else if (property == connector->colorspace_property) {
> + *val = state->colorspace;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8475396..ed10dd9 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
> };
> DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
>
> +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
The spec no longer has the BT.601 note here. Which I guess makes sense
since BT.601 didn't even specify any color primaries initially. Later
versions do by they have distinct primaries for NTSC vs. PAL. The spec
calls this just SMPTE 170M now, so I think we should do the same.
> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 [33] */
> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
The spelling is rather inconsistent here. XV_ vs. S_ vs. op. Why not use
the same spelling style for all?
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
"BT2020" vs. "ITU_709" is rather inconsistent as well.
We also seem to be missing the two DCI-P3 things here.
> +};
> +
> /**
> * DOC: standard connector properties
> *
> @@ -1548,6 +1572,57 @@ int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
> EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
>
> /**
> + * DOC: standard connector properties
> + *
> + * Colorspace:
> + * drm_mode_create_colorspace_property - create colorspace property
> + * This property helps select a suitable colorspace based on the sink
> + * capability. Modern sink devices support wider gamut like BT2020.
> + * This helps switch to BT2020 mode if the BT2020 encoded video stream
> + * is being played by the user, same for any other colorspace. Thereby
> + * giving a good visual experience to users.
> + *
> + * The expectation from userspace is that it should parse the EDID
> + * and get supported colorspaces. Use this property and switch to the
> + * one supported. Sink supported colorspaces should be retrieved by
> + * userspace from EDID and driver will not explicitly expose them.
> + *
> + * Basically the expectation from userspace is:
> + * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> + * colorspace
> + * - Set this new property to let the sink know what it
> + * converted the CRTC output to.
> + * - This property is just to inform sink what colorspace
> + * source is trying to drive.
> + *
> + * Called by a driver the first time it's needed, must be attached to desired
> + * connectors.
> + */
> +int drm_mode_create_colorspace_property(struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> + "Colorspace",
> + hdmi_colorspaces,
> + ARRAY_SIZE(hdmi_colorspaces));
> + if (!prop)
> + return -ENOMEM;
> + } else {
> + DRM_DEBUG_KMS("Colorspace property not supported\n");
> + return 0;
> + }
> +
> + connector->colorspace_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_colorspace_property);
> +
> +/**
> * drm_mode_create_content_type_property - create content type property
> * @dev: DRM device
> *
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 9941613..29495b3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -253,6 +253,38 @@ enum drm_panel_orientation {
> DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> };
>
> +/*
> + * This is a consolidated colorimetry list supported by HDMI and
> + * DP protocol standard. The respective connectors will register
> + * a property with the subset of this list (supported by that
> + * respective protocol). Userspace will set the colorspace through
> + * a colorspace property which will be created and exposed to
> + * userspace.
> + */
> +
> +/* For Default case, driver will set the colorspace */
> +#define DRM_MODE_COLORIMETRY_DEFAULT 0
> +/* CEA 861 Normal Colorimetry options */
> +#define DRM_MODE_COLORIMETRY_ITU_601 1
> +#define DRM_MODE_COLORIMETRY_ITU_709 2
> +/* CEA 861 Extended Colorimetry Options */
> +#define DRM_MODE_COLORIMETRY_XV_YCC_601 3
> +#define DRM_MODE_COLORIMETRY_XV_YCC_709 4
> +#define DRM_MODE_COLORIMETRY_S_YCC_601 5
> +#define DRM_MODE_COLORIMETRY_OPYCC_601 6
> +#define DRM_MODE_COLORIMETRY_OPRGB 7
> +#define DRM_MODE_COLORIMETRY_BT2020_RGB 8
> +#define DRM_MODE_COLORIMETRY_BT2020_YCC 9
> +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 10
> +/* DP MSA Colorimetry Options */
> +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601 11
> +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709 12
> +#define DRM_MODE_DP_COLORIMETRY_SRGB 13
> +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 14
> +#define DRM_MODE_DP_COLORIMETRY_SCRGB 15
> +#define DRM_MODE_DP_COLORIMETRY_DCI_P3 16
> +#define DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17
I think some kind of macro to define these would be good. Assuming we're
trying directly interpret these as the C/EC/ACE bits. I can't remember
if multiple enum values can have the same integer value. If not we'd
also need a YCbCr vs. RGB bit in there somewhere. Assuming we want to
keep RGB and YCbCr separate. Currently only BT.2020 has a conflict
between the two.
> +
> /**
> * struct drm_display_info - runtime data about the connected sink
> *
> @@ -503,6 +535,13 @@ struct drm_connector_state {
> unsigned int content_protection;
>
> /**
> + * @colorspace: State variable for Connector property to request
> + * colorspace change on Sink. This is most commonly used to switch
> + * to wider color gamuts like BT2020.
> + */
> + u32 colorspace;
> +
> + /**
> * @writeback_job: Writeback job for writeback connectors
> *
> * Holds the framebuffer and out-fence for a writeback connector. As
> @@ -995,6 +1034,12 @@ struct drm_connector {
> struct drm_property *content_protection_property;
>
> /**
> + * @colorspace_property: Connector property to set the suitable
> + * colorspace supported by the sink.
> + */
> + struct drm_property *colorspace_property;
> +
> + /**
> * @path_blob_ptr:
> *
> * DRM blob property data for the DP MST path property. This should only
> @@ -1269,6 +1314,7 @@ int drm_connector_attach_vrr_capable_property(
> int drm_connector_attach_content_protection_property(
> struct drm_connector *connector);
> int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> +int drm_mode_create_colorspace_property(struct drm_connector *connector);
> int drm_mode_create_content_type_property(struct drm_device *dev);
> void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame,
> const struct drm_connector_state *conn_state);
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [v10 3/3] drm/i915: Attach colorspace property and enable modeset
2019-01-30 12:54 ` [v10 3/3] drm/i915: Attach colorspace property and enable modeset Uma Shankar
@ 2019-02-01 19:01 ` Ville Syrjälä
2019-02-04 17:18 ` Shankar, Uma
0 siblings, 1 reply; 17+ messages in thread
From: Ville Syrjälä @ 2019-02-01 19:01 UTC (permalink / raw)
To: Uma Shankar; +Cc: intel-gfx, ville.syrjala, maarten.lankhorst, dri-devel
On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appropriate colorspace. This can be used to send an
> infoframe packet with proper colorspace value set which
> will help to enable wider color gamut like BT2020 on sink.
>
> This patch attaches and enables HDMI colorspace, DP will be
> taken care separately.
>
> v2: Merged the changes of creating infoframe as well to this
> patch as per Maarten's suggestion.
>
> v3: Addressed review comments from Shashank. Separated HDMI
> and DP colorspaces as suggested by Ville and Maarten.
>
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard. Handle the default case properly.
>
> v5: Merged the DP handling along with platform colorspace
> handling as per Shashank's comments.
>
> v6: Reverted to old design of exposing all colorspaces to
> userspace as per Ville's review comment
>
> v7: Fixed a checkpatch complaint, Addressed Maarten' review
> comment, updated the RB from Maarten and Jani's ack.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/intel_connector.c | 8 ++++++++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 25 +++++++++++++++++++++++++
> 4 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c
> index 16263ad..a4bb906 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn,
> */
> if (new_conn_state->force_audio != old_conn_state->force_audio ||
> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
> + new_conn_state->base.colorspace != old_conn_state->base.colorspace ||
> new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio ||
> new_conn_state->base.content_type != old_conn_state->base.content_type ||
> new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode)
> diff --git a/drivers/gpu/drm/i915/intel_connector.c b/drivers/gpu/drm/i915/intel_connector.c
> index ee16758..8352d0b 100644
> --- a/drivers/gpu/drm/i915/intel_connector.c
> +++ b/drivers/gpu/drm/i915/intel_connector.c
> @@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
> connector->dev->mode_config.aspect_ratio_property,
> DRM_MODE_PICTURE_ASPECT_NONE);
> }
> +
> +void
> +intel_attach_colorspace_property(struct drm_connector *connector)
> +{
> + if (!drm_mode_create_colorspace_property(connector))
> + drm_object_attach_property(&connector->base,
> + connector->colorspace_property, 0);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 85b913e..5178a9a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct drm_connector *connector,
> void intel_attach_force_audio_property(struct drm_connector *connector);
> void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
> void intel_attach_aspect_ratio_property(struct drm_connector *connector);
> +void intel_attach_colorspace_property(struct drm_connector *connector);
>
> /* intel_csr.c */
> void intel_csr_ucode_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
> index 97a98e1..5c5009d 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
> else
> frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>
> + if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
> + /* Set ITU 709 as default for HDMI */
> + frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;
Default should map to NONE.
> + } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XV_YCC_601) {
> + frame.avi.colorimetry = conn_state->colorspace;
> + } else {
> + frame.avi.colorimetry = HDMI_COLORIMETRY_EXTENDED;
> + /*
> + * Starting from extended list where COLORIMETRY_XV_YCC_601
> + * is the first extended mode and its value is 0 as per HDMI
> + * specification.
> + * TODO: This needs to be extended for LSPCON implementation
> + * as well. Will be implemented separately.
> + */
> + frame.avi.extended_colorimetry = conn_state->colorspace -
> + DRM_MODE_COLORIMETRY_XV_YCC_601;
> + }
This code seems like something that should be in the core.
Like said earlier maybe we could just directly map the
values to these bits, and then this should just become
if.colorimetry = val & 0x3;
if.extended_colorimetry = (val >> 2) & 0x7;
if.ace = (val >> 5) & 0xf;
Hmm, looks like hdmi.h doesn't even know about the ACE bits yet :(
> +
> drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> conn_state->connector,
> adjusted_mode,
> @@ -2143,10 +2161,17 @@ static void intel_hdmi_destroy(struct drm_connector *connector)
> intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_digital_port *intel_dig_port =
> + hdmi_to_dig_port(intel_hdmi);
>
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> intel_attach_aspect_ratio_property(connector);
> +
> + /* Attach Colorspace property for Non LSPCON based device */
> + if (!intel_dig_port->lspcon.active)
> + intel_attach_colorspace_property(connector);
> +
> drm_connector_attach_content_type_property(connector);
> connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [v10 2/3] drm: Add DP colorspace property
2019-01-30 12:54 ` [v10 2/3] drm: Add DP " Uma Shankar
@ 2019-02-01 19:17 ` Ville Syrjälä
2019-02-04 17:12 ` Shankar, Uma
0 siblings, 1 reply; 17+ messages in thread
From: Ville Syrjälä @ 2019-02-01 19:17 UTC (permalink / raw)
To: Uma Shankar; +Cc: intel-gfx, ville.syrjala, maarten.lankhorst, dri-devel
On Wed, Jan 30, 2019 at 06:24:25PM +0530, Uma Shankar wrote:
> This patch adds a DP colorspace property, enabling
> userspace to switch to various supported colorspaces.
> This will help enable BT2020 along with other colorspaces.
>
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to incorporate both HDMI and DP supported
> colorspaces. Also, added a default option for colorspace.
>
> v3: Split the changes to have separate colorspace property for
> DP and HDMI.
>
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard.
>
> v5: Merged the DP handling along with platform colorspace
> handling as per Shashank's comments.
>
> v6: Reverted to old design of exposing all colorspaces to
> userspace as per Ville's review comment
>
> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> ---
> drivers/gpu/drm/drm_connector.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index ed10dd9..b331be8 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
> { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> };
>
> +static const struct drm_prop_enum_list dp_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
What's with the duplicated 601/709 values? I think in the HDMI verison
you had only these ones here. Maybe we want to actually state explicitly
that they are for YCbCr, if only to be consistent with the
BT2020 values.
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + /* DP MSA Colorimetry */
> + { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
> + { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
> + { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
> + { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
> + { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
> + { DRM_MODE_DP_COLORIMETRY_DCI_P3, "DCI-P3" },
> + { DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Profile" },
I don't think we want this last one since we don't implement anything
that could transmit the custom profile.
The MSA bits are have "CEA RGB" which we probably want to keep hidden
since it seems to be just a poorly specced limited range vs. full range
knob, and we already have a mechanism for that. The Y-only and RAW I
guess we can skip. Not sure anyone would ever have use for those.
> +};
> +
> +
> /**
> * DOC: standard connector properties
> *
> @@ -1611,6 +1634,14 @@ int drm_mode_create_colorspace_property(struct drm_connector *connector)
> ARRAY_SIZE(hdmi_colorspaces));
> if (!prop)
> return -ENOMEM;
> + } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> + connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> + "Colorspace", dp_colorspaces,
> + ARRAY_SIZE(dp_colorspaces));
> +
> + if (!prop)
> + return -ENOMEM;
> } else {
> DRM_DEBUG_KMS("Colorspace property not supported\n");
> return 0;
> --
> 1.9.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [v10 1/3] drm: Add HDMI colorspace property
2019-02-01 18:50 ` Ville Syrjälä
@ 2019-02-04 15:25 ` Ville Syrjälä
2019-02-04 17:08 ` [Intel-gfx] " Shankar, Uma
0 siblings, 1 reply; 17+ messages in thread
From: Ville Syrjälä @ 2019-02-04 15:25 UTC (permalink / raw)
To: Uma Shankar; +Cc: intel-gfx, ville.syrjala, dri-devel, maarten.lankhorst
On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> > Create a new connector property to program colorspace to sink
> > devices. Modern sink devices support more than 1 type of
> > colorspace like 601, 709, BT2020 etc. This helps to switch
> > based on content type which is to be displayed. The decision
> > lies with compositors as to in which scenarios, a particular
> > colorspace will be picked.
> >
> > This will be helpful mostly to switch to higher gamut colorspaces
> > like BT2020 when the media content is encoded as BT2020. Thereby
> > giving a good visual experience to users.
> >
> > The expectation from userspace is that it should parse the EDID
> > and get supported colorspaces. Use this property and switch to the
> > one supported. Sink supported colorspaces should be retrieved by
> > userspace from EDID and driver will not explicitly expose them.
> >
> > Basically the expectation from userspace is:
> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> > colorspace
> > - Set this new property to let the sink know what it
> > converted the CRTC output to.
> >
> > v2: Addressed Maarten and Ville's review comments. Enhanced
> > the colorspace enum to incorporate both HDMI and DP supported
> > colorspaces. Also, added a default option for colorspace.
> >
> > v3: Removed Adobe references from enum definitions as per
> > Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> > Default to an unset state where driver will assign the colorspace
> > is not chosen by user, suggested by Ville and Maarten. Addressed
> > other misc review comments from Maarten. Split the changes to
> > have separate colorspace property for DP and HDMI.
> >
> > v4: Addressed Chris and Ville's review comments, and created a
> > common colorspace property for DP and HDMI, filtered the list
> > based on the colorspaces supported by the respective protocol
> > standard.
> >
> > v5: Made the property creation helper accept enum list based on
> > platform capabilties as suggested by Shashank. Consolidated HDMI
> > and DP property creation in the common helper.
> >
> > v6: Addressed Shashank's review comments.
> >
> > v7: Added defines instead of enum in uapi as per Brian Starkey's
> > suggestion in order to go with string matching at userspace. Updated
> > the commit message to add more details as well kernel docs.
> >
> > v8: Addressed Maarten's review comments.
> >
> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> > Stone's comments and moved to drm include file. Moved back to older
> > design with exposing all HDMI colorspaces to userspace since infoframe
> > capability is there even on legacy platforms, as per Ville's review
> > comments.
> >
> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > Acked-by: Jani Nikula <jani.nikula@intel.com>
> > Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
> > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > drivers/gpu/drm/drm_connector.c | 75 +++++++++++++++++++++++++++++++++++++++
> > include/drm/drm_connector.h | 46 ++++++++++++++++++++++++
> > 3 files changed, 125 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9a1f41a..9b5d44f 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > return -EINVAL;
> > }
> > state->content_protection = val;
> > + } else if (property == connector->colorspace_property) {
> > + state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) {
> > struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, val);
> > int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > *val = state->picture_aspect_ratio;
> > } else if (property == config->content_type_property) {
> > *val = state->content_type;
> > + } else if (property == connector->colorspace_property) {
> > + *val = state->colorspace;
> > } else if (property == connector->scaling_mode_property) {
> > *val = state->scaling_mode;
> > } else if (property == connector->content_protection_property) {
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 8475396..ed10dd9 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
> > };
> > DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> >
> > +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> > + /* For Default case, driver will set the colorspace */
> > + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> > + /* Standard Definition Colorimetry based on CEA 861 */
> > + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>
> The spec no longer has the BT.601 note here. Which I guess makes sense
> since BT.601 didn't even specify any color primaries initially. Later
> versions do by they have distinct primaries for NTSC vs. PAL. The spec
> calls this just SMPTE 170M now, so I think we should do the same.
>
> > + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> > + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> > + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> > + /* High Definition Colorimetry based on IEC 61966-2-4 */
> > + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> > + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> > + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> > + /* Colorimetry based on IEC 61966-2-5 [33] */
> > + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>
> The spelling is rather inconsistent here. XV_ vs. S_ vs. op. Why not use
> the same spelling style for all?
>
> > + /* Colorimetry based on IEC 61966-2-5 */
> > + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>
> "BT2020" vs. "ITU_709" is rather inconsistent as well.
>
> We also seem to be missing the two DCI-P3 things here.
>
> > +};
> > +
> > /**
> > * DOC: standard connector properties
> > *
> > @@ -1548,6 +1572,57 @@ int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
> > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> >
> > /**
> > + * DOC: standard connector properties
> > + *
> > + * Colorspace:
> > + * drm_mode_create_colorspace_property - create colorspace property
> > + * This property helps select a suitable colorspace based on the sink
> > + * capability. Modern sink devices support wider gamut like BT2020.
> > + * This helps switch to BT2020 mode if the BT2020 encoded video stream
> > + * is being played by the user, same for any other colorspace. Thereby
> > + * giving a good visual experience to users.
> > + *
> > + * The expectation from userspace is that it should parse the EDID
> > + * and get supported colorspaces. Use this property and switch to the
> > + * one supported. Sink supported colorspaces should be retrieved by
> > + * userspace from EDID and driver will not explicitly expose them.
> > + *
> > + * Basically the expectation from userspace is:
> > + * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> > + * colorspace
> > + * - Set this new property to let the sink know what it
> > + * converted the CRTC output to.
> > + * - This property is just to inform sink what colorspace
> > + * source is trying to drive.
> > + *
> > + * Called by a driver the first time it's needed, must be attached to desired
> > + * connectors.
> > + */
> > +int drm_mode_create_colorspace_property(struct drm_connector *connector)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct drm_property *prop;
> > +
> > + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> > + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> > + "Colorspace",
> > + hdmi_colorspaces,
> > + ARRAY_SIZE(hdmi_colorspaces));
> > + if (!prop)
> > + return -ENOMEM;
> > + } else {
> > + DRM_DEBUG_KMS("Colorspace property not supported\n");
> > + return 0;
> > + }
> > +
> > + connector->colorspace_property = prop;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_mode_create_colorspace_property);
> > +
> > +/**
> > * drm_mode_create_content_type_property - create content type property
> > * @dev: DRM device
> > *
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 9941613..29495b3 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -253,6 +253,38 @@ enum drm_panel_orientation {
> > DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> > };
> >
> > +/*
> > + * This is a consolidated colorimetry list supported by HDMI and
> > + * DP protocol standard. The respective connectors will register
> > + * a property with the subset of this list (supported by that
> > + * respective protocol). Userspace will set the colorspace through
> > + * a colorspace property which will be created and exposed to
> > + * userspace.
> > + */
> > +
> > +/* For Default case, driver will set the colorspace */
> > +#define DRM_MODE_COLORIMETRY_DEFAULT 0
> > +/* CEA 861 Normal Colorimetry options */
> > +#define DRM_MODE_COLORIMETRY_ITU_601 1
> > +#define DRM_MODE_COLORIMETRY_ITU_709 2
> > +/* CEA 861 Extended Colorimetry Options */
> > +#define DRM_MODE_COLORIMETRY_XV_YCC_601 3
> > +#define DRM_MODE_COLORIMETRY_XV_YCC_709 4
> > +#define DRM_MODE_COLORIMETRY_S_YCC_601 5
> > +#define DRM_MODE_COLORIMETRY_OPYCC_601 6
> > +#define DRM_MODE_COLORIMETRY_OPRGB 7
> > +#define DRM_MODE_COLORIMETRY_BT2020_RGB 8
> > +#define DRM_MODE_COLORIMETRY_BT2020_YCC 9
> > +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 10
> > +/* DP MSA Colorimetry Options */
> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601 11
> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709 12
> > +#define DRM_MODE_DP_COLORIMETRY_SRGB 13
> > +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 14
> > +#define DRM_MODE_DP_COLORIMETRY_SCRGB 15
> > +#define DRM_MODE_DP_COLORIMETRY_DCI_P3 16
> > +#define DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17
>
> I think some kind of macro to define these would be good. Assuming we're
> trying directly interpret these as the C/EC/ACE bits. I can't remember
> if multiple enum values can have the same integer value. If not we'd
> also need a YCbCr vs. RGB bit in there somewhere. Assuming we want to
> keep RGB and YCbCr separate. Currently only BT.2020 has a conflict
> between the two.
So I think I'm leaning towards having separate YCbCr vs. RGB values
(which is what you had here already, with BT.2020 being the only
case where that actually matters). That way someone could even do
YCbCr 4:4:4 passthrough by just stuffing YUV data into their RGB
framebuffer (with the components swizzled the right way).
The one thing that rather breaks that usecase is the automagic 4k
YCbCr 4:2:0 fallback. So in in order to guarantee that things
work correctly I guess we still need explcit control over the
output CSC.
Ie. some kind of output color encoding prop like this:
default /* current behaviour */
ycbcr BT.601
ycbcr BT.709
ycbcr BT.2020
/* no ycbcr 4:2:0 fallback for below modes? */
rgb 4:4:4
ycbcr 4:4:4 BT.601
ycbcr 4:4:4 BT.709
ycbcr 4:4:4 BT.2020
ycbcr 4:2:2 BT.601
ycbcr 4:2:2 BT.709
ycbcr 4:2:2 BT.2020
ycbcr 4:2:0 BT.601
ycbcr 4:2:0 BT.709
ycbcr 4:2:0 BT.2020
Hmm. In fact the automagic 4:2:0 fallback sort of breaks the
colorspace prop alredy because if someone set an RGB colorspace
but we end up converting to YCbCr 4:2:0 what should we tell the
sink? Maybe we just reject the modeset in that case and tell
users they need to wait for the output color encoding prop to
support that usecase?
>
> > +
> > /**
> > * struct drm_display_info - runtime data about the connected sink
> > *
> > @@ -503,6 +535,13 @@ struct drm_connector_state {
> > unsigned int content_protection;
> >
> > /**
> > + * @colorspace: State variable for Connector property to request
> > + * colorspace change on Sink. This is most commonly used to switch
> > + * to wider color gamuts like BT2020.
> > + */
> > + u32 colorspace;
> > +
> > + /**
> > * @writeback_job: Writeback job for writeback connectors
> > *
> > * Holds the framebuffer and out-fence for a writeback connector. As
> > @@ -995,6 +1034,12 @@ struct drm_connector {
> > struct drm_property *content_protection_property;
> >
> > /**
> > + * @colorspace_property: Connector property to set the suitable
> > + * colorspace supported by the sink.
> > + */
> > + struct drm_property *colorspace_property;
> > +
> > + /**
> > * @path_blob_ptr:
> > *
> > * DRM blob property data for the DP MST path property. This should only
> > @@ -1269,6 +1314,7 @@ int drm_connector_attach_vrr_capable_property(
> > int drm_connector_attach_content_protection_property(
> > struct drm_connector *connector);
> > int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> > +int drm_mode_create_colorspace_property(struct drm_connector *connector);
> > int drm_mode_create_content_type_property(struct drm_device *dev);
> > void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame,
> > const struct drm_connector_state *conn_state);
> > --
> > 1.9.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
2019-02-04 15:25 ` Ville Syrjälä
@ 2019-02-04 17:08 ` Shankar, Uma
2019-02-04 17:24 ` Ville Syrjälä
0 siblings, 1 reply; 17+ messages in thread
From: Shankar, Uma @ 2019-02-04 17:08 UTC (permalink / raw)
To: Ville Syrjälä
Cc: intel-gfx, Syrjala, Ville, dri-devel, Lankhorst, Maarten
>-----Original Message-----
>From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
>Sent: Monday, February 4, 2019 8:55 PM
>To: Shankar, Uma <uma.shankar@intel.com>
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville <ville.syrjala@intel.com>;
>Lankhorst, Maarten <maarten.lankhorst@intel.com>; dri-
>devel@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>
>On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
>> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
>> > Create a new connector property to program colorspace to sink
>> > devices. Modern sink devices support more than 1 type of colorspace
>> > like 601, 709, BT2020 etc. This helps to switch based on content
>> > type which is to be displayed. The decision lies with compositors as
>> > to in which scenarios, a particular colorspace will be picked.
>> >
>> > This will be helpful mostly to switch to higher gamut colorspaces
>> > like BT2020 when the media content is encoded as BT2020. Thereby
>> > giving a good visual experience to users.
>> >
>> > The expectation from userspace is that it should parse the EDID and
>> > get supported colorspaces. Use this property and switch to the one
>> > supported. Sink supported colorspaces should be retrieved by
>> > userspace from EDID and driver will not explicitly expose them.
>> >
>> > Basically the expectation from userspace is:
>> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> > colorspace
>> > - Set this new property to let the sink know what it
>> > converted the CRTC output to.
>> >
>> > v2: Addressed Maarten and Ville's review comments. Enhanced the
>> > colorspace enum to incorporate both HDMI and DP supported
>> > colorspaces. Also, added a default option for colorspace.
>> >
>> > v3: Removed Adobe references from enum definitions as per Ville,
>> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
>> > unset state where driver will assign the colorspace is not chosen by
>> > user, suggested by Ville and Maarten. Addressed other misc review
>> > comments from Maarten. Split the changes to have separate colorspace
>> > property for DP and HDMI.
>> >
>> > v4: Addressed Chris and Ville's review comments, and created a
>> > common colorspace property for DP and HDMI, filtered the list based
>> > on the colorspaces supported by the respective protocol standard.
>> >
>> > v5: Made the property creation helper accept enum list based on
>> > platform capabilties as suggested by Shashank. Consolidated HDMI and
>> > DP property creation in the common helper.
>> >
>> > v6: Addressed Shashank's review comments.
>> >
>> > v7: Added defines instead of enum in uapi as per Brian Starkey's
>> > suggestion in order to go with string matching at userspace. Updated
>> > the commit message to add more details as well kernel docs.
>> >
>> > v8: Addressed Maarten's review comments.
>> >
>> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
>> > Stone's comments and moved to drm include file. Moved back to older
>> > design with exposing all HDMI colorspaces to userspace since
>> > infoframe capability is there even on legacy platforms, as per
>> > Ville's review comments.
>> >
>> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >
>> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>> > Acked-by: Jani Nikula <jani.nikula@intel.com>
>> > Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
>> > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> > ---
>> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
>> > drivers/gpu/drm/drm_connector.c | 75
>+++++++++++++++++++++++++++++++++++++++
>> > include/drm/drm_connector.h | 46 ++++++++++++++++++++++++
>> > 3 files changed, 125 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> > b/drivers/gpu/drm/drm_atomic_uapi.c
>> > index 9a1f41a..9b5d44f 100644
>> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> > return -EINVAL;
>> > }
>> > state->content_protection = val;
>> > + } else if (property == connector->colorspace_property) {
>> > + state->colorspace = val;
>> > } else if (property == config->writeback_fb_id_property) {
>> > struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>> > int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb);
>> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> > *val = state->picture_aspect_ratio;
>> > } else if (property == config->content_type_property) {
>> > *val = state->content_type;
>> > + } else if (property == connector->colorspace_property) {
>> > + *val = state->colorspace;
>> > } else if (property == connector->scaling_mode_property) {
>> > *val = state->scaling_mode;
>> > } else if (property == connector->content_protection_property) {
>> > diff --git a/drivers/gpu/drm/drm_connector.c
>> > b/drivers/gpu/drm/drm_connector.c index 8475396..ed10dd9 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct
>> > drm_display_info *info, };
>> > DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>drm_cp_enum_list)
>> >
>> > +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
>> > + /* For Default case, driver will set the colorspace */
>> > + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> > + /* Standard Definition Colorimetry based on CEA 861 */
>> > + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>>
>> The spec no longer has the BT.601 note here. Which I guess makes sense
>> since BT.601 didn't even specify any color primaries initially. Later
>> versions do by they have distinct primaries for NTSC vs. PAL. The spec
>> calls this just SMPTE 170M now, so I think we should do the same.
Ok Sure, Will update this name. Yeah this was a little confusing as to what name to
go with. Will take the one defined now in spec i.e., SMPTE 170M.
>>
>> > + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> > + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> > + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> > + /* High Definition Colorimetry based on IEC 61966-2-4 */
>> > + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> > + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> > + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> > + /* Colorimetry based on IEC 61966-2-5 [33] */
>> > + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>>
>> The spelling is rather inconsistent here. XV_ vs. S_ vs. op. Why not
>> use the same spelling style for all?
This is the names defined in spec and I used as is. I will make them as
XVYCC, SYCC and OPYCC for consistency. Hope this is ok ?
>>
>> > + /* Colorimetry based on IEC 61966-2-5 */
>> > + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> > + /* Colorimetry based on ITU-R BT.2020 */
>> > + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> > + /* Colorimetry based on ITU-R BT.2020 */
>> > + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> > + /* Colorimetry based on ITU-R BT.2020 */
>> > + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>>
>> "BT2020" vs. "ITU_709" is rather inconsistent as well.
Ok, will update this.
>> We also seem to be missing the two DCI-P3 things here.
Yeah, I initially did as per 861.F where it was not there. This got added in 861.G,
will add this.
>> > +};
>> > +
>> > /**
>> > * DOC: standard connector properties
>> > *
>> > @@ -1548,6 +1572,57 @@ int
>> > drm_mode_create_aspect_ratio_property(struct drm_device *dev)
>> > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
>> >
>> > /**
>> > + * DOC: standard connector properties
>> > + *
>> > + * Colorspace:
>> > + * drm_mode_create_colorspace_property - create colorspace property
>> > + * This property helps select a suitable colorspace based on the sink
>> > + * capability. Modern sink devices support wider gamut like BT2020.
>> > + * This helps switch to BT2020 mode if the BT2020 encoded video stream
>> > + * is being played by the user, same for any other colorspace. Thereby
>> > + * giving a good visual experience to users.
>> > + *
>> > + * The expectation from userspace is that it should parse the EDID
>> > + * and get supported colorspaces. Use this property and switch to the
>> > + * one supported. Sink supported colorspaces should be retrieved by
>> > + * userspace from EDID and driver will not explicitly expose them.
>> > + *
>> > + * Basically the expectation from userspace is:
>> > + * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> > + * colorspace
>> > + * - Set this new property to let the sink know what it
>> > + * converted the CRTC output to.
>> > + * - This property is just to inform sink what colorspace
>> > + * source is trying to drive.
>> > + *
>> > + * Called by a driver the first time it's needed, must be attached
>> > +to desired
>> > + * connectors.
>> > + */
>> > +int drm_mode_create_colorspace_property(struct drm_connector
>> > +*connector) {
>> > + struct drm_device *dev = connector->dev;
>> > + struct drm_property *prop;
>> > +
>> > + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>> > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
>> > + prop = drm_property_create_enum(dev,
>DRM_MODE_PROP_ENUM,
>> > + "Colorspace",
>> > + hdmi_colorspaces,
>> > +
> ARRAY_SIZE(hdmi_colorspaces));
>> > + if (!prop)
>> > + return -ENOMEM;
>> > + } else {
>> > + DRM_DEBUG_KMS("Colorspace property not supported\n");
>> > + return 0;
>> > + }
>> > +
>> > + connector->colorspace_property = prop;
>> > +
>> > + return 0;
>> > +}
>> > +EXPORT_SYMBOL(drm_mode_create_colorspace_property);
>> > +
>> > +/**
>> > * drm_mode_create_content_type_property - create content type property
>> > * @dev: DRM device
>> > *
>> > diff --git a/include/drm/drm_connector.h
>> > b/include/drm/drm_connector.h index 9941613..29495b3 100644
>> > --- a/include/drm/drm_connector.h
>> > +++ b/include/drm/drm_connector.h
>> > @@ -253,6 +253,38 @@ enum drm_panel_orientation {
>> > DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>> > };
>> >
>> > +/*
>> > + * This is a consolidated colorimetry list supported by HDMI and
>> > + * DP protocol standard. The respective connectors will register
>> > + * a property with the subset of this list (supported by that
>> > + * respective protocol). Userspace will set the colorspace through
>> > + * a colorspace property which will be created and exposed to
>> > + * userspace.
>> > + */
>> > +
>> > +/* For Default case, driver will set the colorspace */
>> > +#define DRM_MODE_COLORIMETRY_DEFAULT 0
>> > +/* CEA 861 Normal Colorimetry options */
>> > +#define DRM_MODE_COLORIMETRY_ITU_601 1
>> > +#define DRM_MODE_COLORIMETRY_ITU_709 2
>> > +/* CEA 861 Extended Colorimetry Options */
>> > +#define DRM_MODE_COLORIMETRY_XV_YCC_601 3
>> > +#define DRM_MODE_COLORIMETRY_XV_YCC_709 4
>> > +#define DRM_MODE_COLORIMETRY_S_YCC_601 5
>> > +#define DRM_MODE_COLORIMETRY_OPYCC_601 6
>> > +#define DRM_MODE_COLORIMETRY_OPRGB 7
>> > +#define DRM_MODE_COLORIMETRY_BT2020_RGB 8
>> > +#define DRM_MODE_COLORIMETRY_BT2020_YCC 9
>> > +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 10
>> > +/* DP MSA Colorimetry Options */
>> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601 11
>> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709 12
>> > +#define DRM_MODE_DP_COLORIMETRY_SRGB 13
>> > +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
> 14
>> > +#define DRM_MODE_DP_COLORIMETRY_SCRGB 15
>> > +#define DRM_MODE_DP_COLORIMETRY_DCI_P3 16
>> > +#define DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE
> 17
>>
>> I think some kind of macro to define these would be good. Assuming
>> we're trying directly interpret these as the C/EC/ACE bits. I can't
>> remember if multiple enum values can have the same integer value. If
>> not we'd also need a YCbCr vs. RGB bit in there somewhere. Assuming we
>> want to keep RGB and YCbCr separate. Currently only BT.2020 has a
>> conflict between the two.
>
>So I think I'm leaning towards having separate YCbCr vs. RGB values (which is
>what you had here already, with BT.2020 being the only case where that actually
>matters). That way someone could even do YCbCr 4:4:4 passthrough by just
>stuffing YUV data into their RGB framebuffer (with the components swizzled the
>right way).
>
>The one thing that rather breaks that usecase is the automagic 4k YCbCr 4:2:0
>fallback. So in in order to guarantee that things work correctly I guess we still
>need explcit control over the output CSC.
>
>Ie. some kind of output color encoding prop like this:
> default /* current behaviour */
> ycbcr BT.601
> ycbcr BT.709
> ycbcr BT.2020
> /* no ycbcr 4:2:0 fallback for below modes? */
> rgb 4:4:4
> ycbcr 4:4:4 BT.601
> ycbcr 4:4:4 BT.709
> ycbcr 4:4:4 BT.2020
> ycbcr 4:2:2 BT.601
> ycbcr 4:2:2 BT.709
> ycbcr 4:2:2 BT.2020
> ycbcr 4:2:0 BT.601
> ycbcr 4:2:0 BT.709
> ycbcr 4:2:0 BT.2020
>
>Hmm. In fact the automagic 4:2:0 fallback sort of breaks the colorspace prop
>alredy because if someone set an RGB colorspace but we end up converting to
>YCbCr 4:2:0 what should we tell the sink? Maybe we just reject the modeset in
>that case and tell users they need to wait for the output color encoding prop to
>support that usecase?
Hi yes, an output encoding property to control this make sense and will be useful.
So if a user decides to have a RGB buffer at source or wants to blend multiple layers in RGB,
and still want o/p converted to YUV420 at o/p, he can use the current colorspace property to
set that and send to sink. In case he doesn't do it explicitly we can still let the content be driven
but with warnings or choose to fail his modeset if that seems better.
What do you suggest, should we keep current property interface like this and extend the usage
with a separate property on top of it.
Thanks Ville for your review comments and suggestions.
Regards,
Uma Shankar
>
>>
>> > +
>> > /**
>> > * struct drm_display_info - runtime data about the connected sink
>> > *
>> > @@ -503,6 +535,13 @@ struct drm_connector_state {
>> > unsigned int content_protection;
>> >
>> > /**
>> > + * @colorspace: State variable for Connector property to request
>> > + * colorspace change on Sink. This is most commonly used to switch
>> > + * to wider color gamuts like BT2020.
>> > + */
>> > + u32 colorspace;
>> > +
>> > + /**
>> > * @writeback_job: Writeback job for writeback connectors
>> > *
>> > * Holds the framebuffer and out-fence for a writeback connector.
>> > As @@ -995,6 +1034,12 @@ struct drm_connector {
>> > struct drm_property *content_protection_property;
>> >
>> > /**
>> > + * @colorspace_property: Connector property to set the suitable
>> > + * colorspace supported by the sink.
>> > + */
>> > + struct drm_property *colorspace_property;
>> > +
>> > + /**
>> > * @path_blob_ptr:
>> > *
>> > * DRM blob property data for the DP MST path property. This
>> > should only @@ -1269,6 +1314,7 @@ int
>> > drm_connector_attach_vrr_capable_property(
>> > int drm_connector_attach_content_protection_property(
>> > struct drm_connector *connector); int
>> > drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>> > +int drm_mode_create_colorspace_property(struct drm_connector
>> > +*connector);
>> > int drm_mode_create_content_type_property(struct drm_device *dev);
>> > void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe
>*frame,
>> > const struct drm_connector_state
>*conn_state);
>> > --
>> > 1.9.1
>> >
>> > _______________________________________________
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Ville Syrjälä
>> Intel
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [v10 2/3] drm: Add DP colorspace property
2019-02-01 19:17 ` Ville Syrjälä
@ 2019-02-04 17:12 ` Shankar, Uma
0 siblings, 0 replies; 17+ messages in thread
From: Shankar, Uma @ 2019-02-04 17:12 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Syrjala, Ville, intel-gfx, dri-devel, Lankhorst, Maarten
>-----Original Message-----
>From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Saturday, February 2, 2019 12:48 AM
>To: Shankar, Uma <uma.shankar@intel.com>
>Cc: emil.l.velikov@gmail.com; intel-gfx@lists.freedesktop.org; Syrjala, Ville
><ville.syrjala@intel.com>; Lankhorst, Maarten <maarten.lankhorst@intel.com>;
>dri-devel@lists.freedesktop.org
>Subject: Re: [v10 2/3] drm: Add DP colorspace property
>
>On Wed, Jan 30, 2019 at 06:24:25PM +0530, Uma Shankar wrote:
>> This patch adds a DP colorspace property, enabling userspace to switch
>> to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced
>> the colorspace enum to incorporate both HDMI and DP supported
>> colorspaces. Also, added a default option for colorspace.
>>
>> v3: Split the changes to have separate colorspace property for DP and
>> HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>>
>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>> Acked-by: Jani Nikula <jani.nikula@intel.com>
>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> ---
>> drivers/gpu/drm/drm_connector.c | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index ed10dd9..b331be8 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct
>drm_display_info *info,
>> { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>>
>> +static const struct drm_prop_enum_list dp_colorspaces[] = {
>> + /* For Default case, driver will set the colorspace */
>> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> + /* Standard Definition Colorimetry based on CEA 861 */
>> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>
>What's with the duplicated 601/709 values? I think in the HDMI verison you had
>only these ones here. Maybe we want to actually state explicitly that they are for
>YCbCr, if only to be consistent with the
>BT2020 values.
Yeah they are for YCbCr, will add that detail to be clear.
>
>> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> + /* High Definition Colorimetry based on IEC 61966-2-4 */
>> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> + /* Colorimetry based on IEC 61966-2-5 */
>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> + /* DP MSA Colorimetry */
>> + { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601"
>},
>> + { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709"
>},
>> + { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
>> + { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide
>Gamut" },
>> + { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
>> + { DRM_MODE_DP_COLORIMETRY_DCI_P3, "DCI-P3" },
>> + { DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom
>Profile" },
>
>I don't think we want this last one since we don't implement anything that could
>transmit the custom profile.
>
>The MSA bits are have "CEA RGB" which we probably want to keep hidden since it
>seems to be just a poorly specced limited range vs. full range knob, and we
>already have a mechanism for that. The Y-only and RAW I guess we can skip. Not
>sure anyone would ever have use for those.
Ok Sure, Will drop this.
Regards,
Uma Shankar
>
>> +};
>> +
>> +
>> /**
>> * DOC: standard connector properties
>> *
>> @@ -1611,6 +1634,14 @@ int drm_mode_create_colorspace_property(struct
>drm_connector *connector)
>>
> ARRAY_SIZE(hdmi_colorspaces));
>> if (!prop)
>> return -ENOMEM;
>> + } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP
>||
>> + connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort) {
>> + prop = drm_property_create_enum(dev,
>DRM_MODE_PROP_ENUM,
>> + "Colorspace", dp_colorspaces,
>> + ARRAY_SIZE(dp_colorspaces));
>> +
>> + if (!prop)
>> + return -ENOMEM;
>> } else {
>> DRM_DEBUG_KMS("Colorspace property not supported\n");
>> return 0;
>> --
>> 1.9.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Ville Syrjälä
>Intel
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [v10 3/3] drm/i915: Attach colorspace property and enable modeset
2019-02-01 19:01 ` Ville Syrjälä
@ 2019-02-04 17:18 ` Shankar, Uma
2019-02-05 15:28 ` Shankar, Uma
0 siblings, 1 reply; 17+ messages in thread
From: Shankar, Uma @ 2019-02-04 17:18 UTC (permalink / raw)
To: Ville Syrjälä
Cc: intel-gfx, Syrjala, Ville, dri-devel, Lankhorst, Maarten
>-----Original Message-----
>From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Saturday, February 2, 2019 12:31 AM
>To: Shankar, Uma <uma.shankar@intel.com>
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville <ville.syrjala@intel.com>;
>Lankhorst, Maarten <maarten.lankhorst@intel.com>; dri-
>devel@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and
>enable modeset
>
>On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
>> This patch attaches the colorspace connector property to the hdmi
>> connector. Based on colorspace change, modeset will be triggered to
>> switch to new colorspace.
>>
>> Based on colorspace property value create an infoframe with
>> appropriate colorspace. This can be used to send an infoframe packet
>> with proper colorspace value set which will help to enable wider color
>> gamut like BT2020 on sink.
>>
>> This patch attaches and enables HDMI colorspace, DP will be taken care
>> separately.
>>
>> v2: Merged the changes of creating infoframe as well to this patch as
>> per Maarten's suggestion.
>>
>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> colorspaces as suggested by Ville and Maarten.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handle the
>> default case properly.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed a checkpatch complaint, Addressed Maarten' review comment,
>> updated the RB from Maarten and Jani's ack.
>>
>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>> Acked-by: Jani Nikula <jani.nikula@intel.com>
>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c | 1 +
>> drivers/gpu/drm/i915/intel_connector.c | 8 ++++++++
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_hdmi.c | 25 +++++++++++++++++++++++++
>> 4 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 16263ad..a4bb906 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>drm_connector *conn,
>> */
>> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>> ||
>> + new_conn_state->base.colorspace !=
>> +old_conn_state->base.colorspace ||
>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>base.picture_aspect_ratio ||
>> new_conn_state->base.content_type != old_conn_state-
>>base.content_type ||
>> new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode)
>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> b/drivers/gpu/drm/i915/intel_connector.c
>> index ee16758..8352d0b 100644
>> --- a/drivers/gpu/drm/i915/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> @@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector
>*connector,
>> connector->dev->mode_config.aspect_ratio_property,
>> DRM_MODE_PICTURE_ASPECT_NONE);
>> }
>> +
>> +void
>> +intel_attach_colorspace_property(struct drm_connector *connector) {
>> + if (!drm_mode_create_colorspace_property(connector))
>> + drm_object_attach_property(&connector->base,
>> + connector->colorspace_property, 0); }
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 85b913e..5178a9a 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct
>> drm_connector *connector, void
>> intel_attach_force_audio_property(struct drm_connector *connector);
>> void intel_attach_broadcast_rgb_property(struct drm_connector
>> *connector); void intel_attach_aspect_ratio_property(struct
>> drm_connector *connector);
>> +void intel_attach_colorspace_property(struct drm_connector
>> +*connector);
>>
>> /* intel_csr.c */
>> void intel_csr_ucode_init(struct drm_i915_private *); diff --git
>> a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 97a98e1..5c5009d 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct
>intel_encoder *encoder,
>> else
>> frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>
>> + if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
>> + /* Set ITU 709 as default for HDMI */
>> + frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;
>
>Default should map to NONE.
Ok, I will make it NO DATA i.e. 0 for DEFAULT.
>
>> + } else if (conn_state->colorspace <
>DRM_MODE_COLORIMETRY_XV_YCC_601) {
>> + frame.avi.colorimetry = conn_state->colorspace;
>> + } else {
>> + frame.avi.colorimetry = HDMI_COLORIMETRY_EXTENDED;
>> + /*
>> + * Starting from extended list where COLORIMETRY_XV_YCC_601
>> + * is the first extended mode and its value is 0 as per HDMI
>> + * specification.
>> + * TODO: This needs to be extended for LSPCON implementation
>> + * as well. Will be implemented separately.
>> + */
>> + frame.avi.extended_colorimetry = conn_state->colorspace -
>> + DRM_MODE_COLORIMETRY_XV_YCC_601;
>> + }
>
>This code seems like something that should be in the core.
>
>Like said earlier maybe we could just directly map the values to these bits, and
>then this should just become
>
>if.colorimetry = val & 0x3;
>if.extended_colorimetry = (val >> 2) & 0x7; if.ace = (val >> 5) & 0xf;
Ok, will modify along these lines.
>Hmm, looks like hdmi.h doesn't even know about the ACE bits yet :(
:)
Thanks Ville for all your comments and suggestion.
Regards,
Uma Shankar
>
>> +
>> drm_hdmi_avi_infoframe_quant_range(&frame.avi,
>> conn_state->connector,
>> adjusted_mode,
>> @@ -2143,10 +2161,17 @@ static void intel_hdmi_destroy(struct
>> drm_connector *connector) intel_hdmi_add_properties(struct intel_hdmi
>> *intel_hdmi, struct drm_connector *connector) {
>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> + struct intel_digital_port *intel_dig_port =
>> + hdmi_to_dig_port(intel_hdmi);
>>
>> intel_attach_force_audio_property(connector);
>> intel_attach_broadcast_rgb_property(connector);
>> intel_attach_aspect_ratio_property(connector);
>> +
>> + /* Attach Colorspace property for Non LSPCON based device */
>> + if (!intel_dig_port->lspcon.active)
>> + intel_attach_colorspace_property(connector);
>> +
>> drm_connector_attach_content_type_property(connector);
>> connector->state->picture_aspect_ratio =
>HDMI_PICTURE_ASPECT_NONE;
>>
>> --
>> 1.9.1
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
2019-02-04 17:08 ` [Intel-gfx] " Shankar, Uma
@ 2019-02-04 17:24 ` Ville Syrjälä
2019-02-04 18:16 ` Shankar, Uma
0 siblings, 1 reply; 17+ messages in thread
From: Ville Syrjälä @ 2019-02-04 17:24 UTC (permalink / raw)
To: Shankar, Uma; +Cc: intel-gfx, Syrjala, Ville, dri-devel, Lankhorst, Maarten
On Mon, Feb 04, 2019 at 05:08:40PM +0000, Shankar, Uma wrote:
>
>
> >-----Original Message-----
> >From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> >Sent: Monday, February 4, 2019 8:55 PM
> >To: Shankar, Uma <uma.shankar@intel.com>
> >Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville <ville.syrjala@intel.com>;
> >Lankhorst, Maarten <maarten.lankhorst@intel.com>; dri-
> >devel@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
> >
> >On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
> >> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> >> > Create a new connector property to program colorspace to sink
> >> > devices. Modern sink devices support more than 1 type of colorspace
> >> > like 601, 709, BT2020 etc. This helps to switch based on content
> >> > type which is to be displayed. The decision lies with compositors as
> >> > to in which scenarios, a particular colorspace will be picked.
> >> >
> >> > This will be helpful mostly to switch to higher gamut colorspaces
> >> > like BT2020 when the media content is encoded as BT2020. Thereby
> >> > giving a good visual experience to users.
> >> >
> >> > The expectation from userspace is that it should parse the EDID and
> >> > get supported colorspaces. Use this property and switch to the one
> >> > supported. Sink supported colorspaces should be retrieved by
> >> > userspace from EDID and driver will not explicitly expose them.
> >> >
> >> > Basically the expectation from userspace is:
> >> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >> > colorspace
> >> > - Set this new property to let the sink know what it
> >> > converted the CRTC output to.
> >> >
> >> > v2: Addressed Maarten and Ville's review comments. Enhanced the
> >> > colorspace enum to incorporate both HDMI and DP supported
> >> > colorspaces. Also, added a default option for colorspace.
> >> >
> >> > v3: Removed Adobe references from enum definitions as per Ville,
> >> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
> >> > unset state where driver will assign the colorspace is not chosen by
> >> > user, suggested by Ville and Maarten. Addressed other misc review
> >> > comments from Maarten. Split the changes to have separate colorspace
> >> > property for DP and HDMI.
> >> >
> >> > v4: Addressed Chris and Ville's review comments, and created a
> >> > common colorspace property for DP and HDMI, filtered the list based
> >> > on the colorspaces supported by the respective protocol standard.
> >> >
> >> > v5: Made the property creation helper accept enum list based on
> >> > platform capabilties as suggested by Shashank. Consolidated HDMI and
> >> > DP property creation in the common helper.
> >> >
> >> > v6: Addressed Shashank's review comments.
> >> >
> >> > v7: Added defines instead of enum in uapi as per Brian Starkey's
> >> > suggestion in order to go with string matching at userspace. Updated
> >> > the commit message to add more details as well kernel docs.
> >> >
> >> > v8: Addressed Maarten's review comments.
> >> >
> >> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> >> > Stone's comments and moved to drm include file. Moved back to older
> >> > design with exposing all HDMI colorspaces to userspace since
> >> > infoframe capability is there even on legacy platforms, as per
> >> > Ville's review comments.
> >> >
> >> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> >> >
> >> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >> > Acked-by: Jani Nikula <jani.nikula@intel.com>
> >> > Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
> >> > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >> > ---
> >> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> >> > drivers/gpu/drm/drm_connector.c | 75
> >+++++++++++++++++++++++++++++++++++++++
> >> > include/drm/drm_connector.h | 46 ++++++++++++++++++++++++
> >> > 3 files changed, 125 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> > b/drivers/gpu/drm/drm_atomic_uapi.c
> >> > index 9a1f41a..9b5d44f 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >> > return -EINVAL;
> >> > }
> >> > state->content_protection = val;
> >> > + } else if (property == connector->colorspace_property) {
> >> > + state->colorspace = val;
> >> > } else if (property == config->writeback_fb_id_property) {
> >> > struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
> >NULL, val);
> >> > int ret = drm_atomic_set_writeback_fb_for_connector(state,
> >fb);
> >> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >> > *val = state->picture_aspect_ratio;
> >> > } else if (property == config->content_type_property) {
> >> > *val = state->content_type;
> >> > + } else if (property == connector->colorspace_property) {
> >> > + *val = state->colorspace;
> >> > } else if (property == connector->scaling_mode_property) {
> >> > *val = state->scaling_mode;
> >> > } else if (property == connector->content_protection_property) {
> >> > diff --git a/drivers/gpu/drm/drm_connector.c
> >> > b/drivers/gpu/drm/drm_connector.c index 8475396..ed10dd9 100644
> >> > --- a/drivers/gpu/drm/drm_connector.c
> >> > +++ b/drivers/gpu/drm/drm_connector.c
> >> > @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct
> >> > drm_display_info *info, };
> >> > DRM_ENUM_NAME_FN(drm_get_content_protection_name,
> >drm_cp_enum_list)
> >> >
> >> > +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> >> > + /* For Default case, driver will set the colorspace */
> >> > + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> >> > + /* Standard Definition Colorimetry based on CEA 861 */
> >> > + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> >>
> >> The spec no longer has the BT.601 note here. Which I guess makes sense
> >> since BT.601 didn't even specify any color primaries initially. Later
> >> versions do by they have distinct primaries for NTSC vs. PAL. The spec
> >> calls this just SMPTE 170M now, so I think we should do the same.
>
> Ok Sure, Will update this name. Yeah this was a little confusing as to what name to
> go with. Will take the one defined now in spec i.e., SMPTE 170M.
>
> >>
> >> > + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> >> > + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> >> > + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> >> > + /* High Definition Colorimetry based on IEC 61966-2-4 */
> >> > + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> >> > + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> >> > + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> >> > + /* Colorimetry based on IEC 61966-2-5 [33] */
> >> > + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> >>
> >> The spelling is rather inconsistent here. XV_ vs. S_ vs. op. Why not
> >> use the same spelling style for all?
>
> This is the names defined in spec and I used as is. I will make them as
> XVYCC, SYCC and OPYCC for consistency. Hope this is ok ?
>
> >>
> >> > + /* Colorimetry based on IEC 61966-2-5 */
> >> > + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> >> > + /* Colorimetry based on ITU-R BT.2020 */
> >> > + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> >> > + /* Colorimetry based on ITU-R BT.2020 */
> >> > + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> >> > + /* Colorimetry based on ITU-R BT.2020 */
> >> > + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> >>
> >> "BT2020" vs. "ITU_709" is rather inconsistent as well.
>
> Ok, will update this.
>
> >> We also seem to be missing the two DCI-P3 things here.
>
> Yeah, I initially did as per 861.F where it was not there. This got added in 861.G,
> will add this.
>
> >> > +};
> >> > +
> >> > /**
> >> > * DOC: standard connector properties
> >> > *
> >> > @@ -1548,6 +1572,57 @@ int
> >> > drm_mode_create_aspect_ratio_property(struct drm_device *dev)
> >> > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> >> >
> >> > /**
> >> > + * DOC: standard connector properties
> >> > + *
> >> > + * Colorspace:
> >> > + * drm_mode_create_colorspace_property - create colorspace property
> >> > + * This property helps select a suitable colorspace based on the sink
> >> > + * capability. Modern sink devices support wider gamut like BT2020.
> >> > + * This helps switch to BT2020 mode if the BT2020 encoded video stream
> >> > + * is being played by the user, same for any other colorspace. Thereby
> >> > + * giving a good visual experience to users.
> >> > + *
> >> > + * The expectation from userspace is that it should parse the EDID
> >> > + * and get supported colorspaces. Use this property and switch to the
> >> > + * one supported. Sink supported colorspaces should be retrieved by
> >> > + * userspace from EDID and driver will not explicitly expose them.
> >> > + *
> >> > + * Basically the expectation from userspace is:
> >> > + * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >> > + * colorspace
> >> > + * - Set this new property to let the sink know what it
> >> > + * converted the CRTC output to.
> >> > + * - This property is just to inform sink what colorspace
> >> > + * source is trying to drive.
> >> > + *
> >> > + * Called by a driver the first time it's needed, must be attached
> >> > +to desired
> >> > + * connectors.
> >> > + */
> >> > +int drm_mode_create_colorspace_property(struct drm_connector
> >> > +*connector) {
> >> > + struct drm_device *dev = connector->dev;
> >> > + struct drm_property *prop;
> >> > +
> >> > + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> >> > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> >> > + prop = drm_property_create_enum(dev,
> >DRM_MODE_PROP_ENUM,
> >> > + "Colorspace",
> >> > + hdmi_colorspaces,
> >> > +
> > ARRAY_SIZE(hdmi_colorspaces));
> >> > + if (!prop)
> >> > + return -ENOMEM;
> >> > + } else {
> >> > + DRM_DEBUG_KMS("Colorspace property not supported\n");
> >> > + return 0;
> >> > + }
> >> > +
> >> > + connector->colorspace_property = prop;
> >> > +
> >> > + return 0;
> >> > +}
> >> > +EXPORT_SYMBOL(drm_mode_create_colorspace_property);
> >> > +
> >> > +/**
> >> > * drm_mode_create_content_type_property - create content type property
> >> > * @dev: DRM device
> >> > *
> >> > diff --git a/include/drm/drm_connector.h
> >> > b/include/drm/drm_connector.h index 9941613..29495b3 100644
> >> > --- a/include/drm/drm_connector.h
> >> > +++ b/include/drm/drm_connector.h
> >> > @@ -253,6 +253,38 @@ enum drm_panel_orientation {
> >> > DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> >> > };
> >> >
> >> > +/*
> >> > + * This is a consolidated colorimetry list supported by HDMI and
> >> > + * DP protocol standard. The respective connectors will register
> >> > + * a property with the subset of this list (supported by that
> >> > + * respective protocol). Userspace will set the colorspace through
> >> > + * a colorspace property which will be created and exposed to
> >> > + * userspace.
> >> > + */
> >> > +
> >> > +/* For Default case, driver will set the colorspace */
> >> > +#define DRM_MODE_COLORIMETRY_DEFAULT 0
> >> > +/* CEA 861 Normal Colorimetry options */
> >> > +#define DRM_MODE_COLORIMETRY_ITU_601 1
> >> > +#define DRM_MODE_COLORIMETRY_ITU_709 2
> >> > +/* CEA 861 Extended Colorimetry Options */
> >> > +#define DRM_MODE_COLORIMETRY_XV_YCC_601 3
> >> > +#define DRM_MODE_COLORIMETRY_XV_YCC_709 4
> >> > +#define DRM_MODE_COLORIMETRY_S_YCC_601 5
> >> > +#define DRM_MODE_COLORIMETRY_OPYCC_601 6
> >> > +#define DRM_MODE_COLORIMETRY_OPRGB 7
> >> > +#define DRM_MODE_COLORIMETRY_BT2020_RGB 8
> >> > +#define DRM_MODE_COLORIMETRY_BT2020_YCC 9
> >> > +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 10
> >> > +/* DP MSA Colorimetry Options */
> >> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601 11
> >> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709 12
> >> > +#define DRM_MODE_DP_COLORIMETRY_SRGB 13
> >> > +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
> > 14
> >> > +#define DRM_MODE_DP_COLORIMETRY_SCRGB 15
> >> > +#define DRM_MODE_DP_COLORIMETRY_DCI_P3 16
> >> > +#define DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE
> > 17
> >>
> >> I think some kind of macro to define these would be good. Assuming
> >> we're trying directly interpret these as the C/EC/ACE bits. I can't
> >> remember if multiple enum values can have the same integer value. If
> >> not we'd also need a YCbCr vs. RGB bit in there somewhere. Assuming we
> >> want to keep RGB and YCbCr separate. Currently only BT.2020 has a
> >> conflict between the two.
> >
> >So I think I'm leaning towards having separate YCbCr vs. RGB values (which is
> >what you had here already, with BT.2020 being the only case where that actually
> >matters). That way someone could even do YCbCr 4:4:4 passthrough by just
> >stuffing YUV data into their RGB framebuffer (with the components swizzled the
> >right way).
> >
> >The one thing that rather breaks that usecase is the automagic 4k YCbCr 4:2:0
> >fallback. So in in order to guarantee that things work correctly I guess we still
> >need explcit control over the output CSC.
> >
> >Ie. some kind of output color encoding prop like this:
> > default /* current behaviour */
> > ycbcr BT.601
> > ycbcr BT.709
> > ycbcr BT.2020
> > /* no ycbcr 4:2:0 fallback for below modes? */
> > rgb 4:4:4
> > ycbcr 4:4:4 BT.601
> > ycbcr 4:4:4 BT.709
> > ycbcr 4:4:4 BT.2020
> > ycbcr 4:2:2 BT.601
> > ycbcr 4:2:2 BT.709
> > ycbcr 4:2:2 BT.2020
> > ycbcr 4:2:0 BT.601
> > ycbcr 4:2:0 BT.709
> > ycbcr 4:2:0 BT.2020
> >
> >Hmm. In fact the automagic 4:2:0 fallback sort of breaks the colorspace prop
> >alredy because if someone set an RGB colorspace but we end up converting to
> >YCbCr 4:2:0 what should we tell the sink? Maybe we just reject the modeset in
> >that case and tell users they need to wait for the output color encoding prop to
> >support that usecase?
>
> Hi yes, an output encoding property to control this make sense and will be useful.
> So if a user decides to have a RGB buffer at source or wants to blend multiple layers in RGB,
> and still want o/p converted to YUV420 at o/p, he can use the current colorspace property to
> set that and send to sink. In case he doesn't do it explicitly we can still let the content be driven
> but with warnings or choose to fail his modeset if that seems better.
>
> What do you suggest, should we keep current property interface like this and extend the usage
> with a separate property on top of it.
I think separate prop to control the output CSC is best. The
colorspace prop should only control the infoframe. If the
two are in violent disagreement we can fail the modeset.
>
> Thanks Ville for your review comments and suggestions.
>
> Regards,
> Uma Shankar
>
> >
> >>
> >> > +
> >> > /**
> >> > * struct drm_display_info - runtime data about the connected sink
> >> > *
> >> > @@ -503,6 +535,13 @@ struct drm_connector_state {
> >> > unsigned int content_protection;
> >> >
> >> > /**
> >> > + * @colorspace: State variable for Connector property to request
> >> > + * colorspace change on Sink. This is most commonly used to switch
> >> > + * to wider color gamuts like BT2020.
> >> > + */
> >> > + u32 colorspace;
> >> > +
> >> > + /**
> >> > * @writeback_job: Writeback job for writeback connectors
> >> > *
> >> > * Holds the framebuffer and out-fence for a writeback connector.
> >> > As @@ -995,6 +1034,12 @@ struct drm_connector {
> >> > struct drm_property *content_protection_property;
> >> >
> >> > /**
> >> > + * @colorspace_property: Connector property to set the suitable
> >> > + * colorspace supported by the sink.
> >> > + */
> >> > + struct drm_property *colorspace_property;
> >> > +
> >> > + /**
> >> > * @path_blob_ptr:
> >> > *
> >> > * DRM blob property data for the DP MST path property. This
> >> > should only @@ -1269,6 +1314,7 @@ int
> >> > drm_connector_attach_vrr_capable_property(
> >> > int drm_connector_attach_content_protection_property(
> >> > struct drm_connector *connector); int
> >> > drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> >> > +int drm_mode_create_colorspace_property(struct drm_connector
> >> > +*connector);
> >> > int drm_mode_create_content_type_property(struct drm_device *dev);
> >> > void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe
> >*frame,
> >> > const struct drm_connector_state
> >*conn_state);
> >> > --
> >> > 1.9.1
> >> >
> >> > _______________________________________________
> >> > Intel-gfx mailing list
> >> > Intel-gfx@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >>
> >> --
> >> Ville Syrjälä
> >> Intel
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >--
> >Ville Syrjälä
> >Intel
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
2019-02-04 17:24 ` Ville Syrjälä
@ 2019-02-04 18:16 ` Shankar, Uma
0 siblings, 0 replies; 17+ messages in thread
From: Shankar, Uma @ 2019-02-04 18:16 UTC (permalink / raw)
To: Ville Syrjälä
Cc: intel-gfx, Syrjala, Ville, Lankhorst, Maarten, dri-devel
>-----Original Message-----
>From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Monday, February 4, 2019 10:54 PM
>To: Shankar, Uma <uma.shankar@intel.com>
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville <ville.syrjala@intel.com>; dri-
>devel@lists.freedesktop.org; Lankhorst, Maarten
><maarten.lankhorst@intel.com>
>Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>
>On Mon, Feb 04, 2019 at 05:08:40PM +0000, Shankar, Uma wrote:
>>
>>
>> >-----Original Message-----
>> >From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
>> >Sent: Monday, February 4, 2019 8:55 PM
>> >To: Shankar, Uma <uma.shankar@intel.com>
>> >Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
>> ><ville.syrjala@intel.com>; Lankhorst, Maarten
>> ><maarten.lankhorst@intel.com>; dri- devel@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>> >
>> >On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
>> >> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
>> >> > Create a new connector property to program colorspace to sink
>> >> > devices. Modern sink devices support more than 1 type of
>> >> > colorspace like 601, 709, BT2020 etc. This helps to switch based
>> >> > on content type which is to be displayed. The decision lies with
>> >> > compositors as to in which scenarios, a particular colorspace will be
>picked.
>> >> >
>> >> > This will be helpful mostly to switch to higher gamut colorspaces
>> >> > like BT2020 when the media content is encoded as BT2020. Thereby
>> >> > giving a good visual experience to users.
>> >> >
>> >> > The expectation from userspace is that it should parse the EDID
>> >> > and get supported colorspaces. Use this property and switch to
>> >> > the one supported. Sink supported colorspaces should be retrieved
>> >> > by userspace from EDID and driver will not explicitly expose them.
>> >> >
>> >> > Basically the expectation from userspace is:
>> >> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >> > colorspace
>> >> > - Set this new property to let the sink know what it
>> >> > converted the CRTC output to.
>> >> >
>> >> > v2: Addressed Maarten and Ville's review comments. Enhanced the
>> >> > colorspace enum to incorporate both HDMI and DP supported
>> >> > colorspaces. Also, added a default option for colorspace.
>> >> >
>> >> > v3: Removed Adobe references from enum definitions as per Ville,
>> >> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
>> >> > unset state where driver will assign the colorspace is not chosen
>> >> > by user, suggested by Ville and Maarten. Addressed other misc
>> >> > review comments from Maarten. Split the changes to have separate
>> >> > colorspace property for DP and HDMI.
>> >> >
>> >> > v4: Addressed Chris and Ville's review comments, and created a
>> >> > common colorspace property for DP and HDMI, filtered the list
>> >> > based on the colorspaces supported by the respective protocol standard.
>> >> >
>> >> > v5: Made the property creation helper accept enum list based on
>> >> > platform capabilties as suggested by Shashank. Consolidated HDMI
>> >> > and DP property creation in the common helper.
>> >> >
>> >> > v6: Addressed Shashank's review comments.
>> >> >
>> >> > v7: Added defines instead of enum in uapi as per Brian Starkey's
>> >> > suggestion in order to go with string matching at userspace.
>> >> > Updated the commit message to add more details as well kernel docs.
>> >> >
>> >> > v8: Addressed Maarten's review comments.
>> >> >
>> >> > v9: Removed macro defines from uapi as per Brian Starkey and
>> >> > Daniel Stone's comments and moved to drm include file. Moved back
>> >> > to older design with exposing all HDMI colorspaces to userspace
>> >> > since infoframe capability is there even on legacy platforms, as
>> >> > per Ville's review comments.
>> >> >
>> >> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >> >
>> >> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>> >> > Acked-by: Jani Nikula <jani.nikula@intel.com>
>> >> > Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
>> >> > Reviewed-by: Maarten Lankhorst
>> >> > <maarten.lankhorst@linux.intel.com>
>> >> > ---
>> >> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
>> >> > drivers/gpu/drm/drm_connector.c | 75
>> >+++++++++++++++++++++++++++++++++++++++
>> >> > include/drm/drm_connector.h | 46 ++++++++++++++++++++++++
>> >> > 3 files changed, 125 insertions(+)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > index 9a1f41a..9b5d44f 100644
>> >> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > @@ -746,6 +746,8 @@ static int
>> >> > drm_atomic_connector_set_property(struct
>> >drm_connector *connector,
>> >> > return -EINVAL;
>> >> > }
>> >> > state->content_protection = val;
>> >> > + } else if (property == connector->colorspace_property) {
>> >> > + state->colorspace = val;
>> >> > } else if (property == config->writeback_fb_id_property) {
>> >> > struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>> >NULL, val);
>> >> > int ret = drm_atomic_set_writeback_fb_for_connector(state,
>> >fb);
>> >> > @@ -814,6 +816,8 @@ static int
>> >> > drm_atomic_connector_set_property(struct
>> >drm_connector *connector,
>> >> > *val = state->picture_aspect_ratio;
>> >> > } else if (property == config->content_type_property) {
>> >> > *val = state->content_type;
>> >> > + } else if (property == connector->colorspace_property) {
>> >> > + *val = state->colorspace;
>> >> > } else if (property == connector->scaling_mode_property) {
>> >> > *val = state->scaling_mode;
>> >> > } else if (property == connector->content_protection_property)
>> >> > { diff --git a/drivers/gpu/drm/drm_connector.c
>> >> > b/drivers/gpu/drm/drm_connector.c index 8475396..ed10dd9 100644
>> >> > --- a/drivers/gpu/drm/drm_connector.c
>> >> > +++ b/drivers/gpu/drm/drm_connector.c
>> >> > @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct
>> >> > drm_display_info *info, };
>> >> > DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>> >drm_cp_enum_list)
>> >> >
>> >> > +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
>> >> > + /* For Default case, driver will set the colorspace */
>> >> > + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> >> > + /* Standard Definition Colorimetry based on CEA 861 */
>> >> > + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> >>
>> >> The spec no longer has the BT.601 note here. Which I guess makes
>> >> sense since BT.601 didn't even specify any color primaries
>> >> initially. Later versions do by they have distinct primaries for
>> >> NTSC vs. PAL. The spec calls this just SMPTE 170M now, so I think we should
>do the same.
>>
>> Ok Sure, Will update this name. Yeah this was a little confusing as to
>> what name to go with. Will take the one defined now in spec i.e., SMPTE 170M.
>>
>> >>
>> >> > + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> >> > + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> >> > + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> >> > + /* High Definition Colorimetry based on IEC 61966-2-4 */
>> >> > + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> >> > + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> >> > + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> >> > + /* Colorimetry based on IEC 61966-2-5 [33] */
>> >> > + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>> >>
>> >> The spelling is rather inconsistent here. XV_ vs. S_ vs. op. Why
>> >> not use the same spelling style for all?
>>
>> This is the names defined in spec and I used as is. I will make them
>> as XVYCC, SYCC and OPYCC for consistency. Hope this is ok ?
>>
>> >>
>> >> > + /* Colorimetry based on IEC 61966-2-5 */
>> >> > + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> >> > + /* Colorimetry based on ITU-R BT.2020 */
>> >> > + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> >> > + /* Colorimetry based on ITU-R BT.2020 */
>> >> > + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> >> > + /* Colorimetry based on ITU-R BT.2020 */
>> >> > + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>> >>
>> >> "BT2020" vs. "ITU_709" is rather inconsistent as well.
>>
>> Ok, will update this.
>>
>> >> We also seem to be missing the two DCI-P3 things here.
>>
>> Yeah, I initially did as per 861.F where it was not there. This got
>> added in 861.G, will add this.
>>
>> >> > +};
>> >> > +
>> >> > /**
>> >> > * DOC: standard connector properties
>> >> > *
>> >> > @@ -1548,6 +1572,57 @@ int
>> >> > drm_mode_create_aspect_ratio_property(struct drm_device *dev)
>> >> > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
>> >> >
>> >> > /**
>> >> > + * DOC: standard connector properties
>> >> > + *
>> >> > + * Colorspace:
>> >> > + * drm_mode_create_colorspace_property - create colorspace
>property
>> >> > + * This property helps select a suitable colorspace based on the sink
>> >> > + * capability. Modern sink devices support wider gamut like BT2020.
>> >> > + * This helps switch to BT2020 mode if the BT2020 encoded video
>stream
>> >> > + * is being played by the user, same for any other colorspace. Thereby
>> >> > + * giving a good visual experience to users.
>> >> > + *
>> >> > + * The expectation from userspace is that it should parse the EDID
>> >> > + * and get supported colorspaces. Use this property and switch to the
>> >> > + * one supported. Sink supported colorspaces should be retrieved by
>> >> > + * userspace from EDID and driver will not explicitly expose them.
>> >> > + *
>> >> > + * Basically the expectation from userspace is:
>> >> > + * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >> > + * colorspace
>> >> > + * - Set this new property to let the sink know what it
>> >> > + * converted the CRTC output to.
>> >> > + * - This property is just to inform sink what colorspace
>> >> > + * source is trying to drive.
>> >> > + *
>> >> > + * Called by a driver the first time it's needed, must be
>> >> > +attached to desired
>> >> > + * connectors.
>> >> > + */
>> >> > +int drm_mode_create_colorspace_property(struct drm_connector
>> >> > +*connector) {
>> >> > + struct drm_device *dev = connector->dev;
>> >> > + struct drm_property *prop;
>> >> > +
>> >> > + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>> >> > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
>> >> > + prop = drm_property_create_enum(dev,
>> >DRM_MODE_PROP_ENUM,
>> >> > + "Colorspace",
>> >> > + hdmi_colorspaces,
>> >> > +
>> > ARRAY_SIZE(hdmi_colorspaces));
>> >> > + if (!prop)
>> >> > + return -ENOMEM;
>> >> > + } else {
>> >> > + DRM_DEBUG_KMS("Colorspace property not supported\n");
>> >> > + return 0;
>> >> > + }
>> >> > +
>> >> > + connector->colorspace_property = prop;
>> >> > +
>> >> > + return 0;
>> >> > +}
>> >> > +EXPORT_SYMBOL(drm_mode_create_colorspace_property);
>> >> > +
>> >> > +/**
>> >> > * drm_mode_create_content_type_property - create content type
>property
>> >> > * @dev: DRM device
>> >> > *
>> >> > diff --git a/include/drm/drm_connector.h
>> >> > b/include/drm/drm_connector.h index 9941613..29495b3 100644
>> >> > --- a/include/drm/drm_connector.h
>> >> > +++ b/include/drm/drm_connector.h
>> >> > @@ -253,6 +253,38 @@ enum drm_panel_orientation {
>> >> > DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>> >> > };
>> >> >
>> >> > +/*
>> >> > + * This is a consolidated colorimetry list supported by HDMI and
>> >> > + * DP protocol standard. The respective connectors will register
>> >> > + * a property with the subset of this list (supported by that
>> >> > + * respective protocol). Userspace will set the colorspace
>> >> > +through
>> >> > + * a colorspace property which will be created and exposed to
>> >> > + * userspace.
>> >> > + */
>> >> > +
>> >> > +/* For Default case, driver will set the colorspace */
>> >> > +#define DRM_MODE_COLORIMETRY_DEFAULT 0
>> >> > +/* CEA 861 Normal Colorimetry options */
>> >> > +#define DRM_MODE_COLORIMETRY_ITU_601 1
>> >> > +#define DRM_MODE_COLORIMETRY_ITU_709 2
>> >> > +/* CEA 861 Extended Colorimetry Options */
>> >> > +#define DRM_MODE_COLORIMETRY_XV_YCC_601
> 3
>> >> > +#define DRM_MODE_COLORIMETRY_XV_YCC_709
> 4
>> >> > +#define DRM_MODE_COLORIMETRY_S_YCC_601 5
>> >> > +#define DRM_MODE_COLORIMETRY_OPYCC_601
> 6
>> >> > +#define DRM_MODE_COLORIMETRY_OPRGB 7
>> >> > +#define DRM_MODE_COLORIMETRY_BT2020_RGB
> 8
>> >> > +#define DRM_MODE_COLORIMETRY_BT2020_YCC
> 9
>> >> > +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 10
>> >> > +/* DP MSA Colorimetry Options */
>> >> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601
> 11
>> >> > +#define DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709
> 12
>> >> > +#define DRM_MODE_DP_COLORIMETRY_SRGB 13
>> >> > +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
>> > 14
>> >> > +#define DRM_MODE_DP_COLORIMETRY_SCRGB 15
>> >> > +#define DRM_MODE_DP_COLORIMETRY_DCI_P3 16
>> >> > +#define DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE
>> > 17
>> >>
>> >> I think some kind of macro to define these would be good. Assuming
>> >> we're trying directly interpret these as the C/EC/ACE bits. I can't
>> >> remember if multiple enum values can have the same integer value.
>> >> If not we'd also need a YCbCr vs. RGB bit in there somewhere.
>> >> Assuming we want to keep RGB and YCbCr separate. Currently only
>> >> BT.2020 has a conflict between the two.
>> >
>> >So I think I'm leaning towards having separate YCbCr vs. RGB values
>> >(which is what you had here already, with BT.2020 being the only case
>> >where that actually matters). That way someone could even do YCbCr
>> >4:4:4 passthrough by just stuffing YUV data into their RGB
>> >framebuffer (with the components swizzled the right way).
>> >
>> >The one thing that rather breaks that usecase is the automagic 4k
>> >YCbCr 4:2:0 fallback. So in in order to guarantee that things work
>> >correctly I guess we still need explcit control over the output CSC.
>> >
>> >Ie. some kind of output color encoding prop like this:
>> > default /* current behaviour */
>> > ycbcr BT.601
>> > ycbcr BT.709
>> > ycbcr BT.2020
>> > /* no ycbcr 4:2:0 fallback for below modes? */
>> > rgb 4:4:4
>> > ycbcr 4:4:4 BT.601
>> > ycbcr 4:4:4 BT.709
>> > ycbcr 4:4:4 BT.2020
>> > ycbcr 4:2:2 BT.601
>> > ycbcr 4:2:2 BT.709
>> > ycbcr 4:2:2 BT.2020
>> > ycbcr 4:2:0 BT.601
>> > ycbcr 4:2:0 BT.709
>> > ycbcr 4:2:0 BT.2020
>> >
>> >Hmm. In fact the automagic 4:2:0 fallback sort of breaks the
>> >colorspace prop alredy because if someone set an RGB colorspace but
>> >we end up converting to YCbCr 4:2:0 what should we tell the sink?
>> >Maybe we just reject the modeset in that case and tell users they
>> >need to wait for the output color encoding prop to support that usecase?
>>
>> Hi yes, an output encoding property to control this make sense and will be
>useful.
>> So if a user decides to have a RGB buffer at source or wants to blend
>> multiple layers in RGB, and still want o/p converted to YUV420 at o/p,
>> he can use the current colorspace property to set that and send to
>> sink. In case he doesn't do it explicitly we can still let the content be driven but
>with warnings or choose to fail his modeset if that seems better.
>>
>> What do you suggest, should we keep current property interface like
>> this and extend the usage with a separate property on top of it.
>
>I think separate prop to control the output CSC is best. The colorspace prop
>should only control the infoframe. If the two are in violent disagreement we can
>fail the modeset.
Ok Sure, Will take that as a separate task to add a property interface for output CSC.
Thanks Ville !!!
>>
>> Thanks Ville for your review comments and suggestions.
>>
>> Regards,
>> Uma Shankar
>>
>> >
>> >>
>> >> > +
>> >> > /**
>> >> > * struct drm_display_info - runtime data about the connected sink
>> >> > *
>> >> > @@ -503,6 +535,13 @@ struct drm_connector_state {
>> >> > unsigned int content_protection;
>> >> >
>> >> > /**
>> >> > + * @colorspace: State variable for Connector property to request
>> >> > + * colorspace change on Sink. This is most commonly used to switch
>> >> > + * to wider color gamuts like BT2020.
>> >> > + */
>> >> > + u32 colorspace;
>> >> > +
>> >> > + /**
>> >> > * @writeback_job: Writeback job for writeback connectors
>> >> > *
>> >> > * Holds the framebuffer and out-fence for a writeback connector.
>> >> > As @@ -995,6 +1034,12 @@ struct drm_connector {
>> >> > struct drm_property *content_protection_property;
>> >> >
>> >> > /**
>> >> > + * @colorspace_property: Connector property to set the suitable
>> >> > + * colorspace supported by the sink.
>> >> > + */
>> >> > + struct drm_property *colorspace_property;
>> >> > +
>> >> > + /**
>> >> > * @path_blob_ptr:
>> >> > *
>> >> > * DRM blob property data for the DP MST path property. This
>> >> > should only @@ -1269,6 +1314,7 @@ int
>> >> > drm_connector_attach_vrr_capable_property(
>> >> > int drm_connector_attach_content_protection_property(
>> >> > struct drm_connector *connector); int
>> >> > drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>> >> > +int drm_mode_create_colorspace_property(struct drm_connector
>> >> > +*connector);
>> >> > int drm_mode_create_content_type_property(struct drm_device
>> >> > *dev); void drm_hdmi_avi_infoframe_content_type(struct
>> >> > hdmi_avi_infoframe
>> >*frame,
>> >> > const struct drm_connector_state
>> >*conn_state);
>> >> > --
>> >> > 1.9.1
>> >> >
>> >> > _______________________________________________
>> >> > Intel-gfx mailing list
>> >> > Intel-gfx@lists.freedesktop.org
>> >> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >>
>> >> --
>> >> Ville Syrjälä
>> >> Intel
>> >> _______________________________________________
>> >> Intel-gfx mailing list
>> >> Intel-gfx@lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >
>> >--
>> >Ville Syrjälä
>> >Intel
>
>--
>Ville Syrjälä
>Intel
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [v10 3/3] drm/i915: Attach colorspace property and enable modeset
2019-02-04 17:18 ` Shankar, Uma
@ 2019-02-05 15:28 ` Shankar, Uma
0 siblings, 0 replies; 17+ messages in thread
From: Shankar, Uma @ 2019-02-05 15:28 UTC (permalink / raw)
To: 'Ville Syrjälä'
Cc: 'intel-gfx@lists.freedesktop.org',
Syrjala, Ville, 'dri-devel@lists.freedesktop.org',
Lankhorst, Maarten
>-----Original Message-----
>From: Shankar, Uma
>Sent: Monday, February 4, 2019 10:49 PM
>To: Ville Syrjälä <ville.syrjala@linux.intel.com>
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville <ville.syrjala@intel.com>;
>Lankhorst, Maarten <maarten.lankhorst@intel.com>; dri-
>devel@lists.freedesktop.org
>Subject: RE: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and
>enable modeset
>
>
>
>>-----Original Message-----
>>From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On
>>Behalf Of Ville Syrjälä
>>Sent: Saturday, February 2, 2019 12:31 AM
>>To: Shankar, Uma <uma.shankar@intel.com>
>>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
>><ville.syrjala@intel.com>; Lankhorst, Maarten
>><maarten.lankhorst@intel.com>; dri- devel@lists.freedesktop.org
>>Subject: Re: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property
>>and enable modeset
>>
>>On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
>>> This patch attaches the colorspace connector property to the hdmi
>>> connector. Based on colorspace change, modeset will be triggered to
>>> switch to new colorspace.
>>>
>>> Based on colorspace property value create an infoframe with
>>> appropriate colorspace. This can be used to send an infoframe packet
>>> with proper colorspace value set which will help to enable wider
>>> color gamut like BT2020 on sink.
>>>
>>> This patch attaches and enables HDMI colorspace, DP will be taken
>>> care separately.
>>>
>>> v2: Merged the changes of creating infoframe as well to this patch as
>>> per Maarten's suggestion.
>>>
>>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>>> colorspaces as suggested by Ville and Maarten.
>>>
>>> v4: Addressed Chris and Ville's review comments, and created a common
>>> colorspace property for DP and HDMI, filtered the list based on the
>>> colorspaces supported by the respective protocol standard. Handle the
>>> default case properly.
>>>
>>> v5: Merged the DP handling along with platform colorspace handling as
>>> per Shashank's comments.
>>>
>>> v6: Reverted to old design of exposing all colorspaces to userspace
>>> as per Ville's review comment
>>>
>>> v7: Fixed a checkpatch complaint, Addressed Maarten' review comment,
>>> updated the RB from Maarten and Jani's ack.
>>>
>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>> Acked-by: Jani Nikula <jani.nikula@intel.com>
>>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> ---
>>> drivers/gpu/drm/i915/intel_atomic.c | 1 +
>>> drivers/gpu/drm/i915/intel_connector.c | 8 ++++++++
>>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>>> drivers/gpu/drm/i915/intel_hdmi.c | 25 +++++++++++++++++++++++++
>>> 4 files changed, 35 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>>> b/drivers/gpu/drm/i915/intel_atomic.c
>>> index 16263ad..a4bb906 100644
>>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>>drm_connector *conn,
>>> */
>>> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>>> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>>> ||
>>> + new_conn_state->base.colorspace !=
>>> +old_conn_state->base.colorspace ||
>>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>>base.picture_aspect_ratio ||
>>> new_conn_state->base.content_type != old_conn_state-
>>>base.content_type ||
>>> new_conn_state->base.scaling_mode !=
>>> old_conn_state->base.scaling_mode)
>>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>>> b/drivers/gpu/drm/i915/intel_connector.c
>>> index ee16758..8352d0b 100644
>>> --- a/drivers/gpu/drm/i915/intel_connector.c
>>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>>> @@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector
>>*connector,
>>> connector->dev->mode_config.aspect_ratio_property,
>>> DRM_MODE_PICTURE_ASPECT_NONE);
>>> }
>>> +
>>> +void
>>> +intel_attach_colorspace_property(struct drm_connector *connector) {
>>> + if (!drm_mode_create_colorspace_property(connector))
>>> + drm_object_attach_property(&connector->base,
>>> + connector->colorspace_property, 0); }
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index 85b913e..5178a9a 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct
>>> drm_connector *connector, void
>>> intel_attach_force_audio_property(struct drm_connector *connector);
>>> void intel_attach_broadcast_rgb_property(struct drm_connector
>>> *connector); void intel_attach_aspect_ratio_property(struct
>>> drm_connector *connector);
>>> +void intel_attach_colorspace_property(struct drm_connector
>>> +*connector);
>>>
>>> /* intel_csr.c */
>>> void intel_csr_ucode_init(struct drm_i915_private *); diff --git
>>> a/drivers/gpu/drm/i915/intel_hdmi.c
>>> b/drivers/gpu/drm/i915/intel_hdmi.c
>>> index 97a98e1..5c5009d 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>> @@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct
>>intel_encoder *encoder,
>>> else
>>> frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>>
>>> + if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
>>> + /* Set ITU 709 as default for HDMI */
>>> + frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;
>>
>>Default should map to NONE.
>
>Ok, I will make it NO DATA i.e. 0 for DEFAULT.
>
>>
>>> + } else if (conn_state->colorspace <
>>DRM_MODE_COLORIMETRY_XV_YCC_601) {
>>> + frame.avi.colorimetry = conn_state->colorspace;
>>> + } else {
>>> + frame.avi.colorimetry = HDMI_COLORIMETRY_EXTENDED;
>>> + /*
>>> + * Starting from extended list where COLORIMETRY_XV_YCC_601
>>> + * is the first extended mode and its value is 0 as per HDMI
>>> + * specification.
>>> + * TODO: This needs to be extended for LSPCON implementation
>>> + * as well. Will be implemented separately.
>>> + */
>>> + frame.avi.extended_colorimetry = conn_state->colorspace -
>>> + DRM_MODE_COLORIMETRY_XV_YCC_601;
>>> + }
>>
>>This code seems like something that should be in the core.
>>
>>Like said earlier maybe we could just directly map the values to these
>>bits, and then this should just become
>>
>>if.colorimetry = val & 0x3;
>>if.extended_colorimetry = (val >> 2) & 0x7; if.ace = (val >> 5) & 0xf;
>
>Ok, will modify along these lines.
On looking further, it feels to have the enum defined sequentially for userspace
and then respective encoders taking care as per spec looks better. In the case here,
both DP and HDMI share some colorspaces so we can't have a common value for both
as far as infoframe programming is concerned. Also currently with ACE, total bits go to
9 for HDMI. Hence we need to have enum value going randomly from 0 to 512 which will
look more like magic numbers to userspace.
Currently I have moved this to drm layer as you suggested, will send the next version with all
your comments addressed. Planning to send separate series to handle ACE stuff in linux/hdmi
and then extend this as well as part of that series. Hope this is ok.
Regards,
Uma Shankar
>>Hmm, looks like hdmi.h doesn't even know about the ACE bits yet :(
>
>:)
>
>Thanks Ville for all your comments and suggestion.
>
>Regards,
>Uma Shankar
>>
>>> +
>>> drm_hdmi_avi_infoframe_quant_range(&frame.avi,
>>> conn_state->connector,
>>> adjusted_mode,
>>> @@ -2143,10 +2161,17 @@ static void intel_hdmi_destroy(struct
>>> drm_connector *connector) intel_hdmi_add_properties(struct
>>> intel_hdmi *intel_hdmi, struct drm_connector *connector) {
>>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>>> + struct intel_digital_port *intel_dig_port =
>>> + hdmi_to_dig_port(intel_hdmi);
>>>
>>> intel_attach_force_audio_property(connector);
>>> intel_attach_broadcast_rgb_property(connector);
>>> intel_attach_aspect_ratio_property(connector);
>>> +
>>> + /* Attach Colorspace property for Non LSPCON based device */
>>> + if (!intel_dig_port->lspcon.active)
>>> + intel_attach_colorspace_property(connector);
>>> +
>>> drm_connector_attach_content_type_property(connector);
>>> connector->state->picture_aspect_ratio =
>>HDMI_PICTURE_ASPECT_NONE;
>>>
>>> --
>>> 1.9.1
>>>
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>--
>>Ville Syrjälä
>>Intel
>>_______________________________________________
>>dri-devel mailing list
>>dri-devel@lists.freedesktop.org
>>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-02-05 15:28 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-30 12:54 [v10 0/3] Add Colorspace connector property interface Uma Shankar
2019-01-30 12:52 ` ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface (rev10) Patchwork
2019-01-30 12:54 ` [v10 1/3] drm: Add HDMI colorspace property Uma Shankar
2019-02-01 18:50 ` Ville Syrjälä
2019-02-04 15:25 ` Ville Syrjälä
2019-02-04 17:08 ` [Intel-gfx] " Shankar, Uma
2019-02-04 17:24 ` Ville Syrjälä
2019-02-04 18:16 ` Shankar, Uma
2019-01-30 12:54 ` [v10 2/3] drm: Add DP " Uma Shankar
2019-02-01 19:17 ` Ville Syrjälä
2019-02-04 17:12 ` Shankar, Uma
2019-01-30 12:54 ` [v10 3/3] drm/i915: Attach colorspace property and enable modeset Uma Shankar
2019-02-01 19:01 ` Ville Syrjälä
2019-02-04 17:18 ` Shankar, Uma
2019-02-05 15:28 ` Shankar, Uma
2019-01-30 13:10 ` ✓ Fi.CI.BAT: success for Add Colorspace connector property interface (rev10) Patchwork
2019-01-30 16:00 ` ✓ Fi.CI.IGT: " Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.