Re: YUV Framebuffer

["Antonino A. Daplas" <adaplas@gmail.com>]

On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote:
> On Wed, 17 Oct 2007, Rhee, C. Joon wrote:
> > Interleaved means YCBCR is on the same plane in this order.
> > Y CB Y CR Y CB Y CR.... (TV-Out)
> 
> So it's still FB_TYPE_PACKED_PIXELS.
> 
> > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the
> > pixel cannot be represented directly since CB/CR gets shared between Ys.
> > 
> > So, bitsperpixel would be 16 bit and both B and R offset will be 8.
> 
> Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR
> visual. Even pixels have a Cb, odd have a Cr component.

We need at least 3 fields to describe YUV.

1. The component size - fb_bitfield.length
2. The sample period - fb_bitfield.offset
3. The component ordering - fb_bitfield.msb_right

So if Y = red, U = green, V = blue

YUV422

red|green|blue.length = 8 /* 8 bits per component */
red.offset = 1 /* sampled every pixel */
green.offset = blue.offset = 2 /* sampled every 2 pixels */
red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3
(Y U V order)

UVY411

red|green|blue.length = 8;
red.offset = 1;
green.offset = blue.offset = 4;
red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1;

The FB_VISUAL_* will differentiate if the bitfields are interpreted as
RGB or YUV.

That's the only way I can think of describing YUV packed pixel formats
without adding new fields, or modifying our user-visible structures.

We will need separate drawing functions for fbcon's use.

Of course, the simplest way is to use fourcc naming for our FB_VISUAL_*
constants. But that will become too unwieldy over time.

Tony




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/