[PATCH 0/6] drm: tackle byteorder issues, take two

[Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

  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