Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Geert,

On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
> > On Monday 29 August 2011 10:13:07 Geert Uytterhoeven wrote:
> >> On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart wrote:
> > [snip]
> > 
> >> > +- FB_TYPE_PACKED_PIXELS
> >> > +
> >> > +Color components (usually RGB or YUV) are packed together into
> >> > macropixels +that are stored in a single plane. The exact color
> >> > components layout is +described in a visual-dependent way.
> >> > +
> >> > +Frame buffer visuals that don't use multiple color components per
> >> > pixel +(such as monochrome and pseudo-color visuals) are reported as
> >> > packed frame +buffer types, even though they don't stricly speaking
> >> > pack color components +into macropixels.
> >> 
> >> That's because the "packing" is not about the color components, but
> >> about the bits that represent a single pixel.
> >> 
> >> I.e. the bits that make up the pixel (the macropixel) are stored next
> >> to each other
> >> in memory.
> > 
> > OK, I've modified that last sentence to read
> > 
> > "Frame buffer visuals that don't use multiple color components per pixel
> > (such as monochrome and pseudo-color visuals) are also reported as
> > packed frame buffer types, as the bits that make up individual pixels
> > are packed next to each other in memory."
> 
> Still not correct, as you don't grasp the concept of e.g. bitplanes
> yet (see below).
> The visual doesn't have anything to do with how the macropixels are stored
> in memory.
> 
> >> > +- FB_TYPE_PLANES
> >> > +
> >> > +Color components are stored in separate planes. Planes are located
> >> > +contiguously in memory.
> >> 
> >> The bits that make up a pixel are stored in separate planes. Planes are
> >> located contiguously in memory.
> > 
> > I'm not sure to agree with this. You make it sounds like FB_TYPE_PLANES
> > stores each bit in a different plane. Is that really the case ?
> 
> Yes.
>
> First you store all "first" (fbdev does lack a way to specify little
> or big endian here)
> bits of each pixel in memory, contiguously. Then the second bit of
> each pixel, and so on.
> 
> For 8 pixels (A - H) with 4 bits per pixel (0 - 3) (i.e. the first pixel is
> [A0 A1 A2 A3]), that would be like:
> 
> A0 B0 C0 D0 E0 F0 G0 H0 A1 B1 C1 D1 E1 F1 G1 H1 A2 B2 C2 D2 E2 F2 G2 H2
> A3 B3 C3 D3 E3 F3 G3 H3
> 
> http://en.wikipedia.org/wiki/Bit_plane
> http://en.wikipedia.org/wiki/Planar_(computer_graphics)
> http://en.wikipedia.org/wiki/Color_depth

Thank you. That's clearer now. Planar formats in V4L2 are different, hence my 
initial confusion.

If my understanding is now correct, a V4L2 planar YUV type where Y, U and V 
components are stored in separate byte-oriented planes, with each plane 
storing Y, U or V components packed (such as http://linuxtv.org/downloads/v4l-
dvb-apis/V4L2-PIX-FMT-YUV422P.html), would be of neither FB_TYPE_PLANES nor 
FB_TYPE_PACKED. The same would be true for an RGB format where each component 
is stored in a separate plane with each plane sotring R, G or B packed.

If the above is correct, what FB_TYPE_* should a driver report when using 
FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P (http://linuxtv.org/downloads/v4l-
dvb-apis/V4L2-PIX-FMT-YUV422P.html) or V4L2_PIX_FMT_NV12 
(http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?

> >> - FB_TYPE_INTERLEAVED_PLANES
> >> 
> >> The bits that make up a pixel are stored in separate planes. Planes
> >> are interleaved.
> >> The interleave factor (the distance in bytes between the planes in
> >> memory) is stored in the type_aux field.
> > 
> > That's a bit unclear to me. How are they interleaved ?
> 
> Instead of storing the same bits of all pixels contiguously into memory,
> they are interleaved. Typically this is done per line (type_aux is the
> length of a line in bytes),
> or per word (Atari uses 2 bytes interleaving.
> 
> E.g. for a 320 x 200 display, with FB_TYPE_PLANES, you would store 320 x
> 200 = 64000 first bits, followed 64000 second bits, and so on.
> 
> With FB_TYPE_INTERLEAVED_PLANES and type_aux = 320 / 8 = 40,
> you store the first line of the screen as 320 first bits, followed by
> 320 second bits, and so on.
> Then the next line, as 320 first bits, followed by 320 second bits, and so
> on...
> 
> Hence the bits that make up a pixel are spread across memory. It was
> useful in the days
> computers couldn't show many colors, and allows things like 5 or 6
> bits per pixels.
> 
> >> > +- FB_VISUAL_MONO01
> >> > +
> >> > +Pixels are black or white and stored on one bit. A bit set to 1
> >> > represents a +black pixel and a bit set to 0 a white pixel. Pixels are
> >> > packed together in +bytes with 8 pixels per byte.
> >> 
> >> Actually we do have drivers that use 8 bits per pixel for a monochrome
> >> visual. Hence:
> >> 
> >> "Pixels are black or white. A black pixel is represented by all
> >> (typically one) bits set to ones, a white pixel by all bits set to
> >> zeroes."
> > 
> > OK. I've rephrased it as
> > 
> > "Pixels are black or white and stored on a number of bits (typically one)
> > specified by the variable screen information bpp field.
> > 
> > Black pixels are represented by all bits set to 1 and white pixels by all
> > bits set to 0. When the number of bits per pixel is smaller than 8,
> > several pixels are packed together in a byte."
> 
> OK.
> 
> >> > +FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
> >> 
> >> ... so this may also not be true (but it is for all current drivers,
> >> IIRC). There's a strict orthogonality between type (how is a pixel
> >> stored in memory) and visual (how the bits that represent the pixel are
> >> interpreted and converted to a color value).
> > 
> > What about
> > 
> > "FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only." ?
> 
> stifb.c seems to use FB_TYPE_PLANES, but it uses bits_per_pixel is 1, so
> FB_TYPE_PACKED_PIXELS, FB_TYPE_PLANES, and FB_TYPE_INTERLEAVED_PLANES
> all degenerate to the same case anyway.
> 
> >> > +- FB_VISUAL_TRUECOLOR
> >> > +
> >> > +Pixels are broken into red, green and blue components, and each
> >> > component +indexes a read-only lookup table for the corresponding
> >> > value. Lookup tables +are device-dependent, and provide linear or
> >> > non-linear ramps.
> >> > +
> >> > +Each component is stored in memory according to the variable screen
> >> > +information red, green, blue and transp fields.
> >> 
> >> "Each component is stored in a macropixel according to the variable
> >> screen information red, green, blue and transp fields."
> >> 
> >> Storage format in memory is determined by the FB_TYPE_* value.
> > 
> > How so ? With FB_TYPE_PLANES and FB_VISUAL_TRUECOLOR for an RGB format,
> > how are the R, G and B planes ordered ? Are color components packed or
> > padded
> 
> That's specified by the fb_bitfield structs.
> 
> > inside a plane ? I understand that the design goal was to have orthogonal
> > FB_TYPE_* and FB_VISUAL_* values, but we're missing too much information
> > for that to be truly generic.
> 
> The visual specifies how to interprete the fields that make up a pixel (as
> color components, indices, ...).
> The fb_bitfield structs specify how the fields are laid out in a pixel of
> size bits_per_pixel.
> The frame buffer type specifies how pixels are laid out in memory.

That's fine if the FB device uses bitplanes, but not if it uses a format such 
as the ones described above.

-- 
Regards,

Laurent Pinchart