<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
<article>

<!-- Titles information -->

<title>Information for SVR4 Users
<author>The XFree86 Project, Inc
<date>27 Feb 1998

<abstract>
<bf>NOTE:</bf> 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.
</abstract>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->

<sect>SVR4 versions on which XFree86 has been tested<p>
  XFree86 has been tested on the following versions of <bf>SVR4.0</bf>:
<itemize>
<item>Microport: 2.2, 3.1, 4.1, 4.2
<item>Esix: 4.0.3A, 4.0.4, 4.0.4.1
<item>Dell: 2.1, 2.2, 2.2.1
<item>UHC: 2.0, 3.6
<item>Consensys: 1.2
<item>MST: 4.0.3
<item>AT&amp;T: 2.1, 4.0
<item>ISC: 4.0.3
<item>NCR: MP-RAS
<item>PANIX: 5.0
</itemize>
and the following versions of <bf>SVR4.2</bf>:
<itemize>
<item>Consensys
<item>Novell/SCO UnixWare 1.x and 2.0
</itemize>
Basically, we believe that XFree86 binaries will run unmodified on any
ISA, EISA, or MCA platform version version of SVR4.0 (Solaris 2.x is an
exception), or SVR4.2.  If you run XFree86 on another version of SVR4
that's not in this list, please let us know about it.

<sect>How to cope with VT-switching hotkeys<p>
  Some versions of SVR4 (Esix and Microport) have mechanisms for enabling
two-key sequences for VT switching (<tt>Alt-Fn</tt>).  
The standard SVR4 mechanism
is <tt>Alt-SysReq-Fn</tt>, which all versions we know use.  
Running under X, the
<tt>Alt-Fn</tt> sequences are stolen by the driver before the 
server can see them,
so you can't use them for X applications.  So you want to switch back to
the standard 3-key sequences while you are running X.  Here's how to do
it:
<descrip>
<tag/Microport/
	Microport makes this very simple.  The 2-key mode is called
	"Microport Mode", and the 3-key mode is called "Compatible Mode".
	You enter Microport Mode by pressing <tt>Alt-SysReq-m</tt>.  You enter
	Compatible Mode by pressing <tt>Alt-SysReq-c</tt>.  So all you 
	need to do is press <tt>Alt-SysReq-c</tt> after starting the
	X server to allow X clients access to the
	<tt>Alt-Fn</tt> sequences.
<tag/Esix/
	Esix has no keyboard-driven way to switch modes.  There are two
	levels at which this can be handled:<p>
<enum>
	<item>There is a kernel tunable that determines which mode is the
	default.  The tunable is the initialisation of kd_2keysw in
	<tt>/etc/conf/pack.d/kd/space.c</tt>.  When set to 1 (the default), 
	2-key
	mode is enabled.  When set to 0 it is disabled.<p>
	<item>The mode can be changed for individual VTs programatically by
	an ioctl().  To make life easier for XFree86 users, a program
	called `2key' is provided (in 
	<tt>xc/programs/Xserver/hw/xfree86/etc/</tt>
	in the source tree, and in 
	<tt>/usr/X11R6/lib/X11/etc/</tt> in the binary
	kit).  You can compile and install this program.  Then to make use
	of it, add the line `<tt>VTInit "2key off"</tt>' 
	to the Keyboard section of
	your <tt>XF86Config</tt> file to cause the program to be run 
	automatically
	when the server starts up.  Doing this means that 2-key switching
	will be turned off while in the server's VT, but will still be on
	for the other VTs.<p>
</enum>
	For further details, refer to the keyboard(7) man page included
	with the release notes (the on-line man page doesn't have this
	information).
</descrip>

