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

[Mathieu Malaterre]

Salvatore,

On Sun, May 2, 2021 at 8:59 AM Salvatore Bonaccorso  wrote:
>
> Control: tags -1 + moreinfo
>
> Hi Mathieu,
>
> This bug thread was by the time very long but stoppend in 2016. Are
> the issues still relevant for us or should we close this bug by now?

Thanks for your triaging.

It turns out Adrian was able to release an updated d-i for
debian-power. So now all mac/ppc32 that were affected with the color
inversion are now loading the radeonfb driver instead of the offb one.

The bug is no longer visible to users but to (long beard) developers...

I am going to close it, no chance upstream will ever fix it.

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

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + moreinfo
Bug #825840 [linux] offb/ATY,RockHopper: inverts red and blue in bterm
Added tag(s) moreinfo.

-- 
825840: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825840
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Mathieu,

This bug thread was by the time very long but stoppend in 2016. Are
the issues still relevant for us or should we close this bug by now?

Regards,
Salvatore

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

[Mathieu Malaterre]

On Thu, Oct 6, 2016 at 4:13 PM, Lennart Sorensen
 wrote:
> On Thu, Oct 06, 2016 at 07:44:35AM +0200, Mathieu Malaterre wrote:
>> That's precisely what I tried yesterday.
>>
>> Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
>> display (either black or corrupted). when I then type 'boot' it goes
>> back to normal 8 bits. I have access to another Mac Mini G4 and even a
>> Gigabit Ethernet to test.
>
> Hmm, oh well.  No idea how to test it then, other than hard coding 32bpp
> in the offb.c overriding what it gets from the firmware.
>
> Still fixing the reversed red/blue would be nice.

Still no luck tonight using the other Mac Mini G4. However I did
notice that reseting everything:

Hold down (command-option-o-f) at startup
> reset-nvram
> set-defaults
> reset-all

boot and then display the debian login screen with some weird colors.
Now if I do:

Hold down (command-option-o-f) at startup
> dev screen
> 8 set-depth
> boot

The debian login screen uses now some other weird colors...

That's odd since in both case I have:

$ hexdump 
/proc/device-tree/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0/depth
000  0008
004


