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 alexandre.belloni@bootlin.com Cc: Alexandre Torgue alexandre.torgue@foss.st.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Alison Wang alison.wang@nxp.com Cc: Alyssa Rosenzweig alyssa.rosenzweig@collabora.com Cc: Andrew Jeffery andrew@aj.id.au Cc: Andrzej Hajda a.hajda@samsung.com Cc: Anitha Chrisanthus anitha.chrisanthus@intel.com Cc: Benjamin Gaignard benjamin.gaignard@linaro.org Cc: Ben Skeggs bskeggs@redhat.com Cc: Boris Brezillon bbrezillon@kernel.org Cc: Brian Starkey brian.starkey@arm.com Cc: Chen Feng puck.chen@hisilicon.com Cc: Chen-Yu Tsai wens@csie.org Cc: Christian Gmeiner christian.gmeiner@gmail.com Cc: "Christian König" christian.koenig@amd.com Cc: Chun-Kuang Hu chunkuang.hu@kernel.org Cc: Edmund Dea edmund.j.dea@intel.com Cc: Eric Anholt eric@anholt.net Cc: Fabio Estevam festevam@gmail.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Haneen Mohammed hamohammed.sa@gmail.com Cc: Hans de Goede hdegoede@redhat.com Cc: "Heiko Stübner" heiko@sntech.de Cc: Huang Rui ray.huang@amd.com Cc: Hyun Kwon hyun.kwon@xilinx.com Cc: Inki Dae inki.dae@samsung.com Cc: Jani Nikula jani.nikula@linux.intel.com Cc: Jernej Skrabec jernej.skrabec@siol.net Cc: Jerome Brunet jbrunet@baylibre.com Cc: John Stultz john.stultz@linaro.org Cc: Jonas Karlman jonas@kwiboo.se Cc: Jonathan Hunter jonathanh@nvidia.com Cc: Joonas Lahtinen joonas.lahtinen@linux.intel.com Cc: Joonyoung Shim jy0922.shim@samsung.com Cc: Jyri Sarha jyri.sarha@iki.fi Cc: Kevin Hilman khilman@baylibre.com Cc: Kieran Bingham kieran.bingham+renesas@ideasonboard.com Cc: Krzysztof Kozlowski krzysztof.kozlowski@canonical.com Cc: Kyungmin Park kyungmin.park@samsung.com Cc: Laurent Pinchart Laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Liviu Dudau liviu.dudau@arm.com Cc: Lucas Stach l.stach@pengutronix.de Cc: Ludovic Desroches ludovic.desroches@microchip.com Cc: Marek Vasut marex@denx.de Cc: Martin Blumenstingl martin.blumenstingl@googlemail.com Cc: Matthias Brugger matthias.bgg@gmail.com Cc: Maxime Coquelin mcoquelin.stm32@gmail.com Cc: Maxime Ripard mripard@kernel.org Cc: Melissa Wen melissa.srw@gmail.com Cc: Neil Armstrong narmstrong@baylibre.com Cc: Nicolas Ferre nicolas.ferre@microchip.com Cc: "Noralf Trønnes" noralf@tronnes.org Cc: NXP Linux Team linux-imx@nxp.com Cc: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com Cc: Patrik Jakobsson patrik.r.jakobsson@gmail.com Cc: Paul Cercueil paul@crapouillou.net Cc: Pekka Paalanen pekka.paalanen@collabora.com Cc: Pengutronix Kernel Team kernel@pengutronix.de Cc: Philippe Cornu philippe.cornu@foss.st.com Cc: Philipp Zabel p.zabel@pengutronix.de Cc: Qiang Yu yuq825@gmail.com Cc: Rob Clark robdclark@gmail.com Cc: Robert Foss robert.foss@linaro.org Cc: Rob Herring robh@kernel.org Cc: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com Cc: Rodrigo Vivi rodrigo.vivi@intel.com Cc: Roland Scheidegger sroland@vmware.com Cc: Russell King linux@armlinux.org.uk Cc: Sam Ravnborg sam@ravnborg.org Cc: Sandy Huang hjc@rock-chips.com Cc: Sascha Hauer s.hauer@pengutronix.de Cc: Sean Paul sean@poorly.run Cc: Seung-Woo Kim sw0312.kim@samsung.com Cc: Shawn Guo shawnguo@kernel.org Cc: Simon Ser contact@emersion.fr Cc: Stefan Agner stefan@agner.ch Cc: Steven Price steven.price@arm.com Cc: Sumit Semwal sumit.semwal@linaro.org Cc: Thierry Reding thierry.reding@gmail.com Cc: Tian Tao tiantao6@hisilicon.com Cc: Tomeu Vizoso tomeu.vizoso@collabora.com Cc: Tomi Valkeinen tomba@kernel.org Cc: VMware Graphics linux-graphics-maintainer@vmware.com Cc: Xinliang Liu xinliang.liu@linaro.org Cc: Xinwei Kong kong.kongxinwei@hisilicon.com Cc: Yannick Fertre yannick.fertre@foss.st.com Cc: Zack Rusin zackr@vmware.com Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Maxime Ripard maxime@cerno.tech
---
Changes from v4: - Changes suggested by Pekka
Changes from v3: - Roll back to the v2 - Add Simon and Pekka in Cc
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
Changes from v1: - Typos and wording reported by Daniel and Alex --- Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..47994890fd1e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,36 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections.
+Requirements +------------ + +KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few +requirements, in addition to the one mentioned above: + +* It must be standardized, documenting: + + * The full, exact, name string; + * If the property is an enum, all the valid variants name; + * What values are accepted, and what these values mean; + * What the property does and how it can be used; + * How the property might interact with other, existing properties. + +* It must provide a generic helper in the core code to register that + property on the object it attaches to. + +* Its content must be decoded by the core and provided in the object's + associated state structure. That includes anything drivers might want + to precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for + planes. + +* Its initial state must match the behavior prior to the property + introduction. This might be a fixed value matching what the hardware + does, or it may be inherited from the state the firmware left the + system in during boot. + +* An IGT test must be submitted where reasonable. + Property Types and Blob Property Support ----------------------------------------
On Tue, Jul 06, 2021 at 06:12:44PM +0200, Maxime Ripard 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 alexandre.belloni@bootlin.com Cc: Alexandre Torgue alexandre.torgue@foss.st.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Alison Wang alison.wang@nxp.com Cc: Alyssa Rosenzweig alyssa.rosenzweig@collabora.com Cc: Andrew Jeffery andrew@aj.id.au Cc: Andrzej Hajda a.hajda@samsung.com Cc: Anitha Chrisanthus anitha.chrisanthus@intel.com Cc: Benjamin Gaignard benjamin.gaignard@linaro.org Cc: Ben Skeggs bskeggs@redhat.com Cc: Boris Brezillon bbrezillon@kernel.org Cc: Brian Starkey brian.starkey@arm.com Cc: Chen Feng puck.chen@hisilicon.com Cc: Chen-Yu Tsai wens@csie.org Cc: Christian Gmeiner christian.gmeiner@gmail.com Cc: "Christian König" christian.koenig@amd.com Cc: Chun-Kuang Hu chunkuang.hu@kernel.org Cc: Edmund Dea edmund.j.dea@intel.com Cc: Eric Anholt eric@anholt.net Cc: Fabio Estevam festevam@gmail.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Haneen Mohammed hamohammed.sa@gmail.com Cc: Hans de Goede hdegoede@redhat.com Cc: "Heiko Stübner" heiko@sntech.de Cc: Huang Rui ray.huang@amd.com Cc: Hyun Kwon hyun.kwon@xilinx.com Cc: Inki Dae inki.dae@samsung.com Cc: Jani Nikula jani.nikula@linux.intel.com Cc: Jernej Skrabec jernej.skrabec@siol.net Cc: Jerome Brunet jbrunet@baylibre.com Cc: John Stultz john.stultz@linaro.org Cc: Jonas Karlman jonas@kwiboo.se Cc: Jonathan Hunter jonathanh@nvidia.com Cc: Joonas Lahtinen joonas.lahtinen@linux.intel.com Cc: Joonyoung Shim jy0922.shim@samsung.com Cc: Jyri Sarha jyri.sarha@iki.fi Cc: Kevin Hilman khilman@baylibre.com Cc: Kieran Bingham kieran.bingham+renesas@ideasonboard.com Cc: Krzysztof Kozlowski krzysztof.kozlowski@canonical.com Cc: Kyungmin Park kyungmin.park@samsung.com Cc: Laurent Pinchart Laurent.pinchart@ideasonboard.com Cc: Linus Walleij linus.walleij@linaro.org Cc: Liviu Dudau liviu.dudau@arm.com Cc: Lucas Stach l.stach@pengutronix.de Cc: Ludovic Desroches ludovic.desroches@microchip.com Cc: Marek Vasut marex@denx.de Cc: Martin Blumenstingl martin.blumenstingl@googlemail.com Cc: Matthias Brugger matthias.bgg@gmail.com Cc: Maxime Coquelin mcoquelin.stm32@gmail.com Cc: Maxime Ripard mripard@kernel.org Cc: Melissa Wen melissa.srw@gmail.com Cc: Neil Armstrong narmstrong@baylibre.com Cc: Nicolas Ferre nicolas.ferre@microchip.com Cc: "Noralf Trønnes" noralf@tronnes.org Cc: NXP Linux Team linux-imx@nxp.com Cc: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com Cc: Patrik Jakobsson patrik.r.jakobsson@gmail.com Cc: Paul Cercueil paul@crapouillou.net Cc: Pekka Paalanen pekka.paalanen@collabora.com Cc: Pengutronix Kernel Team kernel@pengutronix.de Cc: Philippe Cornu philippe.cornu@foss.st.com Cc: Philipp Zabel p.zabel@pengutronix.de Cc: Qiang Yu yuq825@gmail.com Cc: Rob Clark robdclark@gmail.com Cc: Robert Foss robert.foss@linaro.org Cc: Rob Herring robh@kernel.org Cc: Rodrigo Siqueira rodrigosiqueiramelo@gmail.com Cc: Rodrigo Vivi rodrigo.vivi@intel.com Cc: Roland Scheidegger sroland@vmware.com Cc: Russell King linux@armlinux.org.uk Cc: Sam Ravnborg sam@ravnborg.org Cc: Sandy Huang hjc@rock-chips.com Cc: Sascha Hauer s.hauer@pengutronix.de Cc: Sean Paul sean@poorly.run Cc: Seung-Woo Kim sw0312.kim@samsung.com Cc: Shawn Guo shawnguo@kernel.org Cc: Simon Ser contact@emersion.fr Cc: Stefan Agner stefan@agner.ch Cc: Steven Price steven.price@arm.com Cc: Sumit Semwal sumit.semwal@linaro.org Cc: Thierry Reding thierry.reding@gmail.com Cc: Tian Tao tiantao6@hisilicon.com Cc: Tomeu Vizoso tomeu.vizoso@collabora.com Cc: Tomi Valkeinen tomba@kernel.org Cc: VMware Graphics linux-graphics-maintainer@vmware.com Cc: Xinliang Liu xinliang.liu@linaro.org Cc: Xinwei Kong kong.kongxinwei@hisilicon.com Cc: Yannick Fertre yannick.fertre@foss.st.com Cc: Zack Rusin zackr@vmware.com Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Maxime Ripard maxime@cerno.tech
Changes from v4:
- Changes suggested by Pekka
Changes from v3:
- Roll back to the v2
- Add Simon and Pekka in Cc
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
Changes from v1:
- Typos and wording reported by Daniel and Alex
Bunch of typos, but still lgtm.
Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..47994890fd1e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,36 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections.
+Requirements +------------
+KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few
s/need/needs/
+requirements, in addition to the one mentioned above:
+* It must be standardized, documenting:
- The full, exact, name string;
- If the property is an enum, all the valid variants name;
I think that should be "variant's names" but not 100% sure.
- What values are accepted, and what these values mean;
- What the property does and how it can be used;
- How the property might interact with other, existing properties.
+* It must provide a generic helper in the core code to register that
- property on the object it attaches to.
+* Its content must be decoded by the core and provided in the object's
- associated state structure. That includes anything drivers might want
- to precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for
Stuff auto-hyperlinks even in .rst files nowadays, so just sturct drm_clip_rect should be enough here. See
https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#cross-referen...
- planes.
+* Its initial state must match the behavior prior to the property
- introduction. This might be a fixed value matching what the hardware
- does, or it may be inherited from the state the firmware left the
- system in during boot.
I like this addition.
Cheers, Daniel
+* An IGT test must be submitted where reasonable.
Property Types and Blob Property Support
-- 2.31.1
On Tue, 6 Jul 2021 18:12:44 +0200 Maxime Ripard maxime@cerno.tech 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.
...
Changes from v4:
- Changes suggested by Pekka
Changes from v3:
- Roll back to the v2
- Add Simon and Pekka in Cc
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
Changes from v1:
- Typos and wording reported by Daniel and Alex
Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..47994890fd1e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,36 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections.
+Requirements +------------
+KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few +requirements, in addition to the one mentioned above:
+* It must be standardized, documenting:
- The full, exact, name string;
- If the property is an enum, all the valid variants name;
Hi,
"variant" feels a little off to me, I would have used "value name strings".
- What values are accepted, and what these values mean;
- What the property does and how it can be used;
- How the property might interact with other, existing properties.
+* It must provide a generic helper in the core code to register that
- property on the object it attaches to.
+* Its content must be decoded by the core and provided in the object's
- associated state structure. That includes anything drivers might want
- to precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for
- planes.
+* Its initial state must match the behavior prior to the property
- introduction. This might be a fixed value matching what the hardware
- does, or it may be inherited from the state the firmware left the
- system in during boot.
I'd like to point out that this rule should apply also to properties that already exist in general, but are newly exposed in a driver for hardware that didn't expose the property before.
+* An IGT test must be submitted where reasonable.
Property Types and Blob Property Support
Regardless of my comments above:
Reviewed-by: Pekka Paalanen pekka.paalanen@collabora.com
Thanks, pq
On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote:
On Tue, 6 Jul 2021 18:12:44 +0200 Maxime Ripard maxime@cerno.tech 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.
...
Changes from v4:
- Changes suggested by Pekka
Changes from v3:
- Roll back to the v2
- Add Simon and Pekka in Cc
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
Changes from v1:
- Typos and wording reported by Daniel and Alex
Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..47994890fd1e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,36 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections.
+Requirements +------------
+KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few +requirements, in addition to the one mentioned above:
+* It must be standardized, documenting:
- The full, exact, name string;
- If the property is an enum, all the valid variants name;
Hi,
"variant" feels a little off to me, I would have used "value name strings".
- What values are accepted, and what these values mean;
- What the property does and how it can be used;
- How the property might interact with other, existing properties.
+* It must provide a generic helper in the core code to register that
- property on the object it attaches to.
+* Its content must be decoded by the core and provided in the object's
- associated state structure. That includes anything drivers might want
- to precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for
- planes.
+* Its initial state must match the behavior prior to the property
- introduction. This might be a fixed value matching what the hardware
- does, or it may be inherited from the state the firmware left the
- system in during boot.
I'd like to point out that this rule should apply also to properties that already exist in general, but are newly exposed in a driver for hardware that didn't expose the property before.
I think we should just make this a very strong recommendation, and in general encourage people to use the tests against their driver?
Otherwise a small "I'll just enable this" thing can become a huge project. And in general I think grandfathering existing things in is the pragmatic choice.
But maybe that could be a follow-up patch? -Daniel
+* An IGT test must be submitted where reasonable.
Property Types and Blob Property Support
Regardless of my comments above:
Reviewed-by: Pekka Paalanen pekka.paalanen@collabora.com
Thanks, pq
On Fri, 9 Jul 2021 10:02:28 +0200 Daniel Vetter daniel@ffwll.ch wrote:
On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote:
On Tue, 6 Jul 2021 18:12:44 +0200 Maxime Ripard maxime@cerno.tech 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.
...
Changes from v4:
- Changes suggested by Pekka
Changes from v3:
- Roll back to the v2
- Add Simon and Pekka in Cc
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
Changes from v1:
- Typos and wording reported by Daniel and Alex
Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..47994890fd1e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,36 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections.
+Requirements +------------
+KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few +requirements, in addition to the one mentioned above:
+* It must be standardized, documenting:
- The full, exact, name string;
- If the property is an enum, all the valid variants name;
Hi,
"variant" feels a little off to me, I would have used "value name strings".
- What values are accepted, and what these values mean;
- What the property does and how it can be used;
- How the property might interact with other, existing properties.
+* It must provide a generic helper in the core code to register that
- property on the object it attaches to.
+* Its content must be decoded by the core and provided in the object's
- associated state structure. That includes anything drivers might want
- to precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for
- planes.
+* Its initial state must match the behavior prior to the property
- introduction. This might be a fixed value matching what the hardware
- does, or it may be inherited from the state the firmware left the
- system in during boot.
I'd like to point out that this rule should apply also to properties that already exist in general, but are newly exposed in a driver for hardware that didn't expose the property before.
I think we should just make this a very strong recommendation, and in general encourage people to use the tests against their driver?
Otherwise a small "I'll just enable this" thing can become a huge project. And in general I think grandfathering existing things in is the pragmatic choice.
But maybe that could be a follow-up patch?
Sure, I don't mind. Just saying now that it came to mind. Drivers do not arbitrarily change behaviour without exposing more properties either, right?
Thanks, pq
-Daniel
+* An IGT test must be submitted where reasonable.
Property Types and Blob Property Support
Regardless of my comments above:
Reviewed-by: Pekka Paalanen pekka.paalanen@collabora.com
Thanks, pq
On Fri, Jul 09, 2021 at 12:08:14PM +0300, Pekka Paalanen wrote:
On Fri, 9 Jul 2021 10:02:28 +0200 Daniel Vetter daniel@ffwll.ch wrote:
On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote:
On Tue, 6 Jul 2021 18:12:44 +0200 Maxime Ripard maxime@cerno.tech 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.
...
Changes from v4:
- Changes suggested by Pekka
Changes from v3:
- Roll back to the v2
- Add Simon and Pekka in Cc
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
Changes from v1:
- Typos and wording reported by Daniel and Alex
Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..47994890fd1e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,36 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections.
+Requirements +------------
+KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few +requirements, in addition to the one mentioned above:
+* It must be standardized, documenting:
- The full, exact, name string;
- If the property is an enum, all the valid variants name;
Hi,
"variant" feels a little off to me, I would have used "value name strings".
- What values are accepted, and what these values mean;
- What the property does and how it can be used;
- How the property might interact with other, existing properties.
+* It must provide a generic helper in the core code to register that
- property on the object it attaches to.
+* Its content must be decoded by the core and provided in the object's
- associated state structure. That includes anything drivers might want
- to precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for
- planes.
+* Its initial state must match the behavior prior to the property
- introduction. This might be a fixed value matching what the hardware
- does, or it may be inherited from the state the firmware left the
- system in during boot.
I'd like to point out that this rule should apply also to properties that already exist in general, but are newly exposed in a driver for hardware that didn't expose the property before.
I think we should just make this a very strong recommendation, and in general encourage people to use the tests against their driver?
Otherwise a small "I'll just enable this" thing can become a huge project. And in general I think grandfathering existing things in is the pragmatic choice.
But maybe that could be a follow-up patch?
Sure, I don't mind. Just saying now that it came to mind. Drivers do not arbitrarily change behaviour without exposing more properties either, right?
Yup. Both are covered under the "no regressions" rule, but better to make this explicit. Maybe we should replicate some of the key bits in the property docs for drivers?
Also anytime we spot an issue we need to improve the internal helpers to make sure things stay consistent. -Daniel
Thanks, pq
-Daniel
+* An IGT test must be submitted where reasonable.
Property Types and Blob Property Support
Regardless of my comments above:
Reviewed-by: Pekka Paalanen pekka.paalanen@collabora.com
Thanks, pq
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Maxime Ripard -
Pekka Paalanen