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

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

[Maxime Ripard]

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: Joel Stanley <joel@jms.id.au>
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 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 | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..c28b464dd397 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -463,6 +463,25 @@ 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, with some documentation to describe how the
+  property can be used.
+
+- 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.
+
+- An IGT test must be submitted where reasonable.
+
 Property Types and Blob Property Support
 ----------------------------------------
 
-- 
2.31.1

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

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 8359 bytes --]

On Wed, 16 Jun 2021 16:38:42 +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.
> 
> 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: Joel Stanley <joel@jms.id.au>
> 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 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 | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..c28b464dd397 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -463,6 +463,25 @@ 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, with some documentation to describe how the
> +  property can be used.

Hi,

I might replace "some" with "full" documentation. Also not only how it
can be used but also what it does.

FYI, some common things that tend to be forgotten IME:
- Spell out exactly the name string for the property in the
  documentation so that it is unambiguous what string userspace should
  look for.
- The same for string names of enum values.
- Explicitly document what each enum value means, do not trust that the
  value name describes it well enough.
- Explain how the property interacts with other, existing properties.

Not sure if these should be written down here or anywhere though.
Interaction with other properties is kind of important.

> +
> +- 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.
> +
> +- An IGT test must be submitted where reasonable.

Would it be too much to replace "where reasonable" with "if it is at
all possible to write a test."?

> +

How about adding the following somewhere?

- The initial state of the property (set during driver initialization)
  must match how the driver+hardware behaved before introducing this
  property. It may be some fixed value or it may be inherited from e.g.
  the firmware that booted the system. How the initial state is
  determined must also be documented, that is, where does it come from.

The initial state must not be called "default", because I want to
reserve the term default for something else if possible: the phrase
"reset everything to defaults", which is a whole another discussion.

How about also saying that fbcon/fbdev must set this property when
taking over? That sounds to be like a common omission leading to funky
KMS state in fbcon. The value fbdev sets it to only needs to make
sense to fbdev, and it does not need to be ~~the initial value~~ nor the
default value. Or are we hoping to kill fbcon in favor of a userspace
kmscon soon? ;-)

Ooh, maybe the KMS property documentation should also say what value
fbdev will set the property to. That's kind of UABI, because userspace
probably implicitly relies on it in many cases. ...which means fbdev
should set the property to its initial value, otherwise userspace will
break.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 9177 bytes --]

Hi Pekka,

On Thu, Jun 17, 2021 at 11:20:36AM +0300, Pekka Paalanen wrote:
> On Wed, 16 Jun 2021 16:38:42 +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.
> > 
> > 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: Joel Stanley <joel@jms.id.au>
> > 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 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 | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 87e5023e3f55..c28b464dd397 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -463,6 +463,25 @@ 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, with some documentation to describe how the
> > +  property can be used.
> 
> Hi,
> 
> I might replace "some" with "full" documentation. Also not only how it
> can be used but also what it does.
> 
> FYI, some common things that tend to be forgotten IME:
> - Spell out exactly the name string for the property in the
>   documentation so that it is unambiguous what string userspace should
>   look for.
> - The same for string names of enum values.
> - Explicitly document what each enum value means, do not trust that the
>   value name describes it well enough.
> - Explain how the property interacts with other, existing properties.
> 
> Not sure if these should be written down here or anywhere though.
> Interaction with other properties is kind of important.
> 
> > +
> > +- 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.
> > +
> > +- An IGT test must be submitted where reasonable.
> 
> Would it be too much to replace "where reasonable" with "if it is at
> all possible to write a test."?
> 
> > +
> 
> How about adding the following somewhere?
> 
> - The initial state of the property (set during driver initialization)
>   must match how the driver+hardware behaved before introducing this
>   property. It may be some fixed value or it may be inherited from e.g.
>   the firmware that booted the system. How the initial state is
>   determined must also be documented, that is, where does it come from.
> 
> The initial state must not be called "default", because I want to
> reserve the term default for something else if possible: the phrase
> "reset everything to defaults", which is a whole another discussion.

I've taken into account your previous comments, thanks

