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 drm: fourcc byteorder: add DRM_FORMAT_CPU_* drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format drm: fourcc byteorder: adapt bochs-drm to drm_mode_legacy_fb_format update drm: fourcc byteorder: adapt virtio to drm_mode_legacy_fb_format update drm: fourcc byteorder: virtio restrict to XRGB8888 include/drm/drm_fourcc.h | 12 ++++++++++ include/uapi/drm/drm_fourcc.h | 2 -- drivers/gpu/drm/bochs/bochs_mm.c | 2 +- drivers/gpu/drm/drm_fourcc.c | 27 +++++++++++++++++++++-- drivers/gpu/drm/drm_framebuffer.c | 2 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 7 ++++-- drivers/gpu/drm/virtio/virtgpu_plane.c | 40 +--------------------------------- 7 files changed, 45 insertions(+), 47 deletions(-) -- 2.9.3 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx