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. Volunteered to write the kernel patch? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
