[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170410101202.19229-1-kraxel@redhat.com>
Date: Mon, 10 Apr 2017 12:12:01 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: dri-devel@...ts.freedesktop.org
Cc: Gerd Hoffmann <kraxel@...hat.com>,
Ville Syrjälä
<ville.syrjala@...ux.intel.com>,
Daniel Vetter <daniel.vetter@...el.com>,
amd-gfx@...ts.freedesktop.org,
Jani Nikula <jani.nikula@...ux.intel.com>,
Sean Paul <seanpaul@...omium.org>,
David Airlie <airlied@...ux.ie>,
linux-kernel@...r.kernel.org (open list)
Subject: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Ok, this is really a kickstart for a discussion. While working on
graphics support for virtual machines on ppc64 (which exists in both
little and big endian variants) I've figured the comments in the header
file don't match reality. They are not considered little endian (as
suggested by the comments) but in practice are used as native endian.
So, go update the comments.
This patch switches all 32bpp / 8 bpc formats over to native endian.
Those used/supported by ppc64 virtual machines (virtio-gpu/bochs-drm
drivers).
Given that DRM_FORMAT_BIG_ENDIAN isn't used anywhere in the codebase
I suspect this problem applies to more formats. When looking at
drm_mode_legacy_fb_format it seems *all* RGB formats are actually
native endian not little endian.
Dunno where we stand in terms of YCbCr.
Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc: Daniel Vetter <daniel.vetter@...el.com>
Cc: amd-gfx@...ts.freedesktop.org
Signed-off-by: Gerd Hoffmann <kraxel@...hat.com>
---
include/uapi/drm/drm_fourcc.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 995c8f9..a7fc81d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -85,15 +85,15 @@ extern "C" {
#define DRM_FORMAT_BGR888 fourcc_code('B', 'G', '2', '4') /* [23:0] B:G:R little endian */
/* 32 bpp RGB */
-#define DRM_FORMAT_XRGB8888 fourcc_code('X', 'R', '2', '4') /* [31:0] x:R:G:B 8:8:8:8 little endian */
-#define DRM_FORMAT_XBGR8888 fourcc_code('X', 'B', '2', '4') /* [31:0] x:B:G:R 8:8:8:8 little endian */
-#define DRM_FORMAT_RGBX8888 fourcc_code('R', 'X', '2', '4') /* [31:0] R:G:B:x 8:8:8:8 little endian */
-#define DRM_FORMAT_BGRX8888 fourcc_code('B', 'X', '2', '4') /* [31:0] B:G:R:x 8:8:8:8 little endian */
+#define DRM_FORMAT_XRGB8888 fourcc_code('X', 'R', '2', '4') /* [31:0] x:R:G:B 8:8:8:8 native endian */
+#define DRM_FORMAT_XBGR8888 fourcc_code('X', 'B', '2', '4') /* [31:0] x:B:G:R 8:8:8:8 native endian */
+#define DRM_FORMAT_RGBX8888 fourcc_code('R', 'X', '2', '4') /* [31:0] R:G:B:x 8:8:8:8 native endian */
+#define DRM_FORMAT_BGRX8888 fourcc_code('B', 'X', '2', '4') /* [31:0] B:G:R:x 8:8:8:8 native endian */
-#define DRM_FORMAT_ARGB8888 fourcc_code('A', 'R', '2', '4') /* [31:0] A:R:G:B 8:8:8:8 little endian */
-#define DRM_FORMAT_ABGR8888 fourcc_code('A', 'B', '2', '4') /* [31:0] A:B:G:R 8:8:8:8 little endian */
-#define DRM_FORMAT_RGBA8888 fourcc_code('R', 'A', '2', '4') /* [31:0] R:G:B:A 8:8:8:8 little endian */
-#define DRM_FORMAT_BGRA8888 fourcc_code('B', 'A', '2', '4') /* [31:0] B:G:R:A 8:8:8:8 little endian */
+#define DRM_FORMAT_ARGB8888 fourcc_code('A', 'R', '2', '4') /* [31:0] A:R:G:B 8:8:8:8 native endian */
+#define DRM_FORMAT_ABGR8888 fourcc_code('A', 'B', '2', '4') /* [31:0] A:B:G:R 8:8:8:8 native endian */
+#define DRM_FORMAT_RGBA8888 fourcc_code('R', 'A', '2', '4') /* [31:0] R:G:B:A 8:8:8:8 native endian */
+#define DRM_FORMAT_BGRA8888 fourcc_code('B', 'A', '2', '4') /* [31:0] B:G:R:A 8:8:8:8 native endian */
#define DRM_FORMAT_XRGB2101010 fourcc_code('X', 'R', '3', '0') /* [31:0] x:R:G:B 2:10:10:10 little endian */
#define DRM_FORMAT_XBGR2101010 fourcc_code('X', 'B', '3', '0') /* [31:0] x:B:G:R 2:10:10:10 little endian */
--
2.9.3
Powered by blists - more mailing lists