> Does the radeonfb have the red/blue reversal problem in pseudocolor mode
> (I think that's what it came up in too by default)?

If I boot using my modified kernel, and then `modprobe radeonfb`, then
I can do the bterm + `tput setaf 1` and it will properly display red.

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

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 04:31:39PM +0200, Gianluca Renzi wrote:
> Just a clue: try to add a module parameter, for example videodepth= where
> you pass to the module offb.
> So if not passed gets the default, otherwise get the correct bpp value
> (8,15,16,24,32)???

The offb.c code seems to clearly use what openfirmware tells it and
nothing else.  It has no module options.

-- 
Len Sorensen

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

[Gianluca Renzi]

Just a clue: try to add a module parameter, for example videodepth= where
you pass to the module offb.
So if not passed gets the default, otherwise get the correct bpp value
(8,15,16,24,32)???


On Thu, Oct 6, 2016 at 4:13 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Thu, Oct 06, 2016 at 07:44:35AM +0200, Mathieu Malaterre wrote:
> > That's precisely what I tried yesterday.
> >
> > Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
> > display (either black or corrupted). when I then type 'boot' it goes
> > back to normal 8 bits. I have access to another Mac Mini G4 and even a
> > Gigabit Ethernet to test.
>
> Hmm, oh well.  No idea how to test it then, other than hard coding 32bpp
> in the offb.c overriding what it gets from the firmware.
>
> Still fixing the reversed red/blue would be nice.
>
> Does the radeonfb have the red/blue reversal problem in pseudocolor mode
> (I think that's what it came up in too by default)?
>
> --
> Len Sorensen
>
>


-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo

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

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 07:44:35AM +0200, Mathieu Malaterre wrote:
> That's precisely what I tried yesterday.
> 
> Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
> display (either black or corrupted). when I then type 'boot' it goes
> back to normal 8 bits. I have access to another Mac Mini G4 and even a
> Gigabit Ethernet to test.

Hmm, oh well.  No idea how to test it then, other than hard coding 32bpp
in the offb.c overriding what it gets from the firmware.

Still fixing the reversed red/blue would be nice.

Does the radeonfb have the red/blue reversal problem in pseudocolor mode
(I think that's what it came up in too by default)?

-- 
Len Sorensen

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

[Mathieu Malaterre]

Hi,

On Wed, Oct 5, 2016 at 9:23 PM, Lennart Sorensen
 wrote:
> On Wed, Oct 05, 2016 at 08:55:50PM +0200, Mathieu Malaterre wrote:
>> Will do ASAP. For reference:
>>
>> https://bugs.debian.org/825840#92
>>
>> and
>>
>> devalias tells me that  'screen' points to
>> '/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'
>
> Not sure how that maps to the dev syntax I found.
>
> I guess you would want '22 set-mode' for 1680x1050 then.
>
> Of course based on that alias, maybe it would work to just do:
>
> dev screen
> 22 set-mode
> 32 set-depth
> boot

That's precisely what I tried yesterday.

Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
display (either black or corrupted). when I then type 'boot' it goes
back to normal 8 bits. I have access to another Mac Mini G4 and even a
Gigabit Ethernet to test.

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

[Lennart Sorensen]

On Wed, Oct 05, 2016 at 08:55:50PM +0200, Mathieu Malaterre wrote:
> Will do ASAP. For reference:
> 
> https://bugs.debian.org/825840#92
> 
> and
> 
> devalias tells me that  'screen' points to
> '/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'

Not sure how that maps to the dev syntax I found.

I guess you would want '22 set-mode' for 1680x1050 then.

Of course based on that alias, maybe it would work to just do:

dev screen
22 set-mode
32 set-depth
boot

-- 
Len Sorensen

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

[Mathieu Malaterre]

On Wed, Oct 5, 2016 at 7:45 PM, Lennart Sorensen
 wrote:
> On Wed, Oct 05, 2016 at 06:40:36PM +0200, Mathieu Malaterre wrote:
>> On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
>>  wrote:
>> > On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
>> >> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
>> >>  wrote:
>> >> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> >> >> € grep bogl_set_palette *
>> >> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> >> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> >> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> >> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. 
>> >> >> */
>> >> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> >> >> palette[][3]);
>> >> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> >> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> >> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) 
>> >> >> palette);
>> >> >> bterm.c:  bogl_set_palette(0, 16, palette);
>> >> >> bterm.c:bogl_set_palette(0, 16, palette);
>> >> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>> >> >>
>> >> >> It looks like bterm always set only colors 0-15.
>> >> >
>> >> > So it does.  Hmm, I will compare the code some more.
>> >> >
>> >> > Has it been confirmed that radeonfb does not have wrong colours while
>> >> > offb on the same machine does?
>> >> >
>> >> > And what video mode does radeonfb run with?  I wish someone had dmesg
>> >> > dumps of both offb and radeonfb, but I am not having much luck finding
>> >> > any with google.
>> >>
>> >> Attached.
>> >
>> > Could you try what offb does if you boot with the kernel option:
>> > video=1680x1050-32
>>
>> Does not seems to be read at all. I tried both:
>>
>> $ cat /etc/yaboot.conf
>> [...]
>> append="video=1680x1050-32"
>>
>> and
>>
>> $ cat /etc/yaboot.conf
>> [...]
>> append="video=offb:1680x1050-32"
>>
>> dmesg & fbset output appears perfectly identical.
>
> Maybe it just doesn't support doing that.
>
> Looking at the code, offb in fact just does whatever open firmware
> settings say to do.
>
> So that means you would have to change the mode in open firmware before
> booting.
>
> So if you know how to drop to the open firmware prompt this might work:
>
> dev pci1/@D/ATY,RockHopper2_A
> 32 set-depth
> boot
>
> I think I am guessing correctly for the dev value to talk to the video
> card.
>
> There is a 'set-mode' command too, but I don't know the mode number
> for 1680x1050.  The radeonfb driver actually talks to the monitor and
> does the mode setting itself.  Looking at modedb.c in the kernel,
> entry 27 happens to be 1600x1200, and entry 36 is 1680x1050.  No idea
> if that relates to the modes in the mac open firmware, but if it does,
> this might work:
>
> dev pci1/@D/ATY,RockHopper2_A
> 36 enable-videomode
> 36 set-mode
> 32 set-depth
> boot
>
> But this is still just to find out of offb works correctly in 24/32 bit
> color mode, in which case the problem is only in 8 bpp.

Will do ASAP. For reference:

https://bugs.debian.org/825840#92

and

devalias tells me that  'screen' points to
'/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'

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

[Lennart Sorensen]

On Wed, Oct 05, 2016 at 06:40:36PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
>  wrote:
> > On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> >> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
> >>  wrote:
> >> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> >> >> € grep bogl_set_palette *
> >> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> >> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> >> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> >> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. 
> >> >> */
> >> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> >> >> palette[][3]);
> >> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
> >> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> >> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> >> >> bterm.c:  bogl_set_palette(0, 16, palette);
> >> >> bterm.c:bogl_set_palette(0, 16, palette);
> >> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> >> >>
> >> >> It looks like bterm always set only colors 0-15.
> >> >
> >> > So it does.  Hmm, I will compare the code some more.
> >> >
> >> > Has it been confirmed that radeonfb does not have wrong colours while
> >> > offb on the same machine does?
> >> >
> >> > And what video mode does radeonfb run with?  I wish someone had dmesg
> >> > dumps of both offb and radeonfb, but I am not having much luck finding
> >> > any with google.
> >>
> >> Attached.
> >
> > Could you try what offb does if you boot with the kernel option:
> > video=1680x1050-32
> 
> Does not seems to be read at all. I tried both:
> 
> $ cat /etc/yaboot.conf
> [...]
> append="video=1680x1050-32"
> 
> and
> 
> $ cat /etc/yaboot.conf
> [...]
> append="video=offb:1680x1050-32"
> 
> dmesg & fbset output appears perfectly identical.

