Annotation of 43BSDTahoe/new/X/QDSS.README, revision 1.1

1.1     ! root        1: This release of 4.3BSD-tahoe contains kernel display drivers for
        !             2: Digital Equipment Corp's QDSS and QVSS display hardware.  The code
        !             3: is made available by the Ultrix Engineering Group.  The X11R2
        !             4: distribution contains server code for both QDSS and QVSS, and the
        !             5: X10R4 distribution contains server binaries for QVSS.  In addition,
        !             6: the Ultrix UWS 1.1 X10R4 qdss server binary apparently works under
        !             7: 4.3BSD-tahoe. The kernel display drivers have been tested using
        !             8: both X11R2 and X10R4 servers.
        !             9: 
        !            10: To include qvss or qdss support in the kernel include one of the
        !            11: following lines in your config file:
        !            12: 
        !            13:     device qd0 at uba0  csr 0177400  flags 0x0f  vector qddint qdaint qdiint
        !            14:     device qv0 at uba0  csr 0177200  vector qvkint qvvint
        !            15: 
        !            16: In /dev make the appropriate special file:
        !            17: 
        !            18:    mknod qd0 c 41 2    # for QDSS
        !            19:    mknod mouse c 40 2  # for QVSS
        !            20: 
        !            21: Here is an example entry of /etc/ttys for starting the window system
        !            22: automatically (it assumes you have renamed a pty/tty pair as ptyv0
        !            23: and ttyv0):
        !            24: 
        !            25:        ttyv0   "/usr/bin/X11/xterm -L -C -bw 3 -fn 9x15 -rv
        !            26:            -geometry 80x24+150+250 -display :0" xterm on secure
        !            27:            window="/usr/bin/X11/Xqdss -c -co /usr/lib/X11/rgb"
        !            28: 
        !            29: Although the hardware supports multiple QDSS's per machine, the
        !            30: current qdss driver has only been tested using one.
        !            31: 
        !            32: Standalone qdss and qvss drivers are present in /boot.  If there
        !            33: is a failure initializing the display, the boot program reverts to the
        !            34: real microvax console port.
        !            35: 
        !            36: Cursor motion has been added to the qdss glass tty driver so full
        !            37: screen editors will work when the window system isn't running.  To
        !            38: take advantage of this feature set the terminal type to "qdcons"
        !            39: when running in the glass tty.  The termcap entry for qdcons is:
        !            40: 
        !            41:     qd|qdss|qdcons|qdss glass tty:\
        !            42:        :am:do=^J:le=^H:bs:cm=\E=%.%.:cl=1^Z:co#128:li#57::nd=^L:up=^K:
        !            43: 
        !            44: The qdss glass tty driver isn't perfect, and in fact operates at
        !            45: a high ipl which degrades performance if a lot of output is sent
        !            46: to it.  It is recommended that all console output be directed to
        !            47: a window when the window system is active.  4.3BSD-tahoe supports the
        !            48: TIOCCONS ioctl which can make any tty the target for console output.
        !            49: The "-C" flag to xterm should invoke this ioctl, or one can write
        !            50: a small program doing essentially:
        !            51: 
        !            52:        int on = 1;
        !            53: 
        !            54:        ioctl(0, TIOCCONS, &on);
        !            55: 
        !            56: A short discussion on console devices is in order.  There are
        !            57: effectively three possible notions of a console on a workstation.
        !            58: The first is the real hardware device known as the console port on
        !            59: the machine.  The second is the effective console, which is where
        !            60: the special file "/dev/console" does its I/O.  In the presence of
        !            61: display hardware, one wants the effective console to be the display
        !            62: device, not the real console port.  Once the CPU has detected the
        !            63: presence of display hardware it automatically uses the display for
        !            64: console command dialogue and diagnostics.  However, once the system
        !            65: software starts running it's up to the software to detect the
        !            66: presence of display hardware and re-channel console I/O there.
        !            67: Ultrix and 4.3BSD-tahoe do this differently.  Under Ultrix, the
        !            68: display drivers replace cdevsw[0] with the glass tty display
        !            69: routines, and all references to /dev/console actually call the
        !            70: display routines directly.  4.3BSD-tahoe leaves cdevsw[0] alone
        !            71: and instead has a global pointer called "consops" which points to
        !            72: the cdevsw entry of the currently active console device.  The
        !            73: standard console routines check if consops is set and if so re-channel
        !            74: I/O there.  This is acceptable until the window system starts
        !            75: running, after which time any output to the glass tty display causes
        !            76: the screen to become a mess, and thus the third notion of a console:
        !            77: where one really wants output to appear.  The goal is to direct
        !            78: console output away from the glass tty when the window system is
        !            79: running, but restore it when it isn't.  4.3BSD-tahoe accomplishes
        !            80: this by having another pointer called "constty" which points to a
        !            81: tty for console output.  Any tty (like an xterm window) can be made
        !            82: the target of console output by using the TIOCCONS ioctl described
        !            83: earlier.  Given that all console I/O of one form or another has
        !            84: effectively been directed away from the real console port, the next
        !            85: obvious question is how to access the real hardware console port.
        !            86: The 4.3BSD-tahoe console routines only redirect console I/O if the
        !            87: minor device number is zero, thus, making another console device
        !            88: with minor device number one will suffice. E.g.
        !            89: 
        !            90:        mknod /dev/altcons c 0 1 
        !            91: 

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.