Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

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

On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) << 8) | \
> +			      ((u32)(c) << 16) | ((u32)(d) << 24))
> +
> +/* RGB codes */
> +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
> +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
> +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
> +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
> +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
> +
> +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
> +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')

I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
formats, so why do we need the RGB/BGR32 variants? If the difference
is in the alpha channel, I'd like to document that fact in the name.

Could we call them ARGB8888, XRGB8888, XRGB1555 etc.?

Also the channel and byte order should be documented clearly.

And one other thing. I probably wouldn't call these fourccs
since they don't actually match the official fourccs. Not that
there is anything sensible defined for RGB formats in the
official list anyway. In fact, I'm not sure what we gain by
cooking our own fourccs when we know most of them won't match
the official list. AFAICS a simple running number would do
just as well as the format identifier.

-- 
Ville Syrjälä
Intel OTC