nanogui: Thread: VT switching questions

 
hi -- in playing with nano-x (mostly by way of porting tightVNC -- not
done yet, but the local mouse cursor is a huge improvement over my
115K serial ppp link), i've noticed a couple of things i don't understand. 
(i'm using kbd_ttyscan.c)

    - VT switching -- the driver clearly has code which supports
	console switching via Alt-FN.  i sort of thought VT switching
	was configured via VTSWITCH in the config file, but clearly
	that's not the case.  what _is_ the code in vtswitch.c for?

    - on my system (486 with very old VGA screen -- max resolution
	is 640x480 w/ 16 colors) when i switch VT's (i'm using the
	framebuffer driver), the switch works fine, but i get
	garbage when i return.  where should i start looking for
	this?  i assume restoration of video modes is a kernel
	function?  but what graphics mode does it restore?  anything
	set by the application?

	oh.  wait.  i just stumbled on the SLOWVGA control in
	vgaplan4.h.  since i had to enable a very similar conditional
	in the kernel's console driver, i can believe i need it
	here too.  i'll try that.

paul
=---------------------
 paul fox, ####@####.#### (arlington, ma, where it's 70.2 degrees)

Paul Fox wrote:
>     - VT switching -- the driver clearly has code which supports
> 	console switching via Alt-FN.  i sort of thought VT switching
> 	was configured via VTSWITCH in the config file, but clearly
> 	that's not the case.  what _is_ the code in vtswitch.c for?

vtswitch.c is only linked in and the code in it only used if VTSWITCH is 
set to Y. The VTY switch code handles:

* Stopping Microwindows from drawing to the framebuffer when ours is not 
the currently active VT by changing the drawing functions to dummy ones 
that don't do anything.
* Re-enabling the drawing functions when we change back.
* Delaying the VT change if a drawing operation is currently in progress 
when the signal is received (otherwise the currently active drawing 
operation, which could be anything from drawing a single dot to painting 
a rectangle the size of the screen, would carry on after the VT switch).
* Saving the palette when changing to another VT.
* Restoring the palette when changing back to our VT.
* Checking 20 times a second of the VT has changed and, if it has, 
triggering a full screen redraw (the kernel doesn't restore it for us 
due to the amount of memory it would take to store an off screen buffer 
of every VT).

There are some ugly bits in the VT handling code but for the most part 
it seems to work fine.

>     - on my system (486 with very old VGA screen -- max resolution
> 	is 640x480 w/ 16 colors) when i switch VT's (i'm using the
> 	framebuffer driver), the switch works fine, but i get
> 	garbage when i return.  where should i start looking for
> 	this?  i assume restoration of video modes is a kernel
> 	function?  but what graphics mode does it restore?  anything
> 	set by the application?

Are you sure you have VTSWITCH enabled and your application isn't 
ignoring the EXPOSURE event that it gets when the screen redraw is 
triggered?

>  paul fox, ####@####.#### (arlington, ma, where it's 70.2 degrees)

You know that still confuses me every time I see it until I remember you 
mean degrees Fahrenheit ;) It's 16.4 degrees Centigrade and falling here 
in Burnley, England...

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

thanks, alex, for all the good info.


 > >     - VT switching -- the driver clearly has code which supports
 > > 	console switching via Alt-FN.  i sort of thought VT switching
 > > 	was configured via VTSWITCH in the config file, but clearly
 > > 	that's not the case.  what _is_ the code in vtswitch.c for?
 > 
 > vtswitch.c is only linked in and the code in it only used if VTSWITCH is 
 > set to Y. The VTY switch code handles:

