Re: Problems with framebuffer in 2.6.22-git17

Antonino A. Daplas
2007-07-28T02:15:11Z

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