From: Maxime Ripard <mripard@kernel.org>
To: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Daniel Vetter <daniel@ffwll.ch>,
Jonathan Corbet <corbet@lwn.net>,
dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm: Document requirements for driver-specific KMS props in new drivers
Date: Wed, 6 Mar 2024 15:14:15 +0100 [thread overview]
Message-ID: <20240306-hulking-funky-fox-b9581b@houat> (raw)
In-Reply-To: <20240229202833.198691-1-sebastian.wick@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]
Hi,
On Thu, Feb 29, 2024 at 09:28:31PM +0100, Sebastian Wick wrote:
> When extending support for a driver-specific KMS property to additional
> drivers, we should apply all the requirements for new properties and
> make sure the semantics are the same and documented.
>
> Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
> ---
> Documentation/gpu/drm-kms.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 13d3627d8bc0..afa10a28035f 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -496,6 +496,11 @@ addition to the one mentioned above:
>
> * An IGT test must be submitted where reasonable.
>
> +For historical reasons, non-standard, driver-specific properties exist. If a KMS
> +driver wants to add support for one of those properties, the requirements for
> +new properties apply where possible. Additionally, the documented behavior must
> +match the de facto semantics of the existing property to ensure compatibility.
> +
I'm conflicted about this one, really.
On one hand, yeah, it's definitely reasonable and something we would
want on the long run.
But on the other hand, a driver getting its technical debt worked on for
free by anyone but its developpers doesn't seem fair to me.
Also, I assume this is in reaction to the discussion we had on the
Broadcast RGB property. We used in vc4 precisely because there was some
userspace code to deal with it and we could just reuse it, and it was
documented. So the requirements were met already.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-03-06 14:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 20:28 [PATCH] drm: Document requirements for driver-specific KMS props in new drivers Sebastian Wick
2024-03-06 14:14 ` Maxime Ripard [this message]
2024-03-06 16:50 ` Sebastian Wick
2024-03-11 12:10 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240306-hulking-funky-fox-b9581b@houat \
--to=mripard@kernel.org \
--cc=airlied@gmail.com \
--cc=corbet@lwn.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=sebastian.wick@redhat.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox