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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2697 bytes --]

On Tue, 15 Nov 2011 22:30:36 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> 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@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.

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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel