linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Pekka Paalanen <ppaalanen@gmail.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 22:50:18 +0200	[thread overview]
Message-ID: <1492548618.27392.72.camel@redhat.com> (raw)
In-Reply-To: <20170418170134.0a60d340@eldfell>

  Hi,

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

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

cheers,
  Gerd

      reply	other threads:[~2017-04-18 20:50 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
2017-04-18 20:50               ` Gerd Hoffmann [this message]

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=1492548618.27392.72.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imirkin@alum.mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ppaalanen@gmail.com \
    /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).