On Sun, 20 Jul 2003, Simon J. Gerraty wrote:
> However twice now, when switching, the target XFree86 gets itself into
> a loop and kill -9 is the only option it seems.  I can kill everying
> running on that vty (eg ttyE1), but although a getty runs again it
> appears to be stuck in graphics mode.  Ie. if I now Ctrl-Alt-F2 I just
> get a frozen view of my other desktop.

I think you'll find that this particular kind of lockup happens less
frequently if you never switch directly between graphical virtual
consoles, but instead switch graphics -> text -> graphics, waiting long
enough in the text console for the mode change to complete.

Once X gets confused, I don't know of anything that will reliably put
the screen back into text mode.  I believe that this is because the
kernel expects the X server to do that job, and if the X server is
confused or killed then it never happens.

I have been told that stupid PC hardware issues make it impossible for
the kernel to switch the screen from an arbitrary unknown mode to a
known text mode.  This theory claims that the things you have to do to
the device registers to change modes are dependent on both the old and
new modes, so if you don't know the old mode then you are in trouble.  I
can almost believe the theory, except that I find it hard to understand
why there's not even a reset command that the kernel could use to put
the screen controller into a known state.

--apb (Alan Barrett)