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

Michel Dänzer michel at daenzer.net
Mon Apr 24 07:03:46 UTC 2017

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

More information about the dri-devel mailing list