[RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Gerd Hoffmann kraxel at redhat.com
Tue Apr 18 13:39:53 UTC 2017


  Hi,

> > Historical note:  RHEL-6.9 (gnome 2) works fine.  Not of much interest
> > here, it drives the qemu stdvga with offb, not bochs-drm.
> 
> I suppose this proves the virtual machine itself is correct about
> framebuffer endianess? Except you are running it on a little-endian
> host machine I presume...

Yes, little endian host, qemu interprets the framebuffer as
PIXMAN_b8g8r8x8.  Which should be correct for a xrgb bigendian
framebuffer as pixman formats are native endian.

> > More interesting:  RHEL-7.3 (gnome 3.14) works fine too.  kernel 3.10,
> > but drm drivers updated to roughly 4.6 level.  Runs bochs-drm.  mesa
> > 11.2.2.  glamour not used.
> > 
> > Most recent:  Fedora 25 (gnome 3.22) looks mostly ok, but there are
> > rendering glitches, for example in the gnome activities screen (the one
> > you get when you press the windows key).  kernel 4.10, mesa 13.0.4.
> > glamor not used, but I think gnome-shell uses opengl (via llvmpipe) for
> > compositing.
> 
> I believe glitches are irrelevant for this topic, what we are
> interested in is if the colors are right or byte-swapped (also mind
> alpha/blue etc. swaps).

Well, I mean color glitches.  But it isn't consistent.  As if some
operations operate with the correct byteorder and some don't.
alpha/blue being swapped is a problem in some areas.

https://www.kraxel.org/tmp/

cheers,
  Gerd



More information about the amd-gfx mailing list