2.6.7 still garbage upon start

2.6.7 still garbage upon start

[Thomas Winischhofer]

modprobing fbcon still paints a white rectangle. Difference to 2.6.6 is 
that this rectangle now fills the entire screen instead of a smaller 
area. As before, text is shown all correctly (painted upon the 
rectangle), and the white rectangle scrolls up just like text and in the 
end vanishes.

Switching to another VT while in X still leaves you with a blank screen 
and a blinking cursor. If one presses return, the screen contents is 
restored.

Hm?

(fbdev driver: sisfb 1.7.13 as of current -mm; kernel vanilla 2.6.7. 
Don't see any relevant changes in the -mm tree either.)

-- 
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/
twini AT xfree86 DOT org


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Antonino A. Daplas]

On Friday 18 June 2004 06:41, Thomas Winischhofer wrote:
> modprobing fbcon still paints a white rectangle. Difference to 2.6.6 is
> that this rectangle now fills the entire screen instead of a smaller
> area. As before, text is shown all correctly (painted upon the
> rectangle), and the white rectangle scrolls up just like text and in the
> end vanishes.
>

The white screen is the result of fbdev being initialized before vgacon is
deinitialized.  I can't find a simple solution for this except to disable vgacon
if fbcon is compiled statically.  Currently vgacon is always enabled in X86, so
I use this in drivers/video/console/Kconfig.

config VGA_CONSOLE
	bool "VGA text console" if EMBEDDED || !X86
	depends on !ARCH_ACORN && !ARCH_EBSA110 && !4xx && !8xx && !SPARC32 &&	!SPARC64 && !M68K && FRAMEBUFFER_CONSOLE != y

> Switching to another VT while in X still leaves you with a blank screen
> and a blinking cursor. If one presses return, the screen contents is
> restored.

You mean switching from X to another VT?  At least you just get a blank screen,
with other drivers, sometimes the machine hangs. 

(I have code I'm planning to send for RFC that will notify the low-level driver if 
switching from KD_GRAPHICS->KD_TEXT and vice versa or if multiple
drivers are mapped to different consoles. However, it seems BenH already has
code for this so I'm holding the submission.  I just can't find BenH's changes in
2.6.7 or -mm.  Hey Ben, where is it?)  

Tony




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Thomas Winischhofer]

Antonino A. Daplas wrote:
> On Friday 18 June 2004 06:41, Thomas Winischhofer wrote:
> 
>> modprobing fbcon still paints a white rectangle. Difference to
>> 2.6.6 is that this rectangle now fills the entire screen instead of
>> a smaller area. As before, text is shown all correctly (painted
>> upon the rectangle), and the white rectangle scrolls up just like
>> text and in the end vanishes.
>> 
> 
> 
> The white screen is the result of fbdev being initialized before
> vgacon is deinitialized.  I can't find a simple solution for this
> except to disable vgacon if fbcon is compiled statically.  Currently
> vgacon is always enabled in X86, so I use this in
> drivers/video/console/Kconfig.
> 
> config VGA_CONSOLE bool "VGA text console" if EMBEDDED || !X86 
> depends on !ARCH_ACORN && !ARCH_EBSA110 && !4xx && !8xx && !SPARC32
> &&	!SPARC64 && !M68K && FRAMEBUFFER_CONSOLE != y


What the heck does vgacon when being deinitialized? Is it supposed to 
write to video memory at this stage? Granted, I haven't looked at the 
vgacon code but that seems a bit strange.


>> Switching to another VT while in X still leaves you with a blank
>> screen and a blinking cursor. If one presses return, the screen
>> contents is restored.
> 
> 
> You mean switching from X to another VT?  At least you just get a
> blank screen, with other drivers, sometimes the machine hangs.


Well, that might be due to the fact that me, myself and I develope both
the X driver as well as the framebuffer driver ;)


> (I have code I'm planning to send for RFC that will notify the
> low-level driver if switching from KD_GRAPHICS->KD_TEXT and vice
> versa or if multiple drivers are mapped to different consoles.
> However, it seems BenH already has code for this so I'm holding the
> submission.  I just can't find BenH's changes in 2.6.7 or -mm.  Hey
> Ben, where is it?)

