Hi all,
When starting to use modetest, I was a bit surprised to discover the default XR24 format wasn't displayed correctly on my work-in-progress Atari DRM driver, which runs on a big-endian system.
This RFC patch series fixes some endianness issues in libdrm. It has been tested on ARAnyM using a work-in-progress Atari DRM driver, which can now display the XR24 format by converting XRGB8888 to RGB332.
Overview: - Patch 1 improves the existing endianness checks in a header file for the Intel driver, - Patch 2 fixes the display of 32 bpp patterns on big-endian systems.
Futher endian fixes may be needed. Note that I also have a variant of patch 2 for 16 bpp, which works with the Atari DRM driver converting RGB565 to RGB332. But I want to get real 16 bpp working in the Atari DRM driver first, as that uses a 16-bit big endian format. And what about 24 bpp?
Please refer to [1] for more information.
Thanks for your comments!
[1] "[PATCH v2 00/10] drm: Add support for low-color frame buffer formats" https://lore.kernel.org/r/cover.1646683502.git.geert@linux-m68k.org
Geert Uytterhoeven (2): intel: Improve checks for big-endian util: Fix 32 bpp patterns on big-endian
intel/uthash.h | 2 +- tests/util/pattern.c | 30 +++++++++++++++++++++--------- 2 files changed, 22 insertions(+), 10 deletions(-)
- sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but does define __sparc__, hence replace the check for SPARC by a check for __sparc__, - powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__, but does define __BIG_ENDIAN__. powerpc64le-linux-gnu-gcc does not define __ppc__ or __ppc64__, but does define __LITTLE_ENDIAN__. Hence remove the checks for __ppc__ and __ppc64__. - mips{,64}-linux-gnu{,abi64}-gcc does not define __BIG_ENDIAN__, but does define __MIPSEB__, so add a check for the latter, - m68k-linux-gnu-gcc does not define __BIG_ENDIAN__, but does define __mc68000__, so add a check for the latter, - hppa{,64}-linux-gnu-gcc defines __BIG_ENDIAN__, and thus should work out-of-the-box.
Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org --- Untested due to lack of hardware. --- intel/uthash.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/intel/uthash.h b/intel/uthash.h index 45d1f9fc12a1d6f9..0f5480be6e8ca033 100644 --- a/intel/uthash.h +++ b/intel/uthash.h @@ -648,7 +648,7 @@ do { #define MUR_PLUS2_ALIGNED(p) (((unsigned long)p & 3UL) == 2UL) #define MUR_PLUS3_ALIGNED(p) (((unsigned long)p & 3UL) == 3UL) #define WP(p) ((uint32_t*)((unsigned long)(p) & ~3UL)) -#if (defined(__BIG_ENDIAN__) || defined(SPARC) || defined(__ppc__) || defined(__ppc64__)) +#if (defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__)) #define MUR_THREE_ONE(p) ((((*WP(p))&0x00ffffff) << 8) | (((*(WP(p)+1))&0xff000000) >> 24)) #define MUR_TWO_TWO(p) ((((*WP(p))&0x0000ffff) <<16) | (((*(WP(p)+1))&0xffff0000) >> 16)) #define MUR_ONE_THREE(p) ((((*WP(p))&0x000000ff) <<24) | (((*(WP(p)+1))&0xffffff00) >> 8))
On 2022-03-07 20:53, Geert Uytterhoeven wrote:
- sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but does define __sparc__, hence replace the check for SPARC by a check for __sparc__,
- powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__, but does define __BIG_ENDIAN__. powerpc64le-linux-gnu-gcc does not define __ppc__ or __ppc64__, but does define __LITTLE_ENDIAN__. Hence remove the checks for __ppc__ and __ppc64__.
- mips{,64}-linux-gnu{,abi64}-gcc does not define __BIG_ENDIAN__, but does define __MIPSEB__, so add a check for the latter,
- m68k-linux-gnu-gcc does not define __BIG_ENDIAN__, but does define __mc68000__, so add a check for the latter,
- hppa{,64}-linux-gnu-gcc defines __BIG_ENDIAN__, and thus should work out-of-the-box.
FWIW there's also __ARM_BIG_ENDIAN for arm-* and aarch64-* targets in BE mode, if you want to flesh out the list even more. In principle there's also "__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__" which should supposedly be consistent across platforms, but I don't know if that's even more of a specific GCC-ism.
Robin.
Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org
Untested due to lack of hardware.
intel/uthash.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/intel/uthash.h b/intel/uthash.h index 45d1f9fc12a1d6f9..0f5480be6e8ca033 100644 --- a/intel/uthash.h +++ b/intel/uthash.h @@ -648,7 +648,7 @@ do { #define MUR_PLUS2_ALIGNED(p) (((unsigned long)p & 3UL) == 2UL) #define MUR_PLUS3_ALIGNED(p) (((unsigned long)p & 3UL) == 3UL) #define WP(p) ((uint32_t*)((unsigned long)(p) & ~3UL)) -#if (defined(__BIG_ENDIAN__) || defined(SPARC) || defined(__ppc__) || defined(__ppc64__)) +#if (defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__)) #define MUR_THREE_ONE(p) ((((*WP(p))&0x00ffffff) << 8) | (((*(WP(p)+1))&0xff000000) >> 24)) #define MUR_TWO_TWO(p) ((((*WP(p))&0x0000ffff) <<16) | (((*(WP(p)+1))&0xffff0000) >> 16)) #define MUR_ONE_THREE(p) ((((*WP(p))&0x000000ff) <<24) | (((*(WP(p)+1))&0xffffff00) >> 8))
DRM formats are defined to be little-endian, unless the DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel values need to take endianness into account.
Introduce a cpu_to_le32() helper to convert 32-bit values from CPU-endian to little-endian, and use them in the various pattern fill functions for 32-bit formats.
Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org --- Works now with Linux' drm_fb_xrgb8888_to_rgb332_line(), which uses le32_to_cpu() to read pixel values from memory.
--- tests/util/pattern.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c index 42d75d700700dc3d..48677ea6d25b2676 100644 --- a/tests/util/pattern.c +++ b/tests/util/pattern.c @@ -61,6 +61,18 @@ struct color_yuv { .u = MAKE_YUV_601_U(r, g, b), \ .v = MAKE_YUV_601_V(r, g, b) }
+#if defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__) +static inline uint32_t cpu_to_le32(uint32_t x) +{ + return ((x & 0x000000ffU) << 24) | + ((x & 0x0000ff00U) << 8) | + ((x & 0x00ff0000U) >> 8) | + ((x & 0xff000000U) >> 24); +} +#else +#define cpu_to_le32(x) (x) +#endif + /* This function takes 8-bit color values */ static inline uint32_t shiftcolor8(const struct util_color_component *comp, uint32_t value) @@ -520,26 +532,26 @@ static void fill_smpte_rgb32(const struct util_rgb_info *rgb, void *mem,
for (y = 0; y < height * 6 / 9; ++y) { for (x = 0; x < width; ++x) - ((uint32_t *)mem)[x] = colors_top[x * 7 / width]; + ((uint32_t *)mem)[x] = cpu_to_le32(colors_top[x * 7 / width]); mem += stride; }
for (; y < height * 7 / 9; ++y) { for (x = 0; x < width; ++x) - ((uint32_t *)mem)[x] = colors_middle[x * 7 / width]; + ((uint32_t *)mem)[x] = cpu_to_le32(colors_middle[x * 7 / width]); mem += stride; }
for (; y < height; ++y) { for (x = 0; x < width * 5 / 7; ++x) ((uint32_t *)mem)[x] = - colors_bottom[x * 4 / (width * 5 / 7)]; + cpu_to_le32(colors_bottom[x * 4 / (width * 5 / 7)]); for (; x < width * 6 / 7; ++x) ((uint32_t *)mem)[x] = - colors_bottom[(x - width * 5 / 7) * 3 - / (width / 7) + 4]; + cpu_to_le32(colors_bottom[(x - width * 5 / 7) * 3 + / (width / 7) + 4]); for (; x < width; ++x) - ((uint32_t *)mem)[x] = colors_bottom[7]; + ((uint32_t *)mem)[x] = cpu_to_le32(colors_bottom[7]); mem += stride; } } @@ -1017,7 +1029,7 @@ static void fill_tiles_rgb32(const struct util_format_info *info, void *mem, (rgb32 >> 8) & 0xff, rgb32 & 0xff, alpha);
- ((uint32_t *)mem)[x] = color; + ((uint32_t *)mem)[x] = cpu_to_le32(color); } mem += stride; } @@ -1164,7 +1176,7 @@ static void fill_gradient_rgb32(const struct util_rgb_info *rgb,
for (j = 0; j < width / 2; j++) { uint32_t value = MAKE_RGBA10(rgb, j & 0x3ff, j & 0x3ff, j & 0x3ff, 0); - row[2*j] = row[2*j+1] = value; + row[2*j] = row[2*j+1] = cpu_to_le32(value); } mem += stride; } @@ -1174,7 +1186,7 @@ static void fill_gradient_rgb32(const struct util_rgb_info *rgb,
for (j = 0; j < width / 2; j++) { uint32_t value = MAKE_RGBA10(rgb, j & 0x3fc, j & 0x3fc, j & 0x3fc, 0); - row[2*j] = row[2*j+1] = value; + row[2*j] = row[2*j+1] = cpu_to_le32(value); } mem += stride; }
On Mon, 7 Mar 2022 21:53:42 +0100 Geert Uytterhoeven geert@linux-m68k.org wrote:
DRM formats are defined to be little-endian, unless the DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel values need to take endianness into account.
Introduce a cpu_to_le32() helper to convert 32-bit values from CPU-endian to little-endian, and use them in the various pattern fill functions for 32-bit formats.
Hi Geert,
FWIW, this explanation matches my understanding, so it sounds correct to me. That's all I can say. I guess that means
Acked-by: Pekka Paalanen pekka.paalanen@collabora.com
?
Thanks, pq
Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org
Works now with Linux' drm_fb_xrgb8888_to_rgb332_line(), which uses le32_to_cpu() to read pixel values from memory.
tests/util/pattern.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c index 42d75d700700dc3d..48677ea6d25b2676 100644 --- a/tests/util/pattern.c +++ b/tests/util/pattern.c @@ -61,6 +61,18 @@ struct color_yuv { .u = MAKE_YUV_601_U(r, g, b), \ .v = MAKE_YUV_601_V(r, g, b) }
+#if defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__) +static inline uint32_t cpu_to_le32(uint32_t x) +{
- return ((x & 0x000000ffU) << 24) |
((x & 0x0000ff00U) << 8) |((x & 0x00ff0000U) >> 8) |((x & 0xff000000U) >> 24);+} +#else +#define cpu_to_le32(x) (x) +#endif
dri-devel@lists.freedesktop.org
-
Geert Uytterhoeven -
Pekka Paalanen -
Robin Murphy