On Monday, May 23, 2011 13:55:21 Marek Szyprowski wrote:
Hello,
On Wednesday, May 18, 2011 8:54 AM Hans Verkuil wrote:
On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote:
On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart laurent.pinchart@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.
That's definitely true. I was confused at the beginning when I saw 2 different tables describing the same pixel formats.
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 always thought that pix_format describes the layout of video data in memory on byte level, which is exactly the same on both little- and big- endian systems.
Correct.
You can notice swapped data only if you access memory by units larger than byte, like 16bit or 32bit integers. BTW - I would really like to avoid little- and big- endian flame, but your statement about 'everything is swapped on a big endian system' is completely wrong. It is rather the characteristic of little-endian system not big endian one if you display the content of the same memory first using byte access and then using word/long access.
You are correct, I wasn't thinking it through.
I can't remember seeing any driver do that. Some have built-in swapping, though, and turn that on if needed.
The drivers shouldn't do ANY byte swapping at all. Only tools that extract pixel data with some 'accelerated' methods (like 32bit integer casting and bit-level shifting) should be aware of endianess.
I really need to run some tests, but I've been telling myself this for years now :-(
I've checked the BTTV board in my PowerMac/G4 and the display was correct with xawtv. It is just a matter of selecting correct pix format basing on the information returned by xsever.
Best regards
Just forget my post (except for the part of cleaning up the tables :-) ).
Regards,
Hans