Subject: The X Window System on Domain/OS: Questions and Answers

From: [email-masked] (Ellis Oliver Jones)
Date: 19 Nov 89 14:48:00 GMT

Domain/OS System Release 10.2 is finally shipping (for m68k node types;
the DN10000 schedule runs a few weeks behind the m68k).  As many of you
know, HP/Apollo has bundled the X Window System(TM) with SR10.2.

During the alpha and beta period for SR10.2, we had many internal users
and a fairly large number of beta sites.  In the X development group we
kept a log of questions and answers about how to use it.  I've edited that
question-and-answer log and I'm posting it here to help newnews readers 
come up to speed with SR10.2 and X.  

This posting covers questions from users.  The next posting will cover
programming questions.

A disclaimer:  keeping the Q&A log and answering the questions has been a
midnight project for myself and others.  I take personal responsibility
for errors in this material, and I hope anyone spotting an error will
inform both me and comp.sys.apollo.  Nothing in this posting should be 
interpreted as the "official" position of HP.

Enjoy!

Ollie Jones.

Question:  I am getting the following messages:
	69>  /usr/X11/bin/xterm
	reference to undefined global (process manager/loader) 
	/usr/X11/bin/xterm
Any ideas?  What am I missing?
Answer:  If you're running Domain/X11 V1.1 on SR10.1, be sure that 
you've followed the installation instructions about adding a reference to 
x11lib to the file /etc/sys.conf.  Alternatively, inlib /lib/x11lib 
before running xterm.

Q:  I get this error message when I run xterm or xclock:
	X Toolkit Error: Can't Open display: 
A:  Make sure the DISPLAY environment variable is defined, and make 
sure your X server is running.  
On SR10.1 you have to do this manually (in some startup script).  
On SR10.2, the DISPLAY environment variable is set for you automatically 
in the appropriate one of the following node startup files:
	/sys/node_data/startup
	/sys/node_data/startup.19l
	/sys/node_data/startup.color
	/sys/node_data/startup.1280bw
	/sys/node_data/startup.1280color
Beware; if you installed SR10.2 as an upgrade on a node which already had 
SR10.1 running on it  the new startup files don't replace the old ones but 
rather get installed with the current date appended to the file name.  If you 
don't have a DISPLAY environment variable, you (or your system 
adminstrator) may have to do some editing of startup files.  
Suppose you installed your SR10.2 upgrade on December 13th, and suppose 
you're using a DN3500F.  Then you should edit 
/sys/node_data/startup.1280color so it includes the setting of the 
environment variable we added for SR10.2.  In this example you would look 
in the SR10.2-installed file /sys/node_data/startup.1280color.12.13. 
Maybe your X server isn't running.  In this case, on SR10.2, create an empty 
(zero-length) file named /etc/daemons/Xapollo and reboot the node.  
Notice that the zero-length file /etc/templates/daemons/Xapollo 
controls what happens with diskless nodes.  

Q:  What exact lines do I need in my ~/user_data/startup_dm.1280.bw 
file?  Are these what I need ?

  env display := ':0'
  export display
  /com/crf /etc/daemons/Xapollo   

A:  You shouldn't need to do any of these things in your private startup 
file.  Just once, you should create the zero-length file 
/etc/daemons/Xapollo, then reboot.  The DISPLAY environment variable 
should be set up automatically in your node-wide startup script (but see the 
previous question and answer).

Q:  Well, I am really stuck. I can't seem to keep X up on my SR10.1 node 
today. Everytime I run xset (no matter which font is being set) I get a XIO 
error, broken pipe. 
   % /usr/bin/X11/Xapollo -K ~/user_data/Xkey.config -D1 s+r- &
   % /usr/bin/X11/xclient &
   % xset fp /usr/lib/X11/fonts/75dpis/ &   
   % Connection # 3 to server broken.
   XIO: Broken pipe
   Connection # 3 to server broken.
   XIO: Broken pipe 

