DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 50BACC04B31E
Message-ID: <1492898365.25675.77.camel@redhat.com>
Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in
 line with reality.
From: Gerd Hoffmann <kraxel@redhat.com>
To: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Cc: Christian =?ISO-8859-1?Q?K=F6nig?= <christian.koenig@amd.com>,
        Jani Nikula <jani.nikula@linux.intel.com>,
        David Airlie <airlied@linux.ie>,
        Michel =?ISO-8859-1?Q?D=E4nzer?= <michel@daenzer.net>,
        open list <linux-kernel@vger.kernel.org>,
        dri-devel@lists.freedesktop.org, Pekka Paalanen <ppaalanen@gmail.com>,
        Sean Paul <seanpaul@chromium.org>, amd-gfx@lists.freedesktop.org,
        Alex Deucher <alexdeucher@gmail.com>,
        Daniel Vetter <daniel.vetter@intel.com>,
        Ilia Mirkin <imirkin@alum.mit.edu>
Date: Sat, 22 Apr 2017 23:59:25 +0200
In-Reply-To: <20170422100522.GS30290@intel.com>
References: <20170421075825.6307-1-kraxel@redhat.com>
         <20170421092530.GE30290@intel.com> <1492768218.25675.33.camel@redhat.com>
         <20170421110804.GH30290@intel.com>
         <f1b0ae60-b20e-ad52-7fbf-32f2c045f5fc@amd.com>
         <1492780323.25675.45.camel@redhat.com>
         <1492791271.25675.57.camel@redhat.com> <20170422100522.GS30290@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1907
Lines: 54

  Hi,

> > I guess that makes changing drm_mode_legacy_fb_format + drivers a
> > reasonable option ...
> 
> Yeah, I came to the same conclusion after chatting with some
> folks on irc.
> 
> So my current idea is that we change any driver that wants to follow the
> CPU endianness to declare support for big endian formats if the CPU is
> big endian. Presumably these are mostly the virtual GPU drivers.

Agree.  Easy.

> Additonally we'll make the mapping performed by drm_mode_legacy_fb_format()
> driver controlled.

I don't think this is useful.  IMO drm_mode_legacy_fb_format should
return host endian formats unconditionally.

> That way drivers that got changed to follow CPU
> endianness can return a framebuffer that matches CPU endianness. And
> drivers that expect the GPU endianness to not depend on the CPU
> endianness will keep working as they do now. The downside is that users
> of the legacy addfb ioctl will need to magically know which endianness
> they will get, but that is apparently already the case.

Existing userspace expects host endian, and IMO we should maintain that
behavior.

> And users of
> addfb2 will keep on specifying the endianness explicitly with
> DRM_FORMAT_BIG_ENDIAN vs. 0.

I'd drop DRM_FORMAT_BIG_ENDIAN.

At least for the virt drivers it doesn't buy us anything.  They support
32bpp / 8 bpc formats only[1], and for those I can specify the
byteswapped format version without a bigendian flag because we have
fourccs for everything we need.


There is a WIP patch series at
https://www.kraxel.org/cgit/linux/log/?h=drm-byteorder

Needs more testing and better commit messages.  /me plans to polish &
post next week, but feel free to look and comment.

cheers,
  Gerd

[1] Everything else is a PITA to deal with on the host side because
    I can't offload that to pixman.  There is no support for
    PIXMAN_r5g6b5 or PIXMAN_x2b10g10r10 in non-host byte order.