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
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
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