5. Notes for running XFree86 on SVR4

NOTE: If you intend to use any of the accelerated servers, read section 10 and follow the instructions. Otherwise the X server will crash when exiting, restarting, or switching VTs.

1. For SVR4, you may also need to add /usr/X11R6/lib to your LD_LIBRARY_PATH, but this is not required for running properly built clients.
2. You may want to increase some kernel parameters (either by running idtune, or editing /etc/conf/cf.d/stune, and rebuilding the kernel with idbuild):

   [HS]FNOLIM hard/soft limit for number of open files

   MAXUP max number of processes per user

   ARG_MAX max length of an arg list

   SHMMAX max size of shared memory segment(in bytes)

3. Choose which mouse driver you will use. For SVR4 the best choice depends on which version you are using. If you have a bus mouse then Xqueue is probably the only option. For a serial mouse the options are as follows:

   Esix 4.0.3

   Xqueue works. It is also possible to use the standard asy driver directly, but the mouse operation is "jerky".

   Microport SVR4 [34].1

   Xqueue works fine, and the asy driver can also be used directly giving smooth mouse operation.

   To use Xqueue, set the Protocol to Xqueue in both the Keyboard and Pointer sections of your XF86Config file, and You must have the mouse driver package installed, and must run mouseadmin to set it up for your mouse. If mouseadmin won't work try doing `touch /dev/gmse' before running it. (Note that mouseadmin will need to be rerun after rebuilding a kernel unless you add an appropriate entry to /etc/conf/node.d/gmse.)

   NOTE: Many of the accelerated server/drivers have problems when using a HW cursor and Xqueue together. If you have a serial mouse, you can work around this by not using Xqueue. Otherwise the only workaround is to disable the HW cursor. This is done by adding the line:

      Option "sw_cursor"
   

   to the Device section of your XF86Config file. The S3 server is the only one known to not have this problem.

   If you have problems with both Xqueue and your standard asy driver with SVR4, then you should install SAS. When using SAS, set up XF86Config as you would for the standard driver.

   SAS is available from ftp.physics.su.oz.au. When using SAS for a serial mouse, you will get smoother operation if you change EVENT_TIME from 80 to 30 in sas.h. A couple of details which aren't spelled out in the SAS README are:

   - An example of the line you should add to /etc/ap/chan.ap is:

         MAJOR    0       255     ldterm ttcompat
   

   where MAJOR is replaced by the major number used for SAS devices. To determine what that is, check /etc/conf/cf.d/mdevice after rebuilding the kernel. The major number is the sixth field in the line starting with `sas'. This file must be updated before rebooting with the new kernel.

   - The installation instructions omit the following:

   3a) Disable the asy driver by either running `kconfig' or editing /etc/conf/sdevice.d/asy.

   3b) Rebuild the kernel by running /etc/conf/bin/idbuild

4. If you want to use xdm with SVR4, extract the files from the shar file in /usr/X11R6/lib/X11/etc/XdmConf.svr4 into a temporary directory. The README file tells where the individual files should be installed. Be sure to read through each file and make any site-specific changes that you need.

   NOTE: Some SVR4 versions (one example is Esix 4.0.3) have a default inittab which runs `vtgetty' on the console. This does not work well when starting xdm at boot time. The problem is that when you logout from a vtgetty session it wants to close all the VTs -- including the one xdm is using for the server. It is recommended that you use `getty'. If you change /etc/inittab, remember to also change /etc/conf/cf.d/init.base or you will lose the changes when you next rebuild the kernel.

5. If you want to change the number of VTs available on SVR4, just edit the file /etc/default/workstations and change the number there. The device nodes will be created/deleted next time you reboot.
6. The default local connection types have changed in X11R6. Unix domain sockets are no longer treated as a "local" connection type. This means that a client connecting to :0 will use not use a Unix socket for the connection. To use the Unix socket connection, the client must connect to unix:0.

   The local connection types available are "NAMED" (named streams pipe), "PTS" (old-stype USL streams pipe), "SCO" (SCO Xsight streams pipe), and "ISC" (ISC streams pipe). The XLOCAL environment variable can be used to set which types of local connection should be used in order of preference. The default setting is PTS:NAMED:ISC:SCO. It is recommended that NAMED be used in most cases because it is faster than the default PTS, and because using PTS can cause you to run out of /dev/pts/ devices (each client using PTS requires a /dev/pts device). To set up the default local connection type, make sure that XLOCAL is set and exported in your .xinitrc file (when using xinit or startx) or your /usr/X11R6/lib/xdm/Xsession script (when using xdm).