Perhaps I am being naive, but I don't understand what the problem can 
be. X restores the display mode before initiating the VT change. And a 
VT change should restore the previous screen contents.

Please excuse if these are stupid comments, I lost track of the console 
code I while back.


Thomas

-- 
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net
twini AT xfree86 DOT org


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Geert Uytterhoeven]

On Fri, 18 Jun 2004, Thomas Winischhofer wrote:
> Antonino A. Daplas wrote:
> > On Friday 18 June 2004 06:41, Thomas Winischhofer wrote:
> >> modprobing fbcon still paints a white rectangle. Difference to
> >> 2.6.6 is that this rectangle now fills the entire screen instead of
> >> a smaller area. As before, text is shown all correctly (painted
> >> upon the rectangle), and the white rectangle scrolls up just like
> >> text and in the end vanishes.
> >
> > The white screen is the result of fbdev being initialized before
> > vgacon is deinitialized.  I can't find a simple solution for this
> > except to disable vgacon if fbcon is compiled statically.  Currently
> > vgacon is always enabled in X86, so I use this in
> > drivers/video/console/Kconfig.
> >
> > config VGA_CONSOLE bool "VGA text console" if EMBEDDED || !X86
> > depends on !ARCH_ACORN && !ARCH_EBSA110 && !4xx && !8xx && !SPARC32
> > &&	!SPARC64 && !M68K && FRAMEBUFFER_CONSOLE != y
>
> What the heck does vgacon when being deinitialized? Is it supposed to
> write to video memory at this stage? Granted, I haven't looked at the
> vgacon code but that seems a bit strange.

Lemme give some background: the virtual console subsystem keeps a copy of all
text+attributes (in VGA text mode format) for all VCs. This means that when
using vgacon, you actually have 2 copies of the same data: once in VGA text
memory, and a second copy in the VC subsystem buffers (called the `shadow
screen' when talking about the current VC).

Therefore, when using vgacon, an optimization is made by not always writing to
this `shadow screen' for the current VC, but only to the VGA text memory. And
when a VC switch is made, the `shadow screen' is updated by copying the VGA
text memory to it.

So when you initialize an fbdev (assuming a graphics chip with a VGA core, of
course ;-), there are some issues:
  - You cannot clear the frame buffer memory, since this is also used for the
    VGA text memory, and still contains the valid contents of the current VC,
    which haven't been updated in the `shadow screen' yet.
  - If you don't clear the frame buffer memory, you will see `random garbage',
    because to VGA text data is still there, and is being interpreted in a
    different way now (as graphics data).

Solution: before initializing and switching to a fbdev, save the contents of
the VGA text memory to the `shadow screen', so the fbdev can clear the frame
buffer memory, and fbcon can recover the current VC contents.

However, it makes things more complex and adds a vgacon dependency to some
code, since you want it to behave differently if people don't compile in
vgacon.

Final solution: VGA is obsolete ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[John Zielinski]

Geert Uytterhoeven wrote:

>Solution: before initializing and switching to a fbdev, save the contents of
>the VGA text memory to the `shadow screen', so the fbdev can clear the frame
>buffer memory, and fbcon can recover the current VC contents.
>
>However, it makes things more complex and adds a vgacon dependency to some
>code, since you want it to behave differently if people don't compile in
>vgacon.
>  
>
That was the old solution.  I found the root cause of the problem.   
There is no code in the vt subsystem to prevent output going to a 
console driver after it has been deinitialized.  The vga console does 
save the VGA memory to it's shadow screen when it's deinitialized but 
any printk's after that screw things up as it starts to output again to 
the screen.  Now the shadow screen and the real screen doesn't match 
anymore.

If it were possible to take over from fbcon to another console driver 
this would have caused an oops as the fbcon font data would have been 
freed at that point.  The vga console doesn't have any extra data that 
needs to be freed so that's why this bug was never noticed.

I posted a fix on May 6th to the vt take_over_console function which 
puts the console temporarily into KD_GRAPHICS so that all output between 
con_deinit and visual_init (where there is no active console driver) go 
to the shadow screen.  This is not vgacon specific and would also make 
it possible to switch between other console drivers without causing an oops.

>Final solution: VGA is obsolete ;-)
>  
>

