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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1492522793.27392.55.camel@redhat.com>
Date:   Tue, 18 Apr 2017 15:39:53 +0200
From:   Gerd Hoffmann <kraxel@...hat.com>
To:     Pekka Paalanen <ppaalanen@...il.com>
Cc:     dri-devel@...ts.freedesktop.org,
        open list <linux-kernel@...r.kernel.org>,
        amd-gfx@...ts.freedesktop.org,
        Daniel Vetter <daniel.vetter@...el.com>,
        Ilia Mirkin <imirkin@...m.mit.edu>
Subject: Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments
 in line with reality.

  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