Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties

[Alyssa Rosenzweig <alyssa@collabora.com>]

> 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.

Just my 2c - if the mainline kernel isn't willing to commit to a feature
for upstream userspace to use, why does that feature belong in the
kernel at all? I don't see much value in exposing hardware for the sake
of exposing it when, practically, Linux userspace /can't/ use it as-is.

Might these vendor properties be used on downstream Android userspaces?
That's not generally an upstream goal to support.