Re: fixing fbdev for various framebuffer configs

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

Jon Smirl wrote:
> It has been determined that bits per pixel is insuffucient to
> enumerate all the needed fbconfigs. Here are the possible fgconfigs
> from the OpenGL headers:
> 
> total bits 
> 8     GL_R3_G3_B2
> 8     GL_RGBA2
> 12   GL_RGB4
> 15   GL_RGB5
> 16   GL_R5_G6_B5
> 16   GL_RGBA4
> 16   GL_RGB5_A1
> 24   GL_RGB8
> 30   GL_RGB10
> 32   GL_RGBA8
> 32   GL_RGB10_A2
> 36   GL_RGB12
> 48   GL_RGB16
> 48   GL_RGBA12
> 48   GL_FLOAT_RGB16
> 64   GL_RGBA16
> 64   GL_FLOAT_RGBA16
> 96   GL_FLOAT_RGB32
> 128 GL_FLOAT_RGBA32
> 
> We need to be able to set any of these through the fbdev interface. We
> also need to allow for possible future expansion.

To set for example, RGBA16, set {transp|green|red|blue}.len to 16, the
offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
sort it out.  I don't know what we can do about the FLOAT formats...

> 
> Ideas on how to adjust the fbdev interface?

Well, no need to adjust the interface.  But it is limited though to
16 bits per channel.  Redefining them to 32 will break a lot of apps.

> 
> What is the effect of alpha bits on the scanout buffer, do they do anything?
> 

I think if there is another layer such as an overlay, the alpha bits can
control the transparency between the framebuffer and the overlay. If only
the framebuffer is active,  I don't believe it has any effects.

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf