On Tue, 15 Nov 2011 22:30:36 +0200 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > 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. Heh, well you can just pick whatever makes sense then for RGB, and remove the _FOURCC_ strings to make it clear we're using sane RGB definitions and not some half-specified fourcc stuff. Thanks, -- Jesse Barnes, Intel Open Source Technology Center
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
