[RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
kraxel at redhat.com
Tue Apr 18 20:50:18 UTC 2017
> Right. Very nice if we can trust the virtual machine at least getting
> things right, gives some chance for people to test anything. Except...
> that's a question of what kind of hardware the virtual machine
> emulates. The display device defines what endianess it uses on
> framebuffers, not the CPU, right?
The display device supports switching the endianess for the framebuffer,
at least with kernel 3.19+ and qemu 2.2+. Default endianness depends on
the machine type, i.e. ppc64 guests get a bigendian framebuffer and
pretty much everything else a little endian framebuffer on reset.
The bochs-drm driver switches the display into native endian mode, i.e.
big endian for ppc64 and little endian for ppc64le kernels.
See commit 9ecdb039b7517dc10b8c3e6dbeb40859178ac28e
> > 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/
> Ooh, yeah, that's definitely bonkers.
> Maybe the 100% blue things are supposed to be a transparent blended
> overlays, like highlights.
> The icons look somehow... not completely right to me. Somehow washed
> Opaque gray shades are hard to tell right from wrong.
> gnome-terminal and the wallpaper look right, but those might be the
> only things.
> Having a compositing manager complicates things.
In some way yes, in some way no. Tried wayland meanwhile (using
"gnome-shell --wayland"). Looks pretty much the same. Window
decorations look a bit different (good on xorg, broken on wayland),
probably because window decorations work completely different.
Otherwise it is bug compatible to xorg. Probably because gnome-shell
composites everything using llvmpipe, so it's largely the same code
running on both xorg and wayland, which then finally scans out to a dumb
More information about the dri-devel