This release of 4.3BSD-tahoe contains kernel display drivers for
Digital Equipment Corp's QDSS and QVSS display hardware.  The code
is made available by the Ultrix Engineering Group.  The X11R2
distribution contains server code for both QDSS and QVSS, and the
X10R4 distribution contains server binaries for QVSS.  In addition,
the Ultrix UWS 1.1 X10R4 qdss server binary apparently works under
4.3BSD-tahoe. The kernel display drivers have been tested using
both X11R2 and X10R4 servers.

To include qvss or qdss support in the kernel include one of the
following lines in your config file:

    device qd0 at uba0  csr 0177400  flags 0x0f  vector qddint qdaint qdiint
    device qv0 at uba0  csr 0177200  vector qvkint qvvint

In /dev make the appropriate special file:

   mknod qd0 c 41 2	# for QDSS
   mknod mouse c 40 2	# for QVSS

Here is an example entry of /etc/ttys for starting the window system
automatically (it assumes you have renamed a pty/tty pair as ptyv0
and ttyv0):

	ttyv0   "/usr/bin/X11/xterm -L -C -bw 3 -fn 9x15 -rv
	    -geometry 80x24+150+250 -display :0" xterm on secure
	    window="/usr/bin/X11/Xqdss -c -co /usr/lib/X11/rgb"

Although the hardware supports multiple QDSS's per machine, the
current qdss driver has only been tested using one.

Standalone qdss and qvss drivers are present in /boot.  If there
is a failure initializing the display, the boot program reverts to the
real microvax console port.

Cursor motion has been added to the qdss glass tty driver so full
screen editors will work when the window system isn't running.  To
take advantage of this feature set the terminal type to "qdcons"
when running in the glass tty.  The termcap entry for qdcons is:

    qd|qdss|qdcons|qdss glass tty:\
       :am:do=^J:le=^H:bs:cm=\E=%.%.:cl=1^Z:co#128:li#57::nd=^L:up=^K:

The qdss glass tty driver isn't perfect, and in fact operates at
a high ipl which degrades performance if a lot of output is sent
to it.  It is recommended that all console output be directed to
a window when the window system is active.  4.3BSD-tahoe supports the
TIOCCONS ioctl which can make any tty the target for console output.
The "-C" flag to xterm should invoke this ioctl, or one can write
a small program doing essentially:

	int on = 1;

	ioctl(0, TIOCCONS, &on);

A short discussion on console devices is in order.  There are
effectively three possible notions of a console on a workstation.
The first is the real hardware device known as the console port on
the machine.  The second is the effective console, which is where
the special file "/dev/console" does its I/O.  In the presence of
display hardware, one wants the effective console to be the display
device, not the real console port.  Once the CPU has detected the
presence of display hardware it automatically uses the display for
console command dialogue and diagnostics.  However, once the system
software starts running it's up to the software to detect the
presence of display hardware and re-channel console I/O there.
Ultrix and 4.3BSD-tahoe do this differently.  Under Ultrix, the
display drivers replace cdevsw[0] with the glass tty display
routines, and all references to /dev/console actually call the
display routines directly.  4.3BSD-tahoe leaves cdevsw[0] alone
and instead has a global pointer called "consops" which points to
the cdevsw entry of the currently active console device.  The
standard console routines check if consops is set and if so re-channel
I/O there.  This is acceptable until the window system starts
running, after which time any output to the glass tty display causes
the screen to become a mess, and thus the third notion of a console:
where one really wants output to appear.  The goal is to direct
console output away from the glass tty when the window system is
running, but restore it when it isn't.  4.3BSD-tahoe accomplishes
this by having another pointer called "constty" which points to a
tty for console output.  Any tty (like an xterm window) can be made
the target of console output by using the TIOCCONS ioctl described
earlier.  Given that all console I/O of one form or another has
effectively been directed away from the real console port, the next
obvious question is how to access the real hardware console port.
The 4.3BSD-tahoe console routines only redirect console I/O if the
minor device number is zero, thus, making another console device
with minor device number one will suffice. E.g.

	mknod /dev/altcons c 0 1