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

[Samuel Thibault]

Mathieu Malaterre, on Tue 06 Sep 2016 08:03:53 +0200, wrote:
> On Tue, Sep 6, 2016 at 2:32 AM, Samuel Thibault  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

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

[Mathieu Malaterre]

Hi Samuel,

On Tue, Sep 6, 2016 at 2:32 AM, Samuel Thibault  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 : 0x9800
>> 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.

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

[Samuel Thibault]

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 : 0x9800
> 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.

Samuel

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

[Samuel Thibault]

Samuel Thibault, on Tue 06 Sep 2016 01:10:07 +0200, wrote:
> BTW, are only the blue and red colors inverted, or are some other colors
> (black, white, gray) inverted too?

An actual screen shot would be welcome to make sure how colors get
mangled precisely.

Samuel

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

[Samuel Thibault]

BTW, are only the blue and red colors inverted, or are some other colors
(black, white, gray) inverted too?

Samuel

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

[Mathieu Malaterre]

Hi Samuel !

On Sun, Sep 4, 2016 at 11:07 PM, Samuel Thibault  wrote:
> Hello,
>
> Mathieu Malaterre, on Sat 03 Sep 2016 16:00:15 +0200, wrote:
>> Some more information. I do not believe this is a 'simple' missing
>> byteswap operation in bterm source code.
>>
>> During debian-installer if I boot using:
>>
>> > install32
>>
>> I can observe the red/blue inversion (using an OFFb fb)
>>
>> Now if I do:
>>
>> > install32 video=offb:off
>>
>> I *cannot* observe the red/blue inversion (using a radeonfb fb).
> [...]
>> So there is something very subbtle (at least to me) that makes bterm
>> have a different behavior in OFFb vs radeonfb cases.
>
> Could you run the attached test in both cases?

$ gcc -o t test.c

Leads to:

$ more test.offb.txt test.radeonfb.txt
::
test.offb.txt
::
0 0 3
::
test.radeonfb.txt
::
0 0 3

I am also including the output of fbset -i in both cases as well:

$ more fbset.offb.txt fbset.radeonfb.txt
::
fbset.offb.txt
::

mode "800x600-186"
# D: 100.000 MHz, H: 119.048 kHz, V: 186.012 Hz
geometry 800 600 800 600 8
timings 1 16 16 16 16 8 8
rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
Name: OFfb ATY,RockHo
Address : 0x9c008000
Size: 614400
Type: PACKED PIXELS
Visual  : PSEUDOCOLOR
XPanStep: 0
YPanStep: 0
YWrapStep   : 0
LineLength  : 1024
Accelerator : No
::
fbset.radeonfb.txt
::

mode "1680x1050-60"
# D: 146.263 MHz, H: 65.296 kHz, V: 59.960 Hz
geometry 1680 1050 1680 1050 8
timings 6837 280 104 30 3 176 6
hsync high
rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
Name: ATI Radeon 5962
Address : 0x9800
Size: 33554432
Type: PACKED PIXELS
Visual  : PSEUDOCOLOR
XPanStep: 8
YPanStep: 1
YWrapStep   : 0
LineLength  : 1728
MMIO Address: 0x9000
MMIO Size   : 16384
Accelerator : ATI Radeon family


Thanks !

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

[Samuel Thibault]

Hello,

Mathieu Malaterre, on Sat 03 Sep 2016 16:00:15 +0200, wrote:
> Some more information. I do not believe this is a 'simple' missing
> byteswap operation in bterm source code.
> 
> During debian-installer if I boot using:
> 
> > install32
> 
> I can observe the red/blue inversion (using an OFFb fb)
> 
> Now if I do:
> 
> > install32 video=offb:off
> 
> I *cannot* observe the red/blue inversion (using a radeonfb fb).
[...]
> So there is something very subbtle (at least to me) that makes bterm
> have a different behavior in OFFb vs radeonfb cases.

Could you run the attached test in both cases?

