nanogui: VT switching questions
Subject:
Re: [nanogui] VT switching questions
From:
Paul Fox ####@####.####
Date:
25 Jul 2002 22:06:46 -0000
Message-Id: <26024.1027634002@foxharp.boston.ma.us>
> :
> : - 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)
