On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
Hi,
Ok, different approach up for discussion. Given that userspace didn't made the transition from ADDFB to ADDFB2 yet it seems we still can muck with the fourcc codes without breaking everything, as long as we maintain ADDFB and fbdev behavior (use cpu byte order format) so nothing changes for userspace.
So, this series basically makes drm_mode_legacy_fb_format return correct formats in bigendian mode and adapts the bochs and virtio drivers to this change. Other drivers must be adapted to this change too.
Ilia Mirkin figured the dispnv04 backend in nouveau turns on/off byteswapping depending on cpu byte order. So, one way to adapt the driver would be to simply use the new #defines added by patch #2. The other way would be to support both XRGB and BGRX and turn on/off byteswapping depending on framebuffer format instead of cpu byte order.
cheers, Gerd
Gerd Hoffmann (6): drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN
I don't see how it can be dropped. It's only optional for formats where all components have 8 bits.
drm: fourcc byteorder: add DRM_FORMAT_CPU_* drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format
As I explained in my last followup in the "[PATCH] drm: fourcc byteorder: brings header file comments in line with reality." thread, the mapping between GPU and CPU formats has to be provided by the driver, it cannot be done statically.