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

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

Bug#825840: localechooser: image display inverts red and blue color

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

Contents

  Bug#825840: localechooser: image display inverts red and blue color Mathieu Malaterre <malat@debian.org> - 2016-09-02 21:10 +0200
    Bug#825840: localechooser: image display inverts red and blue color Samuel Thibault <sthibault@debian.org> - 2016-09-06 08:10 +0200
    Bug#825840: localechooser: image display inverts red and blue color Mathieu Malaterre <malat@debian.org> - 2016-09-06 08:10 +0200

#55006 — Bug#825840: localechooser: image display inverts red and blue color

Control: reassign -1 localechooser 2.68
Control: retitle -1 localechooser: image display inverts red and blue color

Ok, so here is my latest experiment.

1. Get the latest Debian Installer Stretch Alpha 7 release
wget http://cdimage.debian.org/cdimage/stretch_di_alpha7/powerpc/iso-cd/debian-stretch-DI-alpha7-powerpc-netinst.iso
2. Burn to USB key:
dd if=debian-stretch-DI-alpha7-powerpc-netinst.iso of=/dev/sdb bs=4M && sync
3. Plug/Unplug to Mac Minig G4
4. Reboot Mac Mini G4
5. Press Cmd+Opt+o+f to get to Open Firmware
6. Boot USB key:
> boot usb0/disk@1:2,\\yaboot
7. Type:
install32

At this point you should see the localechooser screen with a nicely
inverted color (red background instead of blue background).

Now simply go to alternate screen (eg. Alt+F2), and then type:

# localechooser

And be amazed that now the background is a nice blue background !

Looking at the source of localechooser I could not figure out what
code path was used during debian-installer that gave it some sort of
byte-swapped idea.

Anyway please revert that change and leave the default `localechooser`
background to make big endian (powerpc?) behave the same way as little
endian.

[toc] | [next] | [standalone]

#55029

Mathieu Malaterre, on Tue 06 Sep 2016 08:03:53 +0200, wrote:
> On Tue, Sep 6, 2016 at 2:32 AM, Samuel Thibault <sthibault@debian.org> wrote:
> > I really don't think it's a bterm bug, its only change of behavior is
> > when type or visual changes, which is not the case. It however does
> > use FBIOPUTCMAP, whose implementation does seem suspicious in offb for
> > RockHo.
> 
> I did initially look into that direction (see the early bug report).
> However when I realized that other TERM did not have the color
> inversion I suspected that bterm was assuming BGR instead of RGB.

What happens is that other terms do not use FBIOPUTCMAP.

There is no risk that bogl gets RGB wrong in there, it just fills a
struct fb_cmap, which has explicit "red", "green", and "blue" field
names :)

> I will try your suggested patch, but I fear it will break every single
> other TERM out there (at least in assumption of color organisation).

They don't use it, so they don't risk breaking.

Samuel

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

#55030

Hi Samuel,

On Tue, Sep 6, 2016 at 2:32 AM, Samuel Thibault <sthibault@debian.org> wrote:
> Control: reassign -1 linux
>
> Mathieu Malaterre, on Mon 05 Sep 2016 07:26:15 +0200, wrote:
>> Frame buffer device information:
>>     Name        : OFfb ATY,RockHo
>>     Address     : 0x9c008000
>>     Size        : 614400
>>     Type        : PACKED PIXELS
>>     Visual      : PSEUDOCOLOR
>
>> Frame buffer device information:
>>     Name        : ATI Radeon 5962
>>     Address     : 0x98000000
>>     Size        : 33554432
>>     Type        : PACKED PIXELS
>>     Visual      : PSEUDOCOLOR
>
> Ok, so they look very similar. However, one thing that is different
> is the way they handle FBIOPUTCMAP, i.e. offb_setcolreg(). ATY,RockHo
> is not actually recognized by the offb driver, and it reverts to
> "cmap_simple", which may not actually be the proper way for RockHo, and
> it might very well be simply setting rgb in the wrong order.  You could
> try to patch this over in there: turn
>
>         case cmap_simple:
>                 writeb(regno, par->cmap_adr);
>                 writeb(red, par->cmap_data);
>                 writeb(green, par->cmap_data);
>                 writeb(blue, par->cmap_data);
>                 break;
>
> into
>
>         case cmap_simple:
>                 writeb(regno, par->cmap_adr);
>                 writeb(blue, par->cmap_data);
>                 writeb(green, par->cmap_data);
>                 writeb(red, par->cmap_data);
>                 break;
>
> I really don't think it's a bterm bug, its only change of behavior is
> when type or visual changes, which is not the case. It however does
> use FBIOPUTCMAP, whose implementation does seem suspicious in offb for
> RockHo.

I did initially look into that direction (see the early bug report).
However when I realized that other TERM did not have the color
inversion I suspected that bterm was assuming BGR instead of RGB.

I will try your suggested patch, but I fear it will break every single
other TERM out there (at least in assumption of color organisation).

-M
PS: I'll send the screenshots separately.

[toc] | [prev] | [standalone]

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

csiph-web