linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel@lists.freedesktop.org,
	open list <linux-kernel@vger.kernel.org>,
	amd-gfx@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@intel.com>,
	Ilia Mirkin <imirkin@alum.mit.edu>
Subject: Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Date: Tue, 18 Apr 2017 17:01:34 +0300	[thread overview]
Message-ID: <20170418170134.0a60d340@eldfell> (raw)
In-Reply-To: <1492522793.27392.55.camel@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

On Tue, 18 Apr 2017 15:39:53 +0200
Gerd Hoffmann <kraxel@redhat.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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-04-18 14:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10 10:12 [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality Gerd Hoffmann
2017-04-10 12:02 ` Daniel Vetter
2017-04-10 16:28   ` Alex Deucher
2017-04-10 13:12 ` Pekka Paalanen
2017-04-10 14:17   ` Gerd Hoffmann
2017-04-10 14:45     ` Ilia Mirkin
2017-04-10 16:26       ` Alex Deucher
2017-04-10 15:09     ` Pekka Paalanen
2017-04-10 16:10       ` Ilia Mirkin
2017-04-11  7:31         ` Pekka Paalanen
2017-04-11 11:23           ` Gerd Hoffmann
2017-04-13  7:44             ` Pekka Paalanen
2017-04-11 14:18           ` Ilia Mirkin
2017-04-17  6:43             ` Ilia Mirkin
2017-04-18  2:53               ` Michel Dänzer
2017-04-18  5:04                 ` Ilia Mirkin
2017-04-18  5:58                   ` Michel Dänzer
2017-04-18 10:14                     ` Gerd Hoffmann
2017-04-19  1:01                       ` Michel Dänzer
2017-04-19  3:19                         ` Ilia Mirkin
2017-04-19  3:28                           ` Ilia Mirkin
2017-04-19  7:09                         ` Pekka Paalanen
2017-04-19 12:34                           ` Gerd Hoffmann
2017-04-18 10:00       ` Gerd Hoffmann
2017-04-18 11:18         ` Pekka Paalanen
2017-04-18 13:39           ` Gerd Hoffmann
2017-04-18 14:01             ` Pekka Paalanen [this message]
2017-04-18 20:50               ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170418170134.0a60d340@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imirkin@alum.mit.edu \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).