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

[Liviu Dudau]

On Fri, Jun 11, 2021 at 08:56:04AM -0400, Alyssa Rosenzweig wrote:
> > 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.

I think the assumption is that we are willing to commit to supporting a feature for
userspace, just that (I personally) lack the confidence that I will be getting the
feature right on the first attempt and using only one vendor hardware. And that
supporting potential mistakes I might've made in the first version is harder if the
feature was deemed "standard".

I'm talking from my experience with the writeback connector. We almost committed the
feature twice before more people chipped in and asked us for changes, but that was lucky.

Best regards,
Liviu

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