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@xxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel