On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote:
> On 28/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
