Re: YUV Framebuffer

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

On Thu, 2007-10-18 at 15:41 +0200, Geert Uytterhoeven wrote:
> On Thu, 18 Oct 2007, Antonino A. Daplas wrote:
> > 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
> 
> This completely changes the meaning of the latter 2 fields...
> 

Yes, the intent was to reuse the already present fields to express YUV
formats.

> > 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;
> 
> And you would use bits_per_pixel = 8, as you no longer have access to the
> fb_bitfield.offsets (in the sense of `offsets within a pixel')?

We can define the bits_per_pixel as the effective pixel size. For 422,
that would be 16. For 411, that would be 12.

> 
> How would you express YUV420?

We can't. We need another set of fields in the vertical axis.

> 
> Alternatively:
>   - YUV422 really is 16 bits per pixel.
>   - YUV411 and YUV420 really are 12 bits per pixel.
> But I don't think this makes things easier, especially not for the 12 bpp
> variants.
> 
> > 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.

Basically, since most YUV formats are fundamentally different from RGB
(where all components are sampled per pixel), our best bet is to revive
the framebuffer overlay support that was proposed several years ago.

Or, if we do not want this in the kernel, we can always tell them to use
the DirectFB library instead.

What do you think? Should we extend the fb system to support YUV
formats?

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/