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 Tue, Nov 15, 2011 at 08:16:04AM -0800, Jesse Barnes wrote:
> On Tue, 15 Nov 2011 14:57:02 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > I'm fine with fourccs as long as the defines are named and documented
> > in way that avoids guesswork.
> > 
> > So what I'm thinking is something like this:
> > 
> > DRM_FOURCC_RGB332      ... /* [7:0] R:G:B 3:3:2 */
> > DRM_FOURCC_XRGB1555    ... /* [15:0] x:R:G:B 1:5:5:5, native endian */
> > DRM_FOURCC_RGB565      ... /* [15:0] R:G:B 5:6:5, native endian */
> > DRM_FOURCC_XRGB8888    ... /* [31:0] x:R:G:B 8:8:8:8, native endian */
> > DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */
> > 
> > DRM_FOURCC_RGB888      ... /* [23:0] R:G:B 8:8:8, little endian */
> > DRM_FOURCC_BGR888      ... /* [23:0] B:G:R 8:8:8, little endian */
> > 
> > DRM_FOURCC_YUYV        ... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
> > DRM_FOURCC_UYVY        ... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
> > DRM_FOURCC_YVYU        ... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
> > DRM_FOURCC_VYUY        ... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
> > 
> > That leaves no room for guesswork.
> 
> Looks great.  Want to send Dave an incremental patch?  I'll apply the
> final version to libdrm for use by userland code.

What I listed there doesn't match what v4l2 has. So I'm not sure what
to put in a patch.

It looks like the v4l2 fourccs have explicit endianness (ie. LE or BE).
If we follow that, and assuming people still want to use hardware byte
swappers, it means user space needs some ifdefs to select the approriate
format based on the host endianness. Or, we could do that in the header
file itself, so we would provide three definitions for each format LE,
BE, and NE (which would point to LE or BE depending on host endianness).

One extra issue I just realized is that the 8bpp and 16bpp v4l2 formats
are in fact BGR nor RGB, that is the component order is such that blue
occupies the most significant bit, red the lsb. I've never even seen
a PC graphics card that supports such formats. Adding insult to injury
PIX_FMT_RGB444 is defined the opposite way, ie. matching what most
graphics cards would expect.

-- 
Ville Syrjälä
Intel OTC