[FAQ Index] [To Section 10 - System Management] [To Section 12 - Hardware and Platform-Specific Questions]

11 - The X Window System

Table of Contents

11.1 - Introduction to X

The X Window System (sometimes just called "X", other times, incorrectly called "X Windows") is the environment which provides graphics services to OpenBSD and other Unix-based systems. However, by itself, X provides very little: one also must have a "Window Manager", to present a user interface. Most of the "personality" one will feel from X will be due to the window manager, rather than X itself. OpenBSD ships with a free version of the fvwm(1) and cwm(1) window managers, although you may wish to use any of the other window managers that are in packages. Search using a key of "window manager" for a list of the many window managers available.

X is considered a "client-server" structured protocol, however the terminology is sometimes confusing. The computer with the graphics on the screen is the "X Server". The application which directs the X server what to put on its screen is the "X Client", even though it may be a much more powerful computer in a data center. This model can be used to have large, processor intensive applications (X clients) running on a very powerful machine, using the X Server running on a small, low power machine on your desk for their user interface.

It is possible to run X clients on a system without any graphical support. For example, one could have an application (the X client) running on an mvme88k, displaying its output on an alpha's graphical display (the X server). Since X is a well-defined, cross-platform protocol, it is even possible to have an X application running on (for example) a Solaris machine use an OpenBSD machine for its display.

The client and server can also be running on the same machine, and for most of this section, that will be the assumption.

11.1.1 - How much computer do I need to run X?

X itself is a pretty large program, a fast computer will be appreciated if you are starting it and stopping it regularly. However, once running, it performs pretty responsively on a very modest computer. To get responsive display performance on some platforms, even for just text, you will want to run X. These platforms, such as sparc and sparc64, were intended to be used with a graphical interface, and the text console performance is very poor.

That being said, the point of running X is usually to run X applications. Some X applications are very lean, others will seemingly take and use all the processor and RAM you can give them. Of course, some users just like to use X to provide a large number of xterm(1)s, which can be done on very modest hardware.

11.1.2 - Can I have any kind of graphics without X?

Assuming you won't accept ASCII graphics, that requires some kind of framebuffer console driver. Some operating systems provide this, but there is not currently one for OpenBSD, nor is there much interest among developers for one.

11.2 - Configuring X

Good news: In the vast majority of hardware in most platforms, X requires no configuration at all, it Just Works.

The details of manual configuration of X varies considerably from platform to platform. In all cases, there will be instructions and other platform-specific information in /usr/X11R6/README in the installed system.

Several platforms require the xf86(4) X aperture driver, which provides access to the memory and I/O ports of a VGA board and the PCI configuration registers required by the X servers. This driver must be enabled before it is used, either by answering "yes" to this question during install:

Do you expect to run the X window System [no]
or by changing the value of machdep.allowaperture to the appropriate non-zero value in /etc/sysctl.conf for your platform, and rebooting the machine (this sysctl cannot be changed after boot has been completed for security reasons). There are security implications to this, so do not do this if you do not need it.

11.2.1 - alpha

/usr/X11R6/README for alpha.

Set machdep.allowaperture=1 in /etc/sysctl.conf.

The TGA and some VGA cards are supported. No further configuration should be needed.

11.2.2 - amd64

/usr/X11R6/README for amd64.

Set machdep.allowaperture=2 in /etc/sysctl.conf.

For the vast majority of users, X on amd64 auto-configures successfully, so no further configuration is needed.

11.2.3 - armish

No X servers, only X clients.

11.2.4 - hp300

/usr/X11R6/README for hp300.

11.2.5 - hppa

No X server, only X clients.

11.2.6 - i386

/usr/X11R6/README for i386.

Set machdep.allowaperture=2 in /etc/sysctl.conf.

For the vast majority of users, X on i386 auto-configures successfully, so no further configuration is needed.

11.2.7 - landisk

No X servers, only X clients.

11.2.8 - loongson

No configuration needed.

11.2.9 - luna88k

No X servers, only X clients.

11.2.10 - macppc

/usr/X11R6/README for macppc.

Set machdep.allowaperture=2 in /etc/sysctl.conf.

Supported Macintosh PPC systems can be run in one of two different ways: "accelerated" and "framebuffer" (unaccelerated).

In the "framebuffer" mode, the system will be running with 8 bits per pixel, and the video resolution is controlled by the Macintosh environment, so you will probably want to keep a small MacOS section on your disk to adjust these settings. This mode has the advantage of "Just Working", however it can be frustratingly inflexible (for example, altering resolution may require booting MacOS).

If your Macintosh has an ATI-based video system, it can run using an accelerated X server, which gives better performance and more control in the OpenBSD environment. The NVIDIA video cards in some macppc systems will also work in many cases. The README file has details on configuring the accelerated driver, start by using the sample file there.

While the README file details using the standard Apple one-button mouse with X, unless you are using a laptop, it is highly recommended that you just buy a modern third-party USB mouse with three or more buttons.

CRT iMacs and X

iMacs have a very unusual (in this day) CRT, in that it has a fixed horizontal scan frequency. Attempting to use a horizontal sweep speed outside a very narrow range will cause the monitor to not light up. The following lines, added to xorg.conf in the Section "Monitor" area seem to make a lot of CRT-based iMacs in the 333MHz to 500MHz range (and possibly more!) work well:
        HorizSync       60.0 - 60.0
        VertRefresh     43.0 - 117.0 
You may wish to restrict the lower limit of VertRefresh to values that you are more likely to find acceptable, for example 70.

11.2.11 - mvme68k

No X servers, only X clients.

11.2.12 - mvme88k

No X servers, only X clients.

11.2.13 - sgi

X runs on the O2 system's frame buffer in unaccelerated mode.