I wish.  Hopefully the new EFI firmware on x86 platforms will initialize 
the video card into it's native graphics configuration so we can start 
dropping this excess VGA baggage we've been carrying for the last 
several years.  Of course there's always linuxbios as well.  :)  What's 
the story with VGA on other platforms? 

John




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Geert Uytterhoeven]

On Fri, 18 Jun 2004, John Zielinski wrote:
> Geert Uytterhoeven wrote:
> >Solution: before initializing and switching to a fbdev, save the contents of
> >the VGA text memory to the `shadow screen', so the fbdev can clear the frame
> >buffer memory, and fbcon can recover the current VC contents.
> >
> >However, it makes things more complex and adds a vgacon dependency to some
> >code, since you want it to behave differently if people don't compile in
> >vgacon.
> >
> That was the old solution.  I found the root cause of the problem.
> There is no code in the vt subsystem to prevent output going to a
> console driver after it has been deinitialized.  The vga console does
> save the VGA memory to it's shadow screen when it's deinitialized but
> any printk's after that screw things up as it starts to output again to
> the screen.  Now the shadow screen and the real screen doesn't match
> anymore.

Hence vgacon should be replaced by dummycon when it's deinitialized.

> >Final solution: VGA is obsolete ;-)
>
> I wish.  Hopefully the new EFI firmware on x86 platforms will initialize
> the video card into it's native graphics configuration so we can start
> dropping this excess VGA baggage we've been carrying for the last
> several years.  Of course there's always linuxbios as well.  :)  What's
> the story with VGA on other platforms?

(According to what I learned from the EFI talk at OLS last year) It's worse:
you have to talk to the EFI bytecode to draw text on UGA, no direct access to
the frame buffer ;-(

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[John Zielinski]

Geert Uytterhoeven wrote:

>Hence vgacon should be replaced by dummycon when it's deinitialized.
>
>  
>
I like that.  That way we're not depending on the old console driver to 
do the right thing when in KD_GRAPHICS.  Vgacon currently does but other 
console drivers might not.

I'll try that out tonight and see how it goes and then post the patch.

>(According to what I learned from the EFI talk at OLS last year) It's worse:
>you have to talk to the EFI bytecode to draw text on UGA, no direct access to
>the frame buffer ;-(
>  
>
Doh.  Let me guess, the interface was designed by a committee.....

John




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Antonino A. Daplas]

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

On Friday 18 June 2004 21:18, Geert Uytterhoeven wrote:
> On Fri, 18 Jun 2004, John Zielinski wrote:
> > Geert Uytterhoeven wrote:
> > >Solution: before initializing and switching to a fbdev, save the
> > > contents of the VGA text memory to the `shadow screen', so the fbdev
> > > can clear the frame buffer memory, and fbcon can recover the current VC
> > > contents.
> > >
> > >However, it makes things more complex and adds a vgacon dependency to
> > > some code, since you want it to behave differently if people don't
> > > compile in vgacon.
> >
> > That was the old solution.  I found the root cause of the problem.
> > There is no code in the vt subsystem to prevent output going to a
> > console driver after it has been deinitialized.  The vga console does
> > save the VGA memory to it's shadow screen when it's deinitialized but
> > any printk's after that screw things up as it starts to output again to
> > the screen.  Now the shadow screen and the real screen doesn't match
> > anymore.
>
> Hence vgacon should be replaced by dummycon when it's deinitialized.
>

Actually, to eliminate the white rectangle, we just need to initialize fbdev 
_after_ vgacon.  Currently, there is a set_par call in fbcon_startup()) which is
 called prior to vgacon_deinit.  

1. Solution: Move this set_par call to fbcon_init instead.

If the boot logo is not enabled, then everything is okay.  With the boot logo
enabled, you will see remnants of old text (not garbage) in the space 
provided for the logo.  

2. Solution:  Issue a fillrect to remove the remnants.

Finally, the current steps for making space for the logo is like this:

1. allocate save memory
2. save screen
3. clear space for boot logo in screen
4. redraw saved screen at origin + logo_height

The problem is between 3 and 4.  During 'redraw saved screen', vgacon 
copies contents from shadow screen to actual screen, so the cleared space
we created in step 4 is redrawn again.

3. Solution: Reverse steps 3 and 4.

I've include a patch that incorporates all of the above.  (It also has some fixes
for problems with creation of logo space -- the code does not consider that the
new VC window size is different or even smaller than the old VC window size).
Please test, and if it works for you, I'll push it upstream.