okay.  i now understand this.  i think.  :-)

 > 
 > * Stopping Microwindows from drawing to the framebuffer when ours is not 
 > the currently active VT by changing the drawing functions to dummy ones 
 > that don't do anything.
 > * Re-enabling the drawing functions when we change back.
 > * Delaying the VT change if a drawing operation is currently in progress 
 > when the signal is received (otherwise the currently active drawing 
 > operation, which could be anything from drawing a single dot to painting 
 > a rectangle the size of the screen, would carry on after the VT switch).
 > * Saving the palette when changing to another VT.
 > * Restoring the palette when changing back to our VT.
 > * Checking 20 times a second of the VT has changed and, if it has, 
 > triggering a full screen redraw (the kernel doesn't restore it for us 
 > due to the amount of memory it would take to store an off screen buffer 
 > of every VT).

so i guess to summarize, the code in kbd_ttyscan.c causes the VT switch,
and the code in vtswitch.c deals with the results, to keep things pretty.
fair?

my switching doesn't work whether VTSWITCH is configured on or
off.  i have it off right now because otherwise i can't start my
app using gdb from a telnet session.  (running gdb on the console
is a non-starter, of course.  :-) the vtswitch code gives an
early error if you start the app from a non-console screen.

 > 
 > There are some ugly bits in the VT handling code but for the most part 
 > it seems to work fine.
 > 
 > >     - on my system (486 with very old VGA screen -- max resolution
 > > 	is 640x480 w/ 16 colors) when i switch VT's (i'm using the
 > > 	framebuffer driver), the switch works fine, but i get
 > > 	garbage when i return.  where should i start looking for
 > > 	this?  i assume restoration of video modes is a kernel
 > > 	function?  but what graphics mode does it restore?  anything
 > > 	set by the application?
 > 
 > Are you sure you have VTSWITCH enabled and your application isn't 
 > ignoring the EXPOSURE event that it gets when the screen redraw is 
 > triggered?

ahem.  hmmm.  no, it doesn't.  the vnc in the demos directory doesn't,
and that's what i started with for my tightVNC port.

so that'll help, for sure -- but without handling EXPOSURE, i
would have expected a blank screen of some sort after the switch, no?
i'm getting a screen full of ascii, and line-drawing characters.  it
looks more like the graphic mode hasn't been restored.  i assume the
kernel _does_ restore the chips' registers, right?

anyway, that's another thing to fix/try.  thanks.

paul
=---------------------
 paul fox, ####@####.#### (arlington, ma, where it's 69.8 degrees)

:     - VT switching -- the driver clearly has code which supports
: console switching via Alt-FN.  i sort of thought VT switching
: was configured via VTSWITCH in the config file, but clearly
: that's not the case.  what _is_ the code in vtswitch.c for?

Normally, the kernel handles sending a signal to nano-X
when the console is changed via the Alt-FN function keys.
The receiving code for this is in vtswitch.c.  When the
kbd_ttyscan.c raw-mode keyboard driver is used, those
same function keys don't do anything - so there's
some code in kbd_ttyscan.c to start the virtual console
switch, which is handled eventually in vtswitch.c.


: 
:     - on my system (486 with very old VGA screen -- max resolution
: is 640x480 w/ 16 colors) when i switch VT's (i'm using the
: framebuffer driver), the switch works fine, but i get
: garbage when i return.  where should i start looking for
: this?  i assume restoration of video modes is a kernel
: function?  but what graphics mode does it restore?  anything
: set by the application?

This is the second time I've heard this.  It sounds like there might
be a problem with the kernel redrawing the graphics area on
return from a VT switch.  If this is the case, then a call
to GsRedrawScreen() might be necessary from the vtswitch
code to case nano-X to tell all applications to redraw their screens.
(this will only work for Nano-X,  win32 will require a
MwRedrawScreen()).

Regards,

Greg

 > : 
 > :     - on my system (486 with very old VGA screen -- max resolution
 > : is 640x480 w/ 16 colors) when i switch VT's (i'm using the
 > : framebuffer driver), the switch works fine, but i get
 > : garbage when i return.  where should i start looking for
 > : this?  i assume restoration of video modes is a kernel
 > : function?  but what graphics mode does it restore?  anything
 > : set by the application?
 > 
 > This is the second time I've heard this.  It sounds like there might
 > be a problem with the kernel redrawing the graphics area on
 > return from a VT switch.  If this is the case, then a call
 > to GsRedrawScreen() might be necessary from the vtswitch
 > code to case nano-X to tell all applications to redraw their screens.
 > (this will only work for Nano-X,  win32 will require a
 > MwRedrawScreen()).