> How about also saying that fbcon/fbdev must set this property when
> taking over? That sounds to be like a common omission leading to funky
> KMS state in fbcon. The value fbdev sets it to only needs to make
> sense to fbdev, and it does not need to be ~~the initial value~~ nor the
> default value. Or are we hoping to kill fbcon in favor of a userspace
> kmscon soon? ;-)
> 
> Ooh, maybe the KMS property documentation should also say what value
> fbdev will set the property to. That's kind of UABI, because userspace
> probably implicitly relies on it in many cases. ...which means fbdev
> should set the property to its initial value, otherwise userspace will
> break.

I'm not sure about this one: fbdev and fbcon are still optional features
of the kernel and can be disabled at the user discretion. Having any
part of the user-space rely on the fbdev behavior seems a bit broken,
especially when we have a mechanism to retrieve the state when the
application starts.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 10993 bytes --]

On Tue, 6 Jul 2021 10:52:02 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> Hi Pekka,
> 
> On Thu, Jun 17, 2021 at 11:20:36AM +0300, Pekka Paalanen wrote:
> > On Wed, 16 Jun 2021 16:38:42 +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.
> > > 
> > > 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: Joel Stanley <joel@jms.id.au>
> > > 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 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 | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > > index 87e5023e3f55..c28b464dd397 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -463,6 +463,25 @@ 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, with some documentation to describe how the
> > > +  property can be used.  
> > 
> > Hi,
> > 
> > I might replace "some" with "full" documentation. Also not only how it
> > can be used but also what it does.
> > 
> > FYI, some common things that tend to be forgotten IME:
> > - Spell out exactly the name string for the property in the
> >   documentation so that it is unambiguous what string userspace should
> >   look for.
> > - The same for string names of enum values.
> > - Explicitly document what each enum value means, do not trust that the
> >   value name describes it well enough.
> > - Explain how the property interacts with other, existing properties.
> > 
> > Not sure if these should be written down here or anywhere though.
> > Interaction with other properties is kind of important.
> >   
> > > +
> > > +- 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.
> > > +
> > > +- An IGT test must be submitted where reasonable.  
> > 
> > Would it be too much to replace "where reasonable" with "if it is at
> > all possible to write a test."?
> >   
> > > +  
> > 
> > How about adding the following somewhere?
> > 
> > - The initial state of the property (set during driver initialization)
> >   must match how the driver+hardware behaved before introducing this
> >   property. It may be some fixed value or it may be inherited from e.g.
> >   the firmware that booted the system. How the initial state is
> >   determined must also be documented, that is, where does it come from.
> > 
> > The initial state must not be called "default", because I want to
> > reserve the term default for something else if possible: the phrase
> > "reset everything to defaults", which is a whole another discussion.  
> 
> I've taken into account your previous comments, thanks
> 
> > How about also saying that fbcon/fbdev must set this property when
> > taking over? That sounds to be like a common omission leading to funky
> > KMS state in fbcon. The value fbdev sets it to only needs to make
> > sense to fbdev, and it does not need to be ~~the initial value~~ nor the
> > default value. Or are we hoping to kill fbcon in favor of a userspace
> > kmscon soon? ;-)
> > 
> > Ooh, maybe the KMS property documentation should also say what value
> > fbdev will set the property to. That's kind of UABI, because userspace
> > probably implicitly relies on it in many cases. ...which means fbdev
> > should set the property to its initial value, otherwise userspace will
> > break.  
> 
> I'm not sure about this one: fbdev and fbcon are still optional features
> of the kernel and can be disabled at the user discretion. Having any
> part of the user-space rely on the fbdev behavior seems a bit broken,
> especially when we have a mechanism to retrieve the state when the
> application starts.

Hi,

yes, exactly that is why fbdev/fbcon should reset the properties to
their initial values. You would not want userspace inheriting a
different KMS state with vs. without fbcon when it starts.

Retrieving the current KMS state is useless if the current KMS state is
somehow wonky and the application does not understand that specific KMS
property that is wonky. It cannot set the property to any value other
than it already had without user intervention.