Diffs are against 2.6.7 and 2.6.7-rc3-mm2.

Tony


[-- Attachment #2: screen-2.6.7.diff --]
[-- Type: text/x-diff, Size: 4824 bytes --]

diff -Naur linux-2.6.7-orig/drivers/video/console/fbcon.c linux-2.6.7/drivers/video/console/fbcon.c
--- linux-2.6.7-orig/drivers/video/console/fbcon.c	2004-06-18 17:41:19.161273824 +0000
+++ linux-2.6.7/drivers/video/console/fbcon.c	2004-06-18 17:42:02.253722776 +0000
@@ -503,13 +503,6 @@
 		vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */
 	}
 
-	/*
-	 * We must always set the mode. The mode of the previous console
-	 * driver could be in the same resolution but we are using different
-	 * hardware so we have to initialize the hardware.
-	 */
-	if (info->fbops->fb_set_par)
-		info->fbops->fb_set_par(info);
 	cols = info->var.xres/vc->vc_font.width;
 	rows = info->var.yres/vc->vc_font.height;
 	vc_resize(vc->vc_num, cols, rows);
@@ -599,13 +592,24 @@
 	struct vc_data **default_mode = vc->vc_display_fg;
 	struct display *t, *p = &fb_display[vc->vc_num];
 	int display_fg = (*default_mode)->vc_num;
-	int logo = 1, rows, cols, charcnt = 256;
+	int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
 	unsigned short *save = NULL, *r, *q;
 
 	if (vc->vc_num != display_fg || (info->flags & FBINFO_FLAG_MODULE) ||
 	    (info->fix.type == FB_TYPE_TEXT))
 		logo = 0;
 
+	/*
+	 * We must always set the mode. The mode of the previous console
+	 * driver could be in the same resolution but we are using different
+	 * hardware so we have to initialize the hardware.
+	 * 
+	 * We need to do it in fbcon_init() to prevent screen corruption.
+	 */
+	if (CON_IS_VISIBLE(vc))
+		if (info->fbops->fb_set_par)
+			info->fbops->fb_set_par(info);
+	
 	info->var.xoffset = info->var.yoffset = p->yscroll = 0;	/* reset wrap/pan */
 
 	/* If we are not the first console on this
@@ -631,9 +635,11 @@
 			vc->vc_complement_mask <<= 1;
 	}
 
-	cols = info->var.xres / vc->vc_font.width;
-	rows = info->var.yres / vc->vc_font.height;
-	vc_resize(vc->vc_num, cols, rows);
+	cols = vc->vc_cols;
+	rows = vc->vc_rows;
+	new_cols = info->var.xres / vc->vc_font.width;
+	new_rows = info->var.yres / vc->vc_font.height;
+	vc_resize(vc->vc_num, new_cols, new_rows);
 
 	if (info->var.accel_flags)
 		p->scrollmode = SCROLL_YNOMOVE;
@@ -645,9 +651,9 @@
 	 *  vc_{cols,rows}, but we must not set those if we are only
 	 *  resizing the console.
 	 */
-	if (init) {
-		vc->vc_cols = cols;
-		vc->vc_rows = rows;
+	if (!init) {
+		vc->vc_cols = new_cols;
+		vc->vc_rows = new_rows;
 	}
 
 	if (logo) {
@@ -664,14 +670,15 @@
 		for (r = q - logo_lines * cols; r < q; r++)
 			if (scr_readw(r) != vc->vc_video_erase_char)
 				break;
-		if (r != q && rows >= rows + logo_lines) {
-			save = kmalloc(logo_lines * cols * 2, GFP_KERNEL);
+		if (r != q && new_rows >= rows + logo_lines) {
+			save = kmalloc(logo_lines * new_cols * 2, GFP_KERNEL);
 			if (save) {
+				int i = cols < new_cols ? cols : new_cols;
 				scr_memsetw(save, vc->vc_video_erase_char,
-					    logo_lines * cols * 2);
+					    logo_lines * new_cols * 2);
 				r = q - step;
-				for (cnt = 0; cnt < logo_lines; cnt++, r += cols)
-					scr_memcpyw(save + cnt * cols, r, 2 * cols);
+				for (cnt = 0; cnt < logo_lines; cnt++, r += i)
+					scr_memcpyw(save + cnt * new_cols, r, 2 * i);
 				r = q;
 			}
 		}
@@ -687,19 +694,19 @@
 				vc->vc_pos += logo_lines * vc->vc_size_row;
 			}
 		}
