Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #55313 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Mathieu Malaterre <malat@debian.org> - 2016-10-04 08:30 +0200
    Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-04 15:50 +0200
      Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Samuel Thibault <sthibault@debian.org> - 2016-10-04 16:00 +0200
        Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-04 16:50 +0200
          Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Mathieu Malaterre <malat@debian.org> - 2016-10-04 17:00 +0200
            Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-04 17:10 +0200
          Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-04 22:30 +0200
            Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Mathieu Malaterre <malat@debian.org> - 2016-10-05 18:50 +0200
              Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-05 19:50 +0200
                Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Mathieu Malaterre <malat@debian.org> - 2016-10-05 21:00 +0200
                  Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-05 21:30 +0200
                    Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Mathieu Malaterre <malat@debian.org> - 2016-10-06 07:50 +0200
                      Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-06 16:20 +0200
                        Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Gianluca Renzi <icjtqr@gmail.com> - 2016-10-06 16:40 +0200
                          Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-06 17:20 +0200
                        Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 Mathieu Malaterre <malat@debian.org> - 2016-10-06 22:10 +0200
    Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2 lsorense@csclub.uwaterloo.ca (Lennart Sorensen) - 2016-10-04 18:00 +0200

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

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

[toc] | [next] | [standalone]

#55316

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

[toc] | [prev] | [next] | [standalone]

#55317

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

[toc] | [prev] | [next] | [standalone]

#55318

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

[toc] | [prev] | [next] | [standalone]

#55319

On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> 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.

[toc] | [prev] | [next] | [standalone]

#55320

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

[toc] | [prev] | [next] | [standalone]

#55325

On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
> <lsorense@csclub.uwaterloo.ca> 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

[toc] | [prev] | [next] | [standalone]

#55333

On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> 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
>> <lsorense@csclub.uwaterloo.ca> 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.

[toc] | [prev] | [next] | [standalone]

#55335

On Wed, Oct 05, 2016 at 06:40:36PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
> <lsorense@csclub.uwaterloo.ca> 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
> >> <lsorense@csclub.uwaterloo.ca> 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

[toc] | [prev] | [next] | [standalone]

#55336

On Wed, Oct 5, 2016 at 7:45 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> 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
>> <lsorense@csclub.uwaterloo.ca> 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
>> >> <lsorense@csclub.uwaterloo.ca> 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@f0000000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'

[toc] | [prev] | [next] | [standalone]

#55337

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@f0000000/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

[toc] | [prev] | [next] | [standalone]

#55348

Hi,

On Wed, Oct 5, 2016 at 9:23 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> 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@f0000000/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.

[toc] | [prev] | [next] | [standalone]

#55351

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

[toc] | [prev] | [next] | [standalone]

#55352

[Multipart message — attachments visible in raw view] — view raw

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 <
lsorense@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

[toc] | [prev] | [next] | [standalone]

#55353

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

[toc] | [prev] | [next] | [standalone]

#55354

On Thu, Oct 6, 2016 at 4:13 PM, Lennart Sorensen
<lsorense@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.

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@f0000000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0/depth
0000000 0000 0008
0000004


> 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.

[toc] | [prev] | [next] | [standalone]

#55321

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web