]
Attempting to use other make targets will not work because the
entire source tree is not in the link kit.
When successful, there will be an executable ./Xserver/Xsco
server.
Usually you must be 'root' user to run the server because it will
access I/O ports and memory that can only be obtained from the O/S
by root processes. To debug the server you must also run the
debugger from a root login.
When not debugging the server, you can use the server as a normal
user login by setting root suid permissions. To set these
permissions on the server:
# chown root ./Xsco # must be root ownership
# chgrp sys ./Xsco # optional, not necessary
# chmod 4755 ./Xsco # suid permissions
# ls -l ./Xsco
-rwsr-xr-x 1 root sys 9 Dec 21 15:00 ./Xsco
As a normal user, you can now use this server via xinit:
$ xinit -- `pwd`/Xsco
Or, simply via:
$ ./Xsco
To debug the server it is necessary to have a separate second
login into the test box so the console screen can be left for the
sole use of the server. Either connect a serial terminal to the
box, or use a network rlogin or telnet session.
From this second login, to debug the server, use your favorite
debugger, for example debug:
# debug ./Xsco
And, for the run time command line options, direct the server to
use the console screen with the -crt option:
(dbx) run -crt /dev/console
The server will use the graphics hardware of the console screen,
and from the login session where the debugger is running, you can
control the debugger. You can not use the multi-screen switch
function of the console screen as the second login for the
debugger, because the screen switch operation sends a signal to
the X server expecting it to do the job of switching to text mode
and if your debugger stops for a breakpoint, or for the signal
before the server finishes the mode change, you will not be able
to access your debugger.
It is also helpful to have a second login session besides the
debugger login session if you need to restore the console screen
when your partially working X server leaves the graphics hardware
in an unknown state. To restore the console screen:
# ./Xsco.dy -reset
If this doesn't work, try:
# ./Xsco.dy -reset -d ibm.vga.vga.640x480-16
In the rare case that none of these techniques will reset the
hardware, power cycle the computer as a last resort. It is quite
possible to hang the entire system while working on graphics
hardware. In this case, press your reset button.
------------------------------------------------------------------
Suggested debug sequence:
The first thing to watch your server run through is the init code
and grafinfo file manipulation to see if it can set the hardware
into graphics mode upon startup, and return to text mode upon
exit. Watch the execution of your Init routine carefully to prove
its correctness. Alt-SysReq then will exit the server.
After you have the server setting graphics/text mode properly, you
should have a standard root background display. The presence of
an X cursor is optional at this point. Although that would be
important soon.
An important function to test at this point is the ability of your
libXDriver.so to work with the installed /usr/X11R6.1/bin/Xsco
server. To check this, take your libXDriver.so from
./Xserver/hw/sco/ports/ and place it in a new
directory: /usr/X11R6.1/lib/dyddx//libXDriver.so When
you now use /usr/X11R6.1/bin/Xsco - it will load your
libXDriver.so from that location, dynamically link it into the X
server and run it. Because of the dynamic linking, all symbolic
information is lost and you can not easily debug this server.
That is why there is the static server for debugging. However
your finished driver must be a dynamically loadable libXDriver.so
- so check that it will load and execute at this point. You will
use the static server to debug your driver, but occasionally come
back to this point to ensure that it will work when dynamically
loaded. During final stages of server testing when your driver is
working well, you should be doing all testing with the dynamic
loadable version.
Back to the static server.
With the server now running with the root background, see if a
simple client, for example xlogo, can connect and display
reasonably.
After simple clients can display correctly, run a window manager
and experiment with other standard clients found in
/usr/X11R6.1/bin.
When the standard clients run correctly, try the x11perf
performance test in ./Xserver/tests/x11perf.
To run x11perf quickly:
$ x11perf -all -repeat 1 -time 1
Or more extensively:
$ x11perf -all -repeat 3 -time 5
To run all those performance tests, see the 'RunTests' script in
./display/Xserver/tests/x11perf.
Other vBy now you have fixed most hang ups and serious problems
with your server. From here on you are mostly tuning your server
or finding obscure bugs.
****** Distribution
After completing the above work, you may want to make your robust
driver available for testing or distribute it to your customers.
'MakeProduct' (linked into ./Xserver/hw/sco/ports/)
will create a 'custom' installable archive image of your driver.
You can then run custom to install this image onto your system by
specifying the image file directly to custom. Or you can use
'MakeFloppy' (linked into ./Xserver/hw/sco/ports/) to
copy the archive image to a Unix or DOS floppy and then use custom
to install from the floppy drive. Note: These images will install
on Open Server 5 only. They will not install or work on
OpenDesktop 3.0 systems.
If you wish to change the version number of your product or some
other detail, edit the files in .//dist and then run
MakeProduct -c to rebuild the cuts directory.
****** Distribution
After completing the above work, you may want to make your robust
driver available for testing or distribute it to your customers.
'MakeProduct' (linked into ./Xserver/hw/sco/ports/)
will create a 'custom' installable archive image of your driver.
You can then run custom to install this image onto your system by
specifying the image file directly to custom. Or you can use
'MakeFloppy' (linked into ./Xserver/hw/sco/ports/) to
copy the archive image to a Unix or DOS floppy and then use custom
to install from the floppy drive. Note: These images will install
on Open Server 5 only. They will not install or work on
OpenDesktop 3.0 systems.
If you wish to change the version number of your product or some
other detail, edit the files in .//dist and then run
MakeProduct -c to rebuild the cuts directory.
