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