I'd say fbcon causing all KMS state to be reset is a quality of life
thing. It's possible to live without by rebooting, but it would
certainly make at least developers' and testers' life easier until we
get the real "reset KMS" knob (which fbcon could then use too).

Besides, even if it is broken for userspace to rely on the KMS state
set by fbcon/fbdev, userspace is already doing that and not on purpose
because new KMS properties get added in the kernel. I would bet that
there is not a single userspace program that would actually set all KMS
properties that drivers might expose. So they are depending on
inherited KMS state, which could be left by driver initialization, by
fbdev/fbcon, or by any other userspace.

But yeah, this idea is something new, so don't let this discussion
delay landing the docs.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4610 bytes --]

On Tue, Jul 06, 2021 at 12:37:23PM +0300, Pekka Paalanen wrote:
> > > > +- 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.
> > > > +
> > > > +- An IGT test must be submitted where reasonable.  
> > > 
> > > Would it be too much to replace "where reasonable" with "if it is at
> > > all possible to write a test."?
> > >   
> > > > +  
> > > 
> > > How about adding the following somewhere?
> > > 
> > > - The initial state of the property (set during driver initialization)
> > >   must match how the driver+hardware behaved before introducing this
> > >   property. It may be some fixed value or it may be inherited from e.g.
> > >   the firmware that booted the system. How the initial state is
> > >   determined must also be documented, that is, where does it come from.
> > > 
> > > The initial state must not be called "default", because I want to
> > > reserve the term default for something else if possible: the phrase
> > > "reset everything to defaults", which is a whole another discussion.  
> > 
> > I've taken into account your previous comments, thanks
> > 
> > > How about also saying that fbcon/fbdev must set this property when
> > > taking over? That sounds to be like a common omission leading to funky
> > > KMS state in fbcon. The value fbdev sets it to only needs to make
> > > sense to fbdev, and it does not need to be ~~the initial value~~ nor the
> > > default value. Or are we hoping to kill fbcon in favor of a userspace
> > > kmscon soon? ;-)
> > > 
> > > Ooh, maybe the KMS property documentation should also say what value
> > > fbdev will set the property to. That's kind of UABI, because userspace
> > > probably implicitly relies on it in many cases. ...which means fbdev
> > > should set the property to its initial value, otherwise userspace will
> > > break.  
> > 
> > I'm not sure about this one: fbdev and fbcon are still optional features
> > of the kernel and can be disabled at the user discretion. Having any
> > part of the user-space rely on the fbdev behavior seems a bit broken,
> > especially when we have a mechanism to retrieve the state when the
> > application starts.
> 
> yes, exactly that is why fbdev/fbcon should reset the properties to
> their initial values. You would not want userspace inheriting a
> different KMS state with vs. without fbcon when it starts.

I'm not sure I'm following you when fbdev/fbcon should reset these
properties. When a master takes over?

If we consider fbdev as any KMS client, isn't it a fundamental change
with how it's currently done? I haven't seen anywhere that a compositor
(or any client for that matter) should put the KMS device in the same
state that it started it with. In case of a crash it would be fairly
difficult to achieve.

> Retrieving the current KMS state is useless if the current KMS state is
> somehow wonky and the application does not understand that specific KMS
> property that is wonky. It cannot set the property to any value other
> than it already had without user intervention.

Yeah, that's true. But the same could be said if you switch from one
client to the other for example, at the moment there's no guarantee that
the first one didn't change a property to a value you don't expect in
the second. Unless we manage to tie that somehow to a first open of the
device?

> I'd say fbcon causing all KMS state to be reset is a quality of life
> thing. It's possible to live without by rebooting, but it would
> certainly make at least developers' and testers' life easier until we
> get the real "reset KMS" knob (which fbcon could then use too).
> 
> Besides, even if it is broken for userspace to rely on the KMS state
> set by fbcon/fbdev, userspace is already doing that and not on purpose
> because new KMS properties get added in the kernel. I would bet that
> there is not a single userspace program that would actually set all KMS
> properties that drivers might expose. So they are depending on
> inherited KMS state, which could be left by driver initialization, by
> fbdev/fbcon, or by any other userspace.
> 
> But yeah, this idea is something new, so don't let this discussion
> delay landing the docs.