A:  Are you waiting for Xapollo to start before issuing the client 
commands? Sometimes Xapollo takes a while to start up.  This is especially 
true if tcp/ip isn't working on your node:  the X server attempts to initialize 
a TCP socket.   Try sleep 60 or similar right after the Xapollo command.
Also, notice that /usr/lib/X11/fonts/75dpis/ probably isn't a valid font 
path, and /usr/lib/X11/fonts/75dpi/ probably is.

Q:  My Xapollo server crashes sometimes.
A:  What's in the /sys/node_data/system_logs/X0msgs file? That's 
how we tell what the crash was.  You can read this file with the UNIX(r)
utility cat.  Please file an APR when you see a server crash.

Q:  I'm running Xapollo SR10.2.  Today, when I tried to run gnuemacs I 
got the error message
   emacs: X server unable to find requested font `fixed'.
Does anyone know what I need to do to make X happy with my fonts?
On related notes, I'm not terribly happy with the default behavior of Emacs-
under-X;  the font is so small as to be almost unreadable and the window-
size is correspondingly tiny

A:  Try putting this line in your .Xdefaults file in your home directory.  If 
you already use xrdb, don't forget to rerun it.  This will give you a legible 
font in emacs.
    emacs*font:	*-courier-bold-r-normal*-140-*
Also, try issuing this command to allow your SR10.2 X server to use the 
fonts from both XV11R3 and XV11R2:
    % xset fp+ /usr/lib/X11/fonts/oldX11/

Q:  I would like to start xclock from my startup_dm file.  (Is there a 
better way to start xclock at login?)  When I am logged in and give the 
following to the dm:
   cpo /bin/csh -c '/usr/X11/bin/xclock -display \:0 -u 60 -g 100x100+1178+0 &'
the xclock seems to start just fine, but if I put the same line in my personal 
DM startup file , the xclock nevers starts up when I log in and doesn't give 
any error messages.  What am I doing wrong?

A:  Many /bin/csh or /bin/sh users start X stuff from their .login or 
.profile files.  This is a good way to do things for a couple of reasons:
(1) it's a good idea to use xrdb to load resource info from your ~/.Xdefaults 
file.  (2) Once you've loaded resource info, you don't have to say as much to 
the xclock command.  For example, if you have these lines in your 
~/.Xdefaults file, the position and update time of your xclock are automatic.

    xclock.*.mode:              analog
    xclock.*.borderWidth:       3
    xclock.*.update:            60
    xclock.*.geometry:          40x40-1-50
    #ifdef COLOR
    xclock.*.border:            red
    xclock.*.background:	turquoise
    xclock.*.foreground:	black
    xclock.*.hands:             red
    xclock.*.highlight:         black
    #endif

Q:  I am having this strange bug with deleting windows. It seems
somewhat connected to using X windows.  When windows are resized, 
there are leftover parts of windows left around on the screen. 
A:  We've seen this before, when running with an X window manager 
(like uwm, twm, or the like) and forgetting to tell the X server it owns the 
"root" or screen background window.
To run an X window manager, you have to do three things:
  (1) say "wmgr -off" (to the DM command window.)
  (2) say /usr/X11/bin/xownroot -on   (to some shell)
  (3) run the window manager, e.g. uwm & (to some shell)
It sounds like you forgot  step 2, which leaves nobody owning the root, which 
means that neither the DM nor X can clean up after windows which have 
gone away.

Q:  If I let the DM own root at startup, everything works fine, but if I 
have X own the root at startup and comment the "xownroot -on" out of my 
.login file, I don't get any rubberbanding when I resize or move windows 
and icons.
A:  Try changing your background to some other color, for example
   xsetroot -solid cornflowerblue
Then see if you still don't get rubberbanding.  

Q:  I am currently running sr10.2 on my color node and by using xgif I 
have been able to display images as my background display.  Do you have 
anything like that that I could run on my mono node? 
A:  Mono gif images can be converted to xbitmaps via 
	giftopbm | pbmtoxbm > file.xbm
and xsetroot can then be used to make them the background.  Similarly the 
macpaint files can be viewed with xmac, or converted using 
	macptopbm | pbmtoxbm
Do a "man pbm" and "man fbm" (both in /usr/local/man) for more 
information about these publicly available programs.  Use ftp to get them 
from expo.lcs.mit.edu.

Q:  I don't know how to make xgif get rid of previous root pictures:  
successive invocations cause refreshes to recapitulate all of the old images. 
A:  You are probably running several different invocations of xgif.  Kill
all-but-one.

Q:  Does Xlib support anything analogous to the external GPR  bitmap 
file?
A:  Not really.  It supports an ASCII representation for single-plane 
bitmaps.  This ASCII representation is in a form that can be read/written 
by Xlib (XReadBitmapFile/XWriteBitmapFile) or #included in a C program.
See /usr/X11/include/bitmaps/star for an example.

Q:  I hate X.  It's a stupid system, but now at SR10.2 Apollo forces me to 
run it on my node, wasting memory and a process slot.  Do I have to go back 
to SR10.1 to get rid of X?
A:  No, you can stay with SR10.2 even if you don't want X running.  To 
prevent the X server from starting automatically when you boot your node, 
either answer "no" to the relevant config question or customize your 
SR10.2 installation by deleting the following files (if they exist).  Reboot your 
node after deleting the files.
         /etc/daemons/Xapollo
         /etc/templates/daemons/Xapollo
These files have zero length and contain no useful information, so if you 
decide later that you wish to run the X server, you may recreate these files 
with zero length and reboot.
Please be aware that an increasing number of software developers are 
committing to X, and that you may need to run the X server in the future
to use their products.

Q:  Whenever I try to set the DISPLAY variable so I can draw on the 
color node in the next  office, I get "Can't open display" as an error 
message.  If I set it to just :0 for my own node everything is OK.  These nodes 
all run TCP and have proper TCP addresses.  
A:  You have to log in to the node in the next office and use the xhost 
command to allow your node to have access. For example, suppose your 
node is named //mine and the color node is named //color.  Log in to 
//color and issue these two commands:

    /usr/X11/bin/xclient &
    /usr/X11/bin/xhost +mine

Notice that you should invoke xclient to keep the X server on //color 
from resetting after the xhost command (whenever the X server detects 
that no client programs are attached to it it assumes the user has logged off 
and "resets," cleaning up all sorts of per-session data).  Notice also that you 
don't use the node name's slashes in the xhost command.  
A permanent xhost entry can be created by editing the file /etc/X0hosts to 
include the appropriate host name.  

Q:  We are trying to determine if we are able to set up X on an Apollo 
workstation and have the client process run on a Digital VAXStation (tm).
A:  Yes, network transparency is the entire point of X.  You have to make sure 
your VAX is registered as a host in the /etc/hosts file on your Apollo node, 
and vice versa.   See the answer to the previous question for information 
on how to authorize the VAX to connect to the Apollo display.

Q:  I tried out the Motif Window Manager on a 1280 x 1028 x 8 DM 4500 at 
sr10.2.  The machine was started with the DM managing the root and X 
running in shared mode. I started up the mwm and turned DM window 
management off.
In this configuration the MWM does not clear the display. A posted menu 
stays up. A moved window shows up in both locations.
A:  Here's a script you can use to start up mwm on a "vanilla" SR10.2 
node.  I suspect you didn't give the "xownroot -on" command.
    /com/xdmc "wmgr -off"  # turn off dm's window manager capability
    xownroot -on           # tell X it owns the root window
    xclient &              # start up a dummy client to prevent server reset
    xrdb ~/.Xdefaults      # load my ~/.Xdefaults file into the server
    mwm   &                # start mwm
    /usr/X11/bin/xmodmap /usr/lib/X11/keyboard/xmodmap.kb3sample 

[the mwm window manager isn't distributed with SR10.2, but rather with
 the Domain Motif distribution, which isn't out yet.  -editor]

Q:  I seem to be having a problem when I set this in my .Xdefaults:
     mwm*iconBoxGeometry: =500x100+10+690
A:  Holy Cow!  You're asking for an icon box with enough room for 500 
icons across by 100 icons down.  That's big!  Try
     mwm*iconBoxGeometry: 7x1+10+690

Q:  The window manager is oue problem.  We would like to use twm instead 
of uwm.  But apollo has made undocumented modifications (no source code) to uwm 
and so the customer is not able to use both dm and x clients with twm 
simultaneously.
A:  If we have made changes to uwm, they're insignificant.  uwm from 
the MIT tape should run fine on Domain/X11.  
The actual problem with using twm is that it's a reparenting window 
manager:  it wraps windows in new "decoration" windows.  This gives nice 
functionality.  Unfortunately it also plays havoc with the Domain/X11 share 
mode.   Only at sr10.2 and later does the share-mode Domain/X11 server 
work correctly with reparenting window managers. So, I suggest 
upgrading to sr10.2 as soon as it is available.  If you can't upgrade
to sr10.2 call Customer Service and explain your problem.  They should
be able to help you.

Q:  Why does my xterm take so much virtual memory, and why does it 
take so long to resize?
A:  You may have set your xterm saveLines to a large number, like 10000, 
in your ~/.Xdefaults file to emulate the DM's infinite transcript pads.  If you 
do this, each time you make an xterm it allocates several megabytes of 
virtual memory complete with backing store (enough to hold 10000 of the 
longest lines you can have).  Furthermore, when you resize the xterm, it 
reallocates the memory.  Better to set xterm's saveLines property to a much 
small number, like 500 or 1000.

Q:  What's the "name" of the dm windows as far as mwm or twm is 
concerned? If I want the alarm server's little windows to pop up with no 
decoration, what do I put in my ~/.Xdefaults file?
A:  For the sr10.2 DM there isn't one stored in the X property. Therefore 
all DM windows will use no name or as mwm likes to put it, "*****".  twm 
labels these windows "NoName."  The only way to treat a DM window 
specially is to set the default window dressing to be what you want for the 
DM and individually tailor X apps. Or you can wait for the Grue DM.

Q:  Occasionally, I try to start up an xterm and get this message:
	xterm: no available ptys
I'm not sure, but I think this is a lie; I have ptyp0 through ptypf and ttyp0 
through ttypf, and I'm not running that many processes. Any hints?
A:  For some reason your pty(s) became trashed.  The easiest way to
solve the problem is recreate them.   Use these commands, then reboot:
	rm /dev/pty* /dev/ttyp*
	/etc/mkdev /dev pty 16
GNU emacs is one program which appears to consume ptys.  After several 
invocations of shells from with GNU emacs you may have to recreate the 
ptys.

Q:  How can I create a DM transcript pad with a shell running in it 
from within an xterm or other X program?  /com/xdmc only works from 
within a DM pad. so I can't use a DM "cp" command.
A:  Use /usr/X11/bin/dmwin.  This program serves as a wrapper from 
which any program that uses PAD calls on any of the standard streams 
may be run.  dmwin creates a transcript/input pad pair on the screen of the 
local Display Manager, and then runs the program given to it with its 
standard streams connected to the new pads.  It also makes sure the 
"TERM" environment variable is set to a reasonable value for a DM 
window.

Q:  If I've got two dm windows (started in my startx script) overlapping 
each other and they are controlled by mwm (with X as root), I can get the 
arrow keys to move from one window to another without catching on the 
window manager resize border.  I'm using OSF/Motif 1.0 beta.
A:  The DM keeps track of its "locator" and its cursor position separately.  
The arrow keys move the locator, but not this cursor.  So if you drive out of a 
window with an arrow key then hit a letter key, you get <beep>.  But if you 
drive from one window to another, it just works (except the cursor 
doesn't follow along, but rather jumps when the locator arrives in the new 
window).  We have a bug logged on this, but fixing it is deferred until the 
next major release.

Q:  I used to let the DM use colors 0 - 16 and lived with 240 colors for the 
color ramp (this was real easy to do with GPR).
Now I want to do the same with X/Motif.  Unfortunately, when I start up 
mwm, it allocates (by default) colors 3-6 and 16-22.  I can cut down on a 
couple of colors that it grabs above index 15 (by making DM colors the same, 
so that it will *share* them in the 7 - 15 range), but not all of them.

How can I get 240 contiguous colors in X and still use mwm?  Will using 
xdm instead work (ie: are colors 7 - 15 available for mwm?)?

A:  Yes, before you start mwm issue the "mono" command to the DM.  
This will induce the DM to release some colors.  Also, don't run any other 
motif stuff besides the window manager.  Now, if you play around with the 
stuff in your ~/.Xdefaults file (to simplify the motif colors) you may get 240 
consecutive colors 14-253 to play with.   You'll probably be able to figure 
something out.

Q:  I understand that apollo has created a separate X library called xdl 
for performance reasons.  My question is does this library work in share 
mode or is it X only functionality?
  
A:  We have improved X performance on sr10.2 by using native X 
graphics on selected devices.  The code we use for this is the "X display 
library" or "xdl." 
Currently only monochrome devices (including the DN2500) have xdl 
drivers.  These drivers cause the X server to run faster, and have no effect 
on GPR or the DM.  Share-mode still works with these xdl drivers.

If you use X on sr10.2 on the supported devices, then you are using the xdl 
drivers (but see the next question and answer).  Stay tuned for news about 
support of color displays post-sr10.2.

Q:  My SR10.2 X server runs ridiculously slowly.  Why?

A:  There are some installation and configuration problems which can 
cause an Xapollo server to run abnormally slowly.

(1) If your node is monochrome, you may not have the x display type 
manager running due to an error in installation.  To find out whether it's 
running, do this:

a)  ps axu to find out the Xapollo process id.
b)  /usr/apollo/bin/las <pid> on the Xapollo process id (list-address-space)
        Look for one of the following files to be mapped:
          /sys/mgrs.split/dtm_mono_big/xdl_trait 
          /sys/mgrs.split/dtm_mono_small/xdl_trait 
          /sys/mgrs.split/dtm_fm/xdl_trait 
If none of these files is mapped on your mono node, there's something 
wrong with your sr10.2 installation.

(2) Make sure your X fonts are installed locally rather than through a soft 
link to another node.     Network-access time for fonts can slow you down 
drastically.

Q:  How do X window managers deal with the three dm command lines 
at the bottom of the screen?  Is there some way to tell mwm not to put 
decorations around these three windows?

A:  X window managers (mwm for example) deal poorly with those 
windows.  You can specify that the default window decoration should be 
"none" but then that affects all DM windows, not just the command 
windows.  If you wanted to do that with mwm, you'd put lines like the 
following in your xrdb file:

      Mwm*defaults.clientDecoration:		none
      Mwm*xgetmail.clientDecoration:		none
      Mwm*xprmon.clientDecoration:		title
      Mwm*xperfmon.clientDecoration:	title
      Mwm*xsysmon.clientDecoration:		title
      Mwm*datebook.clientDecoration:		all

Many of us mwm users just leave the decorations on the command 
windows, but make the command windows smaller to accomodate the 
decorations, using the following entries in `node_data/startup.1280color .   
Notice that these same lines will work in `node_data/startup.1280bw , but 
that you'll need something else in the files for a 1024x800 display.

       (630,1001)dr;(1270,1013)cv /sys/dm/output
       (540,1001)dr;(620,1013)dr;(632,1010)cc;pb
       (0,1001)dr;(530,1013)cv /sys/dm/input

Thanks to Kee Hinckley, Rod Owen, Joe Bowbeer, Glen Valante, Craig 
Wolpert, John Brezak, Jim Glading, Mike Burati and Rob Stanzel for some 
of these answers, and to many people for the questions.