X display shift with disabled console blanking

X display shift with disabled console blanking

[James Pearson]

I have a problem whereby the X display 'shifts' to left when anything 
writes to /dev/console - where console screen blanking has been disabled 
i.e. doing something like:

boot to run level 3

If not root, then make sure /dev/console is writeable

login and type:

setterm -blank 0

start X

type into an xterm:

echo "some random text" > /dev/console
(may have to repeat the echo above a few times)

... and the whole X display jumps (and wraps) to the left

I'm using a RHEL4 based distro with a vanilla 2.6.21 x86_64 kernel 
(although I've seen the problem with various x86_64 and i686 2.6.X kernels).

I've seen this problem on a number of different nVidia cards - using 
the vesa driver (same problem occurs with nVidia's binary driver). I 
haven't tried using other makes of graphics cards.


OK, this may be a strange combination of disabling the text console 
blanking and running X, but something isn't right somewhere ...

Any ideas?

Thanks

James Pearson

Re: X display shift with disabled console blanking

[Antonino A. Daplas]

On Fri, 2007-04-27 at 18:08 +0100, James Pearson wrote:
> I have a problem whereby the X display 'shifts' to left when anything 
> writes to /dev/console - where console screen blanking has been disabled 
> i.e. doing something like:
> 
> boot to run level 3
> 
> If not root, then make sure /dev/console is writeable
> 
> login and type:
> 
> setterm -blank 0
> 
> start X
> 
> type into an xterm:
> 
> echo "some random text" > /dev/console
> (may have to repeat the echo above a few times)
> 
> ... and the whole X display jumps (and wraps) to the left
> 
> I'm using a RHEL4 based distro with a vanilla 2.6.21 x86_64 kernel 
> (although I've seen the problem with various x86_64 and i686 2.6.X kernels).
> 
> I've seen this problem on a number of different nVidia cards - using 
> the vesa driver (same problem occurs with nVidia's binary driver). I 
> haven't tried using other makes of graphics cards.
> 
> 
> OK, this may be a strange combination of disabling the text console 
> blanking and running X, but something isn't right somewhere ...

Yep, it's strange because I can't reproduce this. And the console write
should not succeed if the current console is in KD_GRAPHICS mode, which
is done by X (unless your version is different).

> 
> Any ideas?

I don't.  But, what is your current console?  Is it VGA, or framebuffer?
Can you try doing this again in both VGA and vesafb?

And this does not happen if there is no previous setterm -blank 0
command?

Tony

Re: X display shift with disabled console blanking

[James Pearson]

Antonino A. Daplas wrote:
> On Fri, 2007-04-27 at 18:08 +0100, James Pearson wrote:
> 
>>I have a problem whereby the X display 'shifts' to left when anything 
>>writes to /dev/console - where console screen blanking has been disabled 
>>i.e. doing something like:
>>
>>boot to run level 3
>>
>>If not root, then make sure /dev/console is writeable
>>
>>login and type:
>>
>>setterm -blank 0
>>
>>start X
>>
>>type into an xterm:
>>
>>echo "some random text" > /dev/console
>>(may have to repeat the echo above a few times)
>>
>>... and the whole X display jumps (and wraps) to the left
>>
>>I'm using a RHEL4 based distro with a vanilla 2.6.21 x86_64 kernel 
>>(although I've seen the problem with various x86_64 and i686 2.6.X kernels).
>>
>>I've seen this problem on a number of different nVidia cards - using 
>>the vesa driver (same problem occurs with nVidia's binary driver). I 
>>haven't tried using other makes of graphics cards.
>>
>>
>>OK, this may be a strange combination of disabling the text console 
>>blanking and running X, but something isn't right somewhere ...
> 
> 
> Yep, it's strange because I can't reproduce this. And the console write
> should not succeed if the current console is in KD_GRAPHICS mode, which
> is done by X (unless your version is different).

I've just installed a vanilla CentOS 4.4 on an i686 SMP machine - with 
an nVidia Quadro4 980 XGL card.

By default, this sets up X using the 'nv' driver (using RedHat's 
xorg-x11-6.8.2-1.EL.13.37).

If I follow my 'recipe' above, then the screen shifts - note: it looks 
like you have to write several lines of text to /dev/console (at least 
30) to trigger the problem (e.g. run the echo to /dev/console in a loop) 
- also, I've found that switching to the console and back to X 
(Ctrl-Alt-F1 then Ctrl-Alt-F7) while this echo loop is running can force 
the shift to start ...

This is with the RedHat based 2.6.9-42.ELsmp kernel - but I also get the 
problem with a vanilla 2.6.21 kernel.

>>Any ideas?
> 
> 
> I don't.  But, what is your current console?  Is it VGA, or framebuffer?
> Can you try doing this again in both VGA and vesafb?

I'm not sure what the current console is - whatever is the default with 
RHEL4/CentOS4 - how do I select a different type of console?

> And this does not happen if there is no previous setterm -blank 0
> command?

It doesn't happen if there is no previous 'setterm -blank 0' - so, 
arguably, this is the 'fix' ...

James Pearson

Re: X display shift with disabled console blanking

[Antonino A. Daplas]

On Mon, 2007-04-30 at 13:58 +0100, James Pearson wrote:
> Antonino A. Daplas wrote:
> > On Fri, 2007-04-27 at 18:08 +0100, James Pearson wrote:
> > 
> >>I have a problem whereby the X display 'shifts' to left when anything 
> >>writes to /dev/console - where console screen blanking has been disabled 
> >>i.e. doing something like:
> >>
> >>boot to run level 3
> >>
> >>If not root, then make sure /dev/console is writeable
> >>
> >>login and type:
> >>
> >>setterm -blank 0
> >>
> >>start X
> >>
> >>type into an xterm:
> >>
> >>echo "some random text" > /dev/console
> >>(may have to repeat the echo above a few times)
> >>
> >>... and the whole X display jumps (and wraps) to the left
> >>
> >>I'm using a RHEL4 based distro with a vanilla 2.6.21 x86_64 kernel 
> >>(although I've seen the problem with various x86_64 and i686 2.6.X kernels).
> >>
> >>I've seen this problem on a number of different nVidia cards - using 
> >>the vesa driver (same problem occurs with nVidia's binary driver). I 
> >>haven't tried using other makes of graphics cards.
> >>
> >>
> >>OK, this may be a strange combination of disabling the text console 
> >>blanking and running X, but something isn't right somewhere ...
> > 
> > 
> > Yep, it's strange because I can't reproduce this. And the console write
> > should not succeed if the current console is in KD_GRAPHICS mode, which
> > is done by X (unless your version is different).
> 
> I've just installed a vanilla CentOS 4.4 on an i686 SMP machine - with 
> an nVidia Quadro4 980 XGL card.
> 
> By default, this sets up X using the 'nv' driver (using RedHat's 
> xorg-x11-6.8.2-1.EL.13.37).
> 
> If I follow my 'recipe' above, then the screen shifts - note: it looks 
> like you have to write several lines of text to /dev/console (at least 
> 30) to trigger the problem (e.g. run the echo to /dev/console in a loop) 
> - also, I've found that switching to the console and back to X 
> (Ctrl-Alt-F1 then Ctrl-Alt-F7) while this echo loop is running can force 
> the shift to start ...

I would understand that switching from text to graphics and vice versa
can trigger display problems (it shouldn't, but it happens), but not
while you are only echoing text to the system console in graphics mode.

> 
> This is with the RedHat based 2.6.9-42.ELsmp kernel - but I also get the 
> problem with a vanilla 2.6.21 kernel.
> 
> >>Any ideas?
> > 
> > 
> > I don't.  But, what is your current console?  Is it VGA, or framebuffer?
> > Can you try doing this again in both VGA and vesafb?
> 
> I'm not sure what the current console is - whatever is the default with 
> RHEL4/CentOS4 - how do I select a different type of console?
> 

dmesg | grep "Console:"



> > And this does not happen if there is no previous setterm -blank 0
> > command?
> 
> It doesn't happen if there is no previous 'setterm -blank 0' - so, 
> arguably, this is the 'fix' ...

Weird. The only thing I can think of is that console blanking is being
triggered while the console is in graphics mode, which is not legal. 

How about 'setterm -blank 1', do an infinite echo loop and wait for at
least 1 minute?

Also, can you open drivers/char/vt.c and look for the function
do_blank_screen?  You should have this particular segment.

Change this

if (console_blanked) {
	if (blank_state == blank_vesa_wait) {
		blank_state = blank_off;
		vc->vc_sw->con_blank(vc, vesa_blank_mode + 1, 0);
	}
	return;
}

to

if (console_blanked && vc->vc_mode == KD_TEXT && !entering_gfx ) {
	if (blank_state == blank_vesa_wait) {
		blank_state = blank_off;
		vc->vc_sw->con_blank(vc, vesa_blank_mode + 1, 0);
	}
	return;
}

Let me know if that even makes a difference.

Tony

Re: X display shift with disabled console blanking

[James Pearson]

Antonino A. Daplas wrote:
> On Mon, 2007-04-30 at 13:58 +0100, James Pearson wrote:
> 
>>Antonino A. Daplas wrote:
>>
>>>On Fri, 2007-04-27 at 18:08 +0100, James Pearson wrote:
>>>
>>>
>>>>I have a problem whereby the X display 'shifts' to left when anything 
>>>>writes to /dev/console - where console screen blanking has been disabled 
>>>>i.e. doing something like:
>>>>
>>>>boot to run level 3
>>>>
>>>>If not root, then make sure /dev/console is writeable
>>>>
>>>>login and type:
>>>>
>>>>setterm -blank 0
>>>>
>>>>start X
>>>>
>>>>type into an xterm:
>>>>
>>>>echo "some random text" > /dev/console
>>>>(may have to repeat the echo above a few times)
>>>>
>>>>... and the whole X display jumps (and wraps) to the left
>>>>
>>>>I'm using a RHEL4 based distro with a vanilla 2.6.21 x86_64 kernel 
>>>>(although I've seen the problem with various x86_64 and i686 2.6.X kernels).
>>>>
>>>>I've seen this problem on a number of different nVidia cards - using 
>>>>the vesa driver (same problem occurs with nVidia's binary driver). I 
>>>>haven't tried using other makes of graphics cards.
>>>>
>>>>
>>>>OK, this may be a strange combination of disabling the text console 
>>>>blanking and running X, but something isn't right somewhere ...
>>>
>>>
>>>Yep, it's strange because I can't reproduce this. And the console write
>>>should not succeed if the current console is in KD_GRAPHICS mode, which
>>>is done by X (unless your version is different).
>>
>>I've just installed a vanilla CentOS 4.4 on an i686 SMP machine - with 
>>an nVidia Quadro4 980 XGL card.
>>
>>By default, this sets up X using the 'nv' driver (using RedHat's 
>>xorg-x11-6.8.2-1.EL.13.37).
>>
>>If I follow my 'recipe' above, then the screen shifts - note: it looks 
>>like you have to write several lines of text to /dev/console (at least 
>>30) to trigger the problem (e.g. run the echo to /dev/console in a loop) 
>>- also, I've found that switching to the console and back to X 
>>(Ctrl-Alt-F1 then Ctrl-Alt-F7) while this echo loop is running can force 
>>the shift to start ...
> 
> 
> I would understand that switching from text to graphics and vice versa
> can trigger display problems (it shouldn't, but it happens), but not
> while you are only echoing text to the system console in graphics mode.

It looks like switching from graphics -> text -> graphics definitely 
plays a part in the problem ... see below

>>This is with the RedHat based 2.6.9-42.ELsmp kernel - but I also get the 
>>problem with a vanilla 2.6.21 kernel.
>>
>>
>>>>Any ideas?
>>>
>>>
>>>I don't.  But, what is your current console?  Is it VGA, or framebuffer?
>>>Can you try doing this again in both VGA and vesafb?
>>
>>I'm not sure what the current console is - whatever is the default with 
>>RHEL4/CentOS4 - how do I select a different type of console?
>>
> 
> 
> dmesg | grep "Console:"

Console: colour VGA+ 80x25

>>>And this does not happen if there is no previous setterm -blank 0
>>>command?
>>
>>It doesn't happen if there is no previous 'setterm -blank 0' - so, 
>>arguably, this is the 'fix' ...
> 
> 
> Weird. The only thing I can think of is that console blanking is being
> triggered while the console is in graphics mode, which is not legal. 
> 
> How about 'setterm -blank 1', do an infinite echo loop and wait for at
> least 1 minute?

Setting the blank time to anything other than 0 is fine (no screen shift)

> Also, can you open drivers/char/vt.c and look for the function
> do_blank_screen?  You should have this particular segment.
> 
> Change this
> 
> if (console_blanked) {
> 	if (blank_state == blank_vesa_wait) {
> 		blank_state = blank_off;
> 		vc->vc_sw->con_blank(vc, vesa_blank_mode + 1, 0);
> 	}
> 	return;
> }
> 
> to
> 
> if (console_blanked && vc->vc_mode == KD_TEXT && !entering_gfx ) {
> 	if (blank_state == blank_vesa_wait) {
> 		blank_state = blank_off;
> 		vc->vc_sw->con_blank(vc, vesa_blank_mode + 1, 0);
> 	}
> 	return;
> }
> 
> Let me know if that even makes a difference.

Made no difference, although I can't see how it would as console_blanked 
is 0 when the problem happens.

It does indeed seem that the switching back and forth between text and 
graphics does appear to be part of the issue - in my previous testing I 
probably did do this (but didn't include this in my recipe above) - so 
here is a new 'recipe' that shows the problem (for me)

boot to run level 3

if not root, then make sure /dev/console is writeable

login and type:

setterm -blank 0

start X

type into an xterm:

while true; do echo "" > /dev/console; usleep 100000; done

while the above loop is running switch to the text console and back 
again (Ctrl-Alt-F1 then Ctrl-Alt-F7)

... and the screen will be shifting (and wrapping) to the left.

James Pearson

Re: X display shift with disabled console blanking

[Antonino A. Daplas]

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

On Tue, 2007-05-01 at 13:17 +0100, James Pearson wrote:
> Antonino A. Daplas wrote:
> > On Mon, 2007-04-30 at 13:58 +0100, James Pearson wrote:
> > 
> >>Antonino A. Daplas wrote:
> >>
> >>>On Fri, 2007-04-27 at 18:08 +0100, James Pearson wrote:

> It does indeed seem that the switching back and forth between text and 
> graphics does appear to be part of the issue - in my previous testing I 
> probably did do this (but didn't include this in my recipe above) - so 
> here is a new 'recipe' that shows the problem (for me)
> 
> boot to run level 3
> 
> if not root, then make sure /dev/console is writeable
> 
> login and type:
> 
> setterm -blank 0
> 
> start X
> 
> type into an xterm:
> 
> while true; do echo "" > /dev/console; usleep 100000; done
> 
> while the above loop is running switch to the text console and back 
> again (Ctrl-Alt-F1 then Ctrl-Alt-F7)
> 
> ... and the screen will be shifting (and wrapping) to the left.
> 

Okay, this makes me see the problem more clearly.  It looks like that
vt/console layer is unreliable in terms of checking for the
text/graphics mode of the current console.  Instead of auditing the
console code, I'll just have vgacon check for the mode.  Try the
attached patch and let me know if it helps. 

Tony

[-- Attachment #2: vgacon.diff --]
[-- Type: text/x-patch, Size: 650 bytes --]

diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index d0d2733..2460b82 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -660,6 +660,9 @@ #endif
 
 static void vgacon_cursor(struct vc_data *c, int mode)
 {
+	if (c->vc_mode != KD_TEXT)
+		return;
+
 	vgacon_restore_screen(c);
 
 	switch (mode) {
@@ -1318,7 +1321,7 @@ static int vgacon_scroll(struct vc_data 
 	unsigned long oldo;
 	unsigned int delta;
 
-	if (t || b != c->vc_rows || vga_is_gfx)
+	if (t || b != c->vc_rows || vga_is_gfx || c->vc_mode != KD_TEXT)
 		return 0;
 
 	if (!vga_hardscroll_enabled || lines >= c->vc_rows / 2)

Re: X display shift with disabled console blanking

[James Pearson]

Antonino A. Daplas wrote:
> On Tue, 2007-05-01 at 13:17 +0100, James Pearson wrote:
> 
>>Antonino A. Daplas wrote:
>>
>>>On Mon, 2007-04-30 at 13:58 +0100, James Pearson wrote:
>>>
>>>
>>>>Antonino A. Daplas wrote:
>>>>
>>>>
>>>>>On Fri, 2007-04-27 at 18:08 +0100, James Pearson wrote:
> 
> 
>>It does indeed seem that the switching back and forth between text and 
>>graphics does appear to be part of the issue - in my previous testing I 
>>probably did do this (but didn't include this in my recipe above) - so 
>>here is a new 'recipe' that shows the problem (for me)
>>
>>boot to run level 3
>>
>>if not root, then make sure /dev/console is writeable
>>
>>login and type:
>>
>>setterm -blank 0
>>
>>start X
>>
>>type into an xterm:
>>
>>while true; do echo "" > /dev/console; usleep 100000; done
>>
>>while the above loop is running switch to the text console and back 
>>again (Ctrl-Alt-F1 then Ctrl-Alt-F7)
>>
>>... and the screen will be shifting (and wrapping) to the left.
>>
> 
> 
> Okay, this makes me see the problem more clearly.  It looks like that
> vt/console layer is unreliable in terms of checking for the
> text/graphics mode of the current console.  Instead of auditing the
> console code, I'll just have vgacon check for the mode.  Try the
> attached patch and let me know if it helps. 

That seems to fix it!

Thanks

James Pearson