<sect>Running SVR3 binaries on SVR4.0.4 and SVR4.2<p>
  SVR4.0.4 added the `Advanced Compatibility Package', which provides
iBCS-2 compliance for running SVR3 binaries.  These facilities are also
present in SVR4.2.  XFree86 makes use of this to accept local connections
from SVR3 clients.  The XFree86 binary distribution is built to use these
capabilities.  You need to install the `Advanced Compatibility Package', if
you have not done so already.<p>
We have found that SVR4.0.4 is not able to run all SCO, and perhaps not
many ISC SVR3 binaries.  This is not a failing of XFree86, but of SVR4
itself.  One particular example is that many SVR3 programs are ignorant of
the UFS filesystem, and attempt to read directories as files, rather than
using the system call that is defined for the purpose.  This will fail for
obvious reasons.  The SVR4.0.4 release notes from USL (which you should
have gotten from your vendor) have lots of suggestions for how to improve
compatibility.<p>
That said, we have had luck with several SCO binaries right out of the
box.  No changes are needed - just go to an xterm window and run the
program.<p>
ISC users will need a binary editor before they can attempt to run their
binaries.  ISC, for whatever reason, put the pipe for local connections in
<tt>/tmp/.X11-unix/Xn</tt>.  This unfortunately is the same place as the X
Consortium X server puts the Unix-domain socket normally used for local
connections.  The XFree86 server was modified to use 
<tt>/dev/X/ISCCONN/Xn</tt> for
local connections to ISC clients.  So what you must do is use a binary
editor to edit your client program.  Search for <tt>/tmp/.X11-unix</tt>, 
and change
it to <tt>/dev/X/ISCCONN</tt>.  Now you just have to worry about base-OS
compatibility.<p>
<sect>Notes for building XFree86 on SVR4<p>
<enum>
<item>If you are using gcc with SVR4, we highly recommend that you use
   gcc-2.4.5 (or a later stable release).  Version 2.6.0 has some problems
   on i386 platforms and is not recommended.<p>
<item>It is recommended that you increase the <tt>UFSNINODE</tt> 
   (for a UFS filesystem)
   and/or the <tt>S5NINODE</tt> (for an S5 filesystem) kernel parameter 
   to about 650
   before attempting to build the distribution.  See the "Notes for running
   XFree86 on SVR4" section for some other parameters you may want to
   change.<p>
<item>The <tt>BOOTSTRAPCFLAGS</tt> required are:
<quote>
   For Unixware:     "<tt>-DUSL</tt>"

   For NCR:          "<tt>-DNCR</tt>"

   For other SVR4:   "<tt>-DSVR4 -Di386</tt>"
</quote>
</enum>
<sect>Notes for running XFree86 on SVR4<p>
<bf>NOTE:</bf> 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.
<enum>
<item>For SVR4, you may also need to add <tt>/usr/X11R6/lib</tt> to your
   <tt>LD_LIBRARY_PATH</tt>, but this is not required for running properly 
   built clients.<p>
<item>You may want to increase some kernel parameters (either by running
   <tt>idtune</tt>, or editing <tt>/etc/conf/cf.d/stune</tt>, and 
   rebuilding the kernel with <tt>idbuild</tt>):
<quote>
        <tt>[HS]FNOLIM         </tt>hard/soft limit for number of open files<p>
        <tt>MAXUP              </tt>max number of processes per user<p>
        <tt>ARG_MAX            </tt>max length of an arg list<p>
        <tt>SHMMAX             </tt>max size of shared memory segment(in bytes)<p>
</quote>
<item>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:<p>
<descrip>
<tag/Esix 4.0.3/             Xqueue works.  It is also possible to
                               use the standard asy driver directly,
                               but the mouse operation is "jerky".

<tag/Microport SVR4 &lsqb;34&rsqb;.1/  Xqueue works fine, and the asy driver
                               can also be used directly giving smooth
                               mouse operation.
</descrip>
   To use Xqueue, set the <tt>Protocol</tt> to <tt>Xqueue</tt> in both the 
   <tt>Keyboard</tt> and
   <tt>Pointer</tt> sections of your <tt>XF86Config</tt> 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 `<tt>touch /dev/gmse</tt>' 
   before
   running it.  (Note that mouseadmin will need to be rerun after
   rebuilding a kernel unless you add an appropriate entry to
   <tt>/etc/conf/node.d/gmse.</tt>)<p>

   <bf>NOTE</bf>: 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:
<tscreen><verb>
   Option "sw_cursor"
</verb></tscreen>
   to the Device section of your XF86Config file.  The S3 server is the
   only one known to not have this problem.
   <p>
   If you have problems with both Xqueue and your standard asy driver with
   SVR4, then you should install SAS.  When using SAS, set up <tt>XF86Config</tt> as
   you would for the standard driver.<p>
   SAS is available from ftp.physics.su.oz.au.  When using SAS for a
   serial mouse, you will get smoother operation if you change 
<tt>EVENT_TIME</tt>
   from 80 to 30 in <tt>sas.h</tt>.  A couple of details which aren't 
spelled out
   in the SAS README are:<p>

   - An example of the line you should add to <tt>/etc/ap/chan.ap</tt> is:
<verb>
      MAJOR    0       255     ldterm ttcompat
</verb>
     where <tt>MAJOR</tt> is replaced by the major number used for SAS 
    devices.  To
     determine what that is, check <tt>/etc/conf/cf.d/mdevice</tt> 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.<p>
   - The installation instructions omit the following:<p>
<quote>
     3a) Disable the asy driver by either running `<tt>kconfig</tt>' or editing
         <tt>/etc/conf/sdevice.d/asy</tt>.<p>
     3b) Rebuild the kernel by running <tt>/etc/conf/bin/idbuild</tt><p>
