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