Thanks for the report - could you send-pr this info?


		David/absolute

On Fri, 4 Feb 2000, Robert Elz wrote:

> 
> 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
> 
> 
> 
>