Fw: [Bugme-new] [Bug 5441] New: SVGATextMode problem on 2.6.14-rc4

Fw: [Bugme-new] [Bug 5441] New: SVGATextMode problem on 2.6.14-rc4

[Andrew Morton]

Begin forwarded message:

Date: Fri, 14 Oct 2005 05:08:31 -0700
From: bugme-daemon@kernel-bugs.osdl.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 5441] New: SVGATextMode problem on 2.6.14-rc4


http://bugzilla.kernel.org/show_bug.cgi?id=5441

           Summary: SVGATextMode problem on 2.6.14-rc4
    Kernel Version: 2.6.14-rc4
            Status: NEW
          Severity: blocking
             Owner: jsimmons@infradead.org
         Submitter: olel@ans.pl


Most recent kernel where this bug did not occur: 2.6.13.4

Distribution: Slackware

Problem Description:

After upgrding my kernel to 2.6.14-rc4 I noticed that SVGATextMode, instead of
changing screen resolution to 100x40, messed my console completely. 

Reverting those two patches helps:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6d36ba629e0ef47a03d3703ee1d38143c25532a8;hp=7b6a186d65589901a73d460070504a5e02703c45
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=28254d439b8c65f93cb331f5aa741efa6a8ec62f;hp=ff55fe2075e3901db4dbdc00e0b44a71bef97afd

Steps to reproduce:
Use SVGATextMode to change screen resolution.

Tested on:
 - Matrox Graphics, Inc. MGA G200 AGP

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Fw: [Bugme-new] [Bug 5441] New: SVGATextMode problem on 2.6.14-rc4

[Samuel Thibault]

Hum, I didn't know about messy programs like svgatextmode... Couldn't
this be integrated in some linux/drivers/video/console/svgacon.c ?... So
because of the existence of the svgatextmode program, the kernel is not
supposed to touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?

Disabling the check in vgacon_resize() might help indeed, but I'm really
not sure whether it will work for any chipset: in my patch, CRT
registers are set at each console switch, since stty rows/cols apply to
consoles separately...

The attached solution is to keep the test, but if it fails, we assume
that the caller knows what it does (i.e. it is svgatextmode) and then
disable any further call to vgacon_doresize. Svgatextmode is usually
used to _expand_ the display, not to shrink it. And it is harmless in
the case of a too big stty rows/cols: the display will just be cropped.
I tested it on my laptop, and it works fine with svgatextmode.

A better solution would be that svgatextmode explicitely tells the
kernel not to care about video timing, but for this an interface needs
be defined and svgatextmode be patched.

Signed-off-by: samuel.thibault@ens-lyon.org

--- drivers/video/console/vgacon-2.4.14-pre.c	2005-10-14 22:35:14.000000000 +0200
+++ drivers/video/console/vgacon.c	2005-10-14 22:58:06.000000000 +0200
@@ -563,7 +563,11 @@
 	if (!vga_is_gfx) {
 		scr_memcpyw((u16 *) c->vc_origin, (u16 *) c->vc_screenbuf,
 			    c->vc_screenbuf_size > vga_vram_size ? vga_vram_size : c->vc_screenbuf_size);
-		vgacon_doresize(c, c->vc_cols, c->vc_rows);
+		if (!(vga_video_num_columns % 2) &&
+		    vga_video_num_columns <= ORIG_VIDEO_COLS &&
+		    vga_video_num_lines <= (ORIG_VIDEO_LINES *
+			vga_default_font_height) / c->vc_font.height)
+			vgacon_doresize(c, c->vc_cols, c->vc_rows);
 	}
 
 	return 0;		/* Redrawing not needed */
@@ -1019,7 +1023,8 @@
 	if (width % 2 || width > ORIG_VIDEO_COLS ||
 	    height > (ORIG_VIDEO_LINES * vga_default_font_height)/
 	    c->vc_font.height)
-		return -EINVAL;
+		/* let svgatextmode tinker with video timings */
+		return 0;
 
 	if (CON_IS_VISIBLE(c) && !vga_is_gfx) /* who knows */
 		vgacon_doresize(c, width, height);


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Fw: [Bugme-new] [Bug 5441] New: SVGATextMode problem on 2.6.14-rc4

[Andrew Morton]

Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
>
> Hum, I didn't know about messy programs like svgatextmode... Couldn't
> this be integrated in some linux/drivers/video/console/svgacon.c ?... So
> because of the existence of the svgatextmode program, the kernel is not
> supposed to touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?
> 
> Disabling the check in vgacon_resize() might help indeed, but I'm really
> not sure whether it will work for any chipset: in my patch, CRT
> registers are set at each console switch, since stty rows/cols apply to
> consoles separately...
> 
> The attached solution is to keep the test, but if it fails, we assume
> that the caller knows what it does (i.e. it is svgatextmode) and then
> disable any further call to vgacon_doresize. Svgatextmode is usually
> used to _expand_ the display, not to shrink it. And it is harmless in
> the case of a too big stty rows/cols: the display will just be cropped.
> I tested it on my laptop, and it works fine with svgatextmode.
> 
> A better solution would be that svgatextmode explicitely tells the
> kernel not to care about video timing, but for this an interface needs
> be defined and svgatextmode be patched.

hm, you removed bugzilla from the Cc.  Please don't do that.  I've restored
it, and I've cc'ed the reporter (Krzysztof) directly.

Krzysztof, could you please test Samuel's fix (which I forwarded) and let
us know?

Thanks.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Fw: [Bugme-new] [Bug 5441] New: SVGATextMode problem on 2.6.14-rc4

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1735 bytes --]



On Fri, 14 Oct 2005, Andrew Morton wrote:

> Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
>>
>> Hum, I didn't know about messy programs like svgatextmode... Couldn't
>> this be integrated in some linux/drivers/video/console/svgacon.c ?... So
>> because of the existence of the svgatextmode program, the kernel is not
>> supposed to touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?
>>
>> Disabling the check in vgacon_resize() might help indeed, but I'm really
>> not sure whether it will work for any chipset: in my patch, CRT
>> registers are set at each console switch, since stty rows/cols apply to
>> consoles separately...
>>
>> The attached solution is to keep the test, but if it fails, we assume
>> that the caller knows what it does (i.e. it is svgatextmode) and then
>> disable any further call to vgacon_doresize. Svgatextmode is usually
>> used to _expand_ the display, not to shrink it. And it is harmless in
>> the case of a too big stty rows/cols: the display will just be cropped.
>> I tested it on my laptop, and it works fine with svgatextmode.
>>
>> A better solution would be that svgatextmode explicitely tells the
>> kernel not to care about video timing, but for this an interface needs
>> be defined and svgatextmode be patched.
>
> hm, you removed bugzilla from the Cc.  Please don't do that.  I've restored
> it, and I've cc'ed the reporter (Krzysztof) directly.
>
> Krzysztof, could you please test Samuel's fix (which I forwarded) and let
> us know?

Tested. Both "stty cols 66", when switching from plain 80x25, and 
SVGATextMode work.

Thank you.

Best regards,

 				Krzysztof Olędzki

PS: Sorry for the delay, I was offline during the weekend.