From: Jocelyn Falempe <jfalempe@redhat.com>
To: tzimmermann@suse.de, airlied@redhat.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
daniel@ffwll.ch, ppaalanen@gmail.com, javierm@redhat.com
Cc: Jocelyn Falempe <jfalempe@redhat.com>, dri-devel@lists.freedesktop.org
Subject: [PATCH 1/1] drm/fourcc: Add documentation about software color conversion.
Date: Mon, 7 Aug 2023 15:45:15 +0200 [thread overview]
Message-ID: <20230807140317.26146-2-jfalempe@redhat.com> (raw)
In-Reply-To: <20230807140317.26146-1-jfalempe@redhat.com>
After discussions on IRC, the consensus is that the DRM drivers should
not do software color conversion, and only advertise the supported formats.
Update the doc accordingly so that the rule and exceptions are clear for
everyone.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
---
include/uapi/drm/drm_fourcc.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8db7fd3f743e..00a29152da9f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -38,6 +38,13 @@ extern "C" {
* fourcc code, a Format Modifier may optionally be provided, in order to
* further describe the buffer's format - for example tiling or compression.
*
+ * DRM drivers should not do software color conversion, and only advertise the
+ * format they support in hardware. But there are two exceptions:
+ * The first is to support XRGB8888 if the hardware doesn't support it, because
+ * it's the de facto standard for userspace applications.
+ * The second is to drop the unused bits when sending the data to the hardware,
+ * to improve the bandwidth, like dropping the "X" in XRGB8888.
+ *
* Format Modifiers
* ----------------
*
--
2.41.0
next prev parent reply other threads:[~2023-08-07 14:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 13:45 [PATCH 0/1] drm/fourcc: Add documentation about software color conversion Jocelyn Falempe
2023-08-07 13:45 ` Jocelyn Falempe [this message]
2023-08-09 16:29 ` [PATCH 1/1] " Simon Ser
2023-08-10 9:23 ` Jocelyn Falempe
2023-08-10 7:45 ` Maxime Ripard
2023-08-10 10:22 ` Jocelyn Falempe
2023-08-11 16:12 ` Javier Martinez Canillas
2023-08-18 13:24 ` Pekka Paalanen
2023-08-21 15:55 ` Maxime Ripard
2023-08-22 8:20 ` Pekka Paalanen
2023-08-22 15:49 ` Jocelyn Falempe
2023-08-23 8:11 ` Pekka Paalanen
2023-08-23 9:14 ` Jocelyn Falempe
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=20230807140317.26146-2-jfalempe@redhat.com \
--to=jfalempe@redhat.com \
--cc=airlied@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ppaalanen@gmail.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