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

[Michel Dänzer]

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