[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