</quote>
<item>If you want to use xdm with SVR4, extract the files from the shar file
   in <tt>/usr/X11R6/lib/X11/etc/XdmConf.svr4</tt> into a temporary 
   directory.  The
   <tt>README</tt> 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.<p>

   <bf>NOTE:</bf> 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 <tt>/etc/inittab</tt>, remember to also change
   <tt>/etc/conf/cf.d/init.base</tt> or you will lose the changes when you next
   rebuild the kernel.<p>

<item>If you want to change the number of VTs available on SVR4, just edit the
   file <tt>/etc/default/workstations</tt> and change the number there.  
   The device
   nodes will be created/deleted next time you reboot.<p>
<item>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.<p>

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

</enum>
<!--
<sect>Notes for running XFree86 on SVR4.2<p>
  In addition to the notes for SVR4.0, you need to be aware of a few
problems with SVR4.2.  Basically, the base SVR4.2 code has broken
Unix-domain sockets in such a way that making local connections via
<tt>UNIXCONN</tt> does not work properly (this bug is known to exist 
on Consensys
SVR4.2 and Novell/SCO UnixWare).  The manifestation of this bug is that
windows remain on the screen after the client program exits, until you
move the mouse into the window, or otherwise cause the server to try to
write to the client.<p>
If you run XFree86 and see the manifestation of the Unix-domain socket bug
described above, you can work around this problem quickly and effectively
by changing the default local connection mode to <tt>NAMED</tt> rather 
than <tt>UNIX</tt>.
The mechanisms for doing this are described above.  This is not a problem
for clients using the X11R6 X libraries because <tt>UNIX</tt> is no longer
considered a local connection type.<p>
-->

<sect>Building non-core clients with SVR4<p>
<enum>
<item>A lot of clients (even some which have explicit SVR4 support) require
   <tt>-DSYSV</tt> when building under SVR4.  This will not be set when 
   using the
   default configuration.  A quick fix is to add something like the
   following to the client's Imakefile:
<verb>
      #if SystemV4
           DEFINES = -DSYSV OTHER_CLIENT_DEPENDENT_DEFINES
      #endif
</verb>
   The best solution is to modify the code so it compiles correctly
   without <tt>-DSYSV</tt>.<p>
</enum>
<sect>Using DOS/Merge 2.2 with XFree86<p>
  It is possible to use the Locus DOS/Merge 2.2 X clients with XFree86.
You need to do a couple of things for this to work, though.  One change is
a generic problem with the X client and X11R5/6; the others are to work
with some things that are specific to the XFree86 servers.  Here are the
things you need to do:
<enum>
<item>Set and export <tt>&dollar;XMERGE</tt> in your <tt>.xinitrc</tt>
	   and/or <tt>.xsession</tt> files.
	   In general, you should set <tt>XMERGE=vga</tt>.<p>
<item>You MUST use the "xqueue" driver instead of the server's native
	   keyboard and mouse driver, if you intend to use the "zoom"
	   feature of the `dos' client.  Otherwise the mouse will cease to
	   function after the first time you "zoom" (because the `dos'
	   client uses the native driver, and the server will not be able
	   to access the mouse after the zoom ends).  The only other
	   alternative is to use separate mice on separate devices.<p>
