>-----Original Message----- >From: Daniel Stone [mailto:daniel@xxxxxxxxxxxxx] >Sent: Tuesday, January 29, 2019 9:24 PM >To: Brian Starkey <Brian.Starkey@xxxxxxx> >Cc: Shankar, Uma <uma.shankar@xxxxxxxxx>; Syrjala, Ville ><ville.syrjala@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri- >devel@xxxxxxxxxxxxxxxxxxxxx; nd <nd@xxxxxxx>; Lankhorst, Maarten ><maarten.lankhorst@xxxxxxxxx> >Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property > >Hi, > >On Tue, 29 Jan 2019 at 15:24, Brian Starkey <Brian.Starkey@xxxxxxx> wrote: >> On Tue, Jan 29, 2019 at 01:30:43PM +0000, 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
