[Intel-gfx] [v7 1/2] drm: Add colorspace connector property

[Shankar, Uma]

>-----Original Message-----
>From: Daniel Stone [mailto:daniel at fooishbar.org]
>Sent: Tuesday, January 29, 2019 9:24 PM
>To: Brian Starkey <Brian.Starkey at arm.com>
>Cc: Shankar, Uma <uma.shankar at intel.com>; Syrjala, Ville
><ville.syrjala at intel.com>; intel-gfx at lists.freedesktop.org; dri-
>devel at lists.freedesktop.org; nd <nd at arm.com>; Lankhorst, Maarten
><maarten.lankhorst at intel.com>
>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 at arm.com> 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