Just curious, but if this is the case, why isn't pseudo_palette defined as
a "u32 *" (instead of "void *") in struct fb_info?  If anything outside
the driver itself is going to be using this, it really should be more
explicit what format it's supposed to be in.

Because there can cases when the hardware requires a 16 bit value. Here we 
can optimize the pseudo_palette to a smaller size. This is for the case 
where we have hardware acceleration. 

For that matter, is it really kosher to have the logo code (or other
things external to the driver) setting pseudo_palette directly anyway? 
Shouldn't there be some sort of an interface function for this (at the
very least to let the driver know it's changed, in case it needs to know
that sort of thing)?

That is totally bad. In fact the code is broken in that when I attempt to 
draw a 4 bpp image on 16 bpp or 32 bpp framebuffers the colors come out 
all wrong. This is not easy to fix. All the drivers need to be brought up 
to date in creating a 256 palette cmap. As I update drivers you wil see 
this fix. Once the drivers are done the logo hacks can go away.




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297