|
|
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: As distributed, the X makefile only creates \fIXvs100\fP. 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: .NH 2
12: Prelude
13: .PP
14: NOTE:
15: As X is a network transparent window system, client programs use
16: network facilities to communicate with the window system.
17: Make sure your network code works properly BEFORE attempting to use X.
18: For example, \fItalk(1)\fP should be working properly between normal terminals,
19: or you should be able to \fIrlogin\fP to either the local or to
20: another machine if you have a network.
21: .PP
22: Also make sure you have made as many pseudo-teletypes as possible
23: (cd /dev; MAKEDEV pty0; MAKEDEV pty1).
24: These are used for terminal emulator windows, and it is possible you
25: may use quite a few of them.
26: .PP
27: If you have other machines in your network that run a 4.2BSD derived
28: system, you can also move the C language source code and recompile it
29: on those machines.
30: The C applications should be able to communicate with the X server on
31: your display.
32: This has only currently be tested for Sun and IBM RT/PC's, but in
33: principle, you should be able to interoperate properly with your Vax,
34: Sun, or other displays.
35: .NH 2
36: Font and Firmware Files
37: .PP
38: For each device type supported by X, fonts may differ.
39: There may also be local installation restrictions which may
40: prohibit you from using the default location of \fI/usr/new/lib/X\fP
41: for the fonts or other files needed by X (for example, Vs100 firmware).
42: In each device dependent X library should be a file \fIvssite.h\fP
43: which can be tailored to find the fonts and firmware in a different location.
44: Another reason why you may want to change the font and firmware directory
45: locations would be to allow use of the display while not having all of
46: your file systems mounted.
47: Tailor this file to your taste, and modify the master make file to move
48: the fonts and firmware to your location.
49: .PP
50: The binaries are normally installed into \fI/usr/new\fP.
51: If you want to change this, edit the master Makefile and change
52: CONFDIR to the directory you choose.
53: The entry ``make reconfig'' can be used to automatically edit the Makefiles
54: in the directories from \fI/usr/new\fP to your new configuration.
55: .NH 2
56: Building Software
57: .PP
58: To build executable versions of all X programs,
59: execute the command ``make all'' in the main directory.
60: .PP
61: Compiling all software takes quite a while.
62: Building the X library takes the longest, as there are more than one
63: hundred fifty modules.
64: This should complete without error.
65: .NH 2
66: Installing the X Executables
67: .PP
68: As super user,
69: execute the command ``make install''.
70: This should complete without error.
71: .PP
72: This also copies all necessary files for users to program
73: using X into \fI/usr/include/X\fP.
74: .NH 2
75: Building a Kernel With the Device Driver
76: .PP
77: You must add a line to your configuration file for each display you have.
78: Make sure the CSR address matches between your configuration file and your
79: hardware.
80: Configure, make, and install the kernel containing the display driver.
81: When you reboot the machine, make sure that your display auto configures
82: during boot.
83: .PP
84: You should also make a device entry for each display.
85: For a Vs100, change directory to \fI/dev\fP,
86: and perform a ``MAKEDEV vs?'', where `?' is the number of the Vs100 as root.
87: For a QVSS on a MicroVAX,
88: the command would be ``/etc/mknod /dev/mouse c 35 2''.
89: Normally, the protection on the device would be only user read/write,
90: but for debugging purposes you may want to temporarily change it.
91: .NH 2
92: Renaming Pseudo Teletypes
93: .PP
94: To avoid a possible race condition, and to allow consistent Unix program
95: behavior, we dedicate a pseudo teletype for each display's login window.
96: All other pty's are allocated dynamically when used.
97: Pseudo TTY's come in pairs, the master and the slave.
98: We rename them to be ``ttyv?'' where `?' is the number of the display.
99: .PP
100: So for example,
101: we might execute the commands:
102: ``mv ttyqf ttyv0; mv ptyqf ptyv0'', and similarly for any other displays.
103: When logged in, you would appear to be logged in on ``ttyv0'' in this case.
104: We use the last pseudo teletypes since all other utilities start searching
105: from lower to higher, and we'd just as soon have them find a pty as soon
106: as they can.
107: .NH 2
108: Testing and Trouble Shooting
109: .PP
110: We highly recommend testing before attempting to enable
111: login on the display.
112: Error messages will go to your terminal, rather than being logged in a file.
113: You can use \fIxinit(1)\fP to aid you in testing, but
114: it is most easily performed from another terminal or from across the network.
115: .PP
116: To test a Vs100 on line 0, for example,
117: you would change directory to /usr/new (or wherever you decided to put the
118: executable programs), and would type ``Xvs100 0 0 &''.
119: (For a MicroVAX, the command would be ``Xqvss 0 0 &'').
120: The first argument is which device to use (in this case \fI/dev/vs0\fP
121: will be used).
122: There can only be one display on a MicroVAX.
123: The second argument is ignored.
124: See the \fIX(8c)\fP manual page for other options.
125: .PP
126: If everything succeeds, you should get a grey background and a large
127: X cursor on the screen.
128: For reasons we have never understood, it may take three tries to get a
129: VS100 display to respond.
130: If not, the most common mistake is the fonts or firmware to be in the
131: wrong location or a directory or file to not be readable.
132: .PP
133: You should now be able to run any of the X programs.
134: A common beginning mistake would be to forget to set the "DISPLAY"
135: environment variable.
136: Most programs also take arguments to specify the host and display number.
137: So, for convenience while testing, you might execute the
138: command ``setenv DISPLAY \fIyourhost\fP:0'' where \fIyourhost\fP is the name of your
139: machine when using the C-shell.
140: This variable will be set for you automatically
141: when you log in in the future.
142: .PP
143: A common problem that might prevent the \fIxterm(1)\fP
144: program from working is it
145: not being set user ID and owned by root.
146: The installation makefiles should be installing \fIxterm(1)\fP this way.
147: .PP
148: If everything is working, you should be ready to enable the line for login.
149: .NH 2
150: Configuring Lines in /etc/ttys
151: .PP
152: If you started X in the previous step, you will want to abort it now.
153: For each display you have on a machine, you
154: must have a line in \fI/etc/ttys\fP to drive the terminal emulator used for
155: login and the window system server.
156: NOTE:
157: The format of the \fI/etc/ttys\fP file has changed radically between 4.2 and
158: 4.3.
159: You cannot set up a display for login on a 4.2BSD system without installing
160: new versions of \fI/etc/init\fP,
161: \fI/etc/getty\fP, and \fI/bin/login\fP from 4.3.
162: .PP
163: An example line in \fI/etc/ttys\fP is given in the \fIX(8c)\fP manual page
164: (though you will have to customize the line for the location and names of
165: the executable programs).
166: An example for a Vs100 installed without any reconfiguration on 4.3BSD
167: might be:
168: .sp
169: ttyv0 "/usr/new/xterm -L =-1+1 :0" xterms on window="/usr/new/Xvs100 0"
170: .sp
171: You can customize these commands to taste.
172: .PP
173: You can tell \fIinit(8)\fP to re-read the \fI/etc/ttys\fP file by the command
174: ``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.