Re. http://mail-index.netbsd.org/netbsd-help/2003/07/09/0002.html

This may seem like splitting hairs, but putting the right terms on
things may clarify what's going on and suggest solutions:

 * You *do* have access to screen1 (a.k.a. virtual terminal 1).  It
   just happens to be running X instead of a getty login when you
   boot with gdm.

 * <Ctrl>-<Alt>-<Backspace> doesn't "reset" X; it *kills* the X server.
   Apparently, gdm notices this and RESTARTS X.  X hasn't "moved" itself
   anywhere; rather the "bad" instance of X is *gone* and a new one starts.

This, combined with experience from running X via "startx" (which I think
of as the "normal" way to run X) suggests to me what is happening:

When you boot, gdm is started quite early.  It starts X, in turn, before
getty is going on the second (or any?) virtual terminal, so X takes the
first "unused" console it finds.  Later, after booting, when you kill off
X, gdm restarts it.  But getty slips a login console onto the second virtual
terminal ("screen1"), which forces X off to the only used virtual terminal.


I have a few ideas for dealing with this:

 * Run "startx" manually instead of relying on a display manager.  This
   has always worked for me, and it lets you control things like the bit-
   depth.  (Usually I want a 16-bit display, but sometimes I want only
   8 bits and other times I want 24 bits.)

   If you *really* want a graphical login, this may not be all that appealing
   to you.

 * Try using xdm instead of gdm.  (Maybe you really want/need gdm.  But
   my suspicion is that xdm was tested with NetBSD prior to release and
   this problem would have been fixed.  I never run display managers,
   though, so I don't *know* if the problem is fixed there...)

 * If xdm works correctly, you might try to analyze the source code to
   see what it does to get around this.  Then maybe you can fix gdm...

 * Lastly, if you want to use gdm and can't (or don't want to) read the
   xdm sources, you might see if you can somehow wrap a delay around the
   gdm (or gdm's launch of X).  If you can postpone X being launched by
   some short time (perhaps just a few seconds) while the *rest* of the
   NetBSD system boots, virtual terminal 1 ("screen1") will probably be
   busied with a login prompt, so X will be forced off to the last virtual
   terminal.

   It may require a little attention to make sure that you don't also
   postpone launching getty when you postpone gdm...I'm not sure how
   much concurrency occurs in the boot process.


I hope that that helps some.  Good luck.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/