On Tuesday 01 December 2009 16:22:55 Guennadi Liakhovetski wrote:
> 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?
HDMI receivers/transmitters can do YUV with 8, 10 or 12 bits. So when you say
YUYV_2X8_LE do you mean that 10 bits are transported over two bytes, or that
a Y and a U (or V) are transferred one after another? From the absence of a
PADHI or PADLO I can infer that it is the latter, but it is not exactly
obvious.
Actually, why not name these formats YUYV8, etc. and the order of the bytes
going over the bus is just the order of the text 'YUYV'. There is not really
any big or little endian issues since you just need to know the sequence of
Ys, Us and Vs.
> 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.
RGB 5:5:5 consists of 16 bits arrrrrgg gggbbbbb ('a' is either padding or an
alpha bit).
RGB 5:5:5 over an 8 bit data bus is either with the MSB byte first (big endian
aka RGB555X aka RGB555_2X8_PADHI_BE) or with the LSB byte first (little endian
aka RGB555 aka RGB555_2X8_PADHI_LE).
The use of RGB555X in the pixel formats is a really ugly accident of history.
'RGB555' is the name of the format, and _LE or _BE should define what the
order of the LSB and MSB over the data bus is.
>
> > > 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.
Why not do it right from the start? Frankly, the PIX_FMT names aren't that
great. And since this will become a public API in the future I think it is
reasonable to spend some time on it (and it is the reason why I'm so picky
about it :-) ).
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
