Skip to contentSkip to conversation

stifb problem on a 715/100 - sti= parameter broken?

parisc-linux Stuart Brady 1 participant 2 messages Aug 23, 2004

lore
Share & tools
lore
#0 lore raw

Hi,

I can't get the console to work on a 715/100. The console path is set to "graphics.9" which refers to the built-in hardware. There's an HCRX-24 card attached (graphics_1), but I don't have a monitor for that.

PALO chooses sti=1, and 2.4 kernels work fine with sti=1. If I boot with sti=0, I last thing I see is the "If this is the last message you see, you may need to switch your console" message, which is expected since it's presumably using the HCRX card for output.

If I boot a 2.6 kernel, I get the "If this is the last message you see" message regardless of what sti is set to. Does anyone know what I'm doing wrong? I've searched the lists, but I haven't found anything yet except for references to a similar problem in 2.4 in 2001-2002.

"cat /dev/fb0 > /dev/fb1" copies console text to the screen, so it seems that the framebuffer is working correctly, but the wrong device is being used for the console.

Thanks,

Signature · 5 lines
Stuart Brady
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
#1 lore raw

Re: [parisc-linux] [PATCH] sti= parameter ignored by stifb

Quoted 4 lines · Stuart Brady

If I boot a 2.6 kernel, I get the "If this is the last message you see" message regardless of what sti is set to. Does anyone know what I'm doing wrong? I've searched the lists, but I haven't found anything yet except for references to a similar problem in 2.4 in 2001-2002.

I've had a look at the code and I think I've found the problem... Framebuffers are added in their sti_get_rom() sequence. In 2.4, sti_get_rom(0) (the default sti) was included in this, which presumably results in two framebuffers sharing the same sti struct (badness?)

In 2.6, sti_get_rom(0) is not included, and sti_get_rom(1) is the first one to be added. It looks as through whichever framebuffer is initialised first gets the console. On my machine, sti_get_rom(1) refers to the HCRX card (sti=0), and sti_get_rom(2) (sti=1) refers to the built-in graphics.

This patch below works for me, although there's a nasty glitch when booting up (the screen doesn't scroll properly, and new messages are written to the top-most line - this goes away once init starts.) I don't know whether there's anything else that needs fixing, too.

Index: drivers/video/stifb.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/video/stifb.c,v retrieving revision 1.7

video/stifb.c +12 -1
diff -u -r1.7 stifb.c
@@ -1379,6 +1379,7 @@
 stifb_init(void)
 {
 	struct sti_struct *sti;
+	struct sti_struct *def_sti;
 	int i;
 	
 	if (stifb_disabled) {
@@ -1386,9 +1387,19 @@
 		return -ENXIO;
 	}
 	
+	def_sti = sti_get_rom(0);
+	if (def_sti) {
+		for (i = 1; i < MAX_STI_ROMS; i++) {
+			sti = sti_get_rom(i);
+			if (sti == def_sti && bpp > 0)
+				stifb_force_bpp[i] = bpp;
+		}
+		stifb_init_fb(def_sti, stifb_force_bpp[i]);
+	}
+
 	for (i = 1; i < MAX_STI_ROMS; i++) {
 		sti = sti_get_rom(i);
-		if (!sti)
+		if (!sti || sti==def_sti)
 			break;
 		if (bpp > 0)
 			stifb_force_bpp[i] = bpp;
Signature · 5 lines
Stuart Brady
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux