Re: Problems with framebuffer in 2.6.22-git17

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

On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote:
> On 28/07/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> 
> >
> But certainly better at 16bpp
> 
> Can mess about with it later to see if I can get the colours right I suppose.
> 

You can start with pvr2fb_setcolreg() and pvr2fb_set_pal_entry().

A few things I've noticed:

1. In pvr2fb_setcolreg(), pvr2fb_set_pal_entry() is called for bpp 16
and 32.  This means that the palette is modifiable, so
FB_VISUAL_TRUECOLOR is probably not the correct visual for this driver,
FB_VISUAL_DIRECTCOLOR is more appropriate.

So, you either remove the call to set_pal_entry() in setcolreg() or
change the visual to FB_VISUAL_DIRECTCOLOR. Of course, with directcolor,
the pseudo_palette is now written with tmp as:

tmp = transp << var->transp.offset | red << var->red.offset |
	green << var->green.offset | blue << var->green.offset;
 

2. Perhaps, the 3rd parameter passed to set_pal_entry() is not  correct?
Maybe you can try doing it like this for all bpp's, assuming ARGB?

pvr2fb_set_pal_entry(par, regno, transp << 24 | red << 16 | green << 8 |
			blue);

And if you want to maintain FB_VISUAL_TRUECOLOR format, initialize the
palette once on init:

for (i = 0; i < 256; i++)
	pvr2fb_set_pal_entry(par, i, i << 24 | i << 16 | i << 8 | i);

to create a linear color map consistent with truecolor, then remove all
other calls to pvr2fb_set_pal_entry().

Tony