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.
v11: Addressed Ville's review comments. Modified MACRO names, added infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace macro definitions defined in CTA 861.G. Currently linux/hdmi lacks support for ACE formats, will be added as a separate series.
Uma Shankar (4): drm: Add HDMI colorspace property drm: Add DP colorspace property drm: Add colorspace info to AVI Infoframe 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/drm_edid.c | 28 +++++++++ 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 | 13 +++++ include/drm/drm_connector.h | 50 ++++++++++++++++ include/drm/drm_edid.h | 6 ++ 9 files changed, 215 insertions(+)
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.
v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
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 | 78 +++++++++++++++++++++++++++++++++++++++ include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ 3 files changed, 132 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..4309873 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" }, + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, + /* Standard Definition Colorimetry based on IEC 61966-2-4 */ + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, + /* High Definition Colorimetry based on IEC 61966-2-4 */ + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, + /* Colorimetry based on IEC 61966-2-5 [33] */ + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, + /* Colorimetry based on IEC 61966-2-5 */ + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, + /* 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_RGB, "BT2020_RGB" }, + /* Colorimetry based on ITU-R BT.2020 */ + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, + /* Added as part of Additional Colorimetry Extension in 861.G */ + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" }, + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" }, +}; + /** * DOC: standard connector properties * @@ -1548,6 +1575,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..58db66e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -253,6 +253,42 @@ 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_NO_DATA 0 +#define DRM_MODE_COLORIMETRY_SMPTE_170M 1 +#define DRM_MODE_COLORIMETRY_BT709 2 +/* CEA 861 Extended Colorimetry Options */ +#define DRM_MODE_COLORIMETRY_XVYCC_601 3 +#define DRM_MODE_COLORIMETRY_XVYCC_709 4 +#define DRM_MODE_COLORIMETRY_SYCC_601 5 +#define DRM_MODE_COLORIMETRY_OPYCC_601 6 +#define DRM_MODE_COLORIMETRY_OPRGB 7 +#define DRM_MODE_COLORIMETRY_BT2020_YCC 8 +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ +#define DRM_MODE_COLORIMETRY_BT2020_RGB 9 +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9 +/* Additional Colorimetry extension added as part of CTA 861.G */ +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER 11 + +/* DP MSA Colorimetry Options */ +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601 12 +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709 13 +#define DRM_MODE_DP_COLORIMETRY_SRGB 14 +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 15 +#define DRM_MODE_DP_COLORIMETRY_SCRGB 16 + /** * struct drm_display_info - runtime data about the connected sink * @@ -503,6 +539,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 +1038,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 +1318,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);
On Tue, Feb 05, 2019 at 09:33:34PM +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.
v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
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 | 78 +++++++++++++++++++++++++++++++++++++++ include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ 3 files changed, 132 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;@@ -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;diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 8475396..4309873 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" },
- { DRM_MODE_COLORIMETRY_BT709, "BT709" },
- /* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
- /* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
- /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* 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_RGB, "BT2020_RGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
- /* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
+};
/**
- DOC: standard connector properties
@@ -1548,6 +1575,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..58db66e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -253,6 +253,42 @@ 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_NO_DATA 0 +#define DRM_MODE_COLORIMETRY_SMPTE_170M 1 +#define DRM_MODE_COLORIMETRY_BT709 2
Still missing the YCbCr information in these two.
+/* CEA 861 Extended Colorimetry Options */ +#define DRM_MODE_COLORIMETRY_XVYCC_601 3 +#define DRM_MODE_COLORIMETRY_XVYCC_709 4 +#define DRM_MODE_COLORIMETRY_SYCC_601 5 +#define DRM_MODE_COLORIMETRY_OPYCC_601 6 +#define DRM_MODE_COLORIMETRY_OPRGB 7 +#define DRM_MODE_COLORIMETRY_BT2020_YCC 8 +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ +#define DRM_MODE_COLORIMETRY_BT2020_RGB 9 +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9
I though you didn't want these numbers to be based on the spec numbers? This duplicated value seems to go against that idea.
+/* Additional Colorimetry extension added as part of CTA 861.G */ +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER 11
+/* DP MSA Colorimetry Options */ +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601 12 +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709 13
Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. YCC, order of the two).
+#define DRM_MODE_DP_COLORIMETRY_SRGB 14 +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 15 +#define DRM_MODE_DP_COLORIMETRY_SCRGB 16
/**
- struct drm_display_info - runtime data about the connected sink
@@ -503,6 +539,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 +1038,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 +1318,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
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 5, 2019 10:02 PM To: Shankar, Uma uma.shankar@intel.com Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 09:33:34PM +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.
v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
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 | 78
+++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ 3 files changed, 132 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;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;diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 8475396..4309873 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" },
- { DRM_MODE_COLORIMETRY_BT709, "BT709" },
- /* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
- /* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
- /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* 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_RGB, "BT2020_RGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
- /* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
P3_RGB_Theater" },
+};
/**
- DOC: standard connector properties
@@ -1548,6 +1575,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..58db66e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -253,6 +253,42 @@ 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_NO_DATA 0 +#define DRM_MODE_COLORIMETRY_SMPTE_170M 1 +#define DRM_MODE_COLORIMETRY_BT709 2
Still missing the YCbCr information in these two.
As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R BT709, with no specific mention of RGB or YCbCr. Hence, kept it as per spec. We seem to have a common field for both as per CTA spec. Correct me if my understanding is wrong.
+/* CEA 861 Extended Colorimetry Options */ +#define DRM_MODE_COLORIMETRY_XVYCC_601 3 +#define DRM_MODE_COLORIMETRY_XVYCC_709 4 +#define DRM_MODE_COLORIMETRY_SYCC_601 5 +#define DRM_MODE_COLORIMETRY_OPYCC_601 6 +#define DRM_MODE_COLORIMETRY_OPRGB 7 +#define DRM_MODE_COLORIMETRY_BT2020_YCC 8 +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ +#define DRM_MODE_COLORIMETRY_BT2020_RGB 9 +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9
I though you didn't want these numbers to be based on the spec numbers? This duplicated value seems to go against that idea.
Yeah, for HDMI somehow was trying to utilize the definitions to advantage. But I feel, It's better to de-couple this. Define this as normal enum values sequentially so that userspace get readable serial number kind values. And use these in encoder files to get proper values to be programmed as per respective spec, while defining those values per encoder separately. Hope this is fine.
+/* Additional Colorimetry extension added as part of CTA 861.G */ +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER 11
+/* DP MSA Colorimetry Options */ +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601 12 +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709 13
Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. YCC, order of the two).
Will fix this. Thanks Ville.
+#define DRM_MODE_DP_COLORIMETRY_SRGB 14 +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 15 +#define DRM_MODE_DP_COLORIMETRY_SCRGB 16
/**
- struct drm_display_info - runtime data about the connected sink
@@ -503,6 +539,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 +1038,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 +1318,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
On Tue, Feb 05, 2019 at 05:32:16PM +0000, Shankar, Uma wrote:
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 5, 2019 10:02 PM To: Shankar, Uma uma.shankar@intel.com Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 09:33:34PM +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.
v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
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 | 78
+++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ 3 files changed, 132 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;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;diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 8475396..4309873 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" },
- { DRM_MODE_COLORIMETRY_BT709, "BT709" },
- /* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
- /* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
- /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* 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_RGB, "BT2020_RGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
- /* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
P3_RGB_Theater" },
+};
/**
- DOC: standard connector properties
@@ -1548,6 +1575,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..58db66e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -253,6 +253,42 @@ 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_NO_DATA 0 +#define DRM_MODE_COLORIMETRY_SMPTE_170M 1 +#define DRM_MODE_COLORIMETRY_BT709 2
Still missing the YCbCr information in these two.
As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R BT709, with no specific mention of RGB or YCbCr. Hence, kept it as per spec. We seem to have a common field for both as per CTA spec. Correct me if my understanding is wrong.
Check "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), Colorimetry (C) and Extended Colorimetry (EC) Field Settings"
+/* CEA 861 Extended Colorimetry Options */ +#define DRM_MODE_COLORIMETRY_XVYCC_601 3 +#define DRM_MODE_COLORIMETRY_XVYCC_709 4 +#define DRM_MODE_COLORIMETRY_SYCC_601 5 +#define DRM_MODE_COLORIMETRY_OPYCC_601 6 +#define DRM_MODE_COLORIMETRY_OPRGB 7 +#define DRM_MODE_COLORIMETRY_BT2020_YCC 8 +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ +#define DRM_MODE_COLORIMETRY_BT2020_RGB 9 +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9
I though you didn't want these numbers to be based on the spec numbers? This duplicated value seems to go against that idea.
Yeah, for HDMI somehow was trying to utilize the definitions to advantage. But I feel, It's better to de-couple this. Define this as normal enum values sequentially so that userspace get readable serial number kind values. And use these in encoder files to get proper values to be programmed as per respective spec, while defining those values per encoder separately. Hope this is fine.
+/* Additional Colorimetry extension added as part of CTA 861.G */ +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER 11
+/* DP MSA Colorimetry Options */ +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601 12 +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709 13
Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. YCC, order of the two).
Will fix this. Thanks Ville.
+#define DRM_MODE_DP_COLORIMETRY_SRGB 14 +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 15 +#define DRM_MODE_DP_COLORIMETRY_SCRGB 16
/**
- struct drm_display_info - runtime data about the connected sink
@@ -503,6 +539,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 +1038,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 +1318,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
-----Original Message----- From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Ville Syrjälä Sent: Tuesday, February 5, 2019 11:43 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] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 05:32:16PM +0000, Shankar, Uma wrote:
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 5, 2019 10:02 PM To: Shankar, Uma uma.shankar@intel.com Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 09:33:34PM +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.
v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
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 | 78
+++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ 3 files changed, 132 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;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;diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 8475396..4309873 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" },
- { DRM_MODE_COLORIMETRY_BT709, "BT709" },
- /* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
- /* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
- /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* 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_RGB, "BT2020_RGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
- /* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
P3_RGB_Theater" },
+};
/**
- DOC: standard connector properties
@@ -1548,6 +1575,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..58db66e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -253,6 +253,42 @@ 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_NO_DATA 0 +#define DRM_MODE_COLORIMETRY_SMPTE_170M
1
+#define DRM_MODE_COLORIMETRY_BT709 2
Still missing the YCbCr information in these two.
As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R BT709, with no specific mention of RGB or YCbCr. Hence, kept it as per spec. We seem to have a common field for both as per CTA spec. Correct me if my understanding is wrong.
Check "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), Colorimetry (C) and Extended Colorimetry (EC) Field Settings"
These Y2 Y1 Y0 values should be programmed separately and not through the colorspace as they are data formats isn't it. I feel this should get controlled separately independent of colorimetry, or should we add all the YCbCr and RGB versions and program them as part of this property itself ?
My idea was just to update colorimetry fields alone as part of this interface.
+/* CEA 861 Extended Colorimetry Options */ +#define DRM_MODE_COLORIMETRY_XVYCC_601 3 +#define DRM_MODE_COLORIMETRY_XVYCC_709 4 +#define DRM_MODE_COLORIMETRY_SYCC_601 5 +#define DRM_MODE_COLORIMETRY_OPYCC_601 6 +#define DRM_MODE_COLORIMETRY_OPRGB 7 +#define DRM_MODE_COLORIMETRY_BT2020_YCC 8 +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ +#define DRM_MODE_COLORIMETRY_BT2020_RGB 9 +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9
I though you didn't want these numbers to be based on the spec numbers? This duplicated value seems to go against that idea.
Yeah, for HDMI somehow was trying to utilize the definitions to advantage. But I feel, It's better to de-couple this. Define this as normal enum values sequentially so that userspace get readable serial number
kind values.
And use these in encoder files to get proper values to be programmed as per respective spec, while defining those values per encoder separately.
Hope this is fine.
+/* Additional Colorimetry extension added as part of CTA 861.G */ +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER
11
+/* DP MSA Colorimetry Options */ +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601 12 +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709 13
Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. YCC, order of the two).
Will fix this. Thanks Ville.
+#define DRM_MODE_DP_COLORIMETRY_SRGB 14 +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
15
+#define DRM_MODE_DP_COLORIMETRY_SCRGB 16
/**
- struct drm_display_info - runtime data about the connected sink
@@ -503,6 +539,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 +1038,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 +1318,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
-- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Feb 05, 2019 at 07:22:32PM +0000, Shankar, Uma wrote:
-----Original Message----- From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Ville Syrjälä Sent: Tuesday, February 5, 2019 11:43 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] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 05:32:16PM +0000, Shankar, Uma wrote:
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 5, 2019 10:02 PM To: Shankar, Uma uma.shankar@intel.com Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 09:33:34PM +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.
v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
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 | 78
+++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ 3 files changed, 132 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;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;diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 8475396..4309873 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" },
- { DRM_MODE_COLORIMETRY_BT709, "BT709" },
- /* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
- /* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
- /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* 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_RGB, "BT2020_RGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
- /* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
P3_RGB_Theater" },
+};
/**
- DOC: standard connector properties
@@ -1548,6 +1575,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..58db66e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -253,6 +253,42 @@ 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_NO_DATA 0 +#define DRM_MODE_COLORIMETRY_SMPTE_170M
1
+#define DRM_MODE_COLORIMETRY_BT709 2
Still missing the YCbCr information in these two.
As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R BT709, with no specific mention of RGB or YCbCr. Hence, kept it as per spec. We seem to have a common field for both as per CTA spec. Correct me if my understanding is wrong.
Check "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), Colorimetry (C) and Extended Colorimetry (EC) Field Settings"
These Y2 Y1 Y0 values should be programmed separately and not through the colorspace as they are data formats isn't it. I feel this should get controlled separately independent of colorimetry, or should we add all the YCbCr and RGB versions and program them as part of this property itself ?
I don't think we can separate them. The values of the colorimetry bits doesn't mean anything without the Y bits. It would make the uapi kinda crazy if we allow the user to specify BT.2020 RGB but then we actually signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal a totally invalid value for all the other cases.
My idea was just to update colorimetry fields alone as part of this interface.
+/* CEA 861 Extended Colorimetry Options */ +#define DRM_MODE_COLORIMETRY_XVYCC_601 3 +#define DRM_MODE_COLORIMETRY_XVYCC_709 4 +#define DRM_MODE_COLORIMETRY_SYCC_601 5 +#define DRM_MODE_COLORIMETRY_OPYCC_601 6 +#define DRM_MODE_COLORIMETRY_OPRGB 7 +#define DRM_MODE_COLORIMETRY_BT2020_YCC 8 +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ +#define DRM_MODE_COLORIMETRY_BT2020_RGB 9 +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9
I though you didn't want these numbers to be based on the spec numbers? This duplicated value seems to go against that idea.
Yeah, for HDMI somehow was trying to utilize the definitions to advantage. But I feel, It's better to de-couple this. Define this as normal enum values sequentially so that userspace get readable serial number
kind values.
And use these in encoder files to get proper values to be programmed as per respective spec, while defining those values per encoder separately.
Hope this is fine.
+/* Additional Colorimetry extension added as part of CTA 861.G */ +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER
11
+/* DP MSA Colorimetry Options */ +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601 12 +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709 13
Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. YCC, order of the two).
Will fix this. Thanks Ville.
+#define DRM_MODE_DP_COLORIMETRY_SRGB 14 +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
15
+#define DRM_MODE_DP_COLORIMETRY_SCRGB 16
/**
- struct drm_display_info - runtime data about the connected sink
@@ -503,6 +539,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 +1038,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 +1318,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
-- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 5, 2019 10:02 PM To: Shankar, Uma uma.shankar@intel.com Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 09:33:34PM +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.
v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
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 | 78
+++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ 3 files changed, 132 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;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;{ diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 8475396..4309873 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" },
- { DRM_MODE_COLORIMETRY_BT709, "BT709" },
- /* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
- /* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
- /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* 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_RGB, "BT2020_RGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
- /* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-
P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
P3_RGB_Theater" },
+};
/**
- DOC: standard connector properties
@@ -1548,6 +1575,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 colorspaceproperty
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 videostream
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 notsupported\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..58db66e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -253,6 +253,42 @@ 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_NO_DATA 0 +#define DRM_MODE_COLORIMETRY_SMPTE_170M
1
+#define DRM_MODE_COLORIMETRY_BT709 2
Still missing the YCbCr information in these two.
As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R BT709, with no specific mention of RGB or YCbCr. Hence, kept it as per spec. We seem to have a common field for both as per CTA spec. Correct me if my understanding is wrong.
Check "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), Colorimetry (C) and Extended Colorimetry (EC) Field Settings"
These Y2 Y1 Y0 values should be programmed separately and not through the colorspace as they are data formats isn't it. I feel this should get controlled separately independent of colorimetry, or should we add all the YCbCr and RGB versions and program them as part of this property itself
?
I don't think we can separate them. The values of the colorimetry bits doesn't mean anything without the Y bits. It would make the uapi kinda crazy if we allow the user to specify BT.2020 RGB but then we actually signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal a totally invalid value for all the other cases.
I agree we need data format also to be send along with colorspace, but they are 2 different things. To handle YCbCr and variants (YUV 444, 420 or 422) and RGB I feel we should expose a different API instead of using this one. We can create an output csc property which does that job for us.
So from a user perspective if we wants to set a colorspace we should use the one in this series and set the data format separately using the other interface. Both will be received in the state variables and later Infoframe packet will be created accordingly. Clubbing both in one may lead to lot of possible combinations exposed as enum which may not look too clean.
What do you say about handling that in the output csc property. I will go with what you recommend .
Regards, Uma Shankar
My idea was just to update colorimetry fields alone as part of this interface.
+/* CEA 861 Extended Colorimetry Options */ +#define DRM_MODE_COLORIMETRY_XVYCC_601
3
+#define DRM_MODE_COLORIMETRY_XVYCC_709
4
+#define DRM_MODE_COLORIMETRY_SYCC_601 5 +#define DRM_MODE_COLORIMETRY_OPYCC_601
6
+#define DRM_MODE_COLORIMETRY_OPRGB 7 +#define DRM_MODE_COLORIMETRY_BT2020_YCC
8
+/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ +#define DRM_MODE_COLORIMETRY_BT2020_RGB
9
+#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9
I though you didn't want these numbers to be based on the spec numbers? This duplicated value seems to go against that idea.
Yeah, for HDMI somehow was trying to utilize the definitions to advantage. But I feel, It's better to de-couple this. Define this as normal enum values sequentially so that userspace get readable serial number
kind values.
And use these in encoder files to get proper values to be programmed as per respective spec, while defining those values per encoder
separately.
Hope this is fine.
+/* Additional Colorimetry extension added as part of CTA 861.G */ +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER
11
+/* DP MSA Colorimetry Options */ +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601
12
+#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709
13
Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. YCC, order of the two).
Will fix this. Thanks Ville.
+#define DRM_MODE_DP_COLORIMETRY_SRGB 14 +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
15
+#define DRM_MODE_DP_COLORIMETRY_SCRGB
16
/**
- struct drm_display_info - runtime data about the connected sink
@@ -503,6 +539,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 toswitch
* 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 +1038,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 +1318,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 structdrm_connector_state
*conn_state);
-- 1.9.1
Regards Shashank
-----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Shankar, Uma Sent: Friday, February 8, 2019 5:45 PM To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace property
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 5, 2019 10:02 PM To: Shankar, Uma uma.shankar@intel.com Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 09:33:34PM +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. > > v11: Addressed Ville's review comments. Updated the Macro > naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. > > 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 | 78 +++++++++++++++++++++++++++++++++++++++ > include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ > 3 files changed, 132 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..4309873 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" }, > + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, > + /* Standard Definition Colorimetry based on IEC 61966-2-4 */ > + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, > + /* High Definition Colorimetry based on IEC 61966-2-4 */ > + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, > + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ > + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, > + /* Colorimetry based on IEC 61966-2-5 [33] */ > + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, > + /* Colorimetry based on IEC 61966-2-5 */ > + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, > + /* 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_RGB, "BT2020_RGB" }, > + /* Colorimetry based on ITU-R BT.2020 */ > + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, > + /* Added as part of Additional Colorimetry Extension in 861.G */ > + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-
P3_RGB_D65" },
> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- P3_RGB_Theater" }, > +}; > + > /** > * DOC: standard connector properties > * > @@ -1548,6 +1575,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..58db66e 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -253,6 +253,42 @@ 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_NO_DATA 0 > +#define DRM_MODE_COLORIMETRY_SMPTE_170M
1
> +#define DRM_MODE_COLORIMETRY_BT709 2
Still missing the YCbCr information in these two.
As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R BT709, with no specific mention of RGB or YCbCr. Hence, kept it as per spec. We seem to have a common field for both as per CTA spec. Correct me if my understanding is wrong.
Check "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), Colorimetry (C) and Extended Colorimetry (EC) Field Settings"
These Y2 Y1 Y0 values should be programmed separately and not through the colorspace as they are data formats isn't it. I feel this should get controlled separately independent of colorimetry, or should we add all the YCbCr and RGB versions and program them as part of this property itself
?
I don't think we can separate them. The values of the colorimetry bits doesn't mean anything without the Y bits. It would make the uapi kinda crazy if we allow the user to specify BT.2020 RGB but then we actually signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal a totally invalid value for all the other cases.
I agree we need data format also to be send along with colorspace, but they are 2 different things. To handle YCbCr and variants (YUV 444, 420 or 422) and RGB I feel we should expose a different API instead of using this one. We can create an output csc property which does that job for us.
So from a user perspective if we wants to set a colorspace we should use the one in this series and set the data format separately using the other interface. Both will be received in the state variables and later Infoframe packet will be created accordingly. Clubbing both in one may lead to lot of possible combinations exposed as enum which may not look too clean.
What do you say about handling that in the output csc property. I will go with what you recommend .
Programming Y2Y1Y0 is already taken care of, when we added support for YCBCR outputs (4:2:0 implementation). In intel_hdmi.c:intel_hdmi_set_avi_infoframe():
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
IMO This looks like a better way to handle this, ie while adding support for a new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
Regards, Uma Shankar
My idea was just to update colorimetry fields alone as part of this interface.
> +/* CEA 861 Extended Colorimetry Options */ #define > +DRM_MODE_COLORIMETRY_XVYCC_601
3
> +#define DRM_MODE_COLORIMETRY_XVYCC_709
4
> +#define DRM_MODE_COLORIMETRY_SYCC_601 5 > +#define DRM_MODE_COLORIMETRY_OPYCC_601
6
> +#define DRM_MODE_COLORIMETRY_OPRGB 7 > +#define DRM_MODE_COLORIMETRY_BT2020_YCC
8
> +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ > +#define DRM_MODE_COLORIMETRY_BT2020_RGB
9
> +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9
I though you didn't want these numbers to be based on the spec numbers? This duplicated value seems to go against that idea.
Yeah, for HDMI somehow was trying to utilize the definitions to advantage. But I feel, It's better to de-couple this. Define this as normal enum values sequentially so that userspace get readable serial number
kind values.
And use these in encoder files to get proper values to be programmed as per respective spec, while defining those values per encoder
separately.
Hope this is fine.
> +/* Additional Colorimetry extension added as part of CTA 861.G */ > +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 > +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER
11
> + > +/* DP MSA Colorimetry Options */ #define > +DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601
12
> +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709
13
Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. YCC, order of the two).
Will fix this. Thanks Ville.
> +#define DRM_MODE_DP_COLORIMETRY_SRGB 14 > +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
15
> +#define DRM_MODE_DP_COLORIMETRY_SCRGB
16
> + > /** > * struct drm_display_info - runtime data about the connected sink > * > @@ -503,6 +539,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 +1038,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 +1318,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
On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote:
Regards Shashank
-----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Shankar, Uma Sent: Friday, February 8, 2019 5:45 PM To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace property
>-----Original Message----- >From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >Sent: Tuesday, February 5, 2019 10:02 PM >To: Shankar, Uma uma.shankar@intel.com >Cc: intel-gfx@lists.freedesktop.org; >dri-devel@lists.freedesktop.org; Syrjala, Ville >ville.syrjala@intel.com; Lankhorst, Maarten >maarten.lankhorst@intel.com >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >property > >On Tue, Feb 05, 2019 at 09:33:34PM +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. >> >> v11: Addressed Ville's review comments. Updated the Macro >> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. >> >> 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 | 78 >+++++++++++++++++++++++++++++++++++++++ >> include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ >> 3 files changed, 132 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..4309873 100644 >> --- a/drivers/gpu/drm/drm_connector.c >> +++ b/drivers/gpu/drm/drm_connector.c >> @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" }, >> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */ >> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >> + /* Colorimetry based on IEC 61966-2-5 [33] */ >> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >> + /* Colorimetry based on IEC 61966-2-5 */ >> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >> + /* 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_RGB, "BT2020_RGB" }, >> + /* Colorimetry based on ITU-R BT.2020 */ >> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, >> + /* Added as part of Additional Colorimetry Extension in 861.G */ >> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-
P3_RGB_D65" },
>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >P3_RGB_Theater" }, >> +}; >> + >> /** >> * DOC: standard connector properties >> * >> @@ -1548,6 +1575,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..58db66e 100644 >> --- a/include/drm/drm_connector.h >> +++ b/include/drm/drm_connector.h >> @@ -253,6 +253,42 @@ 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_NO_DATA 0 >> +#define DRM_MODE_COLORIMETRY_SMPTE_170M
1
>> +#define DRM_MODE_COLORIMETRY_BT709 2 > >Still missing the YCbCr information in these two.
As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R BT709, with no specific mention of RGB or YCbCr. Hence, kept it as per spec. We seem to have a common field for both as per CTA spec. Correct me if my understanding is wrong.
Check "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), Colorimetry (C) and Extended Colorimetry (EC) Field Settings"
These Y2 Y1 Y0 values should be programmed separately and not through the colorspace as they are data formats isn't it. I feel this should get controlled separately independent of colorimetry, or should we add all the YCbCr and RGB versions and program them as part of this property itself
?
I don't think we can separate them. The values of the colorimetry bits doesn't mean anything without the Y bits. It would make the uapi kinda crazy if we allow the user to specify BT.2020 RGB but then we actually signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal a totally invalid value for all the other cases.
I agree we need data format also to be send along with colorspace, but they are 2 different things. To handle YCbCr and variants (YUV 444, 420 or 422) and RGB I feel we should expose a different API instead of using this one. We can create an output csc property which does that job for us.
So from a user perspective if we wants to set a colorspace we should use the one in this series and set the data format separately using the other interface. Both will be received in the state variables and later Infoframe packet will be created accordingly. Clubbing both in one may lead to lot of possible combinations exposed as enum which may not look too clean.
What do you say about handling that in the output csc property. I will go with what you recommend .
Programming Y2Y1Y0 is already taken care of, when we added support for YCBCR outputs (4:2:0 implementation). In intel_hdmi.c:intel_hdmi_set_avi_infoframe():
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
IMO This looks like a better way to handle this, ie while adding support for a new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
That's an exceptional case. We're programming the CSC in that case to do the RGB->YCbCr conversion without telling userspace. So we must also configure the Y bits automagically.
What we want is a check like so:
if (prop.colorspace != default && output_format != RGB) return -INVAL;
because we can't set up the CSC to make a mess of the user's carefully crafted pixels. The pixels might not even contain RGB data in that case.
We'll need to extend that a little bit once we add the explicit control of the output CSC via another prop. But the same principle should hold.
Regards, Uma Shankar
My idea was just to update colorimetry fields alone as part of this interface.
> >> +/* CEA 861 Extended Colorimetry Options */ #define >> +DRM_MODE_COLORIMETRY_XVYCC_601
3
>> +#define DRM_MODE_COLORIMETRY_XVYCC_709
4
>> +#define DRM_MODE_COLORIMETRY_SYCC_601 5 >> +#define DRM_MODE_COLORIMETRY_OPYCC_601
6
>> +#define DRM_MODE_COLORIMETRY_OPRGB 7 >> +#define DRM_MODE_COLORIMETRY_BT2020_YCC
8
>> +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ >> +#define DRM_MODE_COLORIMETRY_BT2020_RGB
9
>> +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9 > >I though you didn't want these numbers to be based on the spec >numbers? This duplicated value seems to go against that idea.
Yeah, for HDMI somehow was trying to utilize the definitions to advantage. But I feel, It's better to de-couple this. Define this as normal enum values sequentially so that userspace get readable serial number
kind values.
And use these in encoder files to get proper values to be programmed as per respective spec, while defining those values per encoder
separately.
Hope this is fine.
>> +/* Additional Colorimetry extension added as part of CTA 861.G */ >> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 >> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER
11
>> + >> +/* DP MSA Colorimetry Options */ #define >> +DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601
12
>> +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709
13
> >Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. >YCC, order of the two).
Will fix this. Thanks Ville.
> >> +#define DRM_MODE_DP_COLORIMETRY_SRGB 14 >> +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT
15
>> +#define DRM_MODE_DP_COLORIMETRY_SCRGB
16
>> + >> /** >> * struct drm_display_info - runtime data about the connected sink >> * >> @@ -503,6 +539,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 +1038,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 +1318,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
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote:
Regards Shashank
-----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Shankar, Uma Sent: Friday, February 8, 2019 5:45 PM To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace property
>> -----Original Message----- >> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >> Sent: Tuesday, February 5, 2019 10:02 PM >> To: Shankar, Uma uma.shankar@intel.com >> Cc: intel-gfx@lists.freedesktop.org; >> dri-devel@lists.freedesktop.org; Syrjala, Ville >> ville.syrjala@intel.com; Lankhorst, Maarten >> maarten.lankhorst@intel.com >> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >> property >> >> On Tue, Feb 05, 2019 at 09:33:34PM +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. >>> >>> v11: Addressed Ville's review comments. Updated the Macro >>> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. >>> >>> 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 | 78 >> +++++++++++++++++++++++++++++++++++++++ >>> include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ >>> 3 files changed, 132 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..4309873 100644 >>> --- a/drivers/gpu/drm/drm_connector.c >>> +++ b/drivers/gpu/drm/drm_connector.c >>> @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" }, >>> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >>> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */ >>> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >>> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >>> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >>> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >>> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >>> + /* Colorimetry based on IEC 61966-2-5 [33] */ >>> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >>> + /* Colorimetry based on IEC 61966-2-5 */ >>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >>> + /* 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_RGB, "BT2020_RGB" }, >>> + /* Colorimetry based on ITU-R BT.2020 */ >>> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, >>> + /* Added as part of Additional Colorimetry Extension in 861.G */ >>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-
P3_RGB_D65" },
>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >> P3_RGB_Theater" }, >>> +}; >>> + >>> /** >>> * DOC: standard connector properties >>> * >>> @@ -1548,6 +1575,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..58db66e 100644 >>> --- a/include/drm/drm_connector.h >>> +++ b/include/drm/drm_connector.h >>> @@ -253,6 +253,42 @@ 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_NO_DATA 0 >>> +#define DRM_MODE_COLORIMETRY_SMPTE_170M 1 >>> +#define DRM_MODE_COLORIMETRY_BT709 2 >> Still missing the YCbCr information in these two. > As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R > BT709, with no specific mention of RGB or YCbCr. Hence, kept it as > per spec. We seem to have a common field for both as per CTA spec. > Correct me if my understanding is wrong. Check "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), Colorimetry (C) and Extended Colorimetry (EC) Field Settings"
These Y2 Y1 Y0 values should be programmed separately and not through the colorspace as they are data formats isn't it. I feel this should get controlled separately independent of colorimetry, or should we add all the YCbCr and RGB versions and program them as part of this property itself
?
I don't think we can separate them. The values of the colorimetry bits doesn't mean anything without the Y bits. It would make the uapi kinda crazy if we allow the user to specify BT.2020 RGB but then we actually signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal a totally invalid value for all the other cases.
I agree we need data format also to be send along with colorspace, but they are 2 different things. To handle YCbCr and variants (YUV 444, 420 or 422) and RGB I feel we should expose a different API instead of using this one. We can create an output csc property which does that job for us.
So from a user perspective if we wants to set a colorspace we should use the one in this series and set the data format separately using the other interface. Both will be received in the state variables and later Infoframe packet will be created accordingly. Clubbing both in one may lead to lot of possible combinations exposed as enum which may not look too clean.
What do you say about handling that in the output csc property. I will go with what you recommend .
Programming Y2Y1Y0 is already taken care of, when we added support for YCBCR outputs (4:2:0 implementation). In intel_hdmi.c:intel_hdmi_set_avi_infoframe():
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
IMO This looks like a better way to handle this, ie while adding support for a new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
That's an exceptional case. We're programming the CSC in that case to do the RGB->YCbCr conversion without telling userspace. So we must also configure the Y bits automagically.
What we want is a check like so:
if (prop.colorspace != default && output_format != RGB) return -INVAL;
because we can't set up the CSC to make a mess of the user's carefully crafted pixels. The pixels might not even contain RGB data in that case.
We'll need to extend that a little bit once we add the explicit control of the output CSC via another prop. But the same principle should hold.
In fact, I remember the reason why we created infrastructure like this, so that, going forward, we could just add a output_format property, for which, we already have the backed and the state variables ready. The consume of this backend can be this drm_property (like output_format), or internal modeset like YCBCR4:2:0 only modes in EDID. It will also be inline with your suggestion of CSC property.
So we can have two properties colorspace (BT2020/SRGB/REC709) and color_model/color_format(RGB/YCBCR444/420), and a combination of both should program the output AVI info-frames. Does it appeal you ?
- Shashank
Regards, Uma Shankar
My idea was just to update colorimetry fields alone as part of this interface.
>>> +/* CEA 861 Extended Colorimetry Options */ #define >>> +DRM_MODE_COLORIMETRY_XVYCC_601
3
>>> +#define DRM_MODE_COLORIMETRY_XVYCC_709
4
>>> +#define DRM_MODE_COLORIMETRY_SYCC_601 5 >>> +#define DRM_MODE_COLORIMETRY_OPYCC_601
6
>>> +#define DRM_MODE_COLORIMETRY_OPRGB 7 >>> +#define DRM_MODE_COLORIMETRY_BT2020_YCC
8
>>> +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ >>> +#define DRM_MODE_COLORIMETRY_BT2020_RGB
9
>>> +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9 >> I though you didn't want these numbers to be based on the spec >> numbers? This duplicated value seems to go against that idea. > Yeah, for HDMI somehow was trying to utilize the definitions to > advantage. But I feel, It's better to de-couple this. Define this > as normal enum values sequentially so that userspace get readable > serial number kind values. > And use these in encoder files to get proper values to be > programmed as per respective spec, while defining those values per > encoder
separately.
Hope this is fine. >>> +/* Additional Colorimetry extension added as part of CTA 861.G */ >>> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 >>> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER 11 >>> + >>> +/* DP MSA Colorimetry Options */ #define >>> +DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601
12
>>> +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709
13
>> Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. >> YCC, order of the two). > Will fix this. Thanks Ville. > >>> +#define DRM_MODE_DP_COLORIMETRY_SRGB 14 >>> +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 15 >>> +#define DRM_MODE_DP_COLORIMETRY_SCRGB
16
>>> + >>> /** >>> * struct drm_display_info - runtime data about the connected sink >>> * >>> @@ -503,6 +539,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 +1038,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 +1318,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
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote:
Regards Shashank
-----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Shankar, Uma Sent: Friday, February 8, 2019 5:45 PM To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace property
>>> -----Original Message----- >>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >>> Sent: Tuesday, February 5, 2019 10:02 PM >>> To: Shankar, Uma uma.shankar@intel.com >>> Cc: intel-gfx@lists.freedesktop.org; >>> dri-devel@lists.freedesktop.org; Syrjala, Ville >>> ville.syrjala@intel.com; Lankhorst, Maarten >>> maarten.lankhorst@intel.com >>> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >>> property >>> >>> On Tue, Feb 05, 2019 at 09:33:34PM +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. >>>> >>>> v11: Addressed Ville's review comments. Updated the Macro >>>> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. >>>> >>>> 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 | 78 >>> +++++++++++++++++++++++++++++++++++++++ >>>> include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ >>>> 3 files changed, 132 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..4309873 100644 >>>> --- a/drivers/gpu/drm/drm_connector.c >>>> +++ b/drivers/gpu/drm/drm_connector.c >>>> @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" }, >>>> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >>>> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */ >>>> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >>>> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >>>> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >>>> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >>>> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >>>> + /* Colorimetry based on IEC 61966-2-5 [33] */ >>>> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >>>> + /* Colorimetry based on IEC 61966-2-5 */ >>>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >>>> + /* 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_RGB, "BT2020_RGB" }, >>>> + /* Colorimetry based on ITU-R BT.2020 */ >>>> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, >>>> + /* Added as part of Additional Colorimetry Extension in 861.G */ >>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-
P3_RGB_D65" },
>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >>> P3_RGB_Theater" }, >>>> +}; >>>> + >>>> /** >>>> * DOC: standard connector properties >>>> * >>>> @@ -1548,6 +1575,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..58db66e 100644 >>>> --- a/include/drm/drm_connector.h >>>> +++ b/include/drm/drm_connector.h >>>> @@ -253,6 +253,42 @@ 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_NO_DATA 0 >>>> +#define DRM_MODE_COLORIMETRY_SMPTE_170M > 1 >>>> +#define DRM_MODE_COLORIMETRY_BT709 2 >>> Still missing the YCbCr information in these two. >> As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R >> BT709, with no specific mention of RGB or YCbCr. Hence, kept it as >> per spec. We seem to have a common field for both as per CTA spec. >> Correct me if my understanding is wrong. > Check > "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), > Colorimetry > (C) and Extended Colorimetry (EC) Field Settings" These Y2 Y1 Y0 values should be programmed separately and not through the colorspace as they are data formats isn't it. I feel this should get controlled separately independent of colorimetry, or should we add all the YCbCr and RGB versions and program them as part of this property itself
?
I don't think we can separate them. The values of the colorimetry bits doesn't mean anything without the Y bits. It would make the uapi kinda crazy if we allow the user to specify BT.2020 RGB but then we actually signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal a totally invalid value for all the other cases.
I agree we need data format also to be send along with colorspace, but they are 2 different things. To handle YCbCr and variants (YUV 444, 420 or 422) and RGB I feel we should expose a different API instead of using this one. We can create an output csc property which does that job for us.
So from a user perspective if we wants to set a colorspace we should use the one in this series and set the data format separately using the other interface. Both will be received in the state variables and later Infoframe packet will be created accordingly. Clubbing both in one may lead to lot of possible combinations exposed as enum which may not look too clean.
What do you say about handling that in the output csc property. I will go with what you recommend .
Programming Y2Y1Y0 is already taken care of, when we added support for YCBCR outputs (4:2:0 implementation). In intel_hdmi.c:intel_hdmi_set_avi_infoframe():
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
IMO This looks like a better way to handle this, ie while adding support for a new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
That's an exceptional case. We're programming the CSC in that case to do the RGB->YCbCr conversion without telling userspace. So we must also configure the Y bits automagically.
What we want is a check like so:
if (prop.colorspace != default && output_format != RGB) return -INVAL;
because we can't set up the CSC to make a mess of the user's carefully crafted pixels. The pixels might not even contain RGB data in that case.
We'll need to extend that a little bit once we add the explicit control of the output CSC via another prop. But the same principle should hold.
In fact, I remember the reason why we created infrastructure like this, so that, going forward, we could just add a output_format property, for which, we already have the backed and the state variables ready. The consume of this backend can be this drm_property (like output_format), or internal modeset like YCBCR4:2:0 only modes in EDID. It will also be inline with your suggestion of CSC property.
So we can have two properties colorspace (BT2020/SRGB/REC709) and color_model/color_format(RGB/YCBCR444/420), and a combination of both should program the output AVI info-frames. Does it appeal you ?
I'm not sure it's feasible to split it like that. The combinations supported by the infoframe are rather specific so trying to split it up leads to either super limited uapi, or one that exposes a lot of illegal combinations. Also DP has slightly different set of things it supports which adds more complications.
So I think the best option is still to include the Y=yes/no information in the prop value alognside the C/EC/ACE bits.
- Shashank
Regards, Uma Shankar
My idea was just to update colorimetry fields alone as part of this interface.
>>>> +/* CEA 861 Extended Colorimetry Options */ #define >>>> +DRM_MODE_COLORIMETRY_XVYCC_601
3
>>>> +#define DRM_MODE_COLORIMETRY_XVYCC_709
4
>>>> +#define DRM_MODE_COLORIMETRY_SYCC_601 5 >>>> +#define DRM_MODE_COLORIMETRY_OPYCC_601
6
>>>> +#define DRM_MODE_COLORIMETRY_OPRGB 7 >>>> +#define DRM_MODE_COLORIMETRY_BT2020_YCC
8
>>>> +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ >>>> +#define DRM_MODE_COLORIMETRY_BT2020_RGB
9
>>>> +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9 >>> I though you didn't want these numbers to be based on the spec >>> numbers? This duplicated value seems to go against that idea. >> Yeah, for HDMI somehow was trying to utilize the definitions to >> advantage. But I feel, It's better to de-couple this. Define this >> as normal enum values sequentially so that userspace get readable >> serial number > kind values. >> And use these in encoder files to get proper values to be >> programmed as per respective spec, while defining those values per >> encoder
separately.
> Hope this is fine. >>>> +/* Additional Colorimetry extension added as part of CTA 861.G */ >>>> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 >>>> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER > 11 >>>> + >>>> +/* DP MSA Colorimetry Options */ #define >>>> +DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601
12
>>>> +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709
13
>>> Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. >>> YCC, order of the two). >> Will fix this. Thanks Ville. >> >>>> +#define DRM_MODE_DP_COLORIMETRY_SRGB 14 >>>> +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT > 15 >>>> +#define DRM_MODE_DP_COLORIMETRY_SCRGB
16
>>>> + >>>> /** >>>> * struct drm_display_info - runtime data about the connected sink >>>> * >>>> @@ -503,6 +539,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 +1038,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 +1318,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
Regards
Shashank
On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote:
Regards Shashank
-----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Shankar, Uma Sent: Friday, February 8, 2019 5:45 PM To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace property
>>>> -----Original Message----- >>>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >>>> Sent: Tuesday, February 5, 2019 10:02 PM >>>> To: Shankar, Uma uma.shankar@intel.com >>>> Cc: intel-gfx@lists.freedesktop.org; >>>> dri-devel@lists.freedesktop.org; Syrjala, Ville >>>> ville.syrjala@intel.com; Lankhorst, Maarten >>>> maarten.lankhorst@intel.com >>>> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >>>> property >>>> >>>> On Tue, Feb 05, 2019 at 09:33:34PM +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. >>>>> >>>>> v11: Addressed Ville's review comments. Updated the Macro >>>>> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. >>>>> >>>>> 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 | 78 >>>> +++++++++++++++++++++++++++++++++++++++ >>>>> include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ >>>>> 3 files changed, 132 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..4309873 100644 >>>>> --- a/drivers/gpu/drm/drm_connector.c >>>>> +++ b/drivers/gpu/drm/drm_connector.c >>>>> @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" }, >>>>> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >>>>> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */ >>>>> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >>>>> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >>>>> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >>>>> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >>>>> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >>>>> + /* Colorimetry based on IEC 61966-2-5 [33] */ >>>>> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >>>>> + /* Colorimetry based on IEC 61966-2-5 */ >>>>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >>>>> + /* 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_RGB, "BT2020_RGB" }, >>>>> + /* Colorimetry based on ITU-R BT.2020 */ >>>>> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, >>>>> + /* Added as part of Additional Colorimetry Extension in 861.G */ >>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI- P3_RGB_D65" }, >>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >>>> P3_RGB_Theater" }, >>>>> +}; >>>>> + >>>>> /** >>>>> * DOC: standard connector properties >>>>> * >>>>> @@ -1548,6 +1575,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..58db66e 100644 >>>>> --- a/include/drm/drm_connector.h >>>>> +++ b/include/drm/drm_connector.h >>>>> @@ -253,6 +253,42 @@ 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_NO_DATA 0 >>>>> +#define DRM_MODE_COLORIMETRY_SMPTE_170M >> 1 >>>>> +#define DRM_MODE_COLORIMETRY_BT709 2 >>>> Still missing the YCbCr information in these two. >>> As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R >>> BT709, with no specific mention of RGB or YCbCr. Hence, kept it as >>> per spec. We seem to have a common field for both as per CTA spec. >>> Correct me if my understanding is wrong. >> Check >> "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), >> Colorimetry >> (C) and Extended Colorimetry (EC) Field Settings" > These Y2 Y1 Y0 values should be programmed separately and not > through the colorspace as they are data formats isn't it. I feel this > should get controlled separately independent of colorimetry, or > should we add all the YCbCr and RGB versions and program them as part > of this property itself ?
I don't think we can separate them. The values of the colorimetry bits doesn't mean anything without the Y bits. It would make the uapi kinda crazy if we allow the user to specify BT.2020 RGB but then we actually signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal a totally invalid value for all the other cases.
I agree we need data format also to be send along with colorspace, but they are 2 different things. To handle YCbCr and variants (YUV 444, 420 or 422) and RGB I feel we should expose a different API instead of using this one. We can create an output csc property which does that job for us.
So from a user perspective if we wants to set a colorspace we should use the one in this series and set the data format separately using the other interface. Both will be received in the state variables and later Infoframe packet will be created accordingly. Clubbing both in one may lead to lot of possible combinations exposed as enum which may not look too clean.
What do you say about handling that in the output csc property. I will go with what you recommend .
Programming Y2Y1Y0 is already taken care of, when we added support for YCBCR outputs (4:2:0 implementation). In intel_hdmi.c:intel_hdmi_set_avi_infoframe():
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
IMO This looks like a better way to handle this, ie while adding support for a new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
That's an exceptional case. We're programming the CSC in that case to do the RGB->YCbCr conversion without telling userspace. So we must also configure the Y bits automagically.
What we want is a check like so:
if (prop.colorspace != default && output_format != RGB) return -INVAL;
because we can't set up the CSC to make a mess of the user's carefully crafted pixels. The pixels might not even contain RGB data in that case.
We'll need to extend that a little bit once we add the explicit control of the output CSC via another prop. But the same principle should hold.
In fact, I remember the reason why we created infrastructure like this, so that, going forward, we could just add a output_format property, for which, we already have the backed and the state variables ready. The consume of this backend can be this drm_property (like output_format), or internal modeset like YCBCR4:2:0 only modes in EDID. It will also be inline with your suggestion of CSC property.
So we can have two properties colorspace (BT2020/SRGB/REC709) and color_model/color_format(RGB/YCBCR444/420), and a combination of both should program the output AVI info-frames. Does it appeal you ?
I'm not sure it's feasible to split it like that. The combinations supported by the infoframe are rather specific so trying to split it up leads to either super limited uapi, or one that exposes a lot of illegal combinations. Also DP has slightly different set of things it supports which adds more complications.
So I think the best option is still to include the Y=yes/no information in the prop value alognside the C/EC/ACE bits.
Yes, you are right, this could be a simpler way of doing things, but with a limited set of combination.
Consider this example:
- If a HDMI monitor supports BT2020, but doesn't support YCBCR formatting, how to handle this option ? This means we have to selectively show BT2020_RGB enum value only not BT2020_YCBCR_444/420,
- This also means we have to probe the EDID first, and then create this property, which means we will be dependent on the hot-plug / detect to create this property, instead of doing this in hdmi_init.
Even more complex scenario would be when the output support depends on monitor + platform both. This means we have to provide this combination upfront while creating this property.
On the other hand, the invalid combination of two property, it would be easy to detect at runtime at atomic_check() and fail the commit.
This is just a thought, honestly I am also not sure what would be the most appropriate solution for this, but seems its simpler to create property with two properties, might be difficult to manage at runtime.
With one property, its very difficult to create, but once created, it would work sure shot.
- Shashank
- Shashank
Regards, Uma Shankar
> My idea was just to update colorimetry fields alone as part of this interface. > >>>>> +/* CEA 861 Extended Colorimetry Options */ #define >>>>> +DRM_MODE_COLORIMETRY_XVYCC_601 3 >>>>> +#define DRM_MODE_COLORIMETRY_XVYCC_709 4 >>>>> +#define DRM_MODE_COLORIMETRY_SYCC_601 5 >>>>> +#define DRM_MODE_COLORIMETRY_OPYCC_601 6 >>>>> +#define DRM_MODE_COLORIMETRY_OPRGB 7 >>>>> +#define DRM_MODE_COLORIMETRY_BT2020_YCC 8 >>>>> +/* Both BT2020_RGB and BT2020_YCbCbCr have same value */ >>>>> +#define DRM_MODE_COLORIMETRY_BT2020_RGB 9 >>>>> +#define DRM_MODE_COLORIMETRY_BT2020_CYCC 9 >>>> I though you didn't want these numbers to be based on the spec >>>> numbers? This duplicated value seems to go against that idea. >>> Yeah, for HDMI somehow was trying to utilize the definitions to >>> advantage. But I feel, It's better to de-couple this. Define this >>> as normal enum values sequentially so that userspace get readable >>> serial number >> kind values. >>> And use these in encoder files to get proper values to be >>> programmed as per respective spec, while defining those values per >>> encoder separately. >> Hope this is fine. >>>>> +/* Additional Colorimetry extension added as part of CTA 861.G */ >>>>> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 10 >>>>> +#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER >> 11 >>>>> + >>>>> +/* DP MSA Colorimetry Options */ #define >>>>> +DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601 12 >>>>> +#define DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709 13 >>>> Still inconsistent naming in many places (ITU_ vs. BT, YCBCR vs. >>>> YCC, order of the two). >>> Will fix this. Thanks Ville. >>> >>>>> +#define DRM_MODE_DP_COLORIMETRY_SRGB 14 >>>>> +#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT >> 15 >>>>> +#define DRM_MODE_DP_COLORIMETRY_SCRGB 16 >>>>> + >>>>> /** >>>>> * struct drm_display_info - runtime data about the connected sink >>>>> * >>>>> @@ -503,6 +539,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 +1038,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 +1318,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
On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote:
Regards Shashank
-----Original Message----- From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Shankar, Uma Sent: Friday, February 8, 2019 5:45 PM To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace property
>>>>> -----Original Message----- >>>>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >>>>> Sent: Tuesday, February 5, 2019 10:02 PM >>>>> To: Shankar, Uma uma.shankar@intel.com >>>>> Cc: intel-gfx@lists.freedesktop.org; >>>>> dri-devel@lists.freedesktop.org; Syrjala, Ville >>>>> ville.syrjala@intel.com; Lankhorst, Maarten >>>>> maarten.lankhorst@intel.com >>>>> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >>>>> property >>>>> >>>>> On Tue, Feb 05, 2019 at 09:33:34PM +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. >>>>>> >>>>>> v11: Addressed Ville's review comments. Updated the Macro >>>>>> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. >>>>>> >>>>>> 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 | 78 >>>>> +++++++++++++++++++++++++++++++++++++++ >>>>>> include/drm/drm_connector.h | 50 +++++++++++++++++++++++++ >>>>>> 3 files changed, 132 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..4309873 100644 >>>>>> --- a/drivers/gpu/drm/drm_connector.c >>>>>> +++ b/drivers/gpu/drm/drm_connector.c >>>>>> @@ -826,6 +826,33 @@ 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_SMPTE_170M, "SMPTE_170M" }, >>>>>> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >>>>>> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */ >>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >>>>>> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >>>>>> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >>>>>> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >>>>>> + /* Colorimetry based on IEC 61966-2-5 [33] */ >>>>>> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >>>>>> + /* Colorimetry based on IEC 61966-2-5 */ >>>>>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >>>>>> + /* 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_RGB, "BT2020_RGB" }, >>>>>> + /* Colorimetry based on ITU-R BT.2020 */ >>>>>> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, >>>>>> + /* Added as part of Additional Colorimetry Extension in 861.G */ >>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI- > P3_RGB_D65" }, >>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >>>>> P3_RGB_Theater" }, >>>>>> +}; >>>>>> + >>>>>> /** >>>>>> * DOC: standard connector properties >>>>>> * >>>>>> @@ -1548,6 +1575,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..58db66e 100644 >>>>>> --- a/include/drm/drm_connector.h >>>>>> +++ b/include/drm/drm_connector.h >>>>>> @@ -253,6 +253,42 @@ 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_NO_DATA 0 >>>>>> +#define DRM_MODE_COLORIMETRY_SMPTE_170M >>> 1 >>>>>> +#define DRM_MODE_COLORIMETRY_BT709 2 >>>>> Still missing the YCbCr information in these two. >>>> As per CTA 861.G spec, we have these as only SMPTE_170M and ITU-R >>>> BT709, with no specific mention of RGB or YCbCr. Hence, kept it as >>>> per spec. We seem to have a common field for both as per CTA spec. >>>> Correct me if my understanding is wrong. >>> Check >>> "Table 14 Picture Colorimetry Indicated by the RGB or YC B C R (Y), >>> Colorimetry >>> (C) and Extended Colorimetry (EC) Field Settings" >> These Y2 Y1 Y0 values should be programmed separately and not >> through the colorspace as they are data formats isn't it. I feel this >> should get controlled separately independent of colorimetry, or >> should we add all the YCbCr and RGB versions and program them as part >> of this property itself > ? > > I don't think we can separate them. The values of the colorimetry bits > doesn't mean anything without the Y bits. It would make the uapi kinda > crazy if we allow the user to specify BT.2020 RGB but then we actually > signal BT.2020 YCbCr in the infoframe, or vice versa. Or we just signal > a totally invalid value for all the other cases. I agree we need data format also to be send along with colorspace, but they are 2 different things. To handle YCbCr and variants (YUV 444, 420 or 422) and RGB I feel we should expose a different API instead of using this one. We can create an output csc property which does that job for us.
So from a user perspective if we wants to set a colorspace we should use the one in this series and set the data format separately using the other interface. Both will be received in the state variables and later Infoframe packet will be created accordingly. Clubbing both in one may lead to lot of possible combinations exposed as enum which may not look too clean.
What do you say about handling that in the output csc property. I will go with what you recommend .
Programming Y2Y1Y0 is already taken care of, when we added support for YCBCR outputs (4:2:0 implementation). In intel_hdmi.c:intel_hdmi_set_avi_infoframe():
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
IMO This looks like a better way to handle this, ie while adding support for a new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
That's an exceptional case. We're programming the CSC in that case to do the RGB->YCbCr conversion without telling userspace. So we must also configure the Y bits automagically.
What we want is a check like so:
if (prop.colorspace != default && output_format != RGB) return -INVAL;
because we can't set up the CSC to make a mess of the user's carefully crafted pixels. The pixels might not even contain RGB data in that case.
We'll need to extend that a little bit once we add the explicit control of the output CSC via another prop. But the same principle should hold.
In fact, I remember the reason why we created infrastructure like this, so that, going forward, we could just add a output_format property, for which, we already have the backed and the state variables ready. The consume of this backend can be this drm_property (like output_format), or internal modeset like YCBCR4:2:0 only modes in EDID. It will also be inline with your suggestion of CSC property.
So we can have two properties colorspace (BT2020/SRGB/REC709) and color_model/color_format(RGB/YCBCR444/420), and a combination of both should program the output AVI info-frames. Does it appeal you ?
I'm not sure it's feasible to split it like that. The combinations supported by the infoframe are rather specific so trying to split it up leads to either super limited uapi, or one that exposes a lot of illegal combinations. Also DP has slightly different set of things it supports which adds more complications.
So I think the best option is still to include the Y=yes/no information in the prop value alognside the C/EC/ACE bits.
Yes, you are right, this could be a simpler way of doing things, but with a limited set of combination.
Consider this example:
- If a HDMI monitor supports BT2020, but doesn't support YCBCR
formatting, how to handle this option ? This means we have to selectively show BT2020_RGB enum value only not BT2020_YCBCR_444/420,
- This also means we have to probe the EDID first, and then create this
property, which means we will be dependent on the hot-plug / detect to create this property, instead of doing this in hdmi_init.
IMO we just ignore this problem and expose all the legal options the spec has.
If userspace wants to know what's actually supported it will have to parse the EDID. We could think about parsing that in the kernel too and exposing an immutable prop to expose that infromation. But I'm not sure this is such a good idea since we'd basically drown in properties if we try to expose all the information from the EDID. A better long term plan would be a common EDID parsing library for everyone.
Even more complex scenario would be when the output support depends on monitor + platform both. This means we have to provide this combination upfront while creating this property.
On the other hand, the invalid combination of two property, it would be easy to detect at runtime at atomic_check() and fail the commit.
This is just a thought, honestly I am also not sure what would be the most appropriate solution for this, but seems its simpler to create property with two properties, might be difficult to manage at runtime.
With one property, its very difficult to create, but once created, it would work sure shot.
I don't think it's that difficult. Just expose all the things in the CTA-861 big table. Which means including the Y bit too.
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Friday, February 8, 2019 8:08 PM To: Sharma, Shashank shashank.sharma@intel.com Cc: Shankar, Uma uma.shankar@intel.com; 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] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote:
Regards Shashank
> -----Original Message----- > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] > On Behalf Of Shankar, Uma > Sent: Friday, February 8, 2019 5:45 PM > To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace > property > >>>>>> -----Original Message----- >>>>>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >>>>>> Sent: Tuesday, February 5, 2019 10:02 PM >>>>>> To: Shankar, Uma uma.shankar@intel.com >>>>>> Cc: intel-gfx@lists.freedesktop.org; >>>>>> dri-devel@lists.freedesktop.org; Syrjala, Ville >>>>>> ville.syrjala@intel.com; Lankhorst, Maarten >>>>>> maarten.lankhorst@intel.com >>>>>> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >>>>>> property >>>>>> >>>>>> On Tue, Feb 05, 2019 at 09:33:34PM +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.
>>>>>>> >>>>>>> v11: Addressed Ville's review comments. Updated the Macro >>>>>>> naming and added DCI-P3 colorspace as well defined in CEA 861.G
spec.
>>>>>>> >>>>>>> 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 | 78 >>>>>> +++++++++++++++++++++++++++++++++++++++ >>>>>>> include/drm/drm_connector.h | 50
+++++++++++++++++++++++++
>>>>>>> 3 files changed, 132 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..4309873 >>>>>>> 100644 >>>>>>> --- a/drivers/gpu/drm/drm_connector.c >>>>>>> +++ b/drivers/gpu/drm/drm_connector.c >>>>>>> @@ -826,6 +826,33 @@ 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_SMPTE_170M,
"SMPTE_170M" },
>>>>>>> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >>>>>>> + /* Standard Definition Colorimetry based on IEC 61966-2-4
*/
>>>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >>>>>>> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >>>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >>>>>>> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >>>>>>> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >>>>>>> + /* Colorimetry based on IEC 61966-2-5 [33] */ >>>>>>> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >>>>>>> + /* Colorimetry based on IEC 61966-2-5 */ >>>>>>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >>>>>>> + /* 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_RGB, "BT2020_RGB"
},
>>>>>>> + /* Colorimetry based on ITU-R BT.2020 */ >>>>>>> + { DRM_MODE_COLORIMETRY_BT2020_CYCC,
"BT2020_CYCC" },
>>>>>>> + /* Added as part of Additional Colorimetry Extension in
861.G */
>>>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI- >> P3_RGB_D65" }, >>>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >>>>>> P3_RGB_Theater" }, >>>>>>> +}; >>>>>>> + >>>>>>> /** >>>>>>> * DOC: standard connector properties >>>>>>> * >>>>>>> @@ -1548,6 +1575,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..58db66e >>>>>>> 100644 >>>>>>> --- a/include/drm/drm_connector.h >>>>>>> +++ b/include/drm/drm_connector.h >>>>>>> @@ -253,6 +253,42 @@ 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_NO_DATA 0 >>>>>>> +#define DRM_MODE_COLORIMETRY_SMPTE_170M >>>> 1 >>>>>>> +#define DRM_MODE_COLORIMETRY_BT709 2 >>>>>> Still missing the YCbCr information in these two. >>>>> As per CTA 861.G spec, we have these as only SMPTE_170M and >>>>> ITU-R BT709, with no specific mention of RGB or YCbCr. >>>>> Hence, kept it as per spec. We seem to have a common field for both as
per CTA spec.
>>>>> Correct me if my understanding is wrong. >>>> Check >>>> "Table 14 Picture Colorimetry Indicated by the RGB or YC B C >>>> R (Y), Colorimetry >>>> (C) and Extended Colorimetry (EC) Field Settings" >>> These Y2 Y1 Y0 values should be programmed separately and not >>> through the colorspace as they are data formats isn't it. I >>> feel this should get controlled separately independent of >>> colorimetry, or should we add all the YCbCr and RGB versions >>> and program them as part of this property itself >> ? >> >> I don't think we can separate them. The values of the >> colorimetry bits doesn't mean anything without the Y bits. It >> would make the uapi kinda crazy if we allow the user to specify >> BT.2020 RGB but then we actually signal BT.2020 YCbCr in the >> infoframe, or vice versa. Or we just signal a totally invalid value for all the
other cases.
> I agree we need data format also to be send along with > colorspace, but they are 2 different things. To handle YCbCr and > variants (YUV 444, 420 or 422) and RGB I feel we should expose a > different API instead of using this one. We can create an output csc property
which does that job for us.
> > So from a user perspective if we wants to set a colorspace we > should use the one in this series and set the data format > separately using the other interface. Both will be received in the state
variables and later Infoframe packet will be created accordingly.
> Clubbing both in one may lead to lot of possible combinations > exposed as enum which may not look too clean. > > What do you say about handling that in the output csc property. > I will go with what you recommend . Programming Y2Y1Y0 is already taken care of, when we added support for
YCBCR outputs (4:2:0 implementation).
In intel_hdmi.c:intel_hdmi_set_avi_infoframe():
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
IMO This looks like a better way to handle this, ie while adding support for a
new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
That's an exceptional case. We're programming the CSC in that case to do the RGB->YCbCr conversion without telling userspace. So we must also configure the Y bits automagically.
What we want is a check like so:
if (prop.colorspace != default && output_format != RGB) return -INVAL;
because we can't set up the CSC to make a mess of the user's carefully crafted pixels. The pixels might not even contain RGB data in that case.
We'll need to extend that a little bit once we add the explicit control of the output CSC via another prop. But the same principle should hold.
In fact, I remember the reason why we created infrastructure like this, so that, going forward, we could just add a output_format property, for which, we already have the backed and the state variables ready. The consume of this backend can be this drm_property (like output_format), or internal modeset like YCBCR4:2:0 only modes in EDID. It will also be inline with your suggestion of CSC
property.
So we can have two properties colorspace (BT2020/SRGB/REC709) and color_model/color_format(RGB/YCBCR444/420), and a combination of both should program the output AVI info-frames. Does it appeal you ?
I'm not sure it's feasible to split it like that. The combinations supported by the infoframe are rather specific so trying to split it up leads to either super limited uapi, or one that exposes a lot of illegal combinations. Also DP has slightly different set of things it supports which adds more complications.
So I think the best option is still to include the Y=yes/no information in the prop value alognside the C/EC/ACE bits.
Yes, you are right, this could be a simpler way of doing things, but with a limited set of combination.
Consider this example:
- If a HDMI monitor supports BT2020, but doesn't support YCBCR
formatting, how to handle this option ? This means we have to selectively show BT2020_RGB enum value only not BT2020_YCBCR_444/420,
- This also means we have to probe the EDID first, and then create
this property, which means we will be dependent on the hot-plug / detect to create this property, instead of doing this in hdmi_init.
IMO we just ignore this problem and expose all the legal options the spec has.
If userspace wants to know what's actually supported it will have to parse the EDID. We could think about parsing that in the kernel too and exposing an immutable prop to expose that infromation. But I'm not sure this is such a good idea since we'd basically drown in properties if we try to expose all the information from the EDID. A better long term plan would be a common EDID parsing library for everyone.
Even more complex scenario would be when the output support depends on monitor + platform both. This means we have to provide this combination upfront while creating this property.
On the other hand, the invalid combination of two property, it would be easy to detect at runtime at atomic_check() and fail the commit.
This is just a thought, honestly I am also not sure what would be the most appropriate solution for this, but seems its simpler to create property with two properties, might be difficult to manage at runtime.
With one property, its very difficult to create, but once created, it would work sure shot.
I don't think it's that difficult. Just expose all the things in the CTA-861 big table. Which means including the Y bit too.
Hi Ville, Ok So will try to do this way then:
Have a separate enum option like DRM_MODE_COLORIMETRY_BT709_YUV444 DRM_MODE_COLORIMETRY_BT709_YUV420 DRM_MODE_COLORIMETRY_BT709_YUV422
and so on for all the others.
Expectation from userspace will be that he should be having content as per above Data format and colorspace and also should be aware that sink is supporting that which can be obtained from EDID.
In driver we will check this and set the appropriate bits of infoframe and send.
Regards, Uma Shankar
-- Ville Syrjälä Intel
On Fri, Feb 08, 2019 at 03:03:34PM +0000, Shankar, Uma wrote:
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Friday, February 8, 2019 8:08 PM To: Sharma, Shashank shashank.sharma@intel.com Cc: Shankar, Uma uma.shankar@intel.com; 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] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote: > Regards > Shashank > >> -----Original Message----- >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] >> On Behalf Of Shankar, Uma >> Sent: Friday, February 8, 2019 5:45 PM >> To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace >> property >> >>>>>>> -----Original Message----- >>>>>>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >>>>>>> Sent: Tuesday, February 5, 2019 10:02 PM >>>>>>> To: Shankar, Uma uma.shankar@intel.com >>>>>>> Cc: intel-gfx@lists.freedesktop.org; >>>>>>> dri-devel@lists.freedesktop.org; Syrjala, Ville >>>>>>> ville.syrjala@intel.com; Lankhorst, Maarten >>>>>>> maarten.lankhorst@intel.com >>>>>>> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >>>>>>> property >>>>>>> >>>>>>> On Tue, Feb 05, 2019 at 09:33:34PM +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.
>>>>>>>> >>>>>>>> v11: Addressed Ville's review comments. Updated the Macro >>>>>>>> naming and added DCI-P3 colorspace as well defined in CEA 861.G
spec.
>>>>>>>> >>>>>>>> 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 | 78 >>>>>>> +++++++++++++++++++++++++++++++++++++++ >>>>>>>> include/drm/drm_connector.h | 50
+++++++++++++++++++++++++
>>>>>>>> 3 files changed, 132 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..4309873 >>>>>>>> 100644 >>>>>>>> --- a/drivers/gpu/drm/drm_connector.c >>>>>>>> +++ b/drivers/gpu/drm/drm_connector.c >>>>>>>> @@ -826,6 +826,33 @@ 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_SMPTE_170M,
"SMPTE_170M" },
>>>>>>>> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >>>>>>>> + /* Standard Definition Colorimetry based on IEC 61966-2-4
*/
>>>>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >>>>>>>> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >>>>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >>>>>>>> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >>>>>>>> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >>>>>>>> + /* Colorimetry based on IEC 61966-2-5 [33] */ >>>>>>>> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >>>>>>>> + /* Colorimetry based on IEC 61966-2-5 */ >>>>>>>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >>>>>>>> + /* 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_RGB, "BT2020_RGB"
},
>>>>>>>> + /* Colorimetry based on ITU-R BT.2020 */ >>>>>>>> + { DRM_MODE_COLORIMETRY_BT2020_CYCC,
"BT2020_CYCC" },
>>>>>>>> + /* Added as part of Additional Colorimetry Extension in
861.G */
>>>>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI- >>> P3_RGB_D65" }, >>>>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >>>>>>> P3_RGB_Theater" }, >>>>>>>> +}; >>>>>>>> + >>>>>>>> /** >>>>>>>> * DOC: standard connector properties >>>>>>>> * >>>>>>>> @@ -1548,6 +1575,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..58db66e >>>>>>>> 100644 >>>>>>>> --- a/include/drm/drm_connector.h >>>>>>>> +++ b/include/drm/drm_connector.h >>>>>>>> @@ -253,6 +253,42 @@ 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_NO_DATA 0 >>>>>>>> +#define DRM_MODE_COLORIMETRY_SMPTE_170M >>>>> 1 >>>>>>>> +#define DRM_MODE_COLORIMETRY_BT709 2 >>>>>>> Still missing the YCbCr information in these two. >>>>>> As per CTA 861.G spec, we have these as only SMPTE_170M and >>>>>> ITU-R BT709, with no specific mention of RGB or YCbCr. >>>>>> Hence, kept it as per spec. We seem to have a common field for both as
per CTA spec.
>>>>>> Correct me if my understanding is wrong. >>>>> Check >>>>> "Table 14 Picture Colorimetry Indicated by the RGB or YC B C >>>>> R (Y), Colorimetry >>>>> (C) and Extended Colorimetry (EC) Field Settings" >>>> These Y2 Y1 Y0 values should be programmed separately and not >>>> through the colorspace as they are data formats isn't it. I >>>> feel this should get controlled separately independent of >>>> colorimetry, or should we add all the YCbCr and RGB versions >>>> and program them as part of this property itself >>> ? >>> >>> I don't think we can separate them. The values of the >>> colorimetry bits doesn't mean anything without the Y bits. It >>> would make the uapi kinda crazy if we allow the user to specify >>> BT.2020 RGB but then we actually signal BT.2020 YCbCr in the >>> infoframe, or vice versa. Or we just signal a totally invalid value for all the
other cases.
>> I agree we need data format also to be send along with >> colorspace, but they are 2 different things. To handle YCbCr and >> variants (YUV 444, 420 or 422) and RGB I feel we should expose a >> different API instead of using this one. We can create an output csc property
which does that job for us.
>> >> So from a user perspective if we wants to set a colorspace we >> should use the one in this series and set the data format >> separately using the other interface. Both will be received in the state
variables and later Infoframe packet will be created accordingly.
>> Clubbing both in one may lead to lot of possible combinations >> exposed as enum which may not look too clean. >> >> What do you say about handling that in the output csc property. >> I will go with what you recommend . > Programming Y2Y1Y0 is already taken care of, when we added support for
YCBCR outputs (4:2:0 implementation).
> In intel_hdmi.c:intel_hdmi_set_avi_infoframe(): > > if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) > frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if > (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) > frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else > frame.avi.colorspace = HDMI_COLORSPACE_RGB; > > IMO This looks like a better way to handle this, ie while adding support for a
new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
That's an exceptional case. We're programming the CSC in that case to do the RGB->YCbCr conversion without telling userspace. So we must also configure the Y bits automagically.
What we want is a check like so:
if (prop.colorspace != default && output_format != RGB) return -INVAL;
because we can't set up the CSC to make a mess of the user's carefully crafted pixels. The pixels might not even contain RGB data in that case.
We'll need to extend that a little bit once we add the explicit control of the output CSC via another prop. But the same principle should hold.
In fact, I remember the reason why we created infrastructure like this, so that, going forward, we could just add a output_format property, for which, we already have the backed and the state variables ready. The consume of this backend can be this drm_property (like output_format), or internal modeset like YCBCR4:2:0 only modes in EDID. It will also be inline with your suggestion of CSC
property.
So we can have two properties colorspace (BT2020/SRGB/REC709) and color_model/color_format(RGB/YCBCR444/420), and a combination of both should program the output AVI info-frames. Does it appeal you ?
I'm not sure it's feasible to split it like that. The combinations supported by the infoframe are rather specific so trying to split it up leads to either super limited uapi, or one that exposes a lot of illegal combinations. Also DP has slightly different set of things it supports which adds more complications.
So I think the best option is still to include the Y=yes/no information in the prop value alognside the C/EC/ACE bits.
Yes, you are right, this could be a simpler way of doing things, but with a limited set of combination.
Consider this example:
- If a HDMI monitor supports BT2020, but doesn't support YCBCR
formatting, how to handle this option ? This means we have to selectively show BT2020_RGB enum value only not BT2020_YCBCR_444/420,
- This also means we have to probe the EDID first, and then create
this property, which means we will be dependent on the hot-plug / detect to create this property, instead of doing this in hdmi_init.
IMO we just ignore this problem and expose all the legal options the spec has.
If userspace wants to know what's actually supported it will have to parse the EDID. We could think about parsing that in the kernel too and exposing an immutable prop to expose that infromation. But I'm not sure this is such a good idea since we'd basically drown in properties if we try to expose all the information from the EDID. A better long term plan would be a common EDID parsing library for everyone.
Even more complex scenario would be when the output support depends on monitor + platform both. This means we have to provide this combination upfront while creating this property.
On the other hand, the invalid combination of two property, it would be easy to detect at runtime at atomic_check() and fail the commit.
This is just a thought, honestly I am also not sure what would be the most appropriate solution for this, but seems its simpler to create property with two properties, might be difficult to manage at runtime.
With one property, its very difficult to create, but once created, it would work sure shot.
I don't think it's that difficult. Just expose all the things in the CTA-861 big table. Which means including the Y bit too.
Hi Ville, Ok So will try to do this way then:
Have a separate enum option like DRM_MODE_COLORIMETRY_BT709_YUV444 DRM_MODE_COLORIMETRY_BT709_YUV420 DRM_MODE_COLORIMETRY_BT709_YUV422
Hmm. I'm not quite convinced that we want the subsampling information included here. That will make it difficult to do the output csc property in a way that leaves the driver free to select the subsampling automagically, which we proably still want because of those annoying HDMI 2.0 monitors.
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Friday, February 8, 2019 9:06 PM To: Shankar, Uma uma.shankar@intel.com Cc: Sharma, Shashank shashank.sharma@intel.com; 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] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 03:03:34PM +0000, Shankar, Uma wrote:
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Friday, February 8, 2019 8:08 PM To: Sharma, Shashank shashank.sharma@intel.com Cc: Shankar, Uma uma.shankar@intel.com; 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] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote: > On Fri, Feb 08, 2019 at 12:36:25PM +0000, Sharma, Shashank wrote: >> Regards >> Shashank >> >>> -----Original Message----- >>> From: Intel-gfx >>> [mailto:intel-gfx-bounces@lists.freedesktop.org] >>> On Behalf Of Shankar, Uma >>> Sent: Friday, February 8, 2019 5:45 PM >>> To: Ville Syrjälä ville.syrjala@linux.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] [v11 1/4] drm: Add HDMI colorspace >>> property >>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ville Syrjälä >>>>>>>> [mailto:ville.syrjala@linux.intel.com] >>>>>>>> Sent: Tuesday, February 5, 2019 10:02 PM >>>>>>>> To: Shankar, Uma uma.shankar@intel.com >>>>>>>> Cc: intel-gfx@lists.freedesktop.org; >>>>>>>> dri-devel@lists.freedesktop.org; Syrjala, Ville >>>>>>>> ville.syrjala@intel.com; Lankhorst, Maarten >>>>>>>> maarten.lankhorst@intel.com >>>>>>>> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI >>>>>>>> colorspace property >>>>>>>> >>>>>>>> On Tue, Feb 05, 2019 at 09:33:34PM +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.
>>>>>>>>> >>>>>>>>> v11: Addressed Ville's review comments. Updated the >>>>>>>>> Macro naming and added DCI-P3 colorspace as well >>>>>>>>> defined in CEA 861.G
spec.
>>>>>>>>> >>>>>>>>> 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 | 78 >>>>>>>> +++++++++++++++++++++++++++++++++++++++ >>>>>>>>> include/drm/drm_connector.h | 50
+++++++++++++++++++++++++
>>>>>>>>> 3 files changed, 132 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..4309873 >>>>>>>>> 100644 >>>>>>>>> --- a/drivers/gpu/drm/drm_connector.c >>>>>>>>> +++ b/drivers/gpu/drm/drm_connector.c >>>>>>>>> @@ -826,6 +826,33 @@ 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_SMPTE_170M,
"SMPTE_170M" },
>>>>>>>>> + { DRM_MODE_COLORIMETRY_BT709, "BT709" }, >>>>>>>>> + /* Standard Definition Colorimetry based on IEC >>>>>>>>> +61966-2-4
*/
>>>>>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, >>>>>>>>> + /* High Definition Colorimetry based on IEC 61966-2-4 */ >>>>>>>>> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, >>>>>>>>> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */ >>>>>>>>> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" }, >>>>>>>>> + /* Colorimetry based on IEC 61966-2-5 [33] */ >>>>>>>>> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" }, >>>>>>>>> + /* Colorimetry based on IEC 61966-2-5 */ >>>>>>>>> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, >>>>>>>>> + /* 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_RGB, "BT2020_RGB"
},
>>>>>>>>> + /* Colorimetry based on ITU-R BT.2020 */ >>>>>>>>> + { DRM_MODE_COLORIMETRY_BT2020_CYCC,
"BT2020_CYCC" },
>>>>>>>>> + /* Added as part of Additional Colorimetry Extension >>>>>>>>> +in
861.G */
>>>>>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI- >>>> P3_RGB_D65" }, >>>>>>>>> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI- >>>>>>>> P3_RGB_Theater" }, >>>>>>>>> +}; >>>>>>>>> + >>>>>>>>> /** >>>>>>>>> * DOC: standard connector properties >>>>>>>>> * >>>>>>>>> @@ -1548,6 +1575,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..58db66e >>>>>>>>> 100644 >>>>>>>>> --- a/include/drm/drm_connector.h >>>>>>>>> +++ b/include/drm/drm_connector.h >>>>>>>>> @@ -253,6 +253,42 @@ 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_NO_DATA
0
>>>>>>>>> +#define DRM_MODE_COLORIMETRY_SMPTE_170M >>>>>> 1 >>>>>>>>> +#define DRM_MODE_COLORIMETRY_BT709 2 >>>>>>>> Still missing the YCbCr information in these two. >>>>>>> As per CTA 861.G spec, we have these as only SMPTE_170M >>>>>>> and ITU-R BT709, with no specific mention of RGB or YCbCr. >>>>>>> Hence, kept it as per spec. We seem to have a common >>>>>>> field for both as
per CTA spec.
>>>>>>> Correct me if my understanding is wrong. >>>>>> Check >>>>>> "Table 14 Picture Colorimetry Indicated by the RGB or YC B >>>>>> C R (Y), Colorimetry >>>>>> (C) and Extended Colorimetry (EC) Field Settings" >>>>> These Y2 Y1 Y0 values should be programmed separately and >>>>> not through the colorspace as they are data formats isn't >>>>> it. I feel this should get controlled separately >>>>> independent of colorimetry, or should we add all the YCbCr >>>>> and RGB versions and program them as part of this property >>>>> itself >>>> ? >>>> >>>> I don't think we can separate them. The values of the >>>> colorimetry bits doesn't mean anything without the Y bits. >>>> It would make the uapi kinda crazy if we allow the user to >>>> specify >>>> BT.2020 RGB but then we actually signal BT.2020 YCbCr in the >>>> infoframe, or vice versa. Or we just signal a totally >>>> invalid value for all the
other cases.
>>> I agree we need data format also to be send along with >>> colorspace, but they are 2 different things. To handle YCbCr >>> and variants (YUV 444, 420 or 422) and RGB I feel we should >>> expose a different API instead of using this one. We can >>> create an output csc property
which does that job for us.
>>> >>> So from a user perspective if we wants to set a colorspace we >>> should use the one in this series and set the data format >>> separately using the other interface. Both will be received >>> in the state
variables and later Infoframe packet will be created accordingly.
>>> Clubbing both in one may lead to lot of possible combinations >>> exposed as enum which may not look too clean. >>> >>> What do you say about handling that in the output csc property. >>> I will go with what you recommend . >> Programming Y2Y1Y0 is already taken care of, when we added >> support for
YCBCR outputs (4:2:0 implementation).
>> In intel_hdmi.c:intel_hdmi_set_avi_infoframe(): >> >> if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) >> frame.avi.colorspace = HDMI_COLORSPACE_YUV420; else if >> (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) >> frame.avi.colorspace = HDMI_COLORSPACE_YUV444; else >> frame.avi.colorspace = HDMI_COLORSPACE_RGB; >> >> IMO This looks like a better way to handle this, ie while >> adding support for a
new format, add support for corresponding AVI IF fileds. This will also make scope of the property under discussion less complicated.
> That's an exceptional case. We're programming the CSC in that > case to do the RGB->YCbCr conversion without telling userspace. > So we must also configure the Y bits automagically. > > What we want is a check like so: > > if (prop.colorspace != default && output_format != RGB) > return -INVAL; > > because we can't set up the CSC to make a mess of the user's > carefully crafted pixels. The pixels might not even contain RGB > data in that case. > > We'll need to extend that a little bit once we add the explicit > control of the output CSC via another prop. But the same > principle should hold. In fact, I remember the reason why we created infrastructure like this, so that, going forward, we could just add a output_format property, for which, we already have the backed and the state variables ready. The consume of this backend can be this drm_property (like output_format), or internal modeset like YCBCR4:2:0 only modes in EDID. It will also be inline with your suggestion of CSC
property.
So we can have two properties colorspace (BT2020/SRGB/REC709) and color_model/color_format(RGB/YCBCR444/420), and a combination of both should program the output AVI info-frames. Does it
appeal you ?
I'm not sure it's feasible to split it like that. The combinations supported by the infoframe are rather specific so trying to split it up leads to either super limited uapi, or one that exposes a lot of illegal combinations. Also DP has slightly different set of things it supports which adds more complications.
So I think the best option is still to include the Y=yes/no information in the prop value alognside the C/EC/ACE bits.
Yes, you are right, this could be a simpler way of doing things, but with a limited set of combination.
Consider this example:
- If a HDMI monitor supports BT2020, but doesn't support YCBCR
formatting, how to handle this option ? This means we have to selectively show BT2020_RGB enum value only not BT2020_YCBCR_444/420,
- This also means we have to probe the EDID first, and then create
this property, which means we will be dependent on the hot-plug / detect to create this property, instead of doing this in hdmi_init.
IMO we just ignore this problem and expose all the legal options the spec has.
If userspace wants to know what's actually supported it will have to parse the
EDID.
We could think about parsing that in the kernel too and exposing an immutable prop to expose that infromation. But I'm not sure this is such a good idea since we'd basically drown in properties if we try to expose all the information from the EDID. A better long term plan would be a
common EDID parsing library for everyone.
Even more complex scenario would be when the output support depends on monitor + platform both. This means we have to provide this combination upfront while creating this property.
On the other hand, the invalid combination of two property, it would be easy to detect at runtime at atomic_check() and fail the commit.
This is just a thought, honestly I am also not sure what would be the most appropriate solution for this, but seems its simpler to create property with two properties, might be difficult to manage at runtime.
With one property, its very difficult to create, but once created, it would work sure shot.
I don't think it's that difficult. Just expose all the things in the CTA-861 big table. Which means including the Y bit too.
Hi Ville, Ok So will try to do this way then:
Have a separate enum option like DRM_MODE_COLORIMETRY_BT709_YUV444 DRM_MODE_COLORIMETRY_BT709_YUV420 DRM_MODE_COLORIMETRY_BT709_YUV422
Hmm. I'm not quite convinced that we want the subsampling information included here. That will make it difficult to do the output csc property in a way that leaves the driver free to select the subsampling automagically, which we proably still want because of those annoying HDMI 2.0 monitors.
Ok, so then I will have all the enum values with explicit information whether its RGB or planar formats. Currently I feel only BT709 and 170M are the ones with ambiguity. Hope we are aligned on this ..
Regards, Uma Shankar
--
Ville Syrjälä Intel
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.
v8: Addressed Ville's review comments and updated the colorspace macro definitions.
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 | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 4309873..86b368bf 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -853,6 +853,24 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info, { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" }, };
+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 IEC 61966-2-4 */ + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" }, + /* High Definition Colorimetry based on IEC 61966-2-4 */ + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, + /* Colorimetry based on IEC 61966-2-5 */ + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, + { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" }, + /* DP MSA Colorimetry */ + { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" }, + { DRM_MODE_DP_COLORIMETRY_YCBCR_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" }, +}; + /** * DOC: standard connector properties * @@ -1614,6 +1632,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;
This adds colorspace information to HDMI AVI infoframe. A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
Signed-off-by: Uma Shankar uma.shankar@intel.com --- drivers/gpu/drm/drm_connector.c | 2 +- drivers/gpu/drm/drm_edid.c | 28 ++++++++++++++++++++++++++++ include/drm/drm_edid.h | 6 ++++++ 3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 86b368bf..086085d 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -862,7 +862,7 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info, { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, /* Colorimetry based on IEC 61966-2-5 */ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" }, - { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" }, + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" }, /* DP MSA Colorimetry */ { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" }, { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" }, diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 990b190..1fc0978 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4925,6 +4925,34 @@ static bool is_hdmi2_sink(struct drm_connector *connector) EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
/** + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe + * colorspace information + * @frame: HDMI AVI infoframe + * @conn_state: connector state + */ +void +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame, + const struct drm_connector_state *conn_state) +{ + if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) { + /* Set No Data as default for HDMI */ + frame->colorimetry = DRM_MODE_COLORIMETRY_NO_DATA; + } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XVYCC_601) { + frame->colorimetry = conn_state->colorspace; + } else { + frame->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: Extend to support ACE formats defined in CTA 861.G + */ + frame->extended_colorimetry = conn_state->colorspace - + DRM_MODE_COLORIMETRY_XVYCC_601; + } +} + +/** * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe * quantization range information * @frame: HDMI AVI infoframe diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 8dc1a08..9d3b5b9 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -331,6 +331,7 @@ struct cea_sad {
struct drm_encoder; struct drm_connector; +struct drm_connector_state; struct drm_display_mode;
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads); @@ -358,6 +359,11 @@ int drm_av_sync_delay(struct drm_connector *connector, drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe *frame, struct drm_connector *connector, const struct drm_display_mode *mode); + +void +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame, + const struct drm_connector_state *conn_state); + void drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, struct drm_connector *connector,
On Tue, Feb 05, 2019 at 09:33:36PM +0530, Uma Shankar wrote:
This adds colorspace information to HDMI AVI infoframe. A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
Signed-off-by: Uma Shankar uma.shankar@intel.com
drivers/gpu/drm/drm_connector.c | 2 +- drivers/gpu/drm/drm_edid.c | 28 ++++++++++++++++++++++++++++ include/drm/drm_edid.h | 6 ++++++ 3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 86b368bf..086085d 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -862,7 +862,7 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info, { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, /* Colorimetry based on IEC 61966-2-5 */ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" }, /* DP MSA Colorimetry */ { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" }, { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 990b190..1fc0978 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4925,6 +4925,34 @@ static bool is_hdmi2_sink(struct drm_connector *connector) EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
/**
- drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
colorspace information
- @frame: HDMI AVI infoframe
- @conn_state: connector state
- */
+void +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
const struct drm_connector_state *conn_state)+{
- if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
/* Set No Data as default for HDMI */frame->colorimetry = DRM_MODE_COLORIMETRY_NO_DATA;- } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XVYCC_601) {
frame->colorimetry = conn_state->colorspace;- } else {
frame->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: Extend to support ACE formats defined in CTA 861.G*/frame->extended_colorimetry = conn_state->colorspace -DRM_MODE_COLORIMETRY_XVYCC_601;
IMO if you don't want to make the numbers based on the spec, then this sould become a proper lookup table.
- }
+}
+/**
- drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
quantization range information- @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 8dc1a08..9d3b5b9 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -331,6 +331,7 @@ struct cea_sad {
struct drm_encoder; struct drm_connector; +struct drm_connector_state; struct drm_display_mode;
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads); @@ -358,6 +359,11 @@ int drm_av_sync_delay(struct drm_connector *connector, drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe *frame, struct drm_connector *connector, const struct drm_display_mode *mode);
+void +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
const struct drm_connector_state *conn_state);void drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, struct drm_connector *connector, -- 1.9.1
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 5, 2019 10:03 PM To: Shankar, Uma uma.shankar@intel.com Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [Intel-gfx] [v11 3/4] drm: Add colorspace info to AVI Infoframe
On Tue, Feb 05, 2019 at 09:33:36PM +0530, Uma Shankar wrote:
This adds colorspace information to HDMI AVI infoframe. A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
Signed-off-by: Uma Shankar uma.shankar@intel.com
drivers/gpu/drm/drm_connector.c | 2 +- drivers/gpu/drm/drm_edid.c | 28 ++++++++++++++++++++++++++++ include/drm/drm_edid.h | 6 ++++++ 3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 86b368bf..086085d 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -862,7 +862,7 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" }, /* Colorimetry based on IEC 61966-2-5 */ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" }, /* DP MSA Colorimetry */ { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" }, { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
diff
--git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 990b190..1fc0978 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4925,6 +4925,34 @@ static bool is_hdmi2_sink(struct drm_connector *connector) EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
/**
- drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
colorspace information
- @frame: HDMI AVI infoframe
- @conn_state: connector state
- */
+void +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
const struct drm_connector_state*conn_state) {
- if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
/* Set No Data as default for HDMI */frame->colorimetry = DRM_MODE_COLORIMETRY_NO_DATA;- } else if (conn_state->colorspace <
DRM_MODE_COLORIMETRY_XVYCC_601) {
frame->colorimetry = conn_state->colorspace;- } else {
frame->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: Extend to support ACE formats defined in CTA 861.G*/frame->extended_colorimetry = conn_state->colorspace -DRM_MODE_COLORIMETRY_XVYCC_601;
IMO if you don't want to make the numbers based on the spec, then this sould become a proper lookup table.
Ok seems good, will define the values separately and use them here.
- }
+}
+/**
- drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
quantization range information- @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 8dc1a08..9d3b5b9 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -331,6 +331,7 @@ struct cea_sad {
struct drm_encoder; struct drm_connector; +struct drm_connector_state; struct drm_display_mode;
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads); @@ -358,6 +359,11 @@ int drm_av_sync_delay(struct drm_connector *connector, drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
struct drm_connector *connector, const struct drm_display_mode*mode);
+void +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
const struct drm_connector_state*conn_state);
void drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, struct drm_connector *connector, -- 1.9.1
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- Ville Syrjälä Intel
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.
v8: Moved colorspace AVI Infoframe programming to drm core and removed from driver as per Ville's suggestion.
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 | 13 +++++++++++++ 4 files changed, 23 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..0b5e483 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -498,6 +498,8 @@ static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder, else frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ drm_hdmi_avi_infoframe_colorspace(&frame.avi, conn_state); + drm_hdmi_avi_infoframe_quant_range(&frame.avi, conn_state->connector, adjusted_mode, @@ -2143,10 +2145,21 @@ 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 + * ToDo: This needs to be extended for LSPCON implementation + * as well. Will be implemented separately. + */ + 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;
dri-devel@lists.freedesktop.org
-
Shankar, Uma -
Sharma, Shashank -
Uma Shankar
-
Ville Syrjälä