-		scr_memsetw((unsigned short *) vc->vc_origin,
-			    vc->vc_video_erase_char,
-			    vc->vc_size_row * logo_lines);
-
 		if (CON_IS_VISIBLE(vc) && vt_cons[vc->vc_num]->vc_mode == KD_TEXT) {
 			accel_clear_margins(vc, info, 0);
 			update_screen(vc->vc_num);
 		}
+		scr_memsetw((unsigned short *) vc->vc_origin,
+			    vc->vc_video_erase_char,
+			    vc->vc_size_row * logo_lines);
+
 		if (save) {
 			q = (unsigned short *) (vc->vc_origin +
 						vc->vc_size_row *
 						rows);
-			scr_memcpyw(q, save, logo_lines * cols * 2);
+			scr_memcpyw(q, save, logo_lines * new_cols * 2);
 			vc->vc_y += logo_lines;
 			vc->vc_pos += logo_lines * vc->vc_size_row;
 			kfree(save);
diff -Naur linux-2.6.7-orig/drivers/video/fbmem.c linux-2.6.7/drivers/video/fbmem.c
--- linux-2.6.7-orig/drivers/video/fbmem.c	2004-06-18 17:40:59.894202864 +0000
+++ linux-2.6.7/drivers/video/fbmem.c	2004-06-18 17:41:52.812158112 +0000
@@ -717,6 +717,7 @@
 	u32 *palette = NULL, *saved_pseudo_palette = NULL;
 	unsigned char *logo_new = NULL;
 	struct fb_image image;
+	struct fb_fillrect rect;
 	int x;
 
 	/* Return if the frame buffer is not mapped or suspended */
@@ -762,6 +763,12 @@
 	image.height = fb_logo.logo->height;
 	image.dy = 0;
 
+	rect.dx = 0;
+	rect.dy = 0;
+	rect.color = 0;
+	rect.width = info->var.xres;
+	rect.height = fb_logo.logo->height;
+	info->fbops->fb_fillrect(info, &rect);
 	for (x = 0; x < num_online_cpus() * (fb_logo.logo->width + 8) &&
 	     x <= info->var.xres-fb_logo.logo->width; x += (fb_logo.logo->width + 8)) {
 		image.dx = x;

[-- Attachment #3: screen-2.6.7-rc3-mm2.diff --]
[-- Type: text/x-diff, Size: 4904 bytes --]

diff -Naur linux-2.6.7-rc3-mm2-orig/drivers/video/console/fbcon.c linux-2.6.7-rc3-mm2/drivers/video/console/fbcon.c
--- linux-2.6.7-rc3-mm2-orig/drivers/video/console/fbcon.c	2004-06-18 17:47:06.374489392 +0000
+++ linux-2.6.7-rc3-mm2/drivers/video/console/fbcon.c	2004-06-18 17:50:24.310398560 +0000
@@ -503,13 +503,6 @@
 		vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */
 	}
 
-	/*
-	 * We must always set the mode. The mode of the previous console
-	 * driver could be in the same resolution but we are using different
-	 * hardware so we have to initialize the hardware.
-	 */
-	if (info->fbops->fb_set_par)
-		info->fbops->fb_set_par(info);
 	cols = info->var.xres/vc->vc_font.width;
 	rows = info->var.yres/vc->vc_font.height;
 	vc_resize(vc->vc_num, cols, rows);
@@ -599,7 +592,7 @@
 	struct vc_data **default_mode = vc->vc_display_fg;
 	struct display *t, *p = &fb_display[vc->vc_num];
 	int display_fg = (*default_mode)->vc_num;
-	int logo = 1, rows, cols, charcnt = 256;
+	int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
 	unsigned short *save = NULL, *r, *q;
 	int cap = info->flags;
 
@@ -607,6 +600,17 @@
 	    (info->fix.type == FB_TYPE_TEXT))
 		logo = 0;
 
+	/*
+	 * We must always set the mode. The mode of the previous console
+	 * driver could be in the same resolution but we are using different
+	 * hardware so we have to initialize the hardware.
+	 * 
+	 * We need to do it in fbcon_init() to prevent screen corruption.
+	 */
+	if (CON_IS_VISIBLE(vc))
+		if (info->fbops->fb_set_par)
+			info->fbops->fb_set_par(info);
+	
 	info->var.xoffset = info->var.yoffset = p->yscroll = 0;	/* reset wrap/pan */
 
 	/* If we are not the first console on this
@@ -632,9 +636,11 @@
 			vc->vc_complement_mask <<= 1;
 	}
 
-	cols = info->var.xres / vc->vc_font.width;
-	rows = info->var.yres / vc->vc_font.height;
-	vc_resize(vc->vc_num, cols, rows);
+	cols = vc->vc_cols;
+	rows = vc->vc_rows;
+	new_cols = info->var.xres / vc->vc_font.width;
+	new_rows = info->var.yres / vc->vc_font.height;
+	vc_resize(vc->vc_num, new_cols, new_rows);
 
 	if ((cap & FBINFO_HWACCEL_COPYAREA) && !(cap & FBINFO_HWACCEL_DISABLED))
 		p->scrollmode = SCROLL_ACCEL;
@@ -646,9 +652,9 @@
 	 *  vc_{cols,rows}, but we must not set those if we are only
 	 *  resizing the console.
 	 */
-	if (init) {
-		vc->vc_cols = cols;
-		vc->vc_rows = rows;
+	if (!init) {
+		vc->vc_cols = new_cols;
+		vc->vc_rows = new_rows;
 	}
 
 	if (logo) {
@@ -665,14 +671,15 @@
 		for (r = q - logo_lines * cols; r < q; r++)
 			if (scr_readw(r) != vc->vc_video_erase_char)
 				break;
-		if (r != q && rows >= rows + logo_lines) {
-			save = kmalloc(logo_lines * cols * 2, GFP_KERNEL);
+		if (r != q && new_rows >= rows + logo_lines) {
+			save = kmalloc(logo_lines * new_cols * 2, GFP_KERNEL);
 			if (save) {
+				int i = cols < new_cols ? cols : new_cols;
 				scr_memsetw(save, vc->vc_video_erase_char,
-					    logo_lines * cols * 2);
+					    logo_lines * new_cols * 2);
 				r = q - step;
-				for (cnt = 0; cnt < logo_lines; cnt++, r += cols)
-					scr_memcpyw(save + cnt * cols, r, 2 * cols);
+				for (cnt = 0; cnt < logo_lines; cnt++, r += i)
+					scr_memcpyw(save + cnt * new_cols, r, 2 * i);
 				r = q;
 			}
 		}
@@ -688,19 +695,19 @@
 				vc->vc_pos += logo_lines * vc->vc_size_row;
 			}
 		}
-		scr_memsetw((unsigned short *) vc->vc_origin,
-			    vc->vc_video_erase_char,
-			    vc->vc_size_row * logo_lines);
-
 		if (CON_IS_VISIBLE(vc) && vt_cons[vc->vc_num]->vc_mode == KD_TEXT) {
 			accel_clear_margins(vc, info, 0);
 			update_screen(vc->vc_num);
 		}
+		scr_memsetw((unsigned short *) vc->vc_origin,
+			    vc->vc_video_erase_char,
+			    vc->vc_size_row * logo_lines);
+
 		if (save) {
 			q = (unsigned short *) (vc->vc_origin +
 						vc->vc_size_row *
 						rows);
-			scr_memcpyw(q, save, logo_lines * cols * 2);
+			scr_memcpyw(q, save, logo_lines * new_cols * 2);
 			vc->vc_y += logo_lines;
 			vc->vc_pos += logo_lines * vc->vc_size_row;
 			kfree(save);
diff -Naur linux-2.6.7-rc3-mm2-orig/drivers/video/fbmem.c linux-2.6.7-rc3-mm2/drivers/video/fbmem.c
--- linux-2.6.7-rc3-mm2-orig/drivers/video/fbmem.c	2004-06-18 17:46:47.927293792 +0000
+++ linux-2.6.7-rc3-mm2/drivers/video/fbmem.c	2004-06-18 17:51:14.754729856 +0000
@@ -717,6 +717,7 @@
 	u32 *palette = NULL, *saved_pseudo_palette = NULL;
 	unsigned char *logo_new = NULL;
 	struct fb_image image;
+	struct fb_fillrect rect;
 	int x;
 
 	/* Return if the frame buffer is not mapped or suspended */
@@ -762,6 +763,12 @@
 	image.height = fb_logo.logo->height;
 	image.dy = 0;
 
+	rect.dx = 0;
+	rect.dy = 0;
+	rect.color = 0;
+	rect.width = info->var.xres;
+	rect.height = fb_logo.logo->height;
+	info->fbops->fb_fillrect(info, &rect);
 	for (x = 0; x < num_online_cpus() * (fb_logo.logo->width + 8) &&
 	     x <= info->var.xres-fb_logo.logo->width; x += (fb_logo.logo->width + 8)) {
 		image.dx = x;

Re: 2.6.7 still garbage upon start

[John Zielinski]

Antonino A. Daplas wrote:

>If the boot logo is not enabled, then everything is okay.  With the boot logo
>enabled, you will see remnants of old text (not garbage) in the space 
>provided for the logo.  
>
>  
>
Actually, my problem _was_ with the boot logo not enabled but your patch 
fixed it.  That misplaced set_par was why it looked like vgacon was 
still being used and the cause of all my grief. 

>Please test, and if it works for you, I'll push it upstream.
>
>  
>
Yes, it does work so please push it.  It just took me a while to test it 
as I had to figure out what was clearing my video memory.  Once that was 
disabled I can now see my bootup sequence all the way back to the beginning.

John




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[David Eger]

On Sat, Jun 19, 2004 at 02:40:31AM +0800, Antonino A. Daplas wrote:
> 
> Actually, to eliminate the white rectangle, we just need to initialize fbdev 
> _after_ vgacon.  Currently, there is a set_par call in fbcon_startup()) which is
>  called prior to vgacon_deinit.  
> 
>  [snip]
>
> I've include a patch that incorporates all of the above.  (It also has some fixes
> for problems with creation of logo space -- the code does not consider that the
> new VC window size is different or even smaller than the old VC window size).
> Please test, and if it works for you, I'll push it upstream.

with my cirrusfb driver and your patch, the area to the right of the
penguins is cleared, but the area where the text is drawn still has
white rectangle crud that scrolls off the screen.

-dte



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Antonino A. Daplas]

On Saturday 19 June 2004 11:08, David Eger wrote:
> On Sat, Jun 19, 2004 at 02:40:31AM +0800, Antonino A. Daplas wrote:
> > Actually, to eliminate the white rectangle, we just need to initialize
> > fbdev _after_ vgacon.  Currently, there is a set_par call in
> > fbcon_startup()) which is called prior to vgacon_deinit.
> >
> >  [snip]
> >
> > I've include a patch that incorporates all of the above.  (It also has
> > some fixes for problems with creation of logo space -- the code does not
> > consider that the new VC window size is different or even smaller than
> > the old VC window size). Please test, and if it works for you, I'll push
> > it upstream.
>
> with my cirrusfb driver and your patch, the area to the right of the
> penguins is cleared, but the area where the text is drawn still has
> white rectangle crud that scrolls off the screen.

Most probably, you are initializing your graphics card  before you register 
the framebuffer.  You should not do it, but only on an explict fb_set_par() 
call. If that cannot be avoided, we can extend the rectangle for fillrect() 
in fb_show_logo() - fbmem.c.  So instead of rect.height = 
fb_logo.logo->height, use info->var.xres (or info->var.yres_virtual). You 
might lose some of the text messages though, not sure.

Tony





-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[David Eger]

On Sat, Jun 19, 2004 at 02:13:03PM +0800, Antonino A. Daplas wrote:
> On Saturday 19 June 2004 11:08, David Eger wrote:
> >
> > with my cirrusfb driver and your patch, the area to the right of the
> > penguins is cleared, but the area where the text is drawn still has
> > white rectangle crud that scrolls off the screen.
> 
> Most probably, you are initializing your graphics card  before you register 
> the framebuffer.  You should not do it, but only on an explict fb_set_par() 
> call. 

