[RFC] Standardize YUV support in the fbdev API

[Hans Verkuil]

On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote:
> On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
> > I need to implement support for a YUV frame buffer in an fbdev driver. As the
> > fbdev API doesn't support this out of the box, I've spent a couple of days
> > reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
> > support to the API. I'd like to share my findings and thoughts, and hopefully
> > receive some comments back.
> >
> > The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
> > will be used interchangeably in this e-mail. They all refer to the way pixels
> > are stored in memory, including both the representation of a pixel as integer
> > values and the layout of those integer values in memory.
> 
> This is a great proposal. It was about time!
> 
> > The third solution has my preference. Comments and feedback will be
> > appreciated. I will then work on a proof of concept and submit patches.
> 
> I also would prefer the third solution. I don't think there's much
> difference from the user-space point of view, and a new ioctl would be
> cleaner. Also the v4l2 fourcc's should do.

I agree with this.

We might want to take the opportunity to fix this section of the V4L2 Spec:

http://www.xs4all.nl/~hverkuil/spec/media.html#pixfmt-rgb

There are two tables, 2.6 and 2.7. But 2.6 is almost certainly wrong and should
be removed. I suspect many if not all V4L2 drivers are badly broken for
big-endian systems and report the wrong pixel formats.

Officially the pixel formats reflect the contents of the memory. But everything
is swapped on a big endian system, so you are supposed to report a different
pix format. I can't remember seeing any driver do that. Some have built-in
swapping, though, and turn that on if needed.

I really need to run some tests, but I've been telling myself this for years
now :-(

Regards,

	Hans