X11 Leopard Fails to Start
- The Console error shows:
.org.x.X11_launcher[13401]) Stray process with PGID equal to this dead job: PID 13402 PPID.etc
.org.x.X11_launcher -xterm Xt error: Can't open display: localhost:0You're probably setting DISPLAY in some of your environment files. Eliminate the setting and that would fix it.
- The Console error shows:
11/3/07 10:37:48 PM login[139] DEAD_PROCESS: 139 tty??
.org.x.X11_launcher /usr/X11/bin/xterm Xt error: Can't open display:
.org.x.X11_launcher /usr/X11/bin/xterm: DISPLAY is not setDid you installed Tiger X11 in Leopard using the following instructions and then you decided to return to use Leopard's X11? If you did, the steps you followed to revert to Tiger's X11 have you remove the launchd plist required to launch X11 in Leopard.
If you run in Terminal the following command, does it show an entry for org.x.X11?
launchctl list | grep org.x
If that file is missing you can download a new 'org.x.X11_launcher.plist' file from here
Put the file in /System/Library/LaunchAgents/ and then run:
sudo launchctl load -w /System/Library/LaunchAgents/org.x.X11.plist
Reboot
- The Console error shows:
01.03.08 11:44:22 org.x.X11[638] xterm: bad command line option "xterm"
org.x.X11[638] usage: xterm [-/+132] [-C] [-Sccn] [- T string] [-/+ah] [-/+ai] [-/+aw]People who reported this problem traced it back to garbage contained in some bash startup script like ~/.bash_profile, ~/.bash_login or ~/.profile.
For example:
"set history = 1000" in ~/.bash_profile.
"set bell-style visible" in ~/.bash_profile
"set noclobber" in ~/.bashrc which had a similar effect.
Setting your PATH with zsh and more
With Leopard, system paths are set by path_helper. Leopard ships with / etc/zprofile calling path_helper by default. This file is sourced by zsh when a login shell is requested. Of course, the problem is that utilities like unison, which MacPorts installs in /opt/local/bin, need to be in the default path when they are called on a remote machine, and shells are not run as login shells when you use unison. Hence, if you need utilities in your path even when you aren't running a login shell, you probably have to move the call to path_helper into /etc/ zshenv, it will force all shells (not just login shells) to pick up the path.
Also, zsh shells opened in mrxvt under X took a fraction of a second to start but those opened in Terminal.app took about 5 seconds. The cause is path_helper. (mrxvt was opening zsh as a non-login shell and thus not triggering path_helper.) The regex it's using in line 18 is really really really slow. You can replace it with this one and it runs in a snap:
[[ "$NEWPATH" = @(${p}|${p}:*|*:${p}|*:${p}:*) ]] && continue
Three ways that xterm can be launched as a side effect
There are exactly three ways xterm can be launched as a side effect of some other process:
- Execute /Applications/Utilities/X11.app, the "X11_launcher"
- You have a ~/.xinitrc that runs xterm, or you modified the system xinitirc (/usr/X11/lib/X11/xinit/xinitrc) to add back in the call to xterm that was removed to prevent this from happening.
- You run some program that tries to do something clever by either executing X11.app for you (see #1) or executing xterm itself.
Suppressing xterm launching by default
In Leopard, xterm is run directly by X11.app which causes the server to start. Think of X11.app AS something that just executes xterm. X11.app runs "defaults read org.x.X11 app_to_run". If you launch X11.app from the dock or run "open -a X11" it will run xterm or "whatever" you wrote in "app_to_run". If you want to launch the X server by hand and don't want any application to start, then set app_to_run to /usr/bin/true:
defaults write org.x.X11 app_to_run /usr/bin/true
Note: starting with the X11-2.1.1 package, "org.x.X11_launcher" is now "org.x.X11"
Starting Vim
Vim automatically does X things on startup, even when running in a terminal, if it was compiled with X support and $DISPLAY is set (very annoying if you have it set but X isn't actually running). The easiest solution for CLI vim is to alias it to "vim -X" in your shell setup, but you can also install a version built without X.
Platypus in 10.5
Platypus works fine in 10.5. In Leopard, X11 apps can be launched from a Terminal window with no need to set DISPLAY. This, along with the fact that you no longer have to worry about starting the X server, makes it dead simple to write Platypus droplets:
#!/bin/sh
/usr/local/bin/foo
Xcode bug
Programs running as children of Xcode (i.e. those being debugged) have the DISPLAY environment variable set to localhost and thus can't run any X clients. You can work around it by setting DISPLAY explicitly in the "environment variables" section of the "custom executable" info dialog.
Leopard Installer bug
Did you do an upgrade install of Leopard?
Then you are perhaps bitten by the Leopard Installer bug. Check if you have the Tiger man pages still sitting in /usr/share/man/ manX side by side with the Leopard man pages. Please, run:
ls -l /usr/share/man/man1/man*
To see if you get a result similar to the following:
-rw-r--r-- 1 root wheel 10981 Jan 13 2006 /usr/share/man/man1/man.1
-r--r--r-- 1 root wheel 4821 Sep 23 21:54 /usr/share/man/man1/man. 1.gz
lrwxr-xr-x 1 root wheel 5 Jul 24 2006 /usr/share/man/man1/ manpath.1 -> man.1
lrwxr-xr-x 1 root wheel 8 Oct 27 15:54 /usr/share/man/man1/ manpath.1.gz -> man.1.gz
The gzipped man pages are from Leopard, the others from Tiger. And the man command chooses the old ones over the new ones every time. Hopefully a future Apple OS installer will get this right from the beginning (it doesn't happen if you did an archive and install of Leopard).
- One way to fix the above problem: (Thanks to Dave Vasilevsky)
A little script to fix the duplicate man pages problem. It looks for all duplicate man pages in /usr/share/man and deletes all but the newest one.
Just put it in a file 'manpages.rb' and run with:
sudo ruby manpages.rb
(please be aware that running a script as sudo has potential risks)
#!/usr/bin/ruby
require 'find'
pages = Hash.new { |h, k| h[k] = [] }
Find.find('/usr/share/man') do |path|
stat = File.lstat(path)
next unless stat.file?
base = File.basename(path)
base.sub!(/\.gz$/,'')
base.sub!(/(\.\d)[^\.]*$/, '\1')
pages[base] << { :path => path, :mtime => stat.mtime }
end
pages.each do |base, files|
next if files.size == 1
ordered = files.sort_by { |f| f[:mtime] }
ordered.pop
ordered.each { |f| File.unlink(f[:path]) }
end- Another way to fix the above problem: (Thanks to James Elliott)
First, make a backup of your /usr/share/man hierarchy in case anything goes wrong.
Then, as root:
cd /usr/share/man/
find . -iname "*.gz" -type f -exec gunzip -v -f {} \;
This uncompresses all the Leopard pages, replacing any outdated Tiger ones, and preserving timestamps. Still inside /usr/share/man/
find . -type f -exec gzip -v {} \;
This recompresses all the Leopard manual pages, and compresses any non-obsoleted old pages which remain, again preserving timestamps.
Unfortunately, this leads to a bunch of broken symbolic links which are pointing to the non-nonexistent uncompressed versions of a page. (You can see this by running /etc/periodic/weekly/320.whatis.)
So a friend and I came up with the attached script "fix_man.sh", which adjusts all the symbolic link names and destinations to reflect the current, compressed situation.
#!/bin/bash
cd /usr/share/man
find -E . -regex '.*\.[1-9][a-z]*$' -type l > /tmp/link.list
while read filename
do
BASE=`ls -l $filename | awk -F'-> ' '{print $2}'`
DIRNAME=`dirname $filename`
GZPATHNAME="$DIRNAME/$BASE.gz"
echo ""
echo "$filename -> $BASE"
if [ -s "$BASE" ]
then
echo "$BASE exists and is greater than zero"
elif [ -s "$GZPATHNAME" ]
then
if [ -s "$filename.gz" ]
then
echo "Removing $filename, $filename.gz exists"
rm -f "$filename"
else
echo "Reworking symlink for $filename to point $filename.gz to $BASE.gz"
rm -f "$filename"
ln -s "$BASE.gz" "$filename.gz"
fi
else
file $filename | grep -q 'broken.symbolic'
return=$?
if [ $return -eq 0 ]
then
echo "$BASE does not seem to exist, orphaning $filename"
fi
fi
done < /tmp/link.list
This repairs everything but one link, /usr/share/man/man1/pcast.1 which seems to represent an alternate, historical name for the podcast man page. I manually replaced the broken man1/pcast.1 link with a working man1/pcast.1.gz link to point at the file /usr/share/man/man1/podcast.1.gz
Last.fm focus stealing bug
Symptoms:
"xterm opens fine. accepts a few keystrokes or mouse clicks and then starts sending keystrokes/mouseclicks to the desktop or the terminal (mostly the desktop). If you click on the xterm, it does come back, but again, after a few bits of input, it sends it somewhere else."
If you have the Last.fm AudioScrobbler plugin installed, for some reason every two seconds it steals focus from X11, which makes it unusable. It's probably something to do with sending (or trying to send) AppleScript events to iTunes to get the currently playing track info. I couldn't tell you why this is now a problem on Leopard, yet not on Tiger.
/usr/libexec/path_helper
In Leopard, the global shell initialization scripts /etc/csh.login and /etc/profile call /usr/libexec/path_helper. This helper script initializes PATH with the contents of /etc/paths and initializes MANPATH with the contents of /etc/manpath.
PATH
Can be extended by putting a file listing the new path in /etc/paths.d
MANPATH
Can be extended by putting a file listing the new manpath in /etc/manpaths.d
In Leopard /etc/paths.d and /etc/manpaths.d each contain a single file named X11, and so PATH and MANPATH include entries for X11. The path /usr/local/bin is one of the paths in /etc/paths, so it is no longer necessary to add this path when installing other programs.
The goal of path_helper is to make it easy to add entries to everyone's PATH, in particular entries for X11. But, it seems that it takes forever for path_helper to process a long MANPATH and it won't work if any of the desired path entries contain spaces. There are other issues, but they're mostly stylistic/portability concerns. This particular program might be best written in a different language.
Two alternative versions of path_helper contributed to the x11-users mailing list:
- By Peter O'Gorman:
"Something like his should both be faster and more portable (although the -u option to read is not portable). Also, even if an invalid option is given, it still reads all the files etc first. Undoubtedly C would be quicker, but this version removes most of the forks which is what causes slowdowns in shell scripts."
#!/bin/sh
#
read_path_dir () {
DIR="$1"
NEWPATH="$2"
DIRD=
[ -d "$DIR".d ] && DIRD="${DIR}.d/*"
for f in "$DIR" $DIRD ; do
if [ -f "$f" ]; then
exec 5< "$f"
while read -u5 -r p; do
case ":${NEWPATH}:" in
*":${p}:"*) continue ;;
::) NEWPATH=${p} ;;
*) NEWPATH="${NEWPATH}:${p}" ;;
esac
done
exec 5<&-
fi
done
path_result=$NEWPATH
}
read_path_dir /etc/paths "$PATH"
P=${path_result}
read_path_dir /etc/manpaths "$MANPATH"
MP=${path_result}
case ${1-no},${SHELL} in
-c,*|no,*csh)
echo setenv PATH \"$P\"\;
echo setenv MANPATH \"$MP\"\;
;;
-s,*|no,*)
echo PATH=\"$P\"\; export PATH;
echo MANPATH=\"$MP\"\; export MANPATH;
;;
*)
echo "usage: path_helper [-c | -s]" 1>&2
exit 1
;;
esac- By Andrew J. Hesford:
"I re-implemented path_helper in Perl, and it's attached. I'd appreciate if people would give it a try. I'm no Perl hacker, so maybe it's horrendously stupid, but it seems okay to me. It seems to duplicate the exact functionality of the original path_helper.
Any existing PATH or MANPATH contents are preserved, in order. Next, the /etc/{man,}paths files are read for defaults, and finally, the files in /etc/{man,}paths.d are processed."
#!/usr/bin/perl -w
# A replacement for /usr/libexec/path_helper
sub pathstring {
my @apath;
while (my ($key, $value) = each (%{$_[0]})) {
$apath[$value] = $key;
}
$pstr = join ":", @apath;
return $pstr;
}
sub hashpath {
my @apath = split ":", $_[0];
my %hpath;
my $offset = 0;
foreach $element (@apath) {
next if exists ($hpath{$element});
$hpath{$element} = $offset;
$offset++;
}
return %hpath;
}
sub procdir {
my $defaults = $_[0];
my %path = %{$_[1]};
my $pathloc = $defaults . ".d";
my @pathfiles = <$pathloc/*>;
my $offset = keys %path;
if (open PATHSRC, "< $defaults") {
chomp (my @elements = );
close (PATHSRC);
foreach $element (@elements) {
next if exists ($path{$element});
$path{$element} = $offset;
$offset++;
}
}
foreach $file (@pathfiles) {
next if not open (PATHSRC, "< $file");
chomp (my @elements = );
close (PATHSRC);
foreach $element (@elements) {
next if exists ($path{$element});
$path{$element} = $offset;
$offset++;
}
}
return %path;
}
my %defpath;
my %defmans;
%defpath = hashpath $ENV{'PATH'} if exists ($ENV{'PATH'});
%defmans = hashpath $ENV{'MANPATH'} if exists ($ENV{'MANPATH'});
my %newpath = procdir '/etc/paths', \%defpath;
my %newmans = procdir '/etc/manpaths', \%defmans;
my $pathstr = pathstring \%newpath;
my $manstr = pathstring \%newmans;
if ($#ARGV >= 0 && $ARGV[0] eq "-c") {
print "setenv PATH \"$pathstr\"\n";
print "setenv MANPATH \"$manstr\"\n";
} else {
print "export PATH=\"$pathstr\"\n";
print "export MANPATH=\"$manstr\"\n";
}
Inkscape in Leopard
You can download a pre-built binary (version 0.45.1) from the Inkscape website which works just fine if you open X11 first. Otherwise it fails to start when some internal settings presume you are running Panther or Tiger and ask you to install X11.
Carbon Emacs
In Leopard, you don't need to install Carbon Emacs 22, you already have it. In fact, /usr/bin/emacs is a full GNU emacs-22.1. The only thing missing for a full-blown Carbon Emacs is the Emacs.app envelope which consists basically of two files, Info.plist and the icon image file.
A ready-made app-bundle (24kB compressed) was recently attached to a message to the X11-users list. You can download it from here
Rename the downloaded file to:
Emacs.app.tar.bz2
Then, run:
tar jxf Emacs.app.tar.bz2
To use the option key as the modifier.
Making a simple ~/.xmodmap file with the following single line gets NEdit working like I expect:
keycode 66 = Alt_L
Beginning with X11.pkg 2.1.0, the default keyboard mapping reverted to using Alt for Mode_switch. This decision was made due to user feedback and to maintain consistency with Tiger's X11 keyboard mapping. If you wish to change to Alt instead of Mode_switch, try using one of the following ~/.Xmodmap files:
To get the Alt/Option key to work:
clear Mod1
keycode 66 = Meta_L
add Mod1 = Meta_L
clear Mod2
This one switches both alt keys to be alt:
keycode 66 = Alt_L
keycode 69 = Alt_R
clear mod1
add mod1 = Alt_L Alt_R
To map Command to Ctrl:
clear control
keycode 63 = Control_L
keycode 67 = Control_L
add control = Control_L
This one leaves the right alt as Mode_switch and places Alt on a separate X11 modifier assignment:
keycode 66 = Alt_L
! keycode 69 = Mode_switch
clear mod1
clear mod4
add mod1 = Mode_switch
add mod4 = Alt_L
Run xmodmap -pm to see the default setup:
shift Shift_L (0x40), Shift_R (0x44)
lock Caps_Lock (0x41)
control Control_L (0x43), Control_R (0x46)
mod1 Mode_switch (0x42), Mode_switch (0x45)
mod2 Meta_L (0x3f), Meta_R (0x47)
mod3To see the keycodes and the keysyms of the keys run xev. Place the mouse cursor in the little window that pops up, and press and release buttons. You will see something like the following sample:
KeyRelease event, serial 26, synthetic NO, window 0x200001,
root 0x3f, subw 0x200002, time 2828829429, (22,20), root:(22,42),
state 0x2000, keycode 69 (keysym 0xff7e, Mode_switch), same_screen YES,
XKeysymToKeycode returns keycode: 66
XLookupString gives 0 bytes:If two keys produce the same keycode, there is no way you can use xmodmap to distinguish them. If they produce different keycodes, you can use xmodmap to assign them different keysyms. Once they have different associated keysyms, you can put them on different modifiers as well. You can learn the proper syntax for your ~/.Xmodmap file simply by looking at the output of: xmodmap -pke
If you launch the regular terminal.app and it runs X as well...
This probably means you have something in your .bash_profile (or other appropriate startup configuration file) that deals with X or X configuration -- xmodmap, perhaps? As soon as you run anything that connects to $DISPLAY, X11.app will start.
The "Are you sure you want to quit?" message...
You can disable this message with the following command:
defaults write org.x.X11 no_quit_alert true
Nautilus
Nautilus fills the whole screen, exhibits a warning that it cannot determine the screen size and you can't access any other windows on the desktop. Solution: launch Nautilus with '--no-desktop' flag, so it doesn't take over the root window.
X11 Fonts (by Ben Byer)
There are two completely different sets of font systems in use with X11 today -- "X11 core fonts" (which are rendered server-side) and "client-side fonts", which generally use libXft. Xft finds fonts using the fontconfig system -- so any fc-* command will deal with that system. Core fonts use the "font path" set in the server to find fonts, and then render them in the server -- these are the fonts you will see with xlsfonts / xfontsel. To expound a bit more:
X11 "client-side fonts"
Modern applications generally use client-side font rendering, due to numerous limitations in the X11 core font system. Here, I'm talking about OpenOffice, Gimp, etc. Anything that uses gtk or Qt. I think these applications can fall back on server-side fonts, if required, but that's really a last resort. In order to get this working, you need to get fontconfig set up properly.
For Leopard, fontconfig was built with --with-confdir=/usr/X11/lib/X11/ fonts, so that's where it will look for the system-wide configuration. (If you're seeing it look in /etc/, then your fontconfig was not built with that configure flag.)
In addition, I'm trying to add the following flags for future official Apple builds:
'--with-default-fonts=/usr/X11/lib/X11/fonts --with-add-fonts="/System/ Library/Fonts,/Library/Fonts,~/Library/Fonts"'
fontconfig will also look for a local configuration file in your home directory (~/.fonts.conf, perhaps?) There's quite a lot more that we can do to fontconfig to make it better play with OS X, including moving the cache files to: /System/Library/Caches and ~/Library/Caches, as appropriate. I played around with this and ran into some weird bugs; I didn't have time to dig further.
Important commands:
fc-cache -v
fc-list
Note that neither of these commands actually connects to the X server, as fontconfig is independent of X11.
X11 core fonts
"Everything else" uses X11 core fonts, which are fraught with architectural limitations, but are sometimes all that you have (especially for any application which was not written from scratch within the last 5 years or so). So, it's important to have these working, too. The X server looks in a "font path" for fonts; you can see the current font path by running "xset q". The default path is set at compile time. It can be changed at runtime with the "xset fp" command. It can also be changed in the X server configuration file -- although we don't ship one, the server should support one but I've never bothered to try.
Occasionally, you'll see people bring up xfs -- the X Font Server. Once upon a time, X servers in general didn't link against things like FreeType, and so they couldn't handle some of the more modern fonts, so people built font servers that filled in the gap in functionality because they couldn't fix it in the server. There should no longer be any need for this. Of course, moving sophisticated font processing in the server has performance issues and apparently stability ones, as well.
Important commands for X11 core fonts:
mkfontdir
mkfontscale
xlsfonts
xfontsel
xset q
xset fpExamples:
[sao @ Heaven: ~] % xlsfonts | wc -l
7992[sao @ Heaven: ~] % xset q
.....
.....
Font Path:
/usr/X11/lib/X11/fonts/misc/, /usr/X11/lib/X11/fonts/TTF/, /usr/X11/lib/X11/fonts/OTF,
/usr/X11/lib/X11/fonts/Type1/, /usr/X11/lib/X11/fonts/100dpi/, /usr/X11/lib/X11/fonts/75dpi/
.....
.....[sao @ Heaven: ~] % cat /usr/X11/lib/X11/fonts/OTF/fonts.dir
22
GohaTibebZemen.otf -misc-goha tibeb zemen-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
GohaTibebZemen.otf -misc-goha tibeb zemen-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMAdiabene.otf -misc-east syriac adiabene-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMAntioch.otf -misc-estrangelo antioch-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMBatnan.otf -misc-serto batnan-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMBatnanBold.otf -misc-serto batnan-bold-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMCtesiphon.otf -misc-east syriac ctesiphon-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMEdessa.otf -misc-estrangelo edessa-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMJerusalem.otf -misc-serto jerusalem-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMJerusalemBold.otf -misc-serto jerusalem-bold-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMJerusalemItalic.otf -misc-serto jerusalem-medium-i-normal--0-0-0-0-p-0-iso10646-1
SyrCOMKharput.otf -misc-serto kharput-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMMalankara.otf -misc-serto malankara-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMMardin.otf -misc-serto mardin-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMMardinBold.otf -misc-serto mardin-bold-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMMidyat.otf -misc-estrangelo midyat-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMNisibin.otf -misc-estrangelo nisibin-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMQenNeshrin.otf -misc-estrangelo quenneshrin-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMTalada.otf -misc-estrangelo talada-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMTurAbdin.otf -misc-estrangelo turabdin-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMUrhoy.otf -misc-serto urhoy-medium-r-normal--0-0-0-0-p-0-iso10646-1
SyrCOMUrhoyBold.otf -misc-serto urhoy-bold-r-normal--0-0-0-0-p-0-iso10646-1
Font size in GnuCash, Inkscape, and Gimp
If the fonts are too small in the menus, menubar, etc. of GnuCash, Inkscape, and Gimp, remember that they all use the GTK2 toolkit, so you change font sizes using the GTK2 way:
If you don't have ~/.gtkrc-2.0, create it, containing the single line:
gtk-font-name = "geneva 12"
Of course, you can choose different font names and sizes, but this is a good starting value.
If you get the error "failed to bind to surface"
If you get the error "failed to bind to surface" when you run remotely certain X11 applications (for example, tecplot, vapor), setting the environment variable LIBGL_ALWAYS_INDIRECT (on the remote machine) should get rid of this.
In a tcsh startup script, this can be done as follows:
if ( $?SSH_TTY ) then
setenv LIBGL_ALWAYS_INDIRECT 1
endif
Running MATLAB from remote machine
Almost all the matlab GUI runs under Java which uses aqua windows. Only the graphics windows run under X11. The only way you can have a 'true' X11 version of matlab is by starting it with the -nojvm option from the command line. Try:
ssh -Y server.name
and then
matlab -nojvm
The "-nojvm" option allow you to run a command-line version of Matlab on a Mac and have the display on a remote machine. It runs fine, but It doesn't provide the nice GUI with the editor, variable list, command history, etc.
Change the default X server DPI setting
Copied from a great tip posted by "steeb" at the Macosxhints website:
"....I read a thread on MacOS Forge that stated that the launchd auto-starter included in their community-supported Xserver releases actually just runs the startx command."
"This is great news, because startx is a script that can be edited. So I installed the latest packaged build available from their website, then opened a Terminal window, and pulled up the startx script in a text editor: sudo nano -w `which startx`. Then I pressed Control-W and located the string defaultserverargs, and changed the first occurrence in the file from this...
defaultserverargs=""
... to this ...
defaultserverargs="-dpi 96"
Then I pressed Control-X to exit, and telling nano to save the changes when prompted.
Now the next time I started X11, my display reported a resolution of 96x96 dpi. You can check what X11 thinks your screen resolution is with the following command:
xdpyinfo | grep -i resolution
Note that the dpi change will have to be re-applied each time you install a new build of X11 from MacOSforge. You may also find that this tip doesn't work if you replace the community supported builds with an Apple-supported build of X11."