KMS enums and bitfields UAPI

[Daniel Vetter]

On Tue, Apr 7, 2020 at 10:19 AM Daniel Stone <daniel at fooishbar.org> wrote:
>
> Hi,
>
> On Fri, 3 Apr 2020 at 13:24, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Fri, 03 Apr 2020 10:15:21 +0000 Simon Ser <contact at emersion.fr> wrote:
> > > At the very least, having a clear policy for both kernel public headers and
> > > user-space would help a lot. Right now it's unclear for both parties what to do
> > > regarding enum values.
> > >
> > > What do you think?
> >
> > I do not think it is unclear at all. You have to query the kernel for
> > value by string names. Maybe it's not clearly communicated though?
> >
> > But I also don't have anything against changing that policy, if kernel
> > maintainers agree.
>
> I'm in the same boat. The existing policy (runtime enum name lookups
> are the only correct thing, and the presence of anything else in
> headers is merely accidental) seems pretty clear to me. But I'd be
> totally fine with changing it too, though it might require a cap to
> say that this kernel version lets you use the stable integer
> enumerations, and anything else requires runtime lookup.
>
> I had a quick look to see how drivers used properties, and was
> pleasantly surprised to see that only the (very old) Intel driver,
> VMware and QXL drivers have custom properties. So maybe we don't have
> to really worry about vendor-extended properties too much ... though
> someone will definitely try to use it on some kind of nightmare vendor
> BSP and have to fork libliftoff for it at some point.

Not sure what you grepped, but I'm also seeing amdgpu, armada, i915
and gma500, nouveau, radeon, rcar and sti create custom properties.

But yeah we've definitely become a lot better at this, with the
cracked down rules on drm properties and what you all need to supply
before merging is ok.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch