From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 2/2] drm: Redefine pixel formats Date: Thu, 17 Nov 2011 16:40:23 +0200 Message-ID: <20111117144023.GU3477@intel.com> References: <1321468945-28224-1-git-send-email-ville.syrjala@linux.intel.com> <1321468945-28224-3-git-send-email-ville.syrjala@linux.intel.com> <1321516325.3794.60.camel@thor.local> <20111117130658.GT3477@intel.com> <1321538417.3794.104.camel@thor.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 67E459E902 for ; Thu, 17 Nov 2011 06:38:00 -0800 (PST) Content-Disposition: inline In-Reply-To: <1321538417.3794.104.camel@thor.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Thu, Nov 17, 2011 at 03:00:17PM +0100, Michel D=E4nzer wrote: > On Don, 2011-11-17 at 15:06 +0200, Ville Syrj=E4l=E4 wrote: = > > On Thu, Nov 17, 2011 at 08:52:05AM +0100, Michel D=E4nzer wrote: > > > On Mit, 2011-11-16 at 20:42 +0200, ville.syrjala@linux.intel.com wrot= e: = > > > > = > > > > Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consi= stent > > > > names, especially for the RGB formats. Component order and byte ord= er are > > > > now strictly specified for each format. > > > > = > > > > The RGB format naming follows a convention where the components nam= es > > > > and sizes are listed from left to right, matching the order within a > > > > single pixel from most significant bit to least significant bit. Lo= wer > > > > case letters are used when listing the components to improve > > > > readablility. I believe this convention matches the one used by pix= man. > > > = > > > The RGB formats are all defined in the CPU native byte order. But e.g. > > > pre-R600 Radeons can only scan out little endian formats. For the > > > framebuffer device, we use GPU byte swapping facilities to make the > > > pixels appear to the CPU in its native byte order, so these format > > > definitions make sense for that. But I'm not sure they make sense for > > > the KMS APIs, e.g. the userspace drivers don't use these facilities b= ut > > > handle byte swapping themselves. > > = > > Hmm. So who decides whether GPU byte swapping is needed when you eg. > > mmap() some buffer? > = > The userspace drivers. Hmm. OK. So I guess we should define the formats as little endian then. Supposing we also need big endian formats in the future, we could just define an extra flag like so: #define DRM_FORMAT_BIG_ENDIAN (1<<31) which would be ORed with the fourcc to get a big endian version of the format. Otherwise we have to duplicate the formats for big endian as well. -- = Ville Syrj=E4l=E4 Intel OTC