Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753225AbdDJQ0W (ORCPT ); Mon, 10 Apr 2017 12:26:22 -0400 Received: from mail-yb0-f196.google.com ([209.85.213.196]:36359 "EHLO mail-yb0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753160AbdDJQ0T (ORCPT ); Mon, 10 Apr 2017 12:26:19 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170410101202.19229-1-kraxel@redhat.com> <20170410161214.305f5daf@eldfell> <1491833847.30990.77.camel@redhat.com> From: Alex Deucher Date: Mon, 10 Apr 2017 12:26:18 -0400 Message-ID: Subject: Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality. To: Ilia Mirkin Cc: Gerd Hoffmann , "dri-devel@lists.freedesktop.org" , Daniel Vetter , Pekka Paalanen , open list , amd-gfx list Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1878 Lines: 44 On Mon, Apr 10, 2017 at 10:45 AM, Ilia Mirkin wrote: > On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann wrote: >> Hi, >> >>> which software have you used as representative of "reality"? >> >> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm >> driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB8888 (one and >> only format supported by bochs-drm), and we have to interpret that in >> bigendian byte order on the host side to get a correct display. >> >> Didn't try wayland. Can do, but will take a while. Don't have a >> wayland-capable guest install at hand, and installing one takes a while >> because I don't have a physical pseries and emulation is slooooww. >> >>> To solve that problem, we would like to know if anything existing would >>> break for each possible solution, but no developers using BE have really >>> turned up. >> >> That is part of the problem. >> And even ppc is moving to little endian these days ... > > The poor saps who are still using PPC G4's and G5's with NVIDIA and > ATI boards constantly get their working setups broken by people trying > to "fix" BE. I think it's important to keep them in mind, and test > those setups, whenever one tries to make a large sweeping change. I think part of the problem is that the higher levels of the stack have different expectations than the kernel does. Mesa breaks every time someone fixes something endian related. Most userspace stuff assumes host endianness. Someone that has the hw and cares about BE should really audit the stack top to bottom and make sure all the expectations are met for each level. I doubt anyone will. Alex > > Cheers, > > -ilia > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx