From: CSRG Date: Wed, 15 Jun 1988 12:15:52 +0000 (-0800) Subject: BSD 4_3_Tahoe development X-Git-Tag: BSD-4_3_Net_1^2~80 X-Git-Url: https://git.subgeniuskitty.com/unix-history/.git/commitdiff_plain/3b0fe1d7e7d9d40ea118ed73521708fe91177cc9 BSD 4_3_Tahoe development Work on file usr/src/new/X/QDSS.README Work on file usr/src/new/X/X11.README Synthesized-from: CSRG/cd2/4.3tahoe --- diff --git a/usr/src/new/X/QDSS.README b/usr/src/new/X/QDSS.README new file mode 100644 index 0000000000..b29654c4d5 --- /dev/null +++ b/usr/src/new/X/QDSS.README @@ -0,0 +1,91 @@ +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 + diff --git a/usr/src/new/X/X11.README b/usr/src/new/X/X11.README new file mode 100644 index 0000000000..52d40b3d4a --- /dev/null +++ b/usr/src/new/X/X11.README @@ -0,0 +1,101 @@ +The X11R2 distribution wasn't included with 4.3BSD-tahoe due to +space considerations. It is available from MIT by anonymous ftp +from expo.lcs.mit.edu or on tape distribution. Minimal changes are +required to compile it under this release. + +The X11R2 code was compiled on a VAX, and servers for Digital +Equipment Corp. display hardware QDSS and QVSS were built (see +QDSS.README for details). The following is a list of changes that +are necessary to compile X11R2 servers for QDSS and QVSS. + +1) Apply patches 1 through 33 to the stock MIT X11R2 distribution. + (patches available from expo.lcs.mit.edu via anonymous FTP) + +2) In X11R2/server/ddx/dec/qdss/Ultrix2.0inc.h, comment out the + reference to "". + +3) Due to changes in preparation for ANSI C, the ioctl macros + have changed. In X11R2/server/ddx/dec/qdss/libtl/tl.h add + single quotes around the letters in the ioctl declarations. + +------- tl.h ------- +*** /tmp/d16813 Tue Jun 14 15:53:44 1988 +--- tl.h Fri May 27 17:42:41 1988 +*************** +*** 186,196 **** + extern char * Cur; + extern struct color_buf * Co[2]; + +! #define SG_MAPDEVICE _IOR(g, 9, struct sgmap) /* map device to user */ +! #define SG_VIDEOON _IO(g,23) /* turn on the video */ +! #define SG_VIDEOOFF _IO(g,24) /* turn off the video */ +! #define SG_CURSORON _IO(g,25) /* turn on the cursor */ +! #define SG_CURSOROFF _IO(g,26) /* turn off the cursor */ + #define ADDRESS_COUNTER 0 + #define REQUEST_ENABLE 1 + #define STATUS 3 +--- 186,196 ---- + extern char * Cur; + extern struct color_buf * Co[2]; + +! #define SG_MAPDEVICE _IOR('g', 9, struct sgmap) /* map device to user */ +! #define SG_VIDEOON _IO('g',23) /* turn on the video */ +! #define SG_VIDEOOFF _IO('g',24) /* turn off the video */ +! #define SG_CURSORON _IO('g',25) /* turn on the cursor */ +! #define SG_CURSOROFF _IO('g',26) /* turn off the cursor */ + #define ADDRESS_COUNTER 0 + #define REQUEST_ENABLE 1 + #define STATUS 3 +------------------------------------------------ + +4) In X11R2/server/ddx/dec/qdss/qdpushpxl.c there is a null + storage declaration which the Ultrix compiler doesn't mind, + but the 4.3BSD-tahoe compiler does. Move the null storage + declaration inside the "#ifdef notdef" section of code. + +------- qdpushpxl.c ------- +*** /tmp/d16864 Tue Jun 14 15:56:21 1988 +--- qdpushpxl.c Fri May 27 18:07:04 1988 +*************** +*** 247,255 **** + int x1, y1, x2, y2; /* clipping rectangle in pixmap coords*/ + int xOrg, yOrg; /* origin of bitmap within pixmap */ + { +- int mask[]; + + #ifdef undef + register int chmask = 0xff << (ch*8); + u_char * destorig = ((QDPixPtr)pPixmap->devPrivate)->data + [ nch * pPixmap->width * pPixmap->height]; +--- 247,255 ---- + int x1, y1, x2, y2; /* clipping rectangle in pixmap coords*/ + int xOrg, yOrg; /* origin of bitmap within pixmap */ + { + + #ifdef undef ++ int mask[]; + register int chmask = 0xff << (ch*8); + u_char * destorig = ((QDPixPtr)pPixmap->devPrivate)->data + [ nch * pPixmap->width * pPixmap->height]; +--------------------------------- + +5) X11R2/server/os/4.2bsd/connection.c has a bug which causes + the unix domain socket to have the wrong permission, and clients + can't connect to it. Add a umask(0) before the bind(). + +*** connection.c-r1.1 Tue Jun 14 15:44:43 1988 +--- connection.c-r1.2 Tue Jun 14 15:44:44 1988 +*************** +*** 219,226 **** +--- 219,228 ---- + } + else + { ++ oldUmask = umask (0); + if(bind(request,(struct sockaddr *)&unsock, strlen(unsock.sun_path)+2)) + Error ("Binding Unix socket"); ++ (void)umask(oldUmask); + if (listen (request, 5)) Error ("Unix Listening"); + WellKnownConnections |= (1 << request); + } +-----------------------------------