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
WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com> To: Pekka Paalanen <ppaalanen@gmail.com> Cc: Daniel Vetter <daniel.vetter@intel.com>, amd-gfx@lists.freedesktop.org, open list <linux-kernel@vger.kernel.org>, dri-devel@lists.freedesktop.org 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-04-18 20:50 UTC|newest] Thread overview: 55+ 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 10:12 ` Gerd Hoffmann 2017-04-10 12:02 ` Daniel Vetter 2017-04-10 12:02 ` Daniel Vetter 2017-04-10 16:28 ` Alex Deucher 2017-04-10 16:28 ` Alex Deucher 2017-04-10 13:12 ` Pekka Paalanen 2017-04-10 13:12 ` Pekka Paalanen 2017-04-10 14:17 ` Gerd Hoffmann 2017-04-10 14:17 ` Gerd Hoffmann 2017-04-10 14:45 ` Ilia Mirkin 2017-04-10 14:45 ` Ilia Mirkin 2017-04-10 16:26 ` Alex Deucher 2017-04-10 16:26 ` Alex Deucher 2017-04-10 15:09 ` Pekka Paalanen 2017-04-10 15:09 ` Pekka Paalanen 2017-04-10 16:10 ` Ilia Mirkin 2017-04-10 16:10 ` Ilia Mirkin 2017-04-11 7:31 ` Pekka Paalanen 2017-04-11 7:31 ` Pekka Paalanen 2017-04-11 11:23 ` Gerd Hoffmann 2017-04-11 11:23 ` Gerd Hoffmann 2017-04-13 7:44 ` Pekka Paalanen 2017-04-13 7:44 ` Pekka Paalanen 2017-04-11 14:18 ` Ilia Mirkin 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 2:53 ` Michel Dänzer 2017-04-18 5:04 ` Ilia Mirkin 2017-04-18 5:04 ` Ilia Mirkin 2017-04-18 5:58 ` Michel Dänzer 2017-04-18 5:58 ` Michel Dänzer 2017-04-18 10:14 ` Gerd Hoffmann 2017-04-18 10:14 ` Gerd Hoffmann 2017-04-19 1:01 ` Michel Dänzer 2017-04-19 1:01 ` Michel Dänzer 2017-04-19 3:19 ` Ilia Mirkin 2017-04-19 3:19 ` Ilia Mirkin 2017-04-19 3:28 ` Ilia Mirkin 2017-04-19 3:28 ` Ilia Mirkin 2017-04-19 7:09 ` Pekka Paalanen 2017-04-19 7:09 ` Pekka Paalanen 2017-04-19 12:34 ` Gerd Hoffmann 2017-04-19 12:34 ` Gerd Hoffmann 2017-04-18 10:00 ` Gerd Hoffmann 2017-04-18 10:00 ` Gerd Hoffmann 2017-04-18 11:18 ` Pekka Paalanen 2017-04-18 11:18 ` Pekka Paalanen 2017-04-18 13:39 ` Gerd Hoffmann 2017-04-18 13:39 ` Gerd Hoffmann 2017-04-18 14:01 ` Pekka Paalanen 2017-04-18 14:01 ` Pekka Paalanen 2017-04-18 20:50 ` Gerd Hoffmann [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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.