[PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
kraxel at redhat.com
Fri Apr 21 13:12:03 UTC 2017
> > "native" to me feels more like "native to the GPU" since these things
> > really are tied to the GPU not the CPU. That's also why I went with the
> > explicit endianness originally so that the driver could properly declare
> > what the GPU supports.
> And to be honest I would really prefer to stick with that approach for
> exactly that reason.
> The proposed change would require that drivers have different code path
> for different CPU byte order. Those code path tend to be not tested very
> well and are additional complexity we probably don't want inside the driver.
We can add fixed-endian #defines without too much effort, at least for
the 8 bits per color formats. In qemu we have the same problem, only
with pixman. Those formats are native endian too, but often we have to
handle a fixed format, so we did this:
* pixman image formats are defined to be native endian,
* that means host byte order on qemu. So we go define
* fixed formats here for cases where it is needed, like
* feeding libjpeg / libpng and writing screenshots.
# define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8
# define PIXMAN_BE_x8r8g8b8 PIXMAN_x8r8g8b8
# define PIXMAN_BE_a8r8g8b8 PIXMAN_a8r8g8b8
# define PIXMAN_BE_b8g8r8x8 PIXMAN_b8g8r8x8
# define PIXMAN_BE_b8g8r8a8 PIXMAN_b8g8r8a8
# define PIXMAN_BE_r8g8b8x8 PIXMAN_r8g8b8x8
# define PIXMAN_BE_r8g8b8a8 PIXMAN_r8g8b8a8
# define PIXMAN_BE_x8b8g8r8 PIXMAN_x8b8g8r8
# define PIXMAN_BE_a8b8g8r8 PIXMAN_a8b8g8r8
# define PIXMAN_LE_x8r8g8b8 PIXMAN_b8g8r8x8
# define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8
# define PIXMAN_BE_x8r8g8b8 PIXMAN_b8g8r8x8
# define PIXMAN_BE_a8r8g8b8 PIXMAN_b8g8r8a8
# define PIXMAN_BE_b8g8r8x8 PIXMAN_x8r8g8b8
# define PIXMAN_BE_b8g8r8a8 PIXMAN_a8r8g8b8
# define PIXMAN_BE_r8g8b8x8 PIXMAN_x8b8g8r8
# define PIXMAN_BE_r8g8b8a8 PIXMAN_a8b8g8r8
# define PIXMAN_BE_x8b8g8r8 PIXMAN_r8g8b8x8
# define PIXMAN_BE_a8b8g8r8 PIXMAN_r8g8b8a8
# define PIXMAN_LE_x8r8g8b8 PIXMAN_x8r8g8b8
> My personal opinion is that formats in drm_fourcc.h should be
> independent of the CPU byte order and the function
> drm_mode_legacy_fb_format() and drivers depending on that incorrect
> assumption be fixed instead.
The problem is this isn't a kernel-internal thing any more. With the
addition of the ADDFB2 ioctl the fourcc codes became part of the
kernel/userspace abi ...
More information about the dri-devel