On Wed, Sep 26, 2018 at 11:08:37AM +0200, Maarten Lankhorst wrote:
Op 01-08-18 om 16:01 schreef Shankar, Uma:
-----Original Message----- From: Adam Jackson [mailto:ajax@redhat.com] Sent: Wednesday, August 1, 2018 1:24 AM To: Shankar, Uma uma.shankar@intel.com; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org Cc: Syrjala, Ville ville.syrjala@intel.com; Lankhorst, Maarten maarten.lankhorst@intel.com Subject: Re: [RFC 1/3] drm: Add colorspace property
On Tue, 2018-07-24 at 21:15 +0530, Uma Shankar wrote:
--- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -209,6 +209,17 @@ #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1 #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
+enum extended_colorimetry {
- EXTENDED_COLORIMETRY_XV_YCC_601 = 0,
- EXTENDED_COLORIMETRY_XV_YCC_709,
- EXTENDED_COLORIMETRY_S_YCC_601,
- EXTENDED_COLORIMETRY_ADOBE_YCC_601,
- EXTENDED_COLORIMETRY_ADOBE_RGB,
- EXTENDED_COLORIMETRY_BT2020_RGB,
- EXTENDED_COLORIMETRY_BT2020_YCC,
- EXTENDED_COLORIMETRY_BT2020_CYCC,
+};
This doesn't give any way to distinguish "not set" from BT.601, which I'm not sure I like.
This enum gives a list of all possible colorspace which can be set on the sink device. The compositors/userspace can choose one of them, based on the capabilities of sink as well as based on rendering/blending policies which are designed to take advantage of hardware resources available.
If you suggest to add something like NO_COLORSPACE_SET = -1, I can add that to this enum list.
I would add a default, but not sure I would introduce a new enum. hdmi_extended_colorimetry is already available.
Yeah, there should be a default entry for "driver automagically picks something suitable".
I think the enum prop should also be some kind of superset of all CEA-861 normal+extended colorimetry options and DP MSA+VSC SDP colorimetry options. The current list seems a bit incomplete to me.