<item>You need to install the `dos' client fonts in the XFree86 font
	   directories.  Locate the BDF files (search for files with names
	   matching the pattern `*pc???.bdf').  These will likely be
	   <tt>/usr/lib/X11/fonts/misc</tt>.  
           Go to the directory where these files
	   are located, and execute the following (using `sh' or `ksh'):
<verb>
	for i in *pc???.bdf
	do
	    /usr/X11R6/bin/bdftopcf $i > \
			/usr/X11R6/lib/X11/fonts/misc/`basename $i .bdf`.pcf
	done
	cd /usr/X11R6/lib/X11/fonts/misc
	/usr/X11R6/bin/mkfontdir
	# Do this only if the server is already running.
	/usr/X11R6/bin/xset fp rehash
</verb>
<item>The `dos' client program uses a translation table to map from
	   an internal key representation to the X keymap.  It is likely
	   that the table supplied with Merge 2.2 use the mapping for
	   SCO's server.  A correct mapping table is available in
	   <tt>/usr/X11R6/lib/X11/etc/xcode.xfree86</tt>.  This file should be
	   installed in <tt>/usr/lib/merge/xc</tt>.  In addition, you must 
           add the
	   following resource to the `dos' client's application-defaults
	   file (usually in <tt>/usr/lib/X11/app-defaults/DOS</tt>):
<verb>
	dos*xcodetable: /usr/lib/merge/xc/xcode.xfree86
</verb>
	   It will be obvious if this new code table is needed, as the
	   arrow keys on the keypad will fail to function in the `dos'
	   client if the wrong table is installed.<p>
<item>For the "zoom" feature to work correctly, you must run `dos'
	   with &dollar;DISPLAY set to "unix:N" or "host_name:N".  If you use
	   just ":0", the client will not function properly.  `dos' does
	   not accept a `-display' parameter.  Hence it is probably a good
	   idea to replace the `dos' program with something like this:
<verb>
	#!/usr/bin/ksh
   	if [ "X${DISPLAY}" != "X" ]
   	then
		case ${DISPLAY} in
		:*)
			DISPLAY=unix${DISPLAY}
			;;
		esac
	fi
	/usr/bin/dos.real "$@"
</verb>
</enum>
<sect>Keyboard mapping problems with some Esix systems<p>
  One of the console driver patches for Esix 4.0.3A causes the XFree86
server's default keymap to be corrupted.  If you are being affected by
this problem it will be obvious because few (if any) of the keys will be
mapped correctly.  There are two solutions to this.  One is to remove the
console driver patch which introduced the problem.  The second is to use
xmodmap(1) to reset the default mapping after server startup.  The default
mapping is provided in the file 
<tt>/usr/X11R6/lib/X11/etc/xmodmap.std</tt>, and can
be installed automatically by adding the line:
<tscreen><verb>
  xmodmap /usr/X11R6/lib/X11/etc/xmodmap.std
</verb></tscreen>
to your <tt>.xinitrc</tt> file (or your <tt>Xsetup</tt> file if using xdm).

<sect>106 Japanese keyboard problem on PANIX<p>
  PANIX for PC-AT uses Japanese keycodes standardized by DICOP(Desktop
UNIX for Intel Cooperative Promotion Group) in Japan.  Therefore keycode
confliction occurs with 106 Japanese keyboard in XFree86.  To avoid it,
specify the keyword "panix106" in XF86Config like this:
<verb>
  Section "Keyboard"
    Protocol    "Standard"
    Autorepeat  500 5
    XkbModel    "jp106"
    XkbLayout   "jp"
    panix106
  EndSection
</verb>

<sect>A kernel patch that is required for accelerated servers<p>
  SVR4.0 has a bug handling programs that access extended I/O registers
(above 0x3FF).  Boards like S3 and 8514/A use these extended I/O
registers.  XFree86 supports boards that tickle this bug.  In
preparation for using these servers, we have produced a kernel patch 
that works around the problem, and provided scripts for you that will 
both install and back out the patch.  You must install this if you
intend to use the S3, 8514, Mach8, Mach32, P9000, AGX or W32 servers.<p>

Dell 2.2 is known to not need the patch, because Thomas Roell found and
fixed the bug while he was working for Dell.  Microport has fixed this in
their 4.0 v4.2 release.  Also, SVR4.2 does not need this patch, as the
problem has been fixed by USL.<p>

The patch scripts are located in <tt>xc/programs/Xserver/hw/xfree86/etc</tt> 
in the
source tree, and <tt>/usr/X11R6/lib/X11/etc</tt> in the binary distribution.  
The
files are `svr4_patch' to install the patch, and `svr4_patch_rem' to back
it out.  The file that is being patched is 
<tt>/etc/conf/pack.d/kernel/os.o.</tt>
The patch script verifies the presence of the bug before patching, and will
tell you whether or not it succeeded in patching.  You need to run the
`svr4_patch' script as root, obviously.  The original <tt>os.o</tt> file, 
as well as
the patching program, and a copy of the removal script are stored in the
directory <tt>/etc/conf/pack.d/kernel/.xfree86</tt><p>

Thanks to John M. Sully of Microport for helping us find a simple
workaround for this problem, and giving us permission to release the
information.<p>

<sect>Other problems<p>
Some accelerated drivers may cause the machine to lockup when starting
up the server on some versions of SVR4.0.  The problem seems to be
related to the kernel checking for the presence of physical memory
when mmaping /dev/pmem.  This can cause problems when mapping memory
mapped registers.  This was known to be a problem with the MGA driver in
the SVGA server.  Some other drivers may be affected too.  The problem with
the MGA driver is now fixed.

<verb>
$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SVR4.sgml,v 3.13.2.3 1998/02/28 08:54:11 dawes Exp $





$XConsortium: SVR4.sgml /main/8 1996/10/27 11:06:06 kaleb $
</verb>
</article>