thanks greg -- so if i understand this correctly, it's the GsRedrawScreen()
that causes the per-window EXPOSURE events that alex mentioned in an
earlier note, correct?

i notice that a periodic check for VT switches is done on a timer
basis if GsInitialize() is called.  however, this won't be called
(i don't think) if running as a monolithic app.  certainly the vnc
code doesn't call it.  of course, now that i'm looking at it, i
don't see how anything at all gets initialized correctly when running
as a monolithic app.  none of the stuff that GsInitialize() does
(opening the mouse, the keyboard, the initial GsRedrawScreen())
gets done.  i guess the answer is that the monolithic app is
running just in a lone window, not in a window on top a root.

so i guess the GsRedrawScreen() _is_ missing...

paul
=---------------------
 paul fox, ####@####.#### (arlington, ma, where it's 66.9 degrees)

Paul Fox wrote:
> so i guess to summarize, the code in kbd_ttyscan.c causes the VT switch,
> and the code in vtswitch.c deals with the results, to keep things pretty.
> fair?

Yes.

> ahem.  hmmm.  no, it doesn't.  the vnc in the demos directory doesn't,
> and that's what i started with for my tightVNC port.

Oh dear. Maybe the VNC port was done before we had pixmap support. I'd 
just set up an offscreen pixmap the same size as the onscreen window and 
draw to both of them at the same time, then when you get an exposure 
event copy the relevant area of the pixmap to the screen.

> so that'll help, for sure -- but without handling EXPOSURE, i
> would have expected a blank screen of some sort after the switch, no?

No, I don't think the kernel clears the screen on VT switch. When the VT 
it's switching to is in text mode (I know it's actually graphics, but 
the VT system still has the concept of seperate text mode and graphics 
modes even when using the framebuffer), it restores the text buffer for 
that VT, but I'm not quite sure what it draws to a VT that's in graphics 
mode. Probably nothing.

> i'm getting a screen full of ascii, and line-drawing characters.  it
> looks more like the graphic mode hasn't been restored.  i assume the
> kernel _does_ restore the chips' registers, right?

I think so. I don't think it restores the palette though which is why we 
do it in vtswitch.c.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

Greg Haerr wrote:
> This is the second time I've heard this.  It sounds like there might
> be a problem with the kernel redrawing the graphics area on
> return from a VT switch.  If this is the case, then a call
> to GsRedrawScreen() might be necessary from the vtswitch
> code to case nano-X to tell all applications to redraw their screens.
> (this will only work for Nano-X,  win32 will require a
> MwRedrawScreen()).

Greg, I don't think the kernel is supposed to redraw the framebuffer 
when it switches to a graphics mode VT. That's why we have 
CheckVtChange() in srvmain.c that runs every 50ms and calls 
GsRedrawScreen() if the VT has switched. Actually looking at that, it 
should have been converted to a periodic timer when they were 
implemented (see attached patch).

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

--- srvmain.c.old	Thu Jul 25 23:11:53 2002
+++ srvmain.c	Thu Jul 25 23:13:17 2002
@@ -655,9 +655,7 @@
 static void
 CheckVtChange(void *arg)
 {
-	if(MwCheckVtChange())
-		GsRedrawScreen();
-	GdAddTimer(50, CheckVtChange, NULL, GR_FALSE);
+	if(MwCheckVtChange()) GsRedrawScreen();
 }
 #endif
   
@@ -828,7 +826,7 @@
 #if VTSWITCH
 	MwInitVt();
 	/* Check for VT change every 50 ms: */
