Fwd: Re: [parisc-linux] Re: STI crash on B132L with HCRX-24

Fwd: Re: [parisc-linux] Re: STI crash on B132L with HCRX-24

[Johannes Raspe]

Hi Helge,

I just noticed that I lost my text-console. Don't know if this is the patched 
stifb.c (I cant' check either :-)). The getty processes are started on tty1 
to tty6, but switching to those consoles with "CTRL+ALT+F1-6" only gives a 
black screen.
After switching system-console to graphics there are no bootmessages, I have 
to switch back to serial console to see them.
X-Server still is working fine.

Any suggestions?

Best regards Johannes

----------  Weitergeleitete Nachricht  ----------

Subject: Re: [parisc-linux] Re: STI crash on B132L with HCRX-24
Date: Freitag, 29. Oktober 2004 21:35
From: Johannes Raspe <j.raspe@t-online.de>
To: Helge Deller <deller@gmx.de>
Cc: "Andy Walker" <ajwalker@broadpark.no>, parisc-linux@lists.parisc-linux.org

Am Donnerstag, 28. Oktober 2004 23:51 schrieb Helge Deller:
> Hi,
>
> could you please test this patch to stifb.c ?
> It compiles, but is else absolutely untested....
>
> Helge

Hi Helge,

you are a wizard!!
After patching and compiling a 2.6.9-bk6-pa7-kernel it boots fine in 32bpp,
did not try 8bpp yet, but could do so if useful.
The hppa "boot-penguin" looks a little bit psychedlic but everything,
 included X-server with "DefaultDepth 24", runs fine.
Will this patch make it into the kernel tree?

Many thanks for your work

Johannes

--
Johannes Raspe - j.raspe@t-online.de
GnuPG-Key ID: D342E105
Fingerprint: D681 F800 FB2D 913E D14C 1F17 C3DB B1F1 D342 E105

-------------------------------------------------------

-- 
Johannes Raspe - j.raspe@t-online.de
GnuPG-Key ID: D342E105
Fingerprint: D681 F800 FB2D 913E D14C 1F17 C3DB B1F1 D342 E105

Re: Fwd: Re: [parisc-linux] Re: STI crash on B132L with HCRX-24

[Helge Deller]

Hi Johannes,

On Friday 29 October 2004 22:28, Johannes Raspe wrote:
> I just noticed that I lost my text-console. Don't know if this is the patched 
> stifb.c (I cant' check either :-)). 

I don't think so.

> The getty processes are started on tty1  to tty6, but switching to those consoles 
> with "CTRL+ALT+F1-6" only gives a  black screen.

Just tested and this works for me on 8bpp with Artist-gfx on a 715/64.

> After switching system-console to graphics there are no bootmessages, I have 
> to switch back to serial console to see them.
> X-Server still is working fine. 
> 
> Any suggestions?

Do you still boot via serial console or is the cable still connected ? 
If yes, please stop at the IPL and delete the line "console=ttyS0", which is auto-appended by palo if you boot from serial console.

You wrote in another mail:
> The hppa "boot-penguin" looks a little bit psychedlic...

could you describe this more exactly. Does the colors seem exchanged (e.g. red is blue and vice-versa) ?

Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: Fwd: Re: [parisc-linux] Re: STI crash on B132L with HCRX-24

[Johannes Raspe]

Hi Helge,

> Hi Johannes,
>
> On Friday 29 October 2004 22:28, Johannes Raspe wrote:
> > I just noticed that I lost my text-console. Don't know if this is the
> > patched stifb.c (I cant' check either :-)).
>
> I don't think so.

I had a strang idea about the text-consoles and it was right: The consoles are 
present, but they are black text on black background.
I can type in commands blindly and they are executed, but I don't see them. So 
it seems to be a minor problem with your patch I think. Somehow the colors 
got screwed up in textmode.

> > The getty processes are started on tty1  to tty6, but switching to those
> > consoles with "CTRL+ALT+F1-6" only gives a  black screen.
>
> Just tested and this works for me on 8bpp with Artist-gfx on a 715/64.
>
> > After switching system-console to graphics there are no bootmessages, I
> > have to switch back to serial console to see them.
> > X-Server still is working fine.
> >
> > Any suggestions?
>
> Do you still boot via serial console or is the cable still connected ?
> If yes, please stop at the IPL and delete the line "console=ttyS0", which
> is auto-appended by palo if you boot from serial console.

No, I changed the path to graphics in boot admin.

> You wrote in another mail:
> > The hppa "boot-penguin" looks a little bit psychedlic...
>
> could you describe this more exactly. Does the colors seem exchanged (e.g.
> red is blue and vice-versa) ?

The background of the penguin is green where it should be black. This is the  
obvious change. The rest just looks weird. If it helps I could make a picture 
of it.

> Helge

Regards Johannes

-- 
Johannes Raspe - j.raspe@t-online.de
GnuPG-Key ID: D342E105
Fingerprint: D681 F800 FB2D 913E D14C 1F17 C3DB B1F1 D342 E105

Re: Fwd: Re: [parisc-linux] Re: STI crash on B132L with HCRX-24

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

Hi Johannes,

could you test the attached patch ?
Until now, we only saved the pseudo_palette with max. 16 entries - maybe for 24/32bpp we need to save 256 entries...

Helge


On Sunday 31 October 2004 10:10, Johannes Raspe wrote:
> Hi Helge,
> 
> > Hi Johannes,
> >
> > On Friday 29 October 2004 22:28, Johannes Raspe wrote:
> > > I just noticed that I lost my text-console. Don't know if this is the
> > > patched stifb.c (I cant' check either :-)).
> >
> > I don't think so.
> 
> I had a strang idea about the text-consoles and it was right: The consoles are 
> present, but they are black text on black background.
> I can type in commands blindly and they are executed, but I don't see them. So 
> it seems to be a minor problem with your patch I think. Somehow the colors 
> got screwed up in textmode.
> 
> > > The getty processes are started on tty1  to tty6, but switching to those
> > > consoles with "CTRL+ALT+F1-6" only gives a  black screen.
> >
> > Just tested and this works for me on 8bpp with Artist-gfx on a 715/64.
> >
> > > After switching system-console to graphics there are no bootmessages, I
> > > have to switch back to serial console to see them.
> > > X-Server still is working fine.
> > >
> > > Any suggestions?
> >
> > Do you still boot via serial console or is the cable still connected ?
> > If yes, please stop at the IPL and delete the line "console=ttyS0", which
> > is auto-appended by palo if you boot from serial console.
> 
> No, I changed the path to graphics in boot admin.
> 
> > You wrote in another mail:
> > > The hppa "boot-penguin" looks a little bit psychedlic...
> >
> > could you describe this more exactly. Does the colors seem exchanged (e.g.
> > red is blue and vice-versa) ?
> 
> The background of the penguin is green where it should be black. This is the  
> obvious change. The rest just looks weird. If it helps I could make a picture 
> of it.
> 
> > Helge
> 
> Regards Johannes

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1343 bytes --]

Index: stifb.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/video/stifb.c,v
retrieving revision 1.11
diff -u -p -r1.11 stifb.c
--- stifb.c	29 Oct 2004 22:59:50 -0000	1.11
+++ stifb.c	31 Oct 2004 12:10:46 -0000
@@ -112,7 +112,7 @@ struct stifb_info {
 	ngle_rom_t ngle_rom;
 	struct sti_struct *sti;
 	int deviceSpecificConfig;
-	u32 pseudo_palette[16];
+	u32 pseudo_palette[256];
 };
 
 static int __initdata bpp = 8;	/* parameter from modprobe */
@@ -1018,6 +1018,16 @@ stifb_setcolreg(u_int regno, u_int red, 
 			 (blue));
 	}
 
+	if (info->var.bits_per_pixel == 32) {
+		((u32 *)(info->pseudo_palette))[regno] =
+			(red   << info->var.red.offset)   |
+			(green << info->var.green.offset) |
+			(blue  << info->var.blue.offset);
+	} else {
+		((u32 *)(info->pseudo_palette))[regno] = regno;
+	}
+
+
 	WRITE_IMAGE_COLOR(fb, regno, color);
 	
 	if (fb->id == S9000_ID_HCRX) {
@@ -1031,14 +1041,6 @@ stifb_setcolreg(u_int regno, u_int red, 
 				/* 0x100 is same as used in WRITE_IMAGE_COLOR() */
 		START_COLORMAPLOAD(fb, lutBltCtl.all);
 		SETUP_FB(fb);
-
-		/* info->var.bits_per_pixel == 32 */
-		if (regno < 16) 
-		  ((u32 *)(info->pseudo_palette))[regno] =
-			(red   << info->var.red.offset)   |
-			(green << info->var.green.offset) |
-			(blue  << info->var.blue.offset);

Re: Fwd: Re: [parisc-linux] Re: STI crash on B132L with HCRX-24

[Johannes Raspe]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Am Sonntag, 31. Oktober 2004 13:12 schrieb Helge Deller:
> Hi Johannes,
>
> could you test the attached patch ?
> Until now, we only saved the pseudo_palette with max. 16 entries - maybe
> for 24/32bpp we need to save 256 entries...
>
> Helge

Hi Helge,

great work! I got my text-consoles back!
For solving the (cosmetical) penguin-color-problem I took a shot with my 
digicam and attached it (sorry for poor quality).

Regards Johannes

-- 
Johannes Raspe - j.raspe@t-online.de
GnuPG-Key ID: D342E105
Fingerprint: D681 F800 FB2D 913E D14C 1F17 C3DB B1F1 D342 E105

[-- Attachment #2: penguin-logo.jpg --]
[-- Type: image/jpeg, Size: 10427 bytes --]

Penguin color problems on HCRX-24 (was: [parisc-linux] Re: STI crash on B132L with HCRX-24)

[Helge Deller]

Hi Johannes,

On Sunday 31 October 2004 14:06, Johannes Raspe wrote:
> For solving the (cosmetical) penguin-color-problem I took a shot with my 
> digicam and attached it (sorry for poor quality).

I was hoping my last patch would have fixed this too. Oh well :-)

Right now I don't have any real idea why the penguin colors are wrong.
But I have two assumptions:
a) cfb_imageblit() works wrong in the current tree with 24/32bpp output and 8bpp input on big endian
b) fb_set_logo_truepalette() creates a wrong palette for 24bpp output [but this function seems correct IMHO].

Both of those I'm currently lost without any testing possibility, but I'll continue to look into it.

BTW, does everything else seemscorrect wrt. colors on the text console, e.g. does midnight command shows blue background ?

Regards,
Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: Penguin color problems on HCRX-24 (was: [parisc-linux] Re: STI crash on B132L with HCRX-24)

[Johannes Raspe]

Hi Helge,

> > For solving the (cosmetical) penguin-color-problem I took a shot with my
> > digicam and attached it (sorry for poor quality).
>
> I was hoping my last patch would have fixed this too. Oh well :-)
>
> Right now I don't have any real idea why the penguin colors are wrong.
> But I have two assumptions:
> a) cfb_imageblit() works wrong in the current tree with 24/32bpp output and
> 8bpp input on big endian b) fb_set_logo_truepalette() creates a wrong
> palette for 24bpp output [but this function seems correct IMHO].
>
> Both of those I'm currently lost without any testing possibility, but I'll
> continue to look into it.
>
> BTW, does everything else seemscorrect wrt. colors on the text console,
> e.g. does midnight command shows blue background ?

Yes. mc looks normal and a "make menuconfig" shows the right colors too.

> Regards,
> Helge

Regards Johannes

-- 
Johannes Raspe - j.raspe@t-online.de
GnuPG-Key ID: D342E105
Fingerprint: D681 F800 FB2D 913E D14C 1F17 C3DB B1F1 D342 E105

Re: Penguin color problems on HCRX-24

[Andy Walker]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

Hi all,

Just to report that I'm basically seeing the same things as Johannes with
Helge's patches. I'm still compiling Helge's latest patch and I'll report
back when I've had a chance to test it.

I'd like to submit the patch below to sanitize the stifb=bpp:x:y:z option
handling. The recent patch (by Stuart Brady?) made fb initialization stop
early once the default sti fb was initialized, possibly leaving other fb's
uninitialized. Also the handling of a "global default" bpp was rather
wacky,
and some array index/bounds problems were fixed.

Is initdata guaranteed to be zero'ed? If so then the loop setting all the
elements of stifb_bpp_pref to zero can be dropped. The patch has been
tested with two fb's, switching console fb either by PDC or using the
'sti=' commandline option.

cheers,

-Andy



[-- Attachment #2: stifb.c.awa.ud --]
[-- Type: application/octet-stream, Size: 2310 bytes --]

--- stifb.c.orig	2004-10-31 19:12:52.114548000 +0100
+++ stifb.c	2004-10-31 19:25:01.644548000 +0100
@@ -115,8 +115,7 @@
 	u32 pseudo_palette[16];
 };
 
