Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
>-Original Message- >From: Daniel Stone [mailto:dan...@fooishbar.org] >Sent: Tuesday, January 29, 2019 9:24 PM >To: Brian Starkey >Cc: Shankar, Uma ; Syrjala, Ville >; intel-gfx@lists.freedesktop.org; dri- >de...@lists.freedesktop.org; nd ; Lankhorst, Maarten > >Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property > >Hi, > >On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote: >> On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote: >> > >> +#define DP_COLORIMETRY_SCRGB 15 >> > >> +#define DP_COLORIMETRY_DCI_P3 16 >> > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17 >> >> Sorry, I somehow missed your reply earlier in the month - but this >> wasn't what I meant. >> >> The expectation with enum properties is that the numeric values are >> determined at runtime - userspace shouldn't depend on them being known >> at compile-time. So, in include/uapi there shouldn't be these numeric >> values. >> >> The strings themselves effectively form the UABI, so I was wondering >> if they should be defined in include/uapi, but you would be the first >> to do that. >> >> Daniel Vetter and/or Daniel Stone might have opinions on this. > >That's correct. The DPMS definitions are a historical aberration, and we should >not be adding any more numeric definitions of enum properties to uABI. > >They can be fixed in the kernel, but userspace must only rely on the strings. Ok so if I understand correctly, we should drop the changes in uapi header for macro definitions and let the userspace match string which are supported in enum as part of property creation. So this info is redundant and not to be relied upon. Regards, Uma Shankar >Cheers, >Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Hi, On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote: > On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote: > > >> +#define DP_COLORIMETRY_SCRGB 15 > > >> +#define DP_COLORIMETRY_DCI_P3 16 > > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17 > > Sorry, I somehow missed your reply earlier in the month - but this > wasn't what I meant. > > The expectation with enum properties is that the numeric values are > determined at runtime - userspace shouldn't depend on them being known > at compile-time. So, in include/uapi there shouldn't be these numeric > values. > > The strings themselves effectively form the UABI, so I was wondering > if they should be defined in include/uapi, but you would be the first > to do that. > > Daniel Vetter and/or Daniel Stone might have opinions on this. That's correct. The DPMS definitions are a historical aberration, and we should not be adding any more numeric definitions of enum properties to uABI. They can be fixed in the kernel, but userspace must only rely on the strings. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Hi Uma,
On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 5:54 PM
> >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> >dri-de...@lists.freedesktop.org
> >Cc: Syrjala, Ville ; Lankhorst, Maarten
> >
> >Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
> >
> >Op 28-01-2019 om 09:44 schreef Uma Shankar:
> >> 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. Driver will expose the platform supported colorspaces,
> >> however sink supported colorspaces should be retrieved by userspace
> >> from EDID.
> >>
> >> 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.
> >>
> >> Signed-off-by: Uma Shankar
> >> Reviewed-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> >> drivers/gpu/drm/drm_connector.c | 95
> >+++
> >> include/drm/drm_connector.h | 17 +++
> >> include/uapi/drm/drm_mode.h | 32 +
> >> 4 files changed, 148 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_typ
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 5:54 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
>
>Op 28-01-2019 om 09:44 schreef Uma Shankar:
>> 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. Driver will expose the platform supported colorspaces,
>> however sink supported colorspaces should be retrieved by userspace
>> from EDID.
>>
>> 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.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
>> drivers/gpu/drm/drm_connector.c | 95
>+++
>> include/drm/drm_connector.h | 17 +++
>> include/uapi/drm/drm_mode.h | 32 +
>> 4 files changed, 148 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/
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Op 28-01-2019 om 09:44 schreef Uma Shankar:
> 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. Driver will expose the platform supported colorspaces,
> however sink supported colorspaces should be retrieved by userspace
> from EDID.
>
> 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.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_connector.c | 95
> +++
> include/drm/drm_connector.h | 17 +++
> include/uapi/drm/drm_mode.h | 32 +
> 4 files changed, 148 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..eafa643 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -826,6 +826,54 @@ 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)
>
> +/* List of HDMI Colorspaces supported */
> +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { COLORIMETRY_ITU_601, "ITU_601" },
> + { COLORIMETRY_ITU_709, "ITU_709" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { COLORIMETRY_S_YCC_601, "S_YCC_601
[Intel-gfx] [v7 1/2] drm: Add colorspace connector property
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. Driver will expose the platform supported colorspaces,
however sink supported colorspaces should be retrieved by userspace
from EDID.
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.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 95 +++
include/drm/drm_connector.h | 17 +++
include/uapi/drm/drm_mode.h | 32 +
4 files changed, 148 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..eafa643 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,54 @@ 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)
+/* List of HDMI Colorspaces supported */
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "ITU_601" },
+ { COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_OPRGB, "opRGB"
