[PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

[Simon Ser]

On Friday, February 10th, 2023 at 10:37, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Thu, 09 Feb 2023 17:03:19 +0000
> Simon Ser contact at emersion.fr wrote:
> 
> > On Thursday, February 9th, 2023 at 17:38, Joshua Ashton joshua at froggi.es wrote:
> > 
> > > > I mean, the strings are the uAPI, not the integers, right?
> > > 
> > > Both are uAPI these days.
> > 
> > Yes. The integers are uAPI, if you change them you'll break libliftoff
> > users. There is an old thread discussing this somewhere. The tl;dr was
> > that there is no use-case for exposing the same string with a different
> > integer, so no good reason to justify the substantial complexity of
> > handling this case.
> 
> Funny, I remember exactly the opposite.

There was a bacxk-and-forth on this topic.

> This case would have been multiple different strings with the same
> integer, anyway.

That would be fine. As long as the meaning of an integer doesn't change
across planes, it's all fine.

> But no matter. If a uAPI header or documentation has exposed the
> integers, then there is no taking that back.

uAPI headers/docs don't expose the integers for this property.
Nevertheless, one cannot break user-space.

> This won't be a problem for enums that have no meaningful string names,
> like enums where the integer names a blob that describes what the value
> means, and enums where the integer is an index into an array of
> descriptions exposed as a blob.

This would be pretty tricky to handle.