KMS enums and bitfields UAPI

[Daniel Vetter]

On Tue, Apr 14, 2020 at 3:25 PM Simon Ser <contact at emersion.fr> wrote:
>
> 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.

Hm that sounds like the half-way that wont work. Because then some
compositors will only use the hard-coded versions, and if they don't
have them, nag us to add them. And then be really disappointed if we
don't (or we screw up and add them where we shouldn't). That's the
status quo "let's have it both ways" that I think is the worst of all
options we have. So I guess from that pov the "userspace needs to
decode from symbolic values, always" as the only consistent one.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch