Information for SVR4 Users : Notes for running XFree86 on SVR4
Previous: Notes for building XFree86 on SVR4
Next: Building non-core clients with SVR4

## 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).

Information for SVR4 Users : Notes for running XFree86 on SVR4
Previous: Notes for building XFree86 on SVR4
Next: Building non-core clients with SVR4