KMS enums and bitfields UAPI

[Simon Ser]

On Tuesday, April 14, 2020 2:39 PM, Daniel Vetter <daniel at ffwll.ch> wrote:

> On Tue, Apr 14, 2020 at 12:34:17PM +0000, Simon Ser wrote:
>
> > On Tuesday, April 14, 2020 2:24 PM, Daniel Vetter daniel at ffwll.ch wrote:
> >
> > > On Mon, Apr 13, 2020 at 10:38:37PM +0000, Simon Ser wrote:
> > >
> > > > Daniel Vetter, Ville, any thoughts about this?
> > >
> > > Magic 8ball says "unclear", and I feel like I keep flip-flopping around on
> > > this.
> > > I think best-case outcome here is that we're a) consistent across
> > > compositors and b) document that consensus in the kernel's uapi section
> > > (for lack of better places).
> >
> > Agreed.
> >
> > > I'm not hung up on what exactly that consensus should be, as long as it's
> > > a consistent across projects. If you folks can't figure this out I'll do a
> > > live youtube sessions and throw a dice :-P
> >
> > It seems like everyone's fine with whatever decision we make as long as
> > we make one. :P
> > I guess I'll summarize again my main point here: requiring user-space
> > to use the KMS API to get enum values just makes it more difficult for
> > user-space to use KMS. I can't think of any reason why the kernel would
> > want to use different enum values for a standard property.
> > Does anybody remember if there was such a use-case when this UAPI was
> > introduced?
>
> I just rang across one, and boy does it suck.
>
> So we're trying to standardize across drivers as much as possible. Within
> the kernel we do that by decoding standardized properties directly into
> state structures (including any backwards compat hacks), and outside of
> the kernel by requiring igts so compliance across drivers can be tested.
>
> But we still have a pile of legacy properties, and there's pure wild west
> out there. Some have mispelled version of the same stuff, some have same
> naming but different values. If userspace hardcodes values then we're more
> screwed than if we have some indirection here to remap to standardized
> properties. And legacy userspace did do that full remapping dance, because
> that's how the first X property decoder for connectors was coded.
>
> So given that I think everyone should do the symbolic decoding, so that we
> can more seamlessly upgrade when we standardize props.
>
> Like I said, I'm flip-flopping on this all the time, but since I just ran
> over an example of trying to standardize another one of the old horrors,
> maybe better to make that slightly easier going forward. Userspace should
> be able to just stuff this all into a library and be done.

What I'm suggesting isn't to make all enum values UAPI. I'm suggesting
to add standard enum values as #defines in the UAPI headers to make
these values UAPI. Non-standard properties wouldn't be in the UAPI
headers, so user-space would need to query values from KMS just like
they do now.