Re: [Linux-fbdev-devel] Re: HP300 support checked in

[Antonino A. D. <ad...@ho...>]

On Wednesday 14 July 2004 16:00, Geert Uytterhoeven wrote:
> On Wed, 14 Jul 2004, Antonino A. Daplas wrote:
> > On Monday 12 July 2004 15:25, Geert Uytterhoeven wrote:
> > > On Sun, 11 Jul 2004, Kars de Jong wrote:
> > > > Support for <8 bit framebuffers is probably broken. I don't know how
> > > > I'm going to support them yet. It used to be "special-cased" in
> > > > drivers/video/fbcon.c.
> > > >
> > > > They are laid out in memory like normal 8 bit chunky framebuffers,
> > > > but the upper bits are basically ignored.
> > > >
> > > > So for blitting purposes the bits_per_pixel == 8 code should be used,
> > > > but just setting bits_per_pixel to 8 doesn't work because then the
> > > > amount of colours is assumed to be 256.
> > > >
> > > > I think we basically need to distinguish between bpp and depth.
> > >
> > > What are the possible values of depth? Just 1 (monochrome)? Or also 4
> > > (16 colors)?
> > >
> > > If it's just 1 (monochrome), you can probably get away with setting
> > > var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).
> >
> > Or we can use the fields in var->green, var->red, var->blue, ie,  to
> > describe a 4-color 8-bit chunky framebuffer:
> >
> > var->red.length = 2;
> > var->red.offset = 0;
> > var->green = var->blue = var->red.
> > var->bits_per_pixel = 8;
>
> This breaks something different, since for pseudocolor visuals, the
> *.lengths indicate the sizes of the CLUT entries (e.g. 8 bit per component
> for modern 24-bit color, 6 bit for VGA-style 18-bit color).

I don't know.  For pseudocolor, color depth == CLUT size.  So if we check if all
lengths are equal and if all offsets are equal to zero, then color depth = CLUT size. 
Otherwise, color depth = red.length + green.length + blue.length. Transparency 
can be ignored for now.
  
Tony