lkml.org 
[lkml]   [2017]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
From
Date
  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

\
 
 \ /
  Last update: 2017-04-18 15:40    [W:0.109 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site