Maybe it just doesn't support doing that.

Looking at the code, offb in fact just does whatever open firmware
settings say to do.

So that means you would have to change the mode in open firmware before
booting.

So if you know how to drop to the open firmware prompt this might work:

dev pci1/@D/ATY,RockHopper2_A
32 set-depth
boot

I think I am guessing correctly for the dev value to talk to the video
card.

There is a 'set-mode' command too, but I don't know the mode number
for 1680x1050.  The radeonfb driver actually talks to the monitor and
does the mode setting itself.  Looking at modedb.c in the kernel,
entry 27 happens to be 1600x1200, and entry 36 is 1680x1050.  No idea
if that relates to the modes in the mac open firmware, but if it does,
this might work:

dev pci1/@D/ATY,RockHopper2_A
36 enable-videomode
36 set-mode
32 set-depth
boot

But this is still just to find out of offb works correctly in 24/32 bit
color mode, in which case the problem is only in 8 bpp.

-- 
Len Sorensen

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

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
>> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
>>  wrote:
>> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> >> € grep bogl_set_palette *
>> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
>> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> >> palette[][3]);
>> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
>> >> bterm.c:  bogl_set_palette(0, 16, palette);
>> >> bterm.c:bogl_set_palette(0, 16, palette);
>> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>> >>
>> >> It looks like bterm always set only colors 0-15.
>> >
>> > So it does.  Hmm, I will compare the code some more.
>> >
>> > Has it been confirmed that radeonfb does not have wrong colours while
>> > offb on the same machine does?
>> >
>> > And what video mode does radeonfb run with?  I wish someone had dmesg
>> > dumps of both offb and radeonfb, but I am not having much luck finding
>> > any with google.
>>
>> Attached.
>
> Could you try what offb does if you boot with the kernel option:
> video=1680x1050-32

Does not seems to be read at all. I tried both:

$ cat /etc/yaboot.conf
[...]
append="video=1680x1050-32"

and

$ cat /etc/yaboot.conf
[...]
append="video=offb:1680x1050-32"

dmesg & fbset output appears perfectly identical.

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

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
>  wrote:
> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> >> € grep bogl_set_palette *
> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> >> palette[][3]);
> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> >> bterm.c:  bogl_set_palette(0, 16, palette);
> >> bterm.c:bogl_set_palette(0, 16, palette);
> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> >>
> >> It looks like bterm always set only colors 0-15.
> >
> > So it does.  Hmm, I will compare the code some more.
> >
> > Has it been confirmed that radeonfb does not have wrong colours while
> > offb on the same machine does?
> >
> > And what video mode does radeonfb run with?  I wish someone had dmesg
> > dumps of both offb and radeonfb, but I am not having much luck finding
> > any with google.
> 
> Attached.

Could you try what offb does if you boot with the kernel option:
video=1680x1050-32

I just wonder if that makes bterm work with right colors.

Of course it might not like it if it doesn't know how to change the mode
on an "Unknown" type of device.

Unfortunately /proc/iomem on powerpc is apparently totally useless.

-- 
Len Sorensen

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

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> € grep bogl_set_palette *
>> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
>> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> palette[][3]);
>> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
>> bterm.c:  bogl_set_palette(0, 16, palette);
>> bterm.c:bogl_set_palette(0, 16, palette);
>> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>>
>> It looks like bterm always set only colors 0-15.
>
> So it does.  Hmm, I will compare the code some more.
>
> Has it been confirmed that radeonfb does not have wrong colours while
> offb on the same machine does?
>
> And what video mode does radeonfb run with?  I wish someone had dmesg
> dumps of both offb and radeonfb, but I am not having much luck finding
> any with google.

Attached.


dmesg.radeonfb.txt.gz
Description: GNU Zip compressed data


fbset.radeonfb.txt.gz
Description: GNU Zip compressed data


iomem.radeonfb.txt.gz
Description: GNU Zip compressed data


dmesg.offb.txt.gz
Description: GNU Zip compressed data


fbset.offb.txt.gz
Description: GNU Zip compressed data


iomem.offb.txt.gz
Description: GNU Zip compressed data

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

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> Hi,
> 
> > Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
> > a Radeon, and the way the radeonfb driver handles the pallete appears
> > to match the cmap_radeon in offb, so perhaps this would work in offb.c
> 
> 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.

