![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to QDSS.README CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDTahoe / new / X|
Return to QDSS.README CVS log | Up to [CSRG BSD Unix] / 43BSDTahoe / new / X |
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:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.