Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Denis Oliver Kropp <dok@directfb.org>]

Quoting Russell King (rmk@arm.linux.org.uk):
> On Thu, Jun 13, 2002 at 10:32:43AM +0200, Denis Oliver Kropp wrote:
> > - * Integraphics CyberPro 2000, 2010 and 5000 frame buffer device
> > + * Intergraphics CyberPro 2000, 2010 and 5000 frame buffer device
> 
> This isn't actually a spelling mistake.  The chips I have are quite
> clearly marked "Integraphics" not "Intergraphics".

Ok, I'm sorry for that, seemed obvious.

> > @@ -355,7 +367,9 @@
> >  
> >  			if (regno < 16)
> >  				((u16 *)cfb->fb.pseudo_palette)[regno] =
> > -					regno | regno << 5 | regno << 11;
> > +					((red   << 8) & 0xf800) |
> > +					((green << 3) & 0x07e0) |
> > +					((blue  >> 3));
> >  			break;
> >  		}
> >  #endif
> 
> This seems wrong.  We're setting up the DAC palette to map pixel color
> component 'regno' to 'read', 'green' and 'blue' respectively.
> 
> This means that the pseudopalette should be a 1:1 mapping of desired
> colour value (ie, the 16 VGA colors) to the DAC palette entries -
> the pseudopalette contains the pixel values to insert into the frame
> buffer for each of the 16 VGA colors.

The palette is being bypassed anyway by setting bit 4 in palette_ctrl.
Besides that I tested the rgb modes on a CyberPro 5000 with and without
this fix. The text was dark gray (as expected) in 16bit and hardly
visible in 24bit.

Why is the pseudo palette used anyway? There's no speed benefit and
applications running in true/direct color would look wrong.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH