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