Re: YUV Framebuffer

On Fri, 19 Oct 2007, Antonino A. Daplas wrote:

On Thu, 2007-10-18 at 15:41 +0200, Geert Uytterhoeven wrote:

quoted

On Thu, 18 Oct 2007, Antonino A. Daplas wrote:

quoted

On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote:

quoted

On Wed, 17 Oct 2007, Rhee, C. Joon wrote:

quoted

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.

quoted

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.

IC.

quoted

quoted

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.

quoted

How would you express YUV420?

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

quoted

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.

quoted

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.

What with frame buffers where there's no overlay, i.e. the YUV buffer is
the single frame buffer?

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?

It's definitely needed for single YUV frame buffers.

What about:
  - fb_fix_screeninfo.visual = FB_VISUAL_YUV
  - fb_var_screeninfo.nonstd = FB_NONSTD_YUV
  - use an additional struct fb_yuv_screeninfo for the other parameters?
    or maybe better, put them in fb_var_screeninfo.reserved[]?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
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/