Re: fixing fbdev for various framebuffer configs

[Jon Smirl <jonsmirl@gmail.com>]

On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 29 Jul 2005, Jon Smirl wrote:
> >> On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >>> 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.
> >
> > It's only the colormap entries that are limited to 16 bits per color component,
> > right? The color components in pixel values can be much larger (up to 2^31 bits
> > :-).
> 
> Yes, but struct fb_cmap has entries of u16 and this is used by struct
> fb_var_screeninfo and by the cmap functions. fb_setcolreg is also passed
> with u16 values.  ioctls affected will be FBIO{GET|PUT}_VSCREENINFO ,
> FBIO{GET|PUT}CMAP, all used in userspace.

I was going to leave the IOCTL interface alone and only adjust the
internal data structures.  The IOCTL data would convert to the new
internal buffers inside of fbdev. The more advanced fbconfigs would
only be accessible from the sysfs interface.

No one is going to build 32bit cmaps anytime soon, you need gigabytes
of memory to do it. I think we are fine right now with 16b cmap
entries.

> >> My current idea is to get rid of the bit_per_pixel attribute and
> >> replace it with config. Config would take strings like 8,8,8 or
> >> 5,5,5,1 or 32.,32.,32.
> >
> > That's not acceptable. How do you differentiate between RGB888 (without alpha)
> > using 24 or 32 bits per pixel?
> >
> > Or more general, what with hardware that has unused bits in its pixel values,
> > e.g. hardware that has 8 bits per pixel but uses only 1 bit per byte in
> > monochrome mode and 4 bits in 16-color mode?
> 
> Agree,
> 
> Tony
> 


-- 
Jon Smirl
jonsmirl@gmail.com


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