On Tue, 1 Dec 2009, Hans Verkuil wrote:

> On Monday 30 November 2009 14:49:07 Guennadi Liakhovetski wrote:
> >
> > Right, how about this:
> >
> > /*
> >  * These pixel codes uniquely identify data formats on the media bus.
> > Mostly * they correspond to similarly named V4L2_PIX_FMT_* formats, format
> > 0 is * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs,
> > where the * data format is fixed. Additionally, "2X8" means that one pixel
> > is transferred * in two 8-bit samples, "BE" or "LE" specify in which order
> > those samples are * transferred over the bus: "LE" means that the least
> > significant bits are * transferred first, "BE" means that the most
> > significant bits are transferred * first, and "PADHI" and "PADLO" define
> > which bits - low or high, in the * incomplete high byte, are filled with
> > padding bits.
> >  */
> > enum v4l2_mbus_pixelcode {
> >     V4L2_MBUS_FMT_FIXED = 1,
> >     V4L2_MBUS_FMT_YUYV_2X8_LE,
> >     V4L2_MBUS_FMT_YVYU_2X8_LE,
> >     V4L2_MBUS_FMT_UYVY_2X8_LE,
> >     V4L2_MBUS_FMT_VYUY_2X8_LE,
> 
> These possibly may need a comment saying that each Y/U/V sample is 8 bits 
> wide. I'm not sure how far we want to go with systematic naming schemes here. 
> Adding a short comment if there is a possible ambiguity is probably 
> sufficient.

Is there an ambiguity? Aren't these formats standardised? Do we then have 
to explain what rgb555 means etc?

> >     V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
> >     V4L2_MBUS_FMT_RGB555X_2X8_PADHI_LE,
> 
> Shouldn't this be: V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE? Since the 555X format 
> is 
> just the big-endian variant of the RGB555 if I am not mistaken.

No, don't think so. As an RGB555X format it is sent in LE order, if you 
send RGB555X in BE order you get RGB555 (without an "X"). In fact, you'll 
never have a RGB555X_BE format, because, that's just the RGB555_LE. So, 
you may only have BE variants for formats, whoch byte-swapped variants do 
not have an own name.

> >     V4L2_MBUS_FMT_RGB565_2X8_LE,
> >     V4L2_MBUS_FMT_RGB565X_2X8_LE,
> 
> Ditto.
> 
> >     V4L2_MBUS_FMT_SBGGR8_1X8,
> >     V4L2_MBUS_FMT_SBGGR10_1X10,
> >     V4L2_MBUS_FMT_GREY_1X8,
> 
> This is also 8 bits per sample, right? This might be renamed to GREY8_1X8.

I named it after V4L2_PIX_FMT_GREY. If we ever get GREY7 or similar, I 
think, we anyway will need a new fourcc code for it, then we'll call the 
MBUS_FMT similarly.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to