Ack, I've sent a new version

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 10435 bytes --]

On Tue, 6 Jul 2021 18:42:41 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> On Tue, Jul 06, 2021 at 12:37:23PM +0300, Pekka Paalanen wrote:
> > > > > +- 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.
> > > > > +
> > > > > +- An IGT test must be submitted where reasonable.    
> > > > 
> > > > Would it be too much to replace "where reasonable" with "if it is at
> > > > all possible to write a test."?
> > > >     
> > > > > +    
> > > > 
> > > > How about adding the following somewhere?
> > > > 
> > > > - The initial state of the property (set during driver initialization)
> > > >   must match how the driver+hardware behaved before introducing this
> > > >   property. It may be some fixed value or it may be inherited from e.g.
> > > >   the firmware that booted the system. How the initial state is
> > > >   determined must also be documented, that is, where does it come from.
> > > > 
> > > > The initial state must not be called "default", because I want to
> > > > reserve the term default for something else if possible: the phrase
> > > > "reset everything to defaults", which is a whole another discussion.    
> > > 
> > > I've taken into account your previous comments, thanks
> > >   
> > > > How about also saying that fbcon/fbdev must set this property when
> > > > taking over? That sounds to be like a common omission leading to funky
> > > > KMS state in fbcon. The value fbdev sets it to only needs to make
> > > > sense to fbdev, and it does not need to be ~~the initial value~~ nor the
> > > > default value. Or are we hoping to kill fbcon in favor of a userspace
> > > > kmscon soon? ;-)
> > > > 
> > > > Ooh, maybe the KMS property documentation should also say what value
> > > > fbdev will set the property to. That's kind of UABI, because userspace
> > > > probably implicitly relies on it in many cases. ...which means fbdev
> > > > should set the property to its initial value, otherwise userspace will
> > > > break.    
> > > 
> > > I'm not sure about this one: fbdev and fbcon are still optional features
> > > of the kernel and can be disabled at the user discretion. Having any
> > > part of the user-space rely on the fbdev behavior seems a bit broken,
> > > especially when we have a mechanism to retrieve the state when the
> > > application starts.  
> > 
> > yes, exactly that is why fbdev/fbcon should reset the properties to
> > their initial values. You would not want userspace inheriting a
> > different KMS state with vs. without fbcon when it starts.  
> 
> I'm not sure I'm following you when fbdev/fbcon should reset these
> properties. When a master takes over?

Hi,

when fbcon/fbdev takes over. If it doesn't reset things like GAMMA
LUT, it's possible it won't be readable even though nothing fails.

(Let's say you fumble with an xrandr incantation and manage to set a
LUT that turns everything into a single shade of green or something.
How do you recover?)

When a userspace KMS client hands off to another userspace KMS client,
fbcon/fbdev should not do anything. If it did, that would cause extra
flicker.

I'm assuming fbcon/fbdev already implement all the necessary
mechanisms, but they just don't poke at all the KMS properties
necessary, as is evident from e.g. Michel Dänzer's testing seeing wrong
colors in fbcon after a userspace KMS client changed GAMMA or DEGAMMA
once.

Handling this properly would offer an escape hatch without reboot when
something goes wrong in a display server. It's not a fix for userspace
KMS client handing off to another userspace KMS client, for that we
need something else.

> If we consider fbdev as any KMS client, isn't it a fundamental change
> with how it's currently done? I haven't seen anywhere that a compositor
> (or any client for that matter) should put the KMS device in the same
> state that it started it with. In case of a crash it would be fairly
> difficult to achieve.

It has long been agreed IMO but never implemented anywhere AFAIK that a
userspace KMS client should fully reset the whole KMS state to the KMS
state it started with when it *comes back* after being switched away. I
have talked with Daniel Vetter about this several times over the years.
The problem with resetting the full KMS state is what to do with those
KMS properties the KMS client does not understand but are exposed by the
driver.

