On Monday, May 23, 2011 13:55:21 Marek Szyprowski wrote:
Hello,
On Wednesday, May 18, 2011 8:54 AM Hans Verkuil wrote:
quoted
On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote:
quoted
On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart
[off-list ref] wrote:
quoted
I need to implement support for a YUV frame buffer in an fbdev driver.
As the
quoted
quoted
fbdev API doesn't support this out of the box, I've spent a couple of
days
quoted
quoted
reading fbdev (and KMS) code and thinking about how we could cleanly
add YUV
quoted
quoted
support to the API. I'd like to share my findings and thoughts, and
hopefully
quoted
quoted
receive some comments back.
The terms 'format', 'pixel format', 'frame buffer format' and 'data
format'
quoted
quoted
will be used interchangeably in this e-mail. They all refer to the way
pixels
quoted
quoted
are stored in memory, including both the representation of a pixel as
integer
quoted
quoted
values and the layout of those integer values in memory.
This is a great proposal. It was about time!
quoted
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
quoted
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.
quoted
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.
quoted
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