From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1036549AbdDUIGn (ORCPT ); Fri, 21 Apr 2017 04:06:43 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:34047 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1036514AbdDUIGW (ORCPT ); Fri, 21 Apr 2017 04:06:22 -0400 Date: Fri, 21 Apr 2017 11:06:05 +0300 From: Pekka Paalanen To: Gerd Hoffmann Cc: dri-devel@lists.freedesktop.org, Ville =?UTF-8?B?U3lyasOkbMOk?= , Daniel Vetter , Ilia Mirkin , Michel =?UTF-8?B?RMOkbnplcg==?= , Alex Deucher , amd-gfx@lists.freedesktop.org, Jani Nikula , Sean Paul , David Airlie , linux-kernel@vger.kernel.org (open list) Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Message-ID: <20170421110605.1a255f44@eldfell> In-Reply-To: <20170421075825.6307-1-kraxel@redhat.com> References: <20170421075825.6307-1-kraxel@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_/EPm_PO0l3PQr56drTIVeHE="; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/EPm_PO0l3PQr56drTIVeHE= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 21 Apr 2017 09:58:24 +0200 Gerd Hoffmann wrote: > While working on graphics support for virtual machines on ppc64 (which > exists in both little and big endian variants) I've figured the comments > for various drm fourcc formats in the header file don't match reality. >=20 > Comments says the RGB formats are little endian, but in practice they > are native endian. Look at the drm_mode_legacy_fb_format() helper. It > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB8888, no matter > whenever the machine is little endian or big endian. The users of this > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer > is native endian, not little endian. Most userspace also operates on > native endian only. >=20 > So, go update the comments for all 16+24+32 bpp RGB formats. >=20 > Leaving the yuv formats as-is. I have no idea if and how those are used > on bigendian machines. >=20 > Cc: Ville Syrj=C3=A4l=C3=A4 > Cc: Daniel Vetter > Cc: Pekka Paalanen > Cc: Ilia Mirkin > Cc: Michel D=C3=A4nzer > Cc: Alex Deucher > Cc: amd-gfx@lists.freedesktop.org > Signed-off-by: Gerd Hoffmann > --- > include/uapi/drm/drm_fourcc.h | 82 +++++++++++++++++++++----------------= ------ > 1 file changed, 41 insertions(+), 41 deletions(-) Hi, just an idea - since we are not sure how the remaining formats are being used, should those be marked somehow uncertain whether they are little or native endian? Otherwise the documentation will guide people to believe those are certain, which OTOH might not be bad, because then it will make them certain over time. Unless we would prefer everything to be native endian? This might be a chance to choose the endianess (native vs. little) for all formats. Should we take it? Prefer native? Thanks, pq --Sig_/EPm_PO0l3PQr56drTIVeHE= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlj5vW0ACgkQI1/ltBGq qqdIyQ/8C7Ah0I9Lztc9lxRl7XwzdjBQFNtlugyDS1HrI8ZCZdiQALGSO8GcnlJF VQh/7EnEf0zzz1R/u8Xfz/FBjglPi/E26IdPKEiQ802Mq2pQh/0XGmIrKLdPOzWC V53rHtY9V6Vk3kGZ6jjQKarVRmSW1PQYWa/r3cy9KQnrVdV2finCMthM38XzPdYe jr1uYJdjVLQC/WS7l7mboAECKF3w006GeIRjQRLQfaxNQutmTBBvrC2gNAJ1bxOj 7xl/Ukt8R4OGe9eAZjueothv+DehUY+es9qsV3/bzp4K1A01hkNUh0e9XtNb6/Dv fyFokcEa8ZCY40NduXKwggC1EI+ye8W765roUAZvw1lhBd8TEC4qwyRUIRkjD/Yu 01iFuj54Odq18pkfjqmIopLTD3DyoHM4O+Wd1Hue87/LoFny/uH3Arf8klR0eVZH 2a2X4dUrRFy/pggOzX1AcI7hiHa8OAAeaGM1hcPVcIYgye/DWqDNsxDt2st8D4Lb NziDEfxEVgeW0kHONKQyCF0twNAJ59QDDspTpKVpHrBjRDq+kgVDNFmKVvXx99tg AHfu6RxnaafS1iOrHESgjt2uHsa6oAJSrV0PKphFQ/bNDfXyUiQmGjtZEReFWPpO I1qjjvIbcayWluLKMOrWeo1UeoSvP+Dexh0tzsHPkLcQWUcpD0A= =uWeD -----END PGP SIGNATURE----- --Sig_/EPm_PO0l3PQr56drTIVeHE=--