From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Date: Wed, 19 Apr 2017 14:34:49 +0200 Message-ID: <1492605289.6853.32.camel@redhat.com> References: <20170410101202.19229-1-kraxel@redhat.com> <20170410161214.305f5daf@eldfell> <1491833847.30990.77.camel@redhat.com> <20170410180941.43922e25@eldfell> <20170411103101.0497fe08@eldfell> <1492510440.27392.27.camel@redhat.com> <4230c093-6a8a-76d6-dce8-f9b2300fa70f@daenzer.net> <20170419100956.78e4a7ab@eldfell> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170419100956.78e4a7ab@eldfell> 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: Pekka Paalanen Cc: Daniel Vetter , Michel =?ISO-8859-1?Q?D=E4nzer?= , "dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org" , amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, open list ICBIaSwKCj4gPiA+PiBCVFcsIHRoaXMgc3VwcG9ydHMgR2VyZCdzIHBhdGNoLCBzaW5jZSB0aGUg S01TIGZiZGV2IGVtdWxhdGlvbiBjb2RlIHVzZXMKPiA+ID4+IGUuZy4gRFJNX0ZPUk1BVF9YUkdC ODg4OCBmb3IgZGVwdGgvYnBwIDI0LzMyLCBhbmQgdGhlIGZiZGV2IEFQSSB1c2VzCj4gPiA+PiBu YXRpdmUgZW5kaWFuIHBhY2tlZCBjb2xvdXIgdmFsdWVzLiAgCj4gPiA+IAo+ID4gPiBTYW1lIGlz IHRydWUgZm9yIERSTV9JT0NUTF9NT0RFX0FEREZCLCB3aXRoIGRlcHRoL2JwcCAyNC8zMiB5b3Un bGwgZ2V0Cj4gPiA+IERSTV9GT1JNQVRfWFJHQjg4ODggKG9ubHkgRFJNX0lPQ1RMX01PREVfQURE RkIyIGFsbG93cyB1c2Vyc3BhY2Ugc3BlY2lmeQo+ID4gPiBmb3VyY2MgZm9ybWF0cyBkaXJlY3Rs eSkuICAKPiA+IAo+ID4gUmlnaHQsIGFuZCBzaW5jZSBhbGwgbWFqb3IgWG9yZyBkcml2ZXJzIHVz ZSBEUk1fSU9DVExfTU9ERV9BRERGQiwKPiA+IHRoZXkncmUgZWZmZWN0aXZlbHkgdXNpbmcgRFJN X0ZPUk1BVF9YUkdCODg4OCBhcyBuYXRpdmUgZW5kaWFubmVzcyBhcyB3ZWxsLgo+IAo+IEkgc2lu Y2VyZWx5IGhvcGUgdGhpcyBkb2Vzbid0IGFjdHVhbGx5IGZvcmNlIHVzIGludG8gYSBwbGFjZSB3 aGVyZSB3ZQo+IGhhdmUgWFJHQjg4ODggKGFuZCBBUkdCODg4OD8pIGFzIG5hdGl2ZS1lbmRpYW4s IGJ1dCB0aGUgb3RoZXIgZm9ybWF0Cj4gY29kZXMgLSBzaW5jZSBiZWluZyB1c2VkIGV4cGxpY2l0 bHkgLSBtdXN0IGJlIGtlcHQgYXMgbGl0dGxlLWVuZGlhbgo+IGJlY2F1c2UgdGhleSB3ZXJlIHVz ZWQgbGlrZSB0aGF0IGhvbm91cmluZyB0aGUgZG9jdW1lbnRhdGlvbiB3ZSBoYXZlCj4gYXRtLgoK TXkgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGUgb3RoZXIgZm9ybWF0cyBhcmUgKGFsbW9zdCkgdW51 c2VkIGluCnByYWN0aWNlLiAgY2Fpcm8gZm9yIGV4YW1wbGUgc3VwcG9ydHMgWFJHQjg4ODggKyBB UkdCODg4OCAobmF0aXZlCmVuZGlhbikgb25seSBmcm9tIGFsbCBkZXB0aC9icHAgMjQvMzIgZm9y bWF0cy4KCklJUkMgdGhlcmUgd2FzIGEgYnJpZWYgZGlzY3Vzc2lvbiBob3cgd2Ugc2hvdWxkIGhh bmRsZSBlbmRpYW5uZXNzIGluCnFlbXUgc3RkdmdhIC8gYm9jaHNkcm0ua28gYmVmb3JlIHdlJ3Zl IGFkZGVkIHRoZSBuZXcgKHZpcnR1YWwpIGhhcmR3YXJlCnJlZ2lzdGVyIHRvIHN3aXRjaCBlbmRp YW5uZXNzLiAgVGhlIGlkZWEgdG8gc2ltcGx5IHJ1biB3aXRoIGZpeGVkCmVuZGlhbm5lc3MgKGZy YW1lYnVmZmVyIGlzIGFsd2F5cyBsaXR0bGUgZW5kaWFuKSB3YXMgc2hvdCBkb3duIHF1aWNrbHkK d2l0aCB0aGUgYXJndW1lbnQgdGhhdCB0aGlzIGlzbid0IGdvaW5nIHRvIGZseSBkdWUgdG8gbGFj ayBvZiBzdXBwb3J0CmZvciBYUkdCODg4OCBpbiBub24tbmF0aXZlIGJ5dGUgb3JkZXIgaW4gdGhl IHdob2xlIGdyYXBoaWNzIHN0YWNrLgoKPiBJdCdzIHN0YXJ0aW5nIHRvIHJlc2VtYmxlIHRoZSB3 bF9zaG0gZm9ybWF0IGNvZGVzIHByb2JsZW0gd2UgaGF2ZQo+IG9uIFdheWxhbmQgZm9yIEJFLgo+ IAo+IEhhcyB0aGlzIG5vdyB0dXJuZWQgaW50byBhIHF1ZXN0aW9uIG9mIHdoYXQgdGhlIGtlcm5l bCBkcml2ZXJzIGRvCj4gd2l0aCB0aGUgRFJNIHBpeGVsIGZvcm1hdCBjb2Rlcz8KPiAKPiBIbW0s IEkgc3VwcG9zZSB0aGF0IGhhcyBiZWVuIHRoZSBxdWVzdGlvbiBhbGwgYWxvbmcuLi4KClllcCwg YmFzaWNhbGx5LiAgSSBoYXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgZHJpdmVycyBhcmUgZWl0aGVy IGNvbnNpZGVyCnRob3NlIGZvcm1hdHMgYmVpbmcgbmF0aXZlIGVuZGlhbiBvciBzaW1wbHkgZG9u J3QgY2FyZSBiZWNhdXNlIHRoZXkgYXJlCm5ldmVyIHVzZWQgaW4gc3lzdGVtcyB3aXRoIGJpZ2Vu ZGlhbiAoLWNhcGFibGUpIGNwdXMuCgpBbnlvbmUgYXdhcmUgb2YgYW55dGhpbmcgZWxzZT8KCkd1 ZXNzIEknbGwgZ28gcHJlcGFyZSBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBwYXRjaCwgZGVjbGFyaW5n IGFsbCByZ2IKZm9ybWF0cyBhcyBuYXRpdmUgZW5kaWFuIGFuZCBwdXR0aW5nIGEgYnVuY2ggb2Yg cG9pbnRzIGZyb20gdGhpcyB0aHJlYWQKaW50byB0aGUgY29tbWl0IG1lc3NhZ2UuCgpjaGVlcnMs CiAgR2VyZAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K YW1kLWdmeCBtYWlsaW5nIGxpc3QKYW1kLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6 Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763265AbdDSMe4 convert rfc822-to-8bit (ORCPT ); Wed, 19 Apr 2017 08:34:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39924 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762952AbdDSMew (ORCPT ); Wed, 19 Apr 2017 08:34:52 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1638A6330E Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1638A6330E Message-ID: <1492605289.6853.32.camel@redhat.com> Subject: Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality. From: Gerd Hoffmann To: Pekka Paalanen Cc: Michel =?ISO-8859-1?Q?D=E4nzer?= , Daniel Vetter , amd-gfx@lists.freedesktop.org, "dri-devel@lists.freedesktop.org" , open list Date: Wed, 19 Apr 2017 14:34:49 +0200 In-Reply-To: <20170419100956.78e4a7ab@eldfell> References: <20170410101202.19229-1-kraxel@redhat.com> <20170410161214.305f5daf@eldfell> <1491833847.30990.77.camel@redhat.com> <20170410180941.43922e25@eldfell> <20170411103101.0497fe08@eldfell> <1492510440.27392.27.camel@redhat.com> <4230c093-6a8a-76d6-dce8-f9b2300fa70f@daenzer.net> <20170419100956.78e4a7ab@eldfell> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 19 Apr 2017 12:34:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses > > >> e.g. DRM_FORMAT_XRGB8888 for depth/bpp 24/32, and the fbdev API uses > > >> native endian packed colour values. > > > > > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get > > > DRM_FORMAT_XRGB8888 (only DRM_IOCTL_MODE_ADDFB2 allows userspace specify > > > fourcc formats directly). > > > > Right, and since all major Xorg drivers use DRM_IOCTL_MODE_ADDFB, > > they're effectively using DRM_FORMAT_XRGB8888 as native endianness as well. > > I sincerely hope this doesn't actually force us into a place where we > have XRGB8888 (and ARGB8888?) as native-endian, but the other format > codes - since being used explicitly - must be kept as little-endian > because they were used like that honouring the documentation we have > atm. My expectation is that the other formats are (almost) unused in practice. cairo for example supports XRGB8888 + ARGB8888 (native endian) only from all depth/bpp 24/32 formats. IIRC there was a brief discussion how we should handle endianness in qemu stdvga / bochsdrm.ko before we've added the new (virtual) hardware register to switch endianness. The idea to simply run with fixed endianness (framebuffer is always little endian) was shot down quickly with the argument that this isn't going to fly due to lack of support for XRGB8888 in non-native byte order in the whole graphics stack. > It's starting to resemble the wl_shm format codes problem we have > on Wayland for BE. > > Has this now turned into a question of what the kernel drivers do > with the DRM pixel format codes? > > Hmm, I suppose that has been the question all along... Yep, basically. I have the impression that drivers are either consider those formats being native endian or simply don't care because they are never used in systems with bigendian (-capable) cpus. Anyone aware of anything else? Guess I'll go prepare a new version of the patch, declaring all rgb formats as native endian and putting a bunch of points from this thread into the commit message. cheers, Gerd