11.2.14 - sparc

/usr/X11R6/README for sparc.

With a single supported framebuffer, there is no configuration needed. If you wish to use a multi-headed configuration, see the above README file for details.

Resolution is controlled by the firmware before booting OpenBSD.

11.2.15 - sparc64

/usr/X11R6/README for sparc64.

Most simple configurations now "Just Work". If yours does not or you wish to get fancy, see the above README file.

11.2.16 - vax

/usr/X11R6/README for vax.

The X server currently only works on VAXstation 4000 models with either a lcg(4) or lcspx(4) framebuffer.

11.2.17 - zaurus

/usr/X11R6/README for zaurus.

No configuration needed, X "Just Works".

11.4 - Starting X

There are two common ways to run X:

11.4.1 - On Demand:

Log in to a console as normal, then run startx(1).

11.4.2 - Boot directly into X:

This is done using xdm(1), the X Display Manager. xdm(1) is started as root, normally by rc, and presents a login prompt. Upon successful login, it starts an X session for that user. If or when that X session should be terminated (including by hitting CTRL-ALT-Backspace), xdm(1) will return, prompting the user to login again. For this reason, do NOT attempt to start xdm(1) from /etc/rc.conf.local until you have verified X works as you wish, or your machine may become very difficult to manage! (worst case: boot single user, as if you lost your password, and edit out the xdm_flags line in your /etc/rc.conf.local file.)

On some platforms, you will need to disable the console getty(8) to use xdm(1).

11.5 - Customizing X

11.5.1 - Introduction

OpenBSD's default X environment is fully functional, but you may wish to customize it. You may wish to change the background pattern or color, or you may wish to change the Window Manager (the program that most defines your X environment), or change the applications that are started when X starts.

The default window manager in OpenBSD is fvwm(1). Fvwm is a good, general purpose window manager, but it is hardly your only choice; it isn't even the only window manager included with OpenBSD (see cwm(1) and twm(1)). A large number of window managers are also available through packages.

Similar to the system startup script, X has a process it goes through to set up the user environment. More accurately, it has more than one process; which process is used depends on how you start X. Understanding how X starts will help you understand how to customize your work environment the way you wish it to be.

Note that you can customize the environment on both a system-wide and user level. It is probably best to do user level changes rather than to change the system defaults, as the user scripts are stored in the user's home directory, so you will have less merging of files to do when upgrading to a new version of OpenBSD. The system-wide defaults are in /etc/X11 and were initially loaded from xetcXX.tgz, which is not reloaded by the suggested upgrade process, so if you make system-wide changes, they will persist, but you may need to merge those changes into later versions of those files.

11.5.2 - startx(1) startup

startx(1) looks for the file .xinitrc in the user's home directory. .xinitrc is usually a shell script, which can start as many X "client" (applications that use X) programs as desired. When this script exits, the X server shuts down. Generally, most of the programs run by this script should run in the background, though the last one should run in the foreground (typically the window manager); when it exits, the script will exit, and X will be shutdown.

In the simplest case, this can be as little as just the name of the window manager you wish to invoke:

Or you can get a little more fancy:
xconsole -geometry -0+0 -fn 5x7 &
oclock -geometry 75x75-0-0 &
xsetroot -solid grey &
That will start the xconsole(1) which provides a copy of any text that the kernel would have sent to the console (which is now covered by the graphical screen), an analog clock, oclock(1), and sets the background to a solid grey background with xsetroot(1) all before invoking the cwm(1) window manager. Note that only the window manager is not "backgrounded" with an "&" character. This means that X will stay running until cwm(1) exits.

If a user's home directory does not have a .xinitrc file in it, the system's /etc/X11/xinit/xinitrc file is used. This file can provide you some additional ideas for your .xinitrc script.

11.5.3 - xdm(1) startup

xdm(1) is usually started by the system startup scripts, but for testing purposes (recommended, until you know your have your X config right!), it can be run as root.

xdm(1) has a lot of other functionality that won't be touched on here, but for our purposes, xdm will present the user with a login screen, get and verify a user name and password, and then give the user their X environment. When X shuts down, either deliberately or accidently, xdm will start it back up again. This is why you want to make sure X is configured properly before using xdm(1), and certainly before having xdm(1) start at boot, otherwise, you may have some difficulty getting control of the machine.

When xdm(1) starts, it runs the /etc/X11/xdm/Xsession, which will check to see if the user has a .xsession file in their home directory. So, if you wish to change your default window manager, simply invoke it (and maybe other things) in .xsession. Again, any programs you want started with X (for example, maybe three xterm(1)s) can be placed here, but all should be backgrounded except for your window manager, as again, when that exits, your X session will be ended. In this case, xdm(1) will restart X and bring you back to a login screen.

11.5.4 - Trying a new window manager

You can invoke a particular window manager when you load X without altering any defaults like this:
$ startx /usr/local/bin/fluxbox
Several window managers (including cwm(1) and fvwm(1)) offer the ability to change window managers on the fly, without restarting X or any of your applications. Your new window manager replaces your old one; exiting the newly-loaded window manager terminates X, it does not return you back to your previous window manager. fvwm(1) allows you to start a different window manager by left clicking on the background ("root window"), chose "(Re)Start", then pick your preferred window manager (however, note that you will need to add your alternative window managers to your .fvwmrc file (the system-wide default is /usr/X11R6/lib/X11/fvwm/.fvwmrc)). cwm(1) allows you to invoke another window manager by hitting Ctrl-Alt-w, and typing in the manager you wish to switch to.

Once you have found a window manager you like, you can set it as the final program run by your startup scripts as described above.

[FAQ Index] [To Section 10 - System Management] [To Section 12 - Hardware and Platform-Specific Questions]