KMS enums and bitfields UAPI

[Daniel Vetter]

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.

Volunteered to write the kernel patch?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch