|
|
1.1 root 1: .NH
2: Installation Steps
3: .PP
4: This chapter explains in greater detail the steps covered in the overview.
5: It presumes the source hierarchy has been loaded in some convenient location,
6: and that the \fI/usr/new\fP directory
7: and \fI/usr/new/lib\fP directory already exist.
8: If you
9: have source or object for other display types in their device dependent
10: directories, you should edit the X/X/Makefile to build them.
11: .PP
12: This distribution was tested under the following versions of different
13: vendors systems.
14: .DS
15: 4.3BSD
16: Ultrix 1.2
17: Sun 3.0
18: Apollo 9.5
19: Integrated Solutions 3.07
20: IBM 4.2A Release 2.
21: .DE
22: You are on your own if you are using versions prior to those listed above.
23: We recommend upgrading to the later releases.
24: In particular, the server will not run on IBM 4.2A release 1,
25: and previous releases of the other systems may or may not work properly.
26: It is impossible for us to keep straight all the different versions
27: of different vendor's systems.
28: .PP
29: This distribution has not been tested for the Integrated Solutions
30: machine, as we had none available for testing.
31: .PP
32: The Apollo testing showed the installation to be quite rocky,
33: due to some problems with their C preprocessor,
34: and there was not time for complete integration of the changes required.
35: Good luck; you may need it, but it has been seen to work.
36: .PP
37: The client code should be easily portable to other 4.2BSD based systems,
38: the CCI for example.
39: Some System V based Unix systems also have the Berkeley network
40: support in them, but you are on your own here.
41: .NH 2
42: Prelude
43: .PP
44: NOTE:
45: As X is a network transparent window system, client programs use
46: network facilities to communicate with the window system.
47: Make sure your network code works properly BEFORE attempting to use X.
48: For example, \fItalk(1)\fP should be working properly between normal terminals,
49: or you should be able to \fIrlogin\fP to either the local or to
50: another machine if you have a network.
51: .PP
52: Also make sure you have made as many pseudo-teletypes as possible
53: (cd /dev; MAKEDEV pty0; MAKEDEV pty1).
54: These are used for terminal emulator windows, and it is possible you
55: may use quite a few of them.
56: .PP
57: If you have other machines in your network that run a 4.2BSD derived
58: system, you can also move the C language source code and recompile it
59: on those machines.
60: Performance of the terminal emulator will be improved by use of
61: 4.3BSD's improved pty driver, which is six times faster than the 4.2BSD
62: version.
63: The C applications should be able to communicate with the X server on
64: your display.
65: .NH 2
66: Font and Firmware Files
67: .PP
68: For each device type supported by X, fonts may differ.
69: There may also be local installation restrictions which may
70: prohibit you from using the default location of \fI/usr/new/lib/X\fP
71: for the fonts or other files needed by X (for example, Vs100 firmware).
72: In each device dependent X library should be a file \fIvssite.h\fP
73: which can be tailored to find the fonts and firmware in a different location.
74: Another reason why you may want to change the font and firmware directory
75: locations would be to allow use of the display while not having all of
76: your file systems mounted.
77: Tailor this file to your taste, and modify the master make file to move
78: the fonts and firmware to your location.
79: .PP
80: The binaries are normally installed into \fI/usr/new\fP.
81: If you want to change this, edit the master Makefile and change
82: CONFDIR to the directory you choose.
83: The entry ``make reconfig'' can be used to automatically edit the Makefiles
84: in the directories from \fI/usr/new\fP to your new configuration.
85: .NH 2
86: Reading the distribution.
87: .PP
88: The software comes on a single 1600 BPI magnetic tape in \fItar\fP(1) format.
89: All files will be extracted into a directory named \fBX\fP.
90: An example command would be:
91: .DS
92: \(bu tar xf /dev/rmt8
93: .DE
94: .PP
95: If you move the distribution to a different machine than the
96: one you read the tape on, use care to preserve
97: the symbolic links, either by moving the distribution as a single file
98: or by using \fItar\fP across the net.
99: If you don't, you will end up with more than one copy of certain key
100: include files, and may get confused later if you make changes.
101: .NH 2
102: Building the server
103: .PP
104: If you only want to build the client programs on a machine that does
105: not have a display, you can skip this step.
106: .PP
107: If you have a display on your workstation, you can build a server
108: for your display.
109: The types of displays supported under the MIT distribution include
110: the DEC VS100, VS-1, VS-2 and VS-2 RC, most Sun workstation displays,
111: the Apollo displays, the IBM RT/PC displays under 4.2A only
112: (this distribution will NOT run under AIX!), and the Integrated
113: Solutions Optimim V workstations.
114: Servers for other displays may only be available from the manufacturers.
115: Examples of this include the Vaxstation II/GPX from Digital, the
116: HP Bobcats, and Sony displays.
117: .PP
118: To build the server for your machine,
119: type one of the following:
120: .DS
121: .ta .5i 2.0i
122: .TA .5i 2.0i
123: \(bu make dec # for Digital Vs100 and VS1 and VS2
124: \(bu make sun # for Sun workstations
125: \(bu make apollo # for Apollo Computer workstations
126: \(bu make is # for Integrated Solutions workstations
127: \(bu make ibm # for IBM RT/PC under 4.2A
128: .DE
129: .PP
130: This should complete with no errors on the DEC, Sun, and IBM workstations.
131: The Apollo compiler may generate a number of warnings, and
132: X/dispatch.c takes a LONG time to compile.
133: The Apollo preprocessor has problems with several macros new to release 4;
134: you will have to edit out all occurences of "B16", and "UBPS" should be
135: changed to 1.
136: These macros are defined to make it easier to port X to
137: machines where a short is not 2 bytes.
138: .NH 2
139: Building Software
140: .PP
141: To build executable versions of all X programs,
142: execute the command
143: .DS
144: \(bu make all
145: .DE
146: in the main directory.
147: .PP
148: Compiling all software takes quite a while.
149: Building the X library takes the longest, as there are more than one
150: hundred fifty modules.
151: This should complete without error on most machines.
152: .NH 2
153: Installing the X Executables
154: .PP
155: As super user,
156: execute the command
157: .DS
158: \(bu make install
159: .DE
160: This should complete without error.
161: .PP
162: This also copies all necessary files for users to program
163: using X into \fI/usr/include/X\fP.
164: .PP
165: You should also install the correct termcap and terminfo (if
166: applicable)
167: files out of
168: \fIxterm/termcap\fP and \fIxterm/terminfo\fP into \fI/etc/termcap\fP
169: and your terminfo database if they are not already there.
170: .PP
171: The \fIxinit\fP program, useful
172: on machines without the proper init support for login,
173: expects that the running server to be called "X".
174: You can either rename the appropriate server for your display,
175: or use the correct arguments to \fIxinit\fP.
176: .NH 2
177: Building a Kernel With the Device Driver
178: .PP
179: On some machines, the display driver or other
180: auxilary file may not come configured into
181: the system or other device files may not exist.
182: You must add a line to your configuration file for each display you have.
183: Make sure the CSR address matches between your configuration file and your
184: hardware.
185: The VS100 driver comes with 4.3BSD.
186: Configure, make, and install the kernel containing the display driver.
187: When you reboot the machine, make sure that your display auto configures
188: during boot.
189: .PP
190: You should also make a device entry for each display.
191: For a Vs100, change directory to \fI/dev\fP,
192: and perform a ``MAKEDEV vs?'', where `?' is the number of the Vs100 as root.
193: For a QVSS on a MicroVAX,
194: the command would be
195: .DS
196: \(bu /etc/mknod /dev/mouse c 35 2 # if /dev/mouse does not exist on a VS-2.
197: \(bu /etc/mknod /dev/bell c 12 2 # for bell to ring on a Sun.
198: \(bu MAKEDEV displays # for displays on the RT/PC
199: .DE
200: Normally, the protection on the device would be only user read/write,
201: but for debugging purposes you may want to temporarily change it.
202: On a DEC VS-2, you should also adb /sys/vaxuba/qv.o and change
203: the variable "qv_def_scrn" to 2 and rebuild your system.
204: This will cause the correct screen parameters to be used on the VR-260 monitor.
205: .NH 2
206: Testing and Trouble Shooting
207: .PP
208: We highly recommend testing before attempting to enable
209: login on the display.
210: Error messages will go to your terminal, rather than being logged in
211: the file \fI/usr/adm/X?.hosts\fP.
212: You can use \fIxinit(1)\fP to aid you in testing, but
213: it is most easily performed from terminal or from across the network.
214: .PP
215: To test a Vs100 on line 0, for example,
216: you would change directory to /usr/new (or wherever you decided to put the
217: executable programs), and would type ``Xvs100 0 0 &''.
218: (For a MicroVAX, the command would be ``Xqvss 0 0 &'').
219: The first argument is which device to use (in this case \fI/dev/vs0\fP
220: will be used).
221: There can only be one display on a MicroVAX.
222: The second argument is ignored.
223: See the \fIX(8c)\fP and the manual pages
224: for particular servers manual page for other options.
225: .PP
226: If everything succeeds, you should get a grey background and a large
227: X cursor on the screen.
228: For reasons we have never understood, it may take three tries to get a
229: VS100 display to respond.
230: If not, the most common mistake is the fonts or firmware to be in the
231: wrong location or a directory or file to not be readable.
232: .PP
233: You should now be able to run any of the X programs.
234: A common beginning mistake would be to forget to set the "DISPLAY"
235: environment variable.
236: Most programs also take arguments to specify the host and display number.
237: So, for convenience while testing, you might execute the
238: command ``setenv DISPLAY \fIyourhost\fP:0'' where \fIyourhost\fP is the name of your
239: machine when using the C-shell.
240: This variable will be set for you automatically
241: when you log in in the future.
242: .PP
243: A common problem that might prevent the \fIxterm(1)\fP
244: program from working is it
245: not being set user ID and owned by root.
246: The installation makefiles should be installing \fIxterm(1)\fP this way.
247: \fIXterm\fP may also fail if the files described in the previous
248: section are not consistent, or if you attempt to use an xterm built
249: before the \fI/etc/init\fP changes were installed.
250: .PP
251: If everything is working, you should be ready to enable the line for login.
252: .NH 2
253: Automatic Login Support
254: .PP
255: Some systems are capable of starting the server and a login \fIxterm\fP
256: automatically, in particular 4.3BSD and Ultrix 1.2 and later.
257: If your system does not support the new /etc/ttys format,
258: you should skip this section.
259: On other systems, if you have source for 4.3BSD you may want to
260: install this support.
261: Mere mortals should probably think long and hard before risking such
262: installation, but wizards may find it not too difficult.
263: Affected programs include \fI/etc/init\fP, \fI/etc/getty\fP, \fI/bin/login\fP,
264: and C library routines \fIttyname\fP(3), \fIisatty\fP(3), \fIttyslot\fP(3) and
265: all programs that depend on the format of \fI/etc/ttys\fP, \fI/etc/gettytab\fP
266: and \fI/etc/utmp\fP.
267: The programs need to be installed as a set, and \fIxterm\fP must be recompiled.
268: .PP
269: To avoid a possible race condition, and to allow consistent Unix program
270: behavior, we dedicate a pseudo teletype for each display's login window.
271: All other pty's are allocated dynamically when used.
272: You will use many pty's, so make as many as possible.
273: Pseudo TTY's come in pairs, the master and the slave.
274: We rename them to be ``ttyv?'' where `?' is the number of the display.
275: .PP
276: So for example,
277: we might execute the commands:
278: .DS
279: \(bu cd /dev
280: \(bu MAKEDEV pty0
281: \(bu MAKEDEV pty1
282: \(bu mv ttyqf ttyv0 # may already exist on some machines
283: \(bu mv ptyqf ptyv0
284: .DE
285: and similarly for any other displays.
286: When logged in, you would appear to be logged in on ``ttyv0'' in this case.
287: We use the last pseudo teletypes since all other utilities start searching
288: from lower to higher, and we'd just as soon have them find a pty as soon
289: as they can.
290: .NH 2
291: Configuring Lines in /etc/ttys
292: .PP
293: If you started X in the previous step, you will want to abort it now.
294: For each display you have on a machine, you
295: must have a line in \fI/etc/ttys\fP to drive the terminal emulator used for
296: login and the window system server.
297: NOTE:
298: The format of the \fI/etc/ttys\fP file has changed radically between 4.2 and
299: 4.3.
300: You cannot set up a display for login on a 4.2BSD system without installing
301: new versions of \fI/etc/init\fP,
302: \fI/etc/getty\fP, and \fI/bin/login\fP from 4.3.
303: .PP
304: An example line in \fI/etc/ttys\fP is given in the \fIX(8c)\fP manual page
305: (though you will have to customize the line for the location and names of
306: the executable programs).
307: An example for a Vs100 installed without any reconfiguration on 4.3BSD
308: might be:
309: .sp
310: ttyv0 "/usr/new/xterm -L =-1+1 :0" xterms on window="/usr/new/Xvs100 0"
311: .sp
312: You can customize these commands to taste.
313: .PP
314: You can tell \fIinit(8)\fP to re-read the \fI/etc/ttys\fP file by the command
315: ``kill -1 1'' as super user.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.