On Wed, 9 Jul 2003 14:13:20 -0500, Richard Rauch <rkr@olib.org> wrote:
> 
> 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.
...
>    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.

Let's suppose you're right, Richard, and there's a race condition between
getty and gdm.  That suggests to me that gdm is slightly broken on NetBSD,
insofar as it's not serializing its access to the console in the same way
xdm does.  

Rather than a simple delay-and-hope, surely it would be better to block
against the contended resource.  Do you know anything about that?  

--jkl