You're absolutely correct.  

Unfortunately, removing the set_par() call from the PCI driver probe
code uncovered another problem.  For some reason, the VGA register writes
have to happen twice for the settings to take.  Jeff, this seems really
weird to me.  Do you have any idea why?  I sorta hate to leave in the hack:

cirrusfb_set_par_foo (info) {
	/* real register writes ... */
}

cirrusfb_set_par (info) {
	cirrusfb_set_par_foo (info);
	return cirrusfb_set_par_foo (info);
}

-dte


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: 2.6.7 still garbage upon start

[Antonino A. Daplas]

On Tuesday 22 June 2004 17:45, David Eger wrote:
> On Sat, Jun 19, 2004 at 02:13:03PM +0800, Antonino A. Daplas wrote:
> > On Saturday 19 June 2004 11:08, David Eger wrote:
> > > with my cirrusfb driver and your patch, the area to the right of the
> > > penguins is cleared, but the area where the text is drawn still has
> > > white rectangle crud that scrolls off the screen.
> >
> > Most probably, you are initializing your graphics card  before you
> > register the framebuffer.  You should not do it, but only on an explict
> > fb_set_par() call.
>
> You're absolutely correct.
>
> Unfortunately, removing the set_par() call from the PCI driver probe
> code uncovered another problem.  For some reason, the VGA register writes

