On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote: > On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart > <laurent.pinchart@xxxxxxxxxxxxxxxx> 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 -- 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
