Subject: wscons "usl_detachtimeout" (multiple X servers)
To: None <tech-kern@netbsd.org>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-kern
Date: 02/04/2000 00:08:59
I had long desired to run multiple X sessions from xdm, so I much
appreciated the encouragement to do so in messages from the middle
of last month - since restarting xdm meant logging out (something I
don't do frequently) I only got around to trying this recently, and
since the problem I found only occurs (perhaps) after a reboot,
I found that even more recently.

First, the actual recipe for the Xservers file that worked was ...

:0 local /usr/X11R6/bin/X vt08
:1 local /usr/X11R6/bin/X :1 vt07

(the suggestion omitted the second ":1")   I guess I should add ":0" to
the vt08 line, but that's the default.

When xdm starts this way though, the kernel (wscons) prints "usl_detachtimeout"
messages periodically, and switches to ttyE0 of its own volition.   It is
possible to switch back, but a "xrefresh" is needed to get the X display
back (the X server acts as if it had no idea that its display was yanked
out from under it - though it does return to graphics mode).

This seems related to having the two X servers running - probably related to
one of them never actually getting the display handed to it (normally when the
X server starts wscons switches to that virtual console - but when two are
starting at the same time, one is going to miss out...)

An easy workaround is just to explicitly visit each X server's virtual console
with CTL-ALT-Fn (CTL-ALT-F7 and CTL-ALT-F8 in the example above).   After
each of the servers has had its turn to display something the usl_detachtimeout
messages (and corresponding auto shift to ttyE0) stop, and everything is fine.

I have never looked in the wscons code, so I thought I'd just mention this
in case someone who knows it would like to take a look, and get rid of the
need for the manual switching (even if it means that X servers were
constrained to start serially, and the display hardware switched to each in
turn - though perhaps better would be to simply delay the startup sequence
of all but the first until the user explicitly switches there).

kre