On Tuesday, April 14, 2020 2:39 PM, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