-	GdAddTimer(50, CheckVtChange, NULL, GR_FALSE);
+	GdAddTimer(50, CheckVtChange, NULL, GR_TRUE);
 #endif
 	psd->FillRect(psd, 0, 0, psd->xvirtres-1, psd->yvirtres-1,
 		GdFindColor(BLACK));

: thanks greg -- so if i understand this correctly, it's the GsRedrawScreen()
: that causes the per-window EXPOSURE events that alex mentioned in an
: earlier note, correct?

Yes - but that's not how vtswitch works.  Vtswitch never calls
GsRedrawScreen(), and no applications are ever asked to redraw
their window contents.  Vtswitch depends on the KERNEL
refreshing the screen, based on it having been saved elsewhere
by the kernel.  That's why I think it has to do with a bug
in the VGA16 kernel driver.  A possible workaround is to
have nano-X refresh the screen, which will be slower, and
you'll see flicker as each app refreshes it's window.
(nanowm will redraw the root window)


: 
: i notice that a periodic check for VT switches is done on a timer
: basis if GsInitialize() is called.  however, this won't be called
: (i don't think) if running as a monolithic app.  certainly the vnc
: code doesn't call it.

Wait a moment - VNC is a client app, and doesn't call the
GsXXX routines, which are only available for the server to
call.  The Nano-X server calls GsInitialize in nanox/srvmain.c.

When a monolithic app is used, then NONETWORK is #defined,
and the GrOpen() call from the client ends up calling
nanox/srvmain.c::GrOpen(), which calls GsInitialize()... It's
a little tricky.

Regards,

Greg



  of course, now that i'm looking at it, i
: don't see how anything at all gets initialized correctly when running
: as a monolithic app.  none of the stuff that GsInitialize() does
: (opening the mouse, the keyboard, the initial GsRedrawScreen())
: gets done.  i guess the answer is that the monolithic app is
: running just in a lone window, not in a window on top a root.
: 
: so i guess the GsRedrawScreen() _is_ missing...
: 
: paul
: =---------------------
:  paul fox, ####@####.#### (arlington, ma, where it's 66.9 degrees)
: 
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
: 

: Oh dear. Maybe the VNC port was done before we had pixmap support. I'd 
: just set up an offscreen pixmap the same size as the onscreen window and 
: draw to both of them at the same time, then when you get an exposure 
: event copy the relevant area of the pixmap to the screen.

Actually, I don't recommend this approach - it'd be better to
have VNC request it's server to redisplay everything than to
completely rewreite VNC to draw twice every time it draws.
: 
: No, I don't think the kernel clears the screen on VT switch. When the VT 
: it's switching to is in text mode (I know it's actually graphics, but 
: the VT system still has the concept of seperate text mode and graphics 
: modes even when using the framebuffer), it restores the text buffer for 
: that VT, but I'm not quite sure what it draws to a VT that's in graphics 
: mode. Probably nothing.

The kernel redraws the saved console tty session when switching to
text or graphics modes.  The only difference is settings in the VGA
chip.  In fact, the chip is reprogrammed when switching between
any two graphics resolutions VT's, as well. 

And now that I think of it, that's probably the kernel bug - the
VGA16 console driver tries to refresh the contents of the character
data and trashes the screen, even when the nano-X server data should
be displayed be the kernel instead. (it may be a panning problem)


regards,

Greg

: Greg, I don't think the kernel is supposed to redraw the framebuffer 
: when it switches to a graphics mode VT. That's why we have 
: CheckVtChange() in srvmain.c that runs every 50ms and calls 
: GsRedrawScreen() if the VT has switched.

No, I think that our code is there to send a VT ACK to the kernel
to allow the switch, and then the kernel redisplays the data.  I know
we don't need a GsRedrawScreen() in normal vtswitch code, since
this code has worked for some time.


 Actually looking at that, it 
: should have been converted to a periodic timer when they were 
: implemented (see attached patch).

I'll take a look at it.

Regards,

Greg