-static int __initdata bpp = 8;	/* parameter from modprobe */
-static int __initdata stifb_force_bpp[MAX_STI_ROMS];
+static int __initdata stifb_bpp_pref[MAX_STI_ROMS];
 
 /* ------------------- chipset specific functions -------------------------- */
 
@@ -1156,7 +1155,7 @@
  */
 
 int __init
-stifb_init_fb(struct sti_struct *sti, int force_bpp)
+stifb_init_fb(struct sti_struct *sti, int bpp_pref)
 {
 	struct fb_fix_screeninfo *fix;
 	struct fb_var_screeninfo *var;
@@ -1259,8 +1258,8 @@
 #endif
 		fb->deviceSpecificConfig = __raw_readl(sti_rom_address);
 		if (IS_24_DEVICE(fb)) {
-			if (force_bpp == 8 || force_bpp == 32)
-				bpp = force_bpp;
+			if (bpp_pref == 8 || bpp_pref == 32)
+				bpp = bpp_pref;
 			else
 				bpp = 32;
 		} else
@@ -1410,21 +1409,24 @@
 	
 	def_sti = sti_get_rom(0);
 	if (def_sti) {
-		for (i = 1; i < MAX_STI_ROMS; i++) {
+		for (i = 1; i <= MAX_STI_ROMS; i++) {
 			sti = sti_get_rom(i);
-			if (sti == def_sti && bpp > 0)
-				stifb_force_bpp[i] = bpp;
+			if (!sti)
+				break;
+			if (sti == def_sti) {
+				stifb_init_fb(sti, stifb_bpp_pref[i - 1]);
+				break;
+			}
 		}
-		stifb_init_fb(def_sti, stifb_force_bpp[i]);
 	}
 
-	for (i = 1; i < MAX_STI_ROMS; i++) {
+	for (i = 1; i <= MAX_STI_ROMS; i++) {
 		sti = sti_get_rom(i);
-		if (!sti || sti==def_sti)
+		if (!sti)
 			break;
-		if (bpp > 0)
-			stifb_force_bpp[i] = bpp;
-		stifb_init_fb(sti, stifb_force_bpp[i]);
+		if (sti == def_sti)
+			continue;
+		stifb_init_fb(sti, stifb_bpp_pref[i - 1]);
 	}
 	return 0;
 }
@@ -1439,7 +1441,7 @@
 	struct sti_struct *sti;
 	int i;
 	
-	for (i = 1; i < MAX_STI_ROMS; i++) {
+	for (i = 1; i <= MAX_STI_ROMS; i++) {
 		sti = sti_get_rom(i);
 		if (!sti)
 			break;
@@ -1468,13 +1470,15 @@
 		options += 3;
 	}
 
+	for (i = 0; i < MAX_STI_ROMS; i++)
+		stifb_bpp_pref[i] = 0;
+
 	if (strncmp(options, "bpp", 3) == 0) {
 		options += 3;
 		for (i = 0; i < MAX_STI_ROMS; i++) {
-			if (*options++ == ':') {
-				stifb_force_bpp[i] = simple_strtoul(options, &options, 10);
-				bpp = -1;
-			} else
+			if (*options++ == ':')
+				stifb_bpp_pref[i] = simple_strtoul(options, &options, 10);
+			else
 				break;
 		}
 	}

[parisc-linux] Re: Penguin color problems on HCRX-24

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Sunday 31 October 2004 23:20, Andy Walker wrote:
> I'd like to submit the patch below to sanitize the stifb=bpp:x:y:z option
> handling. The recent patch (by Stuart Brady?) made fb initialization stop
> early once the default sti fb was initialized, possibly leaving other fb's
> uninitialized. 

yes - this is a bug.

> Also the handling of a "global default" bpp was rather wacky, 

I liked that idea. No need to initialize all bpps.

> and some array index/bounds problems were fixed. 

Correct.

> Is initdata guaranteed to be zero'ed? If so then the loop setting all the
> elements of stifb_bpp_pref to zero can be dropped. 

Yes, it's guaranteed.

> The patch has been tested with two fb's, switching console fb either by PDC or using the
> 'sti=' commandline option.

Could you please test the attached patch instead. It is based on your patch, but the "global bpp" is still there.

Helge


[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1210 bytes --]

Index: drivers/video/stifb.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/video/stifb.c,v
retrieving revision 1.13
diff -u -p -r1.13 stifb.c
--- drivers/video/stifb.c	31 Oct 2004 21:07:55 -0000	1.13
+++ drivers/video/stifb.c	1 Nov 2004 12:40:26 -0000
@@ -1411,21 +1411,27 @@ stifb_init(void)
 	
 	def_sti = sti_get_rom(0);
 	if (def_sti) {
-		for (i = 1; i < MAX_STI_ROMS; i++) {
+		/* initialize default sti before all others */
+		for (i = 1; i <= MAX_STI_ROMS; i++) {
 			sti = sti_get_rom(i);
-			if (sti == def_sti && bpp > 0)
-				stifb_force_bpp[i] = bpp;
+			if (sti != def_sti)
+				continue;
+			if (bpp > 0)
+				stifb_force_bpp[i-1] = bpp;
+			stifb_init_fb(def_sti, stifb_force_bpp[i-1]);
+			break;
 		}
-		stifb_init_fb(def_sti, stifb_force_bpp[i]);
 	}
 
-	for (i = 1; i < MAX_STI_ROMS; i++) {
+	for (i = 1; i <= MAX_STI_ROMS; i++) {
 		sti = sti_get_rom(i);
-		if (!sti || sti==def_sti)
+		if (!sti)
 			break;
+		if (sti == def_sti)
+			continue;
 		if (bpp > 0)
-			stifb_force_bpp[i] = bpp;
-		stifb_init_fb(sti, stifb_force_bpp[i]);
+			stifb_force_bpp[i-1] = bpp;
+		stifb_init_fb(sti, stifb_force_bpp[i-1]);
 	}
 	return 0;
 }

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: Penguin color problems on HCRX-24

[Andy Walker]

> On Sunday 31 October 2004 23:20, Andy Walker wrote:
>> I'd like to submit the patch below to sanitize the stifb=bpp:x:y:z
>> option
>> handling. The recent patch (by Stuart Brady?) made fb initialization
>> stop
>> early once the default sti fb was initialized, possibly leaving other
>> fb's
>> uninitialized.
>
> yes - this is a bug.
>
>> Also the handling of a "global default" bpp was rather wacky,
>
> I liked that idea. No need to initialize all bpps.
>
>> and some array index/bounds problems were fixed.
>
> Correct.
>
>> Is initdata guaranteed to be zero'ed? If so then the loop setting all
>> the
>> elements of stifb_bpp_pref to zero can be dropped.
>
> Yes, it's guaranteed.
>
>> The patch has been tested with two fb's, switching console fb either by
>> PDC or using the
>> 'sti=' commandline option.
>
> Could you please test the attached patch instead. It is based on your
> patch, but the "global bpp" is still there.
>
> Helge
>

Hi Helge,

The logic is all wrong though IMHO. What it say is:

- If I have specified a bpp for *ANY* fb, then default
  the others to their "capability" - for HCRX24 this is 32.

- If I have not specified any bpp's then default to 8bpp
  on all.

e.g. with a Vis-EG on fb0 and an HCRX24's on fb1 and the commandline:

  stif=bpp:8

fb0 comes up 8bpp and fb1 comes up 32bpp, but with no commandline
they both come up 8bpp. That's weird.

My change made the logic:

- Default all fb's to their "capability", except where the
  user says otherwise for a given fb (you can default an fb
  by setting 0 e.g. stifb=bpp=0:8).

By "capability" I mean the default value in sti_init_fb.

I can live with either solution though, as long as the code
works as advertised :-)

-Andy

[parisc-linux] Re: Penguin color problems on HCRX-24

[Helge Deller]

On Monday 01 November 2004 15:03, Andy Walker wrote:
> Hi Helge,
> 
> The logic is all wrong though IMHO. What it say is:
> 
> - If I have specified a bpp for *ANY* fb, then default
>   the others to their "capability" - for HCRX24 this is 32.
> 
> - If I have not specified any bpp's then default to 8bpp
>   on all.
> 
> e.g. with a Vis-EG on fb0 and an HCRX24's on fb1 and the commandline:
> 
>   stif=bpp:8
> 
> fb0 comes up 8bpp and fb1 comes up 32bpp, but with no commandline
> they both come up 8bpp. That's weird.
> 
> My change made the logic:
> 
> - Default all fb's to their "capability", except where the
>   user says otherwise for a given fb (you can default an fb
>   by setting 0 e.g. stifb=bpp=0:8).

Ok - please commit your patch, but without this unnecessary part:
+       for (i = 0; i < MAX_STI_ROMS; i++)
+               stifb_bpp_pref[i] = 0;

Rgs,
Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: Penguin color problems on HCRX-24 (was: [parisc-linux] Re: STI crash on B132L with HCRX-24)

[Andy Walker]

> Hi Johannes,
>
> On Sunday 31 October 2004 14:06, Johannes Raspe wrote:
>> For solving the (cosmetical) penguin-color-problem I took a shot with my
>> digicam and attached it (sorry for poor quality).
>
> I was hoping my last patch would have fixed this too. Oh well :-)
>
> Right now I don't have any real idea why the penguin colors are wrong.
> But I have two assumptions:
> a) cfb_imageblit() works wrong in the current tree with 24/32bpp output
> and 8bpp input on big endian
> b) fb_set_logo_truepalette() creates a wrong palette for 24bpp output [but
> this function seems correct IMHO].
>
> Both of those I'm currently lost without any testing possibility, but I'll
> continue to look into it.
>
> BTW, does everything else seemscorrect wrt. colors on the text console,
> e.g. does midnight command shows blue background ?
>
> Regards,
> Helge
>

Hi Helge,

Will get the HCRX24 in the post tomorrow or Tuesday.

The good news with your latest patch is that an HCRX24 on fb1 doesn't
boot up bright magenta anymore - it comes up black. When the HCRX24 is
fb0 and I run X11,  the colour palette is correct on exit and the
virtual consoles all have correct colours. Excellent!

I get the black for green psychedelic tux on boot like Johannes.

The big problem with HCR24 in 32bpp is that the X server only uses
three quarters of the screen width - the last quarter remains black.
Screen content in the visible three quarters is horizontally squashed (i.e.
the image that would have filled the whole width is displayed in 3/4)
and there are colour artefacts on edges, fonts etc.

cheers,
-Andy