On Thu, Sep 27, 2018 at 04:29:52AM +0000, Shankar, Uma wrote: > > > >-----Original Message----- > >From: Ville Syrjälä [mailto:ville.syrjala@xxxxxxxxxxxxxxx] > >Sent: Wednesday, September 26, 2018 3:12 PM > >To: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > >Cc: Shankar, Uma <uma.shankar@xxxxxxxxx>; Adam Jackson > ><ajax@xxxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri- > >devel@xxxxxxxxxxxxxxxxxxxxx; Syrjala, Ville <ville.syrjala@xxxxxxxxx>; Lankhorst, > >Maarten <maarten.lankhorst@xxxxxxxxx> > >Subject: Re: [Intel-gfx] [RFC 1/3] drm: Add colorspace property > > > >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@xxxxxxxxxx] > >> >> Sent: Wednesday, August 1, 2018 1:24 AM > >> >> To: Shankar, Uma <uma.shankar@xxxxxxxxx>; > >> >> intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx > >> >> Cc: Syrjala, Ville <ville.syrjala@xxxxxxxxx>; Lankhorst, Maarten > >> >> <maarten.lankhorst@xxxxxxxxx> > >> >> 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". > > > > Ok got it, will add a default option to the list. > > >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. > > > > So should I keep this enum and append DP MSA +VSC SDP options to the list ? > We can then have encoder specific enums separate from this global colorpsace > enum. My original idea was one enum and each encoder type can then pick the ones it can support by passing in the appropriate bitmask. That's assuming we can reconcile any differences between DP and HDMI in a nice way. -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
