Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756702AbdDROBs (ORCPT ); Tue, 18 Apr 2017 10:01:48 -0400 Received: from mail-lf0-f41.google.com ([209.85.215.41]:34721 "EHLO mail-lf0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756309AbdDROBp (ORCPT ); Tue, 18 Apr 2017 10:01:45 -0400 Date: Tue, 18 Apr 2017 17:01:34 +0300 From: Pekka Paalanen To: Gerd Hoffmann Cc: dri-devel@lists.freedesktop.org, open list , amd-gfx@lists.freedesktop.org, Daniel Vetter , Ilia Mirkin Subject: Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Message-ID: <20170418170134.0a60d340@eldfell> In-Reply-To: <1492522793.27392.55.camel@redhat.com> References: <20170410101202.19229-1-kraxel@redhat.com> <20170410161214.305f5daf@eldfell> <1491833847.30990.77.camel@redhat.com> <20170410180941.43922e25@eldfell> <1492509617.27392.19.camel@redhat.com> <20170418141827.11634103@eldfell> <1492522793.27392.55.camel@redhat.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/UaswdG81tB=TtNOlZHYMFWS"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3350 Lines: 89 --Sig_/UaswdG81tB=TtNOlZHYMFWS Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 18 Apr 2017 15:39:53 +0200 Gerd Hoffmann wrote: > Hi, >=20 > > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > > here, it drives the qemu stdvga with offb, not bochs-drm. =20 > >=20 > > 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... =20 >=20 > 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. > > >=20 > > > Most recent: Fedora 25 (gnome 3.22) looks mostly ok, but there are > > > rendering glitches, for example in the gnome activities screen (the o= ne > > > 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) f= or > > > compositing. =20 > >=20 > > 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). =20 >=20 > 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. >=20 > 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 --Sig_/UaswdG81tB=TtNOlZHYMFWS Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlj2HD4ACgkQI1/ltBGq qqeAMQ//QC6YNcMihtNrPooWZqGsAhMeO3AxXC3RXZtAsgwKfvBrxzI2Rx8Y5o3B CP3gWiCC7P5aOaBL9Xd9QspuYF7iLSlcbIH01FMjm2HmTQOkqf6I9eZ/AGsy4Csn RrnQ2nPPa8mvAcyejSARUsg/v6b2XbzzBGVLali7JkA3P0eT2crDsg1x0DxusY8g FNRyuNwqSZyyTUNC3vZO4EXF2Z6Zw33hFeVJClSelfCiSk4sp9sXyLY86tWfGALx FXI6/3d4rcXcSYUpsjZXua39q2vi41PIWmFsfLQM29TozCF8fpH/1clYlgtvFlnV uW5SRMqSOZr7zGJXvx6HqwwiJknbtJPFtg1GPX5SbjpvBG9PfKyrhB5TMK8NPuTr +lKcMNhihCfmHTJ3AmRvT12IMbi2AaF5s93tnoMOhucY6Bj7g9/qWm3azBpQ23Xa FoVcmFNhPj/CG2zKoVgXikDWQvKnD0DzOmgf+L++YfOJ9odAA7HznI/HyZAqLJAX 3NoX9azD2zb99wfboe8LfrlcK8KkrX0UUD4bcpeFMyo+ax5KGEknx4nonbqTKdl2 oVs2HRwPk7b3kBZxMt6laQhAuaeKssGg094dXJFTOrBDVMi28amX6pXkQ337Env8 4dGHE2e6xug20r4OgY9Tylzl0dXZW5Xj+8JK7sZT9ukkln2V/P8= =fpfx -----END PGP SIGNATURE----- --Sig_/UaswdG81tB=TtNOlZHYMFWS--