The X Window System is included as part of the NetBSD distribution as of the NetBSD 1.2 release. You'll want the latest version, so you can pick up the files form the following directory:
ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-1.5/mac68k/binary/sets/
The xbase.tgz file is the base distribution, including the X binaries,
shared libraries and some of the configuration files. The xcomp.tgz
file includes those items needed for compiling X binaries such as the
static libraries and header files. The xfont.tgz set includes the X11
fonts. The xcontrib.tgz set consists of the binaries and man pages
from the X "contrib" directory (e.g. xload, xev). Finally, the
xserver.tgz file is the X server binary itself. Install these files
using your favorite method (i.e. either the Installer utility or from
within NetBSD). They will unarchive into the various subdirectories of
/usr/X11R6/.
The distribution X server is a monochrome server. In order to use it, your machine must be in 1-bit (i.e. B&W) mode before booting NetBSD. The NetBSD 1.3 X server provides a number of improvements over the 1.2 server, so you will probably want to upgrade if you are using the older binaries.
If you have trouble getting X to run, try starting it with:
startx >& startx.log
startx.log so that
you can examine it to determine the cause of the problem.
startx I get the message: startx: Command not found. What's wrong?You need to add the location of the X binaries to your shell's path
variable. For csh and its derivatives, add /usr/X11R6/bin to
the line in your .cshrc file which sets the path variable. For
sh and its derivatives, you'll need to modify you .profile
instead.
X will not run in single-user mode to the best of my knowledge, because I
don't think that the necessary daemons to manage the port connections it
must have to run have been started at that point. You need to exit from
single-user mode (type exit or hit Ctrl-D), which will then run /etc/rc*,
mount the listed filesystems read-write (or whatever you happen to
specify), and then put you into multi-user mode from which you can run X by
typing startx.
startx something weird happened: I got six really tiny screens on the top of my monitor. Can anyone help me with this one?The problem is that your monitor is not in 1-bit (black & white) mode and the kernel and NetBSD/mac68k X server that you are using do not support color. You need to remember to set your monitor to 1-bit mode before you boot NetBSD.
startx I get the message: xinit: libXmu.so.6.0 not found. What's wrong?The reason you are having trouble is that you have not made the dynamic
link editor aware that the X libraries exist. To do so you need to modify
var/run/ld.so.hints using ldconfig.
If you have the new-style (i.e. post-1.2) configuration files, you can edit
/etc/ld.so.conf to contain the following line:
/usr/X11R6/lib
If you are using the older method, you should edit /etc/rc.local
to contain a line similar to the following:
#
# Build the link-editor fast directory cache.
#
echo "adding X libraries to the runtime link editor directory cache."
ldconfig -m /usr/X11R6/lib
Much thanks to Jim Wise (jim@santafe.arch.columbia.edu) for the hint about
the -m flag to ldconfig.
Keep in mind that the above examples assume that your X shared libraries
are located in /usr/X11R6/lib. If you have moved them elsewhere,
use that location instead.
Although you can generally use the LD_LIBRARY_PATH to override or
extend the list of libraries cached by ldconfig, the X server is a
setuid program, so it will ignore any such attempts in this case. See
ldconfig(8) for details.
startx I get the message: xinit: libXext.so.6.1 not found. What's wrong?See the previous answer
"ld.so: warning: libm.so.0.0: minor version >= 1 expected, using it anyway". Should I worry about this?The reason why you are getting this error is that the X server was compiled with a newer version of the shared libraries than you currently have on your system. You are probably using the 1.0 or 1.1 distribution shared libs. You need to update your shared libraries to fix this problem.
"ld.so: Undefined symbol "__sys_errlist" in X:X", and then X just dies. What am I doing wrong?The problem here is the same as for the question above, you are using an outdated version of the shared libraries. You need to update these libraries by finding a newer version of the base distribution tar file or else compile your own libraries from the current source.
This is a problem with the first two MacBSD X servers. You need to upgrade your X binaries. For the latest sets, take a look at:
ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-1.5/mac68k/binary/sets/
This is a problem with the first two MacBSD X servers. Basically, the 'a' key was bound to keycode 0, something which is not recommended for an X server to do. You need to upgrade your X binaries. For the latest sets, take a look at:
ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-1.5/mac68k/binary/sets/
Try using the -display flag for the X client in question like so:
xterm -display :0.1
This problem appears to be fixed as of the NetBSD 1.3 X distribution. Please obtain a copy of it and install it. An explanation of the problem and a workaround for those using older X distributions follows.
The left and right arrow keys, in conjunction with the option key, are used for emulation of the second and third mouse buttons. This seems to conflict with the up and down arrow keys under X, but a simple fix exists:
From Ken Nakata (kenn@eden.rutgers.edu):
Included below is my .xmodmaprc file:
!
! This is an `xmodmap' input file for Apple Standard ADB keyboards.
! Automatically generated on Wed Jun 28 20:09:20 1995 by kenn with
! XKeyCaps 2.22; Copyright (c) 1994 Jamie Zawinski <jwz@lucid.com>.
!
! This file presupposes that the keyboard is in the default state, and
! may malfunction if it is not.
!
remove Mod1 = Alt_L
keycode 0x3D = Down
keycode 0x3E = Up
add Mod1 = Meta_L
and I just put the following line in my .xinitrc:
xmodmap $HOME/.xmodmaprc
That's it. Removal and addition of Mod1 means I use the command key instead of the option key for Mod1 modifier.
You're using an outdated X distribution. Apparently, sound support for X is a rather difficult thing to provide, however, Scott Reynolds (scottr@og.org) managed to include it in the NetBSD 1.3 X release:
ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-1.5/mac68k/binary/sets/
It depends on your hardware. Thanks to original efforts by Ken Nakata (kenn@eden.rutgers.edu) and Taras Ivanenko (ivanenko@ctpa03.mit.edu) and further work by Paul Goyette (paul@whooppee.com) there is 8-bit color support for Nubus video on some '030 and '040-based Macs.
NOTE: in addition to the information provided below, you may want to check out Mark Andres' (mark@giganet.net) color X HOWTO:
http://www2.giganet.net/~mark/NetBSD/howtos/color-x-howto.html
In order to run in color you need two things: kernel support for color video and an X server which understands this support. You can obtain a color-capable X server which is compatible with the NetBSD 1.3 X distribution from the following location:
ftp://ftp.macbsd.com/pub/NetBSD/X/Xmac68k_color.tar.gz
If you need a color-capable server for the older NetBSD 1.2 X distribution,
please check the old/ subdirectory of the above directory.
Please read the associated README file for the X server. In addition, some information from Ken Nakata on the features of the new X server:
Its new feature is in its grf initialization scheme when you are running a non-color kernel.
It first tries to initialize grf in 8-bpp mode, and then tries 1-bpp if 8-bpp fails. Both attempts use Taras' grf driver ioctl() calls, so neither will work if you have a GENERIC kernel (or whatever without Taras' grf driver built in). The older colorkit server gave up on it here, but the new server does more: It GUESSES that the running kernel doesn't have Taras' driver in it, and it ASSUMES that the grf is already in 1-bpp mode, so it starts in 1-bpp mode. You'll lose if you booted NetBSD in other than 1-bpp mode, but you would have lost even with the older colorkit servers anyway.
A Colorkit Misconception Warning: If you run a kernel with Taras' grf driver and this server, you don't have to boot NetBSD in any particular pixel depth. The server tries 8-bpp first, then 1-bpp if your video doesn't support 8-bpp no matter in what video mode you booted. In other words, X won't run in any other pixel depth even if you explicitly boot NetBSD in that depth. Why not support 4-, 16-, or even 24-bpp modes? Frankly, that's out of range for my skills, and I don't personally want them that much. Sorry.
To summarize, this X server should work on both monochrome and color kernels, and it supports the terminal beep. So, this X server is probably my server of choice.
If you install the color X server as something other than
/usr/X11R6/bin/Xmac68k (the default), you will need to create a
symbolic link from it to /usr/X11R6/bin/X so that startx will
start the correct binary.
There are two methods of adding kernel support for color video. The older of the two is to use the colorkit loadable kernel module. A version that works with NetBSD 1.3 and later should be available at:
ftp://ftp.macbsd.com/pub/NetBSD/X/video_lkm/video_lkm_combined.o
In order for the colorkit LKM to work, you must load it into the kernel.
If you have a recent kernel, the kernel-level support for LKM's is already
built-in. If you are using an older (i.e. 1.2 or earlier kernel, you'll
have to compile your own kernel with LKM support added, or, better yet,
upgrade to 1.3). First, install the object file into /usr/lkm.
Then, if you have the new /etc/lkm.conf, simply edit it to look
something like the following:
# $NetBSD: lkm.conf,v 1.2 1997/07/14 11:55:46 drochner Exp $
#
# see lkm.conf(5) for details. path will look in /lkm and /usr/lkm.
#
# path options entry postinstall output when
video_lkm_combined.o - video_lkm_cmd - /tmp/video -
If you are not using the new /etc/lkm.conf file, you should
upgrade your /etc directory. Or, you can add something like the following
to the end of /etc/rc.local:
# Set up color video
if [ -f /usr/lkm/video_lkm_combined.o ] ; then
echo 'loading color video.'
modload -o /tmp/video -e video_lkm_cmd video_lkm_combined.o
fi
You could also issue the above command by hand, but remember that you must
be in single-user mode to successfully execute modload unless you have
options INSECURE specified in you kernel configuration. A third
option is to obtain the
colorkit LKM source
,
compile and/or install the LKM, and issue a make load command from the
compile directory (while in single-user of course).
One caveat for using the colorkit LKM is that the module does not unload gracefully, so if you shutdown the system from multi-user into single-user and try to load the LKM again, it will most likely hang the system.
The second option for adding kernel support for color video is to get one of Paul Goyette's SLOTMAN kernels or to compile your own kernel with his SLOTMAN patches added. You can obtain both from:
http://www.whooppee.com/slotman/
This method is recommended over using the LKM since the SLOTMAN changes support a wider variety of video hardware because it contains a more complete implementation of the Slot Manager than does the LKM. A list of machines supported by the SLOTMAN changes should be available in the same directory listed above. Please contact Paul (paul@whooppee.com) for further information if your machine is not on his supported list
As for color on Macs with internal video only, support is in the works by Michael Zucca (mrz5149@acm.org). As a result, none of the '040-based Macs will currently support a color X Window System with their onboard video. Check out Michael's project page for the status of this effort:
http://www.mdc.net/~mrz5149/projects.html
Fatal server error: Can't run X server with no screens!, and then X just dies. What am I doing wrong?This is probably due to lack of support for your video hardware in the
kernel you are using. Not all internal video hardware is supported yet,
nor are all nubus video boards. Use the dmesg command to search your
boot message for a line beginning with grf0. If you don't see such a
line, you are currently out of luck (unless there is some experimental
kernel with the support you need built into it).
If you do see such a line, then you probably forgot to make devices. As
root, cd into the /dev directory and do a
sh MAKEDEV grf0 grf1 grf2 grf3
Thanks to Ken Nakata (kenn@eden.rutgers.edu) for the above solution.
Yes, Hauke Fath (hauke@Espresso.Rhein-Neckar.DE) has contributed a German xmodmaprc file. It is available at:
ftp://ftp.NetBSD.org/pub/NetBSD/arch/mac68k/contrib/Xmodmap/de/
/dev/grf2: not found. What's wrong?You are probably running on an older system with at least 2 monitors
attached. Either way, X servers later than September 1995 perform a couple
of checks, one of which results in trying to open /dev/grf2. If
this fails, the X server will die.
To fix this, you need to create the device file. As root, cd to the
/dev directory and type:
sh MAKEDEV grf2 grf3
Thanks to Ken Nakata (kenn@eden.rutgers.edu) and Allen Briggs (briggs@puma.macbsd.com) for the answer and the fix.
You need to either run xconsole or else run an xterm with the "-C" option. Even then, you need to have the
options UCONSOLE
chown the console to yourself and make it readable by you.
You can also edit /etc/syslog.conf to redirect syslog output to
wherever you would like it to go.
Thanks to David Brownlee (abs@anim.dreamworks.com) for this answer.
The problem you are encountering is due to the fact that the new 1.3 X distribution uses gzipped fonts because it is XFree86 3.3-based, while the older distributions used compressed fonts because they were X11R6.1-based. A new server should be backwards compatible, but the old server won't be able to use the newer fonts.
The solution is to upgrade all your X binaries at once, including the X server. If you didn't upgrade the X server because you were using the older color server, there is a new one available that is compatible with the 1.3 X distribution:
ftp://ftp.macbsd.com/pub/NetBSD/X/Xmac68k_color.tar.gz
Thanks to Kevin F. Havener (havenerk@thunder.safb.af.mil) for information on this one.
Assuming that your machine supports X (and most machines which will boot on their own console do), chances are you just aren't waiting long enough for the magic to happen. On machines which lack an FPU and are low on memory (e.g. an LCII), it can take several minutes (like 20+) for X to start. So, just sit back and wait a while.
If you machine is hanging with the gray hatched background and the black X
cursor in the foreground, it might be that you need to setup a .xinitrc
file which will start X clients for you (although by default you should at
least get an xterm if your path is set correctly). Please read the
X(1) and xinit(1) man pages for more info on how to configure X
to your tastes.
You have booted into NetBSD without setting your screen to 1-bit mode first, and you are using the color X server, but color X isn't supported under your current setup. The colors you are seeing a probably a result of the server using whatever colors happen to be in your CLUT at the time you booted NetBSD. If you have a supported NuBus video card, you need to see the Q&A above on setting up color X . Otherwise, you need to boot NetBSD in 1-bit mode .
If you are using a 1.2G or later kernel, you can emulate all three mouse buttons by pressing "option-1", "option-2", or "option-3". However, this is not enabled in the default GENERIC kernel (at least not in version 1.5 anyway).
To enable the mouse button emulation, you will need to build a new
kernel as described in the NetBSD/mac68k
Kernel Compiling HOWTO. After you have downloaded the kernel
source and created a new configuration (following the instructions in
the HOWTO),
remove the initial # from the line in the configuration file
containing ALTXBUTTONS so that it looks like
options ALTXBUTTONS # Map Opt-{1,2,3} to mouse buttons
Now continue with the HOWTO instructions to build and install your new kernel.
Try putting
xmodmap -e "keysym Delete = BackSpace Delete"into your .xinitrc (or .xsession if you are using xdm) file. In theory this should make it generate backspace when pressed on its own and forward-delete when pressed with shift. The forward-delete may or may not work on your system, but it should at least fix the backspace problem.
Table of contents of this chapter, General table of contents