On Wed, 30 Oct 2002, Manuel Bouyer wrote:

# Yes, but it shouldn't prevent getty on the console from working.

Well, "shouldn't" is subjective.  I've always been very very careful
with TIOCCONS.

According to spec, TIOCCONS causes the named window to assume I/O
characteristics of the console, loosely speaking -- meaning if you run a
getty on the console and then run xterm -C, the xterm and the getty will
be competing for tty input.  Similarly, xconsole is going to have all
console I/O running on it.  Since there's no I on an xconsole window,
you can type on the wscons, but all the O goes to the xconsole.
[also, tty modes are ignored on the I channel of the console if something
else is TIOCCONSd in.]

Now, I will state that this arrangement falls under the category of
"inconvenient" if ill-timed, but it's behaving as advertised.

I had to make sure that I timed my XDM startup properly on my sparc, as if
it started up before getty, the getty would hit the xconsole (which I
started purposely to avoid the scrolling-console bit.  I turn it off on my
x86 box because I can M-^<F1> to get back to the console....).  If I
killed the xconsole with a getty attached, incidentally, my box would
panic.  Or XDM would die, I forget precisely which.

[I note this is no longer a problem -- the getty restarts on /dev/console
 when I kill the xconsole window.  I should re-test on the SPARC port
 and see what happens...]

				--*greywolf;
--
NetBSD: The power to Connect