Well radeonfb uses:

OUTREG(PALETTE_INDEX, pindex);
OUTREG(PALETTE_DATA, (red << 16) |
   (green << 8) | blue);

which is :

writel(pindex, (rinfo->mmio_base)+0x00B0)
writel((red << 16) | (green << 8) | blue), 
(rinfo->mmio_base)+0x00B4)

offb in cmap_radeon mode uses:
out_8(par->cmap_adr + 0xb0, regno);
out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));

Not sure if using out_8 for the index versus using a 32 bit write makes
a difference.  I highly doubt it.

The memory being mapped is 0x4000 in size for radeonfb and 0x2000 in offb.
For the colour table that sounds plenty big.

Of course radeonfb is using pci functions to get the memory range while
offb uses OF calls.  The dmesg output I have seen so far seems to indicate
these are both returning the same thing, so that is not likely to be
the problem.

As for radeon driver, it appears to me that it pretty much always runs
32 bit truecolor, which should solve any palette problems by not using
them.

-- 
Len Sorensen

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

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 04:47:21PM +0200, Mathieu Malaterre wrote:
> Yes. If you re-read my post on debian-powerpc :) But getting `modprobe
> radeonfb` to work does not work as you know very well :)
> So the userland code in bterm is correct (no big endian issue).

Yes I also really doubt this is a bterm problem.

I was hoping my offb patch would solve the modprobe radeonfb problem by
freeing the pallete data memory to allow radeonfb to grab all the memory.

> Will do tonight. I can send the fbset output too.

Great.

-- 
Len Sorensen

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

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> € grep bogl_set_palette *
>> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
>> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> palette[][3]);
>> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
>> bterm.c:  bogl_set_palette(0, 16, palette);
>> bterm.c:bogl_set_palette(0, 16, palette);
>> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>>
>> It looks like bterm always set only colors 0-15.
>
> So it does.  Hmm, I will compare the code some more.
>
> Has it been confirmed that radeonfb does not have wrong colours while
> offb on the same machine does?

Yes. If you re-read my post on debian-powerpc :) But getting `modprobe
radeonfb` to work does not work as you know very well :)
So the userland code in bterm is correct (no big endian issue).

> And what video mode does radeonfb run with?  I wish someone had dmesg
> dumps of both offb and radeonfb, but I am not having much luck finding
> any with google.

Will do tonight. I can send the fbset output too.

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

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> € grep bogl_set_palette *
> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> palette[][3]);
> bogl-test.c:  bogl_set_palette (0, 16, palette);
> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> bterm.c:  bogl_set_palette(0, 16, palette);
> bterm.c:bogl_set_palette(0, 16, palette);
> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> 
> It looks like bterm always set only colors 0-15.

So it does.  Hmm, I will compare the code some more.

Has it been confirmed that radeonfb does not have wrong colours while
offb on the same machine does?

And what video mode does radeonfb run with?  I wish someone had dmesg
dumps of both offb and radeonfb, but I am not having much luck finding
any with google.

-- 
Len Sorensen

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

[Samuel Thibault]

Lennart Sorensen, on Tue 04 Oct 2016 09:41:34 -0400, wrote:
> 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.

€ grep bogl_set_palette *
bogl.c:  bogl_set_palette = bogl_fb_set_palette;
bogl.c:   bogl_set_palette = bogl_fb_set_palette;
bogl.c:   bogl_set_palette = bogl_tcfb_set_palette;
bogl.c:   the palette with bogl_set_palette() for this to take effect. */
bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
palette[][3]);
bogl-test.c:  bogl_set_palette (0, 16, palette);
bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
bterm.c:  bogl_set_palette(0, 16, palette);
bterm.c:  bogl_set_palette(0, 16, palette);
ChangeLog:  * bterm.c (main): Call bogl_set_palette after VT switch.

It looks like bterm always set only colors 0-15.

Samuel

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

[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

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

[Mathieu Malaterre]

Hi,

> Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
> a Radeon, and the way the radeonfb driver handles the pallete appears
> to match the cmap_radeon in offb, so perhaps this would work in offb.c

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.

-M

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

[Lennart Sorensen]

Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact 
a Radeon, and the way the radeonfb driver handles the pallete appears
to match the cmap_radeon in offb, so perhaps this would work in offb.c

--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -333,7 +333,7 @@
par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_M3B;
-   } else if (dp && !strncmp(name, "ATY,Rage6", 9)) {
+   } else if (dp && (!strncmp(name, "ATY,Rage6", 9)) || !strncmp(name, 
"ATY,Rockhopper2", 15)) {
par->cmap_adr = offb_map_reg(dp, 1, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_radeon;

-- 
Len Sorensen