KMS enums and bitfields UAPI

[Simon Ser]

On Friday, April 3, 2020 4:23 PM, Adam Jackson <ajax at redhat.com> wrote:

> On Fri, 2020-04-03 at 15:24 +0300, Pekka Paalanen wrote:
>
> > On Fri, 03 Apr 2020 10:15:21 +0000 Simon Ser contact at emersion.fr wrote:
> >
> > > Additionally, I've heard Pekka saying that it would be nice to have constants
> > > for property names in the UAPI headers. Indeed, this would prevent
> > > hard-to-debug typo issues. I have a very good example of such a typo issue that
> > > took literally hours to debug, with X11 atoms which also use free-form strings
> > > like KMS properties [3].
> > > If we have constants for property names in UAPI headers, it wouldn't be a big
> > > hurdle to also have constants for enum values alongside.
> >
> > To clarify, the property names would be of the form
> > #define DRM_KMS_PROPERTY_KERBLAH "KerBlah"
> > while enum values would be integers, i.e. the raw values.
> > Daniel Stone did have a good counter-argument to defining property
> > names: userspace would be full of
> > #ifndef DRM_KMS_PROPERTY_KERBLAH
> > #define DRM_KMS_PROPERTY_KERBLAH "KerBleh"
> > #endif
> > anyway as long as they cannot rely on the headers to be recent enough.
> > (The typo is intentional.)
>
> Why not put this in some external registry and regularly sync it into
> drm-next? This seems like an xorgproto kind of problem to me.

How would that fix the issue of KMS clients which don't want to depend
on too recent dependencies?