On Fri, Jun 11, 2021 at 08:14:59AM +0000, Simon Ser wrote:
> On Thursday, June 10th, 2021 at 23:00, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
>
> > If there's a strong consensus that we really need this then I'm not
> > going to nack this, but this really needs a pile of acks from
> > compositor folks that they're willing to live with the resulting
> > fallout this will likely bring. Your cc list seems to have an absence
> > of compositor folks, but instead every driver maintainer. That's
> > backwards. We make uapi for userspace, not for kernel driver
> > maintainers!
>
> In wlroots we have a policy of only allowing standard KMS properties to
> be used. Any vendor-specific property is going to be less well-defined,
> less widely useful, potentially have more design issues, potentially
> overlap in functionality with other vendor-specific properties, likely
> have some hardware-specific assumptions, etc.
>
> What matters here is discussing with other driver & user-space folks to
> make sure the new property's design is sound. Designing uAPI is hard.
>
> If kernel folks are struggling with a user-space implementation, they
> should discuss with user-space folks to see which project would be
> interested. There's a chance a compositor will be interested in the new
> property and will just do the user-space part for you, if not we can
> suggest candidate projects.
>
> tl;dr strong agree with Daniel here.
I think the assumption you and Daniel are making is that the first implementation of
a new KMS property can be made standard from day one and that it will work for any
late comer driver as is, without having to make changes to its behaviour in a
significant way. In my experience that is not the case.
I think we have moved from the times when we were trying to implement in the Linux
world features that were available in the hardware but needed a kernel and userspace
API. The set of properties that exist in KMS cover a lot of needed functionality and
I don't expect to see new properties for stuff that is already supported by hardware.
What I'm expected to see in the future is new functionality that gets implemented by
one hardware vendor and the kernel developers trying to enable that for userspace. It
could be that the new property is generic, but there is no way of testing that on
more than one implementation yet, so I'd say we are generous calling it "standard
property". When the second or third hardware vendor comes along and starts supporting
that property with their own set of extra requirements, then we can call it
"standard". Then comes the effort cost: would it be easier to start with a vendor
property that only the vendor needs to support (and can submit patches into the
compositors to do so) and when the standard property gets added moves to that, or
should we start with a generic property that gets implemented by the compositors
(maybe, but then only one vendor supports it) and then later when we actually
standardise the property we will have to carry backwards compatibility code in the
kernel to handle the old behaviour for old userspace? My proposal to Maxime was for
the former option to be reflected in the documentation, but I would like to hear your
thoughts.
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
