Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> I had time to test this patch yesterday night. It did not work using
> `cmap_radeon` codepath. I even tried changing:
> 
> out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));
> 
> into:
> 
> out_le32(par->cmap_adr + 0xb4, (blue << 16 | green << 8 | red));
> 
> I am also thinking we are not looking at the right code.
> 
> I can see my `printk` messages so I know we are entering the
> `cmap_radeon` codepath.

But radeonfb works?

I was comparing the code in radeonfb to offb which is why I thought
using the colour setting code in cmap_radeon should work.

It looks like for the first 16 palette entries, something special is
done that matches cmap_simple, which might explain why the TERM=linux case
works, if it just uses the standard 16 colours, while with TERM=bterm
it might be trying to create custom colours, which puts it into the
higher range where different handling is done for the pallete and
cmap_simple no longer works on the radeon.

It is also likely that if you booted in 24bit or 32bit colour mode
instead of 8 bit, it would work too, since that too is done differently.
Might be interesting to try if there is an easy way to try that.

-- 
Len Sorensen