Re: [PATCH 2/2] drm: Redefine pixel formats

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Nov 17, 2011 at 03:00:17PM +0100, Michel Dänzer wrote:
> On Don, 2011-11-17 at 15:06 +0200, Ville Syrjälä wrote: 
> > On Thu, Nov 17, 2011 at 08:52:05AM +0100, Michel Dänzer wrote:
> > > On Mit, 2011-11-16 at 20:42 +0200, ville.syrjala@linux.intel.com wrote: 
> > > > 
> > > > Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
> > > > names, especially for the RGB formats. Component order and byte order are
> > > > now strictly specified for each format.
> > > > 
> > > > The RGB format naming follows a convention where the components names
> > > > and sizes are listed from left to right, matching the order within a
> > > > single pixel from most significant bit to least significant bit. Lower
> > > > case letters are used when listing the components to improve
> > > > readablility. I believe this convention matches the one used by pixman.
> > > 
> > > 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 but
> > > 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älä
Intel OTC