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 (file)
index 0000000..b29654c
--- /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 (file)
index 0000000..52d40b3
--- /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 "<sys/devio.h>".
+
+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);
+      }
+-----------------------------------