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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