When a userspace KMS client switches out or quits, what is implemented
and what should be implemented differs again. I believe that KMS
clients of today do not change anything, so that the number of modesets
is minimized. This is sufficient if the KMS client didn't use any less
commonly used KMS properties. It's also consistent with crash behaviour.

If the KMS client wants to support seamless hand-off to another KMS
client, the practical approach is "reset everything to the sane KMS
state except keep the video mode" so that if the next KMS client
doesn't understand everything, it still works. I don't know if display
servers care to implement this, or do they just assume switching to
another instance of themselves in which case they know what the next
KMS client does. Or maybe the don't even use KMS properties others
don't use too.

Btw. Xorg understands very few KMS properties by itself I think. It
just exposes everything via RandR and assumes that whatever X11 clients
are running, some of them will take care of the KMS properties. So one
cannot look at Xorg as a single entity, one also needs to look at all
the different desktop environments and whatever.

Another idea that has come up is that userspace should invent a KMS
hand-off protocol completely in userspace. I'm not aware of anyone
working on that. It would allow better smooth KMS hand-off between KMS
clients, as the current and the next KMS client could negotiate about
which KMS properties they understand and which need to be reset
abruptly.

In any case, consensus seems to be that when a KMS client switches back
in, there are no guarantees at all about the KMS state it inherits at
that point. Therefore fbcon as a KMS client needs to reset everything.
People just don't seem to care about fbcon working that much.

There is also the assumption that when a KMS client starts, the KMS
state it inherits is... "reasonable". This should be true if the KMS
state is the initial state chosen by a driver, and also if the state
has been touched by fbcon, because it's not uncommon for fbcon to
be up before the first KMS userspace client starts. But after the first
KMS userspace client has started, all bets are practically off for the
next KMS client starting.

> > Retrieving the current KMS state is useless if the current KMS state is
> > somehow wonky and the application does not understand that specific KMS
> > property that is wonky. It cannot set the property to any value other
> > than it already had without user intervention.  
> 
> Yeah, that's true. But the same could be said if you switch from one
> client to the other for example, at the moment there's no guarantee that
> the first one didn't change a property to a value you don't expect in
> the second. Unless we manage to tie that somehow to a first open of the
> device?

As I wrote above, yes, this is an open problem. Fbcon being just a KMS
client needs a solution like all KMS clients. None of it is a
regression per se, unless you see adding new KMS properties that
provoke this problem more as a regression.

The idea I've been pondering about is a flag in atomic commit: instead
of basing the changes on the current KMS state, start with "the default
KMS state".

The definition of the default KMS state is tricky, because it should
not depend on e.g. firmware. So it is not the same as the initial KMS
state programmed in driver initialization. It needs to be defined
separately and individually for each KMS property. In my opinion, the
default KMS state should be defined as everything being off (planes,
crtcs), disabled (dithering, HDR), pass-through/identity (GAMMA,
DEGAMMA, CTM), "auto" where that applies and is the initial state, and
so on. The goal is to make it as neutral and as "off" as possible while
still giving good chances of letting the simpler KMS clients work
correctly.

If there was a mechanism for this "reset to default", fbdev could just
hit it.

There have been opinions that this problem does not need solving,
because an average Linux user will never switch between arbitrary KMS
clients. At most, they switch from bootsplash to a login manager, and
then to a desktop compositor. Bootsplash won't change "advanced" KMS
state, and the login manager's display server acts as the resetting
entity as it is maintained to explicitly(?) support all the different
desktops. If a desktop uses a new KMS property, the login manager is
updated(?) to reset that property.

Hence I didn't go all the way suggesting in the rules that the default
state needs to be defined.

And if fbcon is good to leave rotting, then no need to mention that
either.

> > I'd say fbcon causing all KMS state to be reset is a quality of life
> > thing. It's possible to live without by rebooting, but it would
> > certainly make at least developers' and testers' life easier until we
> > get the real "reset KMS" knob (which fbcon could then use too).
> > 
> > Besides, even if it is broken for userspace to rely on the KMS state
> > set by fbcon/fbdev, userspace is already doing that and not on purpose
> > because new KMS properties get added in the kernel. I would bet that
> > there is not a single userspace program that would actually set all KMS
> > properties that drivers might expose. So they are depending on
> > inherited KMS state, which could be left by driver initialization, by
> > fbdev/fbcon, or by any other userspace.
> > 
> > But yeah, this idea is something new, so don't let this discussion
> > delay landing the docs.  
> 
> Ack, I've sent a new version

Thank you!
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Philippe CORNU]

On 6/16/21 4:38 PM, 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: Joel Stanley <joel@jms.id.au>
> 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 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 | 19 +++++++++++++++++++
>   1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..c28b464dd397 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -463,6 +463,25 @@ 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, with some documentation to describe how the
> +  property can be used.
> +
> +- 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.
> +
> +- An IGT test must be submitted where reasonable.
> +
>   Property Types and Blob Property Support
>   ----------------------------------------
>   
> 

Hi,

Regarding properties, we have a “case study example” related in a 
certain way to this documentation update :-)

The use case: on a front desk at an exhibition, there is a welcome 
screen you can touch for searching various information. When this 
welcome screen is in idle, a small logo is displayed at its center 
(around 20% of the fullscreen). The logo has a white background color. 
We want to reduce the ddr usage for lowering the power (the board is 
battery powered) so the idea is to use a white background color around 
this logo, produced by the drm CRTC so the image in ddr is only the size 
of the logo.

Reading the thread 
https://lists.freedesktop.org/archives/dri-devel/2019-October/239733.html 
dissuade us from coding a generic solution, so we started to implement a 
"STM_" private background color property, it works... but we are not at 
all convince this is the right way and we clearly prefer 
mainline/generic sw for both kernel & userland.

So now, what are our options... well, this v4 documentation update is I 
think clear enough: we have to document + provide a generic helper in 
the core code (similar to the original patch) + update IGT test, right?

Thanks
Philippe :-)

Note: It is really a pleasure to read such interesting thread, exposing 
the “complexity” of our job, dealing with various hw and sw... thank you 
to all of you.

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

[Daniel Vetter]

On Thu, Jun 17, 2021 at 05:38:36PM +0200, Philippe CORNU wrote:
> 
> 
> On 6/16/21 4:38 PM, 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: Joel Stanley <joel@jms.id.au>
> > 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 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 | 19 +++++++++++++++++++
> >   1 file changed, 19 insertions(+)
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 87e5023e3f55..c28b464dd397 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -463,6 +463,25 @@ 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, with some documentation to describe how the
> > +  property can be used.
> > +
> > +- 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.
> > +
> > +- An IGT test must be submitted where reasonable.
> > +
> >   Property Types and Blob Property Support
> >   ----------------------------------------
> > 
> 
> Hi,
> 
> Regarding properties, we have a “case study example” related in a certain
> way to this documentation update :-)
> 
> The use case: on a front desk at an exhibition, there is a welcome screen
> you can touch for searching various information. When this welcome screen is
> in idle, a small logo is displayed at its center (around 20% of the
> fullscreen). The logo has a white background color. We want to reduce the
> ddr usage for lowering the power (the board is battery powered) so the idea
> is to use a white background color around this logo, produced by the drm
> CRTC so the image in ddr is only the size of the logo.
> 
> Reading the thread
> https://lists.freedesktop.org/archives/dri-devel/2019-October/239733.html
> dissuade us from coding a generic solution, so we started to implement a
> "STM_" private background color property, it works... but we are not at all
> convince this is the right way and we clearly prefer mainline/generic sw for
> both kernel & userland.
> 
> So now, what are our options... well, this v4 documentation update is I
> think clear enough: we have to document + provide a generic helper in the
> core code (similar to the original patch) + update IGT test, right?

Yeah, also background color has been talked about for a while (lots of hw
can do it), it's just that no one ever found a use-case to make the
background somethign else than "black". There's a pile of drivers who
could expose this, so definitely makes sense to have this generic.
-Daniel

> 
> Thanks
> Philippe :-)
> 
> Note: It is really a pleasure to read such interesting thread, exposing the
> “complexity” of our job, dealing with various hw and sw... thank you to all
> of you.
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch