Path: utzoo!utgpu!news-server.csri.toronto.edu!orasis.vis.toronto.edu!gene
Newsgroups: comp.sys.sgi
From: gene@vis.toronto.edu (Eugene Amdur)
Subject: Re: Graphics Console Woes
Message-ID: <91Jun26.091927edt.8336@orasis.vis.toronto.edu>
Organization: Department of Computer Science, University of Toronto
References: <9106250455.AA07119@gsusgi1.gsu.edu> <1991Jun26.002448.16305@odin.corp.sgi.com>
Date: 26 Jun 91 13:19:59 GMT
Lines: 75

In article <1991Jun26.002448.16305@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>In <9106250455.AA07119@gsusgi1.gsu.edu> syscrc@GSUSGI1.GSU.EDU (Randy Carpenter) writes:
>| I've talked to a couple of SGI folks about this one and they say:
>| "It can't be done.".   Tell me it ain't so... 
>

yes they told me this as well...

>Perhaps the problem wasn't stated as clearly as it is here?
>
>| [ description of wanting a private console on ttyd1 and a
>|   public graphics terminal at the same time deleted ]

>You don't lose the console, it just doesn't start graphics
>automatically.  What you could do is have a script fire up the
>graphics for you from /etc/inittab or one of the rc scripts.  What
>you lose this way is the ability to have people login as different
>id's.
>
>In IRIX 4.0, the graphics login will come up even when the console
>is set to 'd' (assuming the graphics is present and working).
>
>For now, if the machine is on the net, you could have the person
>who wants to use the graphics console rlogin, and then type
>	/etc/gl/restartgl
>which will start the window system as though they had just logged in.
>An rsh command to do the same thing should also work.

This is a start but you can go further...
I send this to the original poster but perhaps it got lost so...

We have a 340VGX and wanted to do the same thing.  We got the same
answer from SGI but I wasn't happy with no for an answer.  I figured
out a way to do it.  In addition to "setenv console d", you also have to 
change your /etc/inittab.  Just beneath 
the line that says (or used to say if you've deleted it):
	
#On-board DUART ports
	
We have the following four lines:

co:23:respawn:/etc/gl/conslog
gr:23:respawn:/etc/gl/grcond < /dev/grcons /etc/gl/pandora -s
t0:23:off:/etc/getty ttyd0 co_9600
t1:23:respawn:/etc/getty -s console ttyd1 co_9600       # alt console

I can't remember why the first line is needed (it seems that it shouldn't
be needed but I seem to remember it not working without it).  The second line 
starts up a pandora on the graphics console to make is usable as a terminal 
(we like the -s option for various reasons including security).  The third 
line turns off the getty on the ttyd0 port.  The fourth line puts up a getty 
on the tty acting as the real console hidden away in the machine room (I 
would think that the first line does this too).

There are some programs in /etc/gl that are worth noting.  /etc/gl/setupcons
links the /dev/console device to the actual console (i.e. /dev/grcons if
grafics are enabled or /dev/ttyd1 otherwise).  And /etc/conslog sets up
a getty or pandora on the console (depending on ttyd1 or graphics).
Because of the way that SGI detects what to used (i.e. ttyd1 or grcons) there 
is one problem with this whole setup.  If someone logs into the pandora window 
with the NOGRAPHICS option after his user name then she will log onto the 
new console (i.e. /dev/ttyd1)!  I've reported this as a bug and SGI claims 
it will be fixed in 4.0.  

One last thing of note.  When you log on to the graphics monitor with the above
setup, you don't get a console window (the console is busy after all) in your
NeWS setup.  So if you don't have /usr/NeWS/bin in your path you have no way 
of starting up a shell and then the only thing that you can do is log off.  As 
a result we have put /usr/NeWS/bin into our path on the default .cshrc that 
each user gets, this gives those small rectangular icons in the upper left
of the screen which allow you to start shells and the like.

Hope this helps.
--gene
gene@vis.toronto.edu