From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Date: Sat, 22 Apr 2017 13:05:22 +0300 Message-ID: <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> <1492780323.25675.45.camel@redhat.com> <1492791271.25675.57.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <1492791271.25675.57.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: Gerd Hoffmann Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, David Airlie , Michel =?iso-8859-1?Q?D=E4nzer?= , open list , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Pekka Paalanen , Sean Paul , Jani Nikula , Alex Deucher , Daniel Vetter , Christian =?iso-8859-1?Q?K=F6nig?= , Ilia Mirkin T24gRnJpLCBBcHIgMjEsIDIwMTcgYXQgMDY6MTQ6MzFQTSArMDIwMCwgR2VyZCBIb2ZmbWFubiB3 cm90ZToKPiAgIEhpLAo+IAo+ID4gPiBNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgZm9ybWF0 cyBpbiBkcm1fZm91cmNjLmggc2hvdWxkIGJlIAo+ID4gPiBpbmRlcGVuZGVudCBvZiB0aGUgQ1BV IGJ5dGUgb3JkZXIgYW5kIHRoZSBmdW5jdGlvbiAKPiA+ID4gZHJtX21vZGVfbGVnYWN5X2ZiX2Zv cm1hdCgpIGFuZCBkcml2ZXJzIGRlcGVuZGluZyBvbiB0aGF0IGluY29ycmVjdCAKPiA+ID4gYXNz dW1wdGlvbiBiZSBmaXhlZCBpbnN0ZWFkLgo+ID4gCj4gPiBUaGUgcHJvYmxlbSBpcyB0aGlzIGlz bid0IGEga2VybmVsLWludGVybmFsIHRoaW5nIGFueSBtb3JlLiAgV2l0aCB0aGUKPiA+IGFkZGl0 aW9uIG9mIHRoZSBBRERGQjIgaW9jdGwgdGhlIGZvdXJjYyBjb2RlcyBiZWNhbWUgcGFydCBvZiB0 aGUKPiA+IGtlcm5lbC91c2Vyc3BhY2UgYWJpIC4uLgo+IAo+IE9rLCBhZGRlZCBzb21lIHByaW50 aydzIHRvIHRoZSBBRERGQiBhbmQgQURERkIyIGNvZGUgcGF0aHMgYW5kIHRlc3RlZCBhCj4gYml0 LiAgQXBwYXJlbnRseSBwcmV0dHkgbXVjaCBhbGwgdXNlcnNwYWNlIHN0aWxsIHVzZXMgdGhlIEFE REZCIGlvY3RsLgo+IHhvcmcgKG1vZGVzZXR0aW5nIGRyaXZlcikgZG9lcy4gIGdub21lLXNoZWxs IGluIHdheWxhbmQgbW9kZSBkb2VzLgo+IFNlZW1zIHRoZSBiaWcgdHJhbnNpdGlvbiB0byBBRERG QjIgZGlkbid0IGhhcHBlbiB5ZXQuCj4gCj4gSSBndWVzcyB0aGF0IG1ha2VzIGNoYW5naW5nIGRy bV9tb2RlX2xlZ2FjeV9mYl9mb3JtYXQgKyBkcml2ZXJzIGEKPiByZWFzb25hYmxlIG9wdGlvbiAu Li4KClllYWgsIEkgY2FtZSB0byB0aGUgc2FtZSBjb25jbHVzaW9uIGFmdGVyIGNoYXR0aW5nIHdp dGggc29tZQpmb2xrcyBvbiBpcmMuCgpTbyBteSBjdXJyZW50IGlkZWEgaXMgdGhhdCB3ZSBjaGFu Z2UgYW55IGRyaXZlciB0aGF0IHdhbnRzIHRvIGZvbGxvdyB0aGUKQ1BVIGVuZGlhbm5lc3MgdG8g ZGVjbGFyZSBzdXBwb3J0IGZvciBiaWcgZW5kaWFuIGZvcm1hdHMgaWYgdGhlIENQVSBpcwpiaWcg ZW5kaWFuLiBQcmVzdW1hYmx5IHRoZXNlIGFyZSBtb3N0bHkgdGhlIHZpcnR1YWwgR1BVIGRyaXZl cnMuCgpBZGRpdG9uYWxseSB3ZSdsbCBtYWtlIHRoZSBtYXBwaW5nIHBlcmZvcm1lZCBieSBkcm1f bW9kZV9sZWdhY3lfZmJfZm9ybWF0KCkKZHJpdmVyIGNvbnRyb2xsZWQuIFRoYXQgd2F5IGRyaXZl cnMgdGhhdCBnb3QgY2hhbmdlZCB0byBmb2xsb3cgQ1BVCmVuZGlhbm5lc3MgY2FuIHJldHVybiBh IGZyYW1lYnVmZmVyIHRoYXQgbWF0Y2hlcyBDUFUgZW5kaWFubmVzcy4gQW5kCmRyaXZlcnMgdGhh dCBleHBlY3QgdGhlIEdQVSBlbmRpYW5uZXNzIHRvIG5vdCBkZXBlbmQgb24gdGhlIENQVQplbmRp YW5uZXNzIHdpbGwga2VlcCB3b3JraW5nIGFzIHRoZXkgZG8gbm93LiBUaGUgZG93bnNpZGUgaXMg dGhhdCB1c2VycwpvZiB0aGUgbGVnYWN5IGFkZGZiIGlvY3RsIHdpbGwgbmVlZCB0byBtYWdpY2Fs bHkga25vdyB3aGljaCBlbmRpYW5uZXNzCnRoZXkgd2lsbCBnZXQsIGJ1dCB0aGF0IGlzIGFwcGFy ZW50bHkgYWxyZWFkeSB0aGUgY2FzZS4gQW5kIHVzZXJzIG9mCmFkZGZiMiB3aWxsIGtlZXAgb24g c3BlY2lmeWluZyB0aGUgZW5kaWFubmVzcyBleHBsaWNpdGx5IHdpdGgKRFJNX0ZPUk1BVF9CSUdf RU5ESUFOIHZzLiAwLgoKRG9lcyB0aGF0IHNvdW5kIGxpa2UgYSB3b3JrYWJsZSBzb2x1dGlvbj8K Ci0tIApWaWxsZSBTeXJqw6Rsw6QKSW50ZWwgT1RDCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCmFtZC1nZnggbWFpbGluZyBsaXN0CmFtZC1nZnhAbGlzdHMu ZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlz dGluZm8vYW1kLWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422830AbdDVKFe (ORCPT ); Sat, 22 Apr 2017 06:05:34 -0400 Received: from mga06.intel.com ([134.134.136.31]:17413 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1043781AbdDVKFc (ORCPT ); Sat, 22 Apr 2017 06:05:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,233,1488873600"; d="scan'208";a="77540697" Date: Sat, 22 Apr 2017 13:05:22 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Gerd Hoffmann Cc: Christian =?iso-8859-1?Q?K=F6nig?= , Jani Nikula , David Airlie , Michel =?iso-8859-1?Q?D=E4nzer?= , open list , dri-devel@lists.freedesktop.org, Pekka Paalanen , Sean Paul , amd-gfx@lists.freedesktop.org, Alex Deucher , Daniel Vetter , Ilia Mirkin Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Message-ID: <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> <1492780323.25675.45.camel@redhat.com> <1492791271.25675.57.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1492791271.25675.57.camel@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote: > Hi, > > > > My personal opinion is that formats in drm_fourcc.h should be > > > independent of the CPU byte order and the function > > > drm_mode_legacy_fb_format() and drivers depending on that incorrect > > > assumption be fixed instead. > > > > The problem is this isn't a kernel-internal thing any more. With the > > addition of the ADDFB2 ioctl the fourcc codes became part of the > > kernel/userspace abi ... > > Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a > bit. Apparently pretty much all userspace still uses the ADDFB ioctl. > xorg (modesetting driver) does. gnome-shell in wayland mode does. > Seems the big transition to ADDFB2 didn't happen yet. > > 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. Additonally we'll make the mapping performed by drm_mode_legacy_fb_format() driver controlled. 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. And users of addfb2 will keep on specifying the endianness explicitly with DRM_FORMAT_BIG_ENDIAN vs. 0. Does that sound like a workable solution? -- Ville Syrjälä Intel OTC