Samuel
#include 
#include 
#include 
#include 
int main(void) {
  int fb;
  struct fb_fix_screeninfo fb_fix;

  fb = open ("/dev/fb0", O_RDWR);
  if (fb < 0)
fb = open ("/dev/fb/0", O_RDWR);
  if (fb < 0)
return 1;

  if (-1 == ioctl (fb, FBIOGET_FSCREENINFO, _fix))
  return 1;
  
  printf("%d %d %d\n",
  fb_fix.type,
  fb_fix.type_aux,
  fb_fix.visual);
}

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

[Mathieu Malaterre]

Some more information. I do not believe this is a 'simple' missing
byteswap operation in bterm source code.

During debian-installer if I boot using:

> install32

I can observe the red/blue inversion (using an OFFb fb)

Now if I do:

> install32 video=offb:off

I *cannot* observe the red/blue inversion (using a radeonfb fb).

I did check in both case, that the fb are setup the same way at least
how I understand it. I can Ctrl+Alt+2 to switch to an alternate shell
during installation and then type:

Print in blue:

# dd=/dev/zero ibs=1K count=600 | tr '\000' '\001' > /dev/fb0

Print in red:

# dd=/dev/zero ibs=1K count=600 | tr '\000' '\004' > /dev/fb0

(I simply replace count=600 with count=1840 when using radeonfb)

So there is something very subbtle (at least to me) that makes bterm
have a different behavior in OFFb vs radeonfb cases.

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

[Mathieu Malaterre]

Control: reassign -1 bogl-bterm 0.1.18-11

> Hopefully this is the last time I re-assign this bug.

Spoke too soon. This time should be right.

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

[Mathieu Malaterre]

Control: reassign -1 bterm-unifont 1.4
Control: retitle -1 bterm: inverts red and blue in localechooser

On Sat, Sep 3, 2016 at 11:37 AM, Mathieu Malaterre  wrote:
> On Fri, Sep 2, 2016 at 9:28 PM, Ben Hutchings  wrote:
>> Control: tag -1 moreinfo
>>
>> On Fri, 2016-09-02 at 20:56 +0200, Mathieu Malaterre wrote:
>>> Control: reassign -1 localechooser 2.68
>>> Control: retitle -1 localechooser: image display inverts red and blue
>>> color
>>
>> How could this possibly be the fault of localechooser?
>
> Right. Either way:
>
> 1. debian-installer is calling localechooser with a non-default option
> (I could not find which)
> 2. localechooser is reading some env variables.
>
> In both cases it starts rendering in some byte-swapped color mode,
> which I believe should be removed or at least clarified so that case
> (1) is changed in debian-installer.
>
> Comments ?

Answering myself:

With the default TERM=linux, localechooser behave as expected on
PowerPC/MacMiniG4

# localechooser

However with TERM=bterm, localechooser behave in some sort of inverted
(byte-swap?) red is blue background:

# bterm -f /lib/unifont.bgf localchooser

Hopefully this is the last time I re-assign this bug.

Thanks

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

[Mathieu Malaterre]

On Fri, Sep 2, 2016 at 9:28 PM, Ben Hutchings  wrote:
> Control: tag -1 moreinfo
>
> On Fri, 2016-09-02 at 20:56 +0200, Mathieu Malaterre wrote:
>> Control: reassign -1 localechooser 2.68
>> Control: retitle -1 localechooser: image display inverts red and blue
>> color
>
> How could this possibly be the fault of localechooser?

Right. Either way:

1. debian-installer is calling localechooser with a non-default option
(I could not find which)
2. localechooser is reading some env variables.

In both cases it starts rendering in some byte-swapped color mode,
which I believe should be removed or at least clarified so that case
(1) is changed in debian-installer.

Comments ?

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

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2016-09-02 at 20:56 +0200, Mathieu Malaterre wrote:
> Control: reassign -1 localechooser 2.68
> Control: retitle -1 localechooser: image display inverts red and blue
> color

How could this possibly be the fault of localechooser?

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


signature.asc
Description: This is a digitally signed message part

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

[Mathieu Malaterre]

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.