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: <20170418170134.0a60d340@eldfell>
Date:   Tue, 18 Apr 2017 17:01:34 +0300
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Gerd Hoffmann <kraxel@...hat.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.

On Tue, 18 Apr 2017 15:39:53 +0200
Gerd Hoffmann <kraxel@...hat.com> wrote:

>   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.

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?

> > > 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/

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
out?

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.


Thanks,
pq

Content of type "application/pgp-signature" skipped