If you can't avoid doing a set_par duing initialization, you can always memset
the fb memory to the background color.  Not sure if it's going to completely
remove the garbage as vgacon continues to write to vga memory far beyond
fbdev registration.

Note: Doing a set_par during initialization will produce an unusable display 
if you load the driver without fbcon. You can always restore by loading
fbcon or running con2fbmap.

Tony





-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: 2.6.7 still garbage upon start

[John Zielinski]

Antonino A. Daplas wrote:

>1. Solution: Move this set_par call to fbcon_init instead.
>  
>
One thing I just noticed about your patch, if we move the set_par 
shouldn't the vc_resize move with it?

John




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Antonino A. Daplas]

On Sunday 20 June 2004 03:27, John Zielinski wrote:
> Antonino A. Daplas wrote:
> >1. Solution: Move this set_par call to fbcon_init instead.
>
> One thing I just noticed about your patch, if we move the set_par
> shouldn't the vc_resize move with it?
>

I tried it and the white rectangle returned.  Not so sure of the reason, but 
it seems that calling vc_resize while in fbcon_startup() will involve vgacon, 
not fbdev.  By the time we reach fbcon_init(), the vc's dimension already 
matches that of fbdev so fbcon_resize is not called.   On the other hand, 
moving vc_resize to fbcon_init will force a call to fbcon_resize.  Maybe an 
early call to  fbcon_resize is partly the reason for the white rectangle..., 
again not sure.

Tony  




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Re: 2.6.7 still garbage upon start

[Antonino A. Daplas]

On Friday 18 June 2004 15:54, Thomas Winischhofer wrote:
>
> > (I have code I'm planning to send for RFC that will notify the
> > low-level driver if switching from KD_GRAPHICS->KD_TEXT and vice
> > versa or if multiple drivers are mapped to different consoles.
> > However, it seems BenH already has code for this so I'm holding the
> > submission.  I just can't find BenH's changes in 2.6.7 or -mm.  Hey
> > Ben, where is it?)
>
> Perhaps I am being naive, but I don't understand what the problem can
> be. X restores the display mode before initiating the VT change. And a
> VT change should restore the previous screen contents.
>

True, most of the time, there's no problem switching to X as X does a good job 
of restoring its own state.  It's in the other direction, switching from X to 
VC, that fbcon must correctly determine if there is a need to restore the 
hardware state.

With the separation of fbcon and fbdev in 2.6.x, it is now fbcon which decides 
when to do a set_par or not.  Currently, a set_par (via set_var) is only 
called if the current var and the new var is not the same.  So, when you 
switch from  X's VC to the console, fbcon assumes  there was no state change 
(mistakenly, of course, from the POV of fbcon). This is because the current 
var (info->var) and the new_var (created in fbcon_switch->fbcon_resize) is 
the same. As you can see, this leaves fbdev in an undefined state.

So, one solution is to have fbcon detect a switch between consoles in which 
the old console is in graphics mode and the new console will be in text mode.  

Tony  
 




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND