On Fri, Jun 11, 2021 at 07:54:07AM +0200, Maxime Ripard wrote: > On Thu, Jun 10, 2021 at 11:00:05PM +0200, Daniel Vetter wrote: > > On Thu, Jun 10, 2021 at 7:47 PM Maxime Ripard <[email protected]> wrote: > > > > > > New KMS properties come with a bunch of requirements to avoid each > > > driver from running their own, inconsistent, set of properties, > > > eventually leading to issues like property conflicts, inconsistencies > > > between drivers and semantics, etc. > > > > > > Let's document what we expect. > > > > > > Cc: Alexandre Belloni <[email protected]> > > > Cc: Alexandre Torgue <[email protected]> > > > Cc: Alex Deucher <[email protected]> > > > Cc: Alison Wang <[email protected]> > > > Cc: Alyssa Rosenzweig <[email protected]> > > > Cc: Andrew Jeffery <[email protected]> > > > Cc: Andrzej Hajda <[email protected]> > > > Cc: Anitha Chrisanthus <[email protected]> > > > Cc: Benjamin Gaignard <[email protected]> > > > Cc: Ben Skeggs <[email protected]> > > > Cc: Boris Brezillon <[email protected]> > > > Cc: Brian Starkey <[email protected]> > > > Cc: Chen Feng <[email protected]> > > > Cc: Chen-Yu Tsai <[email protected]> > > > Cc: Christian Gmeiner <[email protected]> > > > Cc: "Christian König" <[email protected]> > > > Cc: Chun-Kuang Hu <[email protected]> > > > Cc: Edmund Dea <[email protected]> > > > Cc: Eric Anholt <[email protected]> > > > Cc: Fabio Estevam <[email protected]> > > > Cc: Gerd Hoffmann <[email protected]> > > > Cc: Haneen Mohammed <[email protected]> > > > Cc: Hans de Goede <[email protected]> > > > Cc: "Heiko Stübner" <[email protected]> > > > Cc: Huang Rui <[email protected]> > > > Cc: Hyun Kwon <[email protected]> > > > Cc: Inki Dae <[email protected]> > > > Cc: Jani Nikula <[email protected]> > > > Cc: Jernej Skrabec <[email protected]> > > > Cc: Jerome Brunet <[email protected]> > > > Cc: Joel Stanley <[email protected]> > > > Cc: John Stultz <[email protected]> > > > Cc: Jonas Karlman <[email protected]> > > > Cc: Jonathan Hunter <[email protected]> > > > Cc: Joonas Lahtinen <[email protected]> > > > Cc: Joonyoung Shim <[email protected]> > > > Cc: Jyri Sarha <[email protected]> > > > Cc: Kevin Hilman <[email protected]> > > > Cc: Kieran Bingham <[email protected]> > > > Cc: Krzysztof Kozlowski <[email protected]> > > > Cc: Kyungmin Park <[email protected]> > > > Cc: Laurent Pinchart <[email protected]> > > > Cc: Linus Walleij <[email protected]> > > > Cc: Liviu Dudau <[email protected]> > > > Cc: Lucas Stach <[email protected]> > > > Cc: Ludovic Desroches <[email protected]> > > > Cc: Marek Vasut <[email protected]> > > > Cc: Martin Blumenstingl <[email protected]> > > > Cc: Matthias Brugger <[email protected]> > > > Cc: Maxime Coquelin <[email protected]> > > > Cc: Maxime Ripard <[email protected]> > > > Cc: Melissa Wen <[email protected]> > > > Cc: Neil Armstrong <[email protected]> > > > Cc: Nicolas Ferre <[email protected]> > > > Cc: "Noralf Trønnes" <[email protected]> > > > Cc: NXP Linux Team <[email protected]> > > > Cc: Oleksandr Andrushchenko <[email protected]> > > > Cc: Patrik Jakobsson <[email protected]> > > > Cc: Paul Cercueil <[email protected]> > > > Cc: Pengutronix Kernel Team <[email protected]> > > > Cc: Philippe Cornu <[email protected]> > > > Cc: Philipp Zabel <[email protected]> > > > Cc: Qiang Yu <[email protected]> > > > Cc: Rob Clark <[email protected]> > > > Cc: Robert Foss <[email protected]> > > > Cc: Rob Herring <[email protected]> > > > Cc: Rodrigo Siqueira <[email protected]> > > > Cc: Rodrigo Vivi <[email protected]> > > > Cc: Roland Scheidegger <[email protected]> > > > Cc: Russell King <[email protected]> > > > Cc: Sam Ravnborg <[email protected]> > > > Cc: Sandy Huang <[email protected]> > > > Cc: Sascha Hauer <[email protected]> > > > Cc: Sean Paul <[email protected]> > > > Cc: Seung-Woo Kim <[email protected]> > > > Cc: Shawn Guo <[email protected]> > > > Cc: Stefan Agner <[email protected]> > > > Cc: Steven Price <[email protected]> > > > Cc: Sumit Semwal <[email protected]> > > > Cc: Thierry Reding <[email protected]> > > > Cc: Tian Tao <[email protected]> > > > Cc: Tomeu Vizoso <[email protected]> > > > Cc: Tomi Valkeinen <[email protected]> > > > Cc: VMware Graphics <[email protected]> > > > Cc: Xinliang Liu <[email protected]> > > > Cc: Xinwei Kong <[email protected]> > > > Cc: Yannick Fertre <[email protected]> > > > Cc: Zack Rusin <[email protected]> > > > Reviewed-by: Daniel Vetter <[email protected]> > > > Signed-off-by: Maxime Ripard <[email protected]> > > > > > > --- > > > > > > Changes from v2: > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > force generic properties, but prefix vendor-specific properties with > > > the vendor name > > > > I'm pretty sure my r-b was without this ... > > Yeah, sorry. I wanted to tell you on IRC that you wanted to have a > second look, but I shouldn't have kept it and caught you by surprise > indeed. > > > Why exactly do we need this? KMS is meant to be fairly generic (bugs > > throw a wrench around here sometimes, and semantics can be tricky). If > > we open up the door to yolo vendor properties in upstream, then that > > goal is pretty much written off. And we've been there with vendor > > properties, it's a giantic mess. > > > > Minimally drop my r-b, I'm definitely not in support of this idea. > > So the argument Lidiu and Laurent made was that in some cases, getting a > generic property right with only a couple of users is hard. So they > advocated for the right to keep non-generic properties. I can get the > argument, and no-one else said that was wrong, so it felt like the > consensus was there.
My argument was two-fold. On one hand, there's the issue of standardizing properties when we have a single example. I don't have a good solution for that chicken-and-egg issue, when we tell vendor they should standardize properties, and when they ask how, we tell them we don't know as it hasn't been done before. The option for allowing a staging playground for vendor properties here isn't something I like, but we'll need something similar one way or another. Perhaps at the cost of not guaranteeing userspace ABI for those properties, and converting them later to something standard (it won't be received well by vendor of course, and will make a push for mainline more difficult to sell, so it's not a great solution). On the other hand, there are esoteric vendor-specific features for which standardization really doesn't make sense. For those, I think vendor-specific properties are fine, as long as they're properly documented, with a design documentation merged at the same time as the property. A vendor prefix is really just a namespace clash handling tool here. > > 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! > > Right, but it's mostly about in-kernel rules though? And you're the one > who mentionned CC'ing the driver maintainers in the first iteration? > > > ltdr; I'd go back to v2. And then cc compositor folks on this to get > > their ack. > > So, Pekka, Simon, is there anyone else I should Cc? -- Regards, Laurent Pinchart
