![[OpenBSD]](../images/smalltitle.gif){kind=small}
[FAQ Index] [To Section 10 - System Management] [To Section 12 - Hardware and Platform-Specific Questions]
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.
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.
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:
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.Do you expect to run the X window System [no]
Set machdep.allowaperture=1 in /etc/sysctl.conf.
The TGA and some VGA cards are supported. No further configuration should be needed.
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. IF further configuration is needed, use the X -configure process below.
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. IF further configuration is needed, use the X -configure process below.
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.
HorizSync 60.0 - 60.0
VertRefresh 43.0 - 117.0
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.
Most simple configurations now "Just Work". If yours does not or you wish to get fancy, see the above README file.
The X server currently only works on VAXstation 4000 models with either a lcg(4) or lcspx(4) framebuffer.
No configuration needed, X "Just Works".
If X does not work as desired with your system, you will need to create a configuration file. A good starting place (and sometimes, a good ending place!) is to run Xorg(1) in the "X -configure" mode. This will load all available video driver modules, probes for other hardware, and based on what it finds, writes out a xorg.conf file that may or may not work. Even if it does not work, it will be a useful starting point for creating one that works as desired.
Another time-honored way to configure X is to use your favorite search engine to hunt for someone else who already solved your problem. Note that xorg.conf files for other Unix-like OSs will often provide very useful tips on what you need to get X running on your similar hardware. While that's not a bad way, that method won't be emphasized here.
This is a once high-end video card, with 16M RAM, but is now mostly unsupported on modern versions of "mainstream" operating systems. The monitor attached to the system is a Sony Multiscan G400 19" CRT monitor, and it would be nice to run this monitor at 1280x1024, with a decent refresh rate, and 24 bit color.vga1 at pci1 dev 0 function 0 "3DFX Interactive Banshee" rev 0x03
First, after installing OpenBSD with X (and making sure the aperture driver is enabled in the kernel), let's see what X.Org's auto detection and configuration does, after all, we might get lucky. So, we simply log in and use the command startx(1). The screen goes blank for a few moments, then we get the X "checkerboard" background, the "X" cursor, and then an xterm window.
It works!
More or less. While the system is fully functional, it doesn't appear to have picked up any of the capabilities of the monitor, and is running at what is clearly a low resolution (640x480). We hope to do better than this. Much better, in fact. This does mean we need to make our own xorg.conf file, however.
Let's use the "X -configure" process to generate a starting xorg.conf file. You will need to do this as root:
By the way, the message is serious -- use the entire path to your xorg.conf.new file, even if it is sitting in your current default directory. Failing to do so will result in X(7) not finding the file, and it will silently use the default configuration, and if that had worked, you wouldn't be using this process! This can set back your troubleshooting quite a bit. Trust us on this.# X -configure [...] Your xorg.conf file is /root/xorg.conf.new To test the server, run 'X -config /root/xorg.conf.new'
Let's do as it says, and see what we get:
Now, all we get is a black screen. Things had started out so well...# X -config /root/xorg.conf.new
This might be a really good time to talk about ways of exiting X when started in this way. In order of preference:
Here is where knowing your hardware comes in handy. Attaching this system to a different monitor while it is showing the blank screen produces a "Sync. Out of Range" message on the display. So, apparently the configuration X gave us will not run on this monitor, and may not run on ANY monitor, if a video mode was selected that isn't possible for this particular card (keep in mind, X is looking at the chips on the card, and what they are potentially capable of, not how the manufacturer put it all together). Different monitors will do different things when the timing is way off, some will attempt to display what they can, others will drop to power saving mode, some will make horrible noises, some will display useful messages on the screen. This monitor seems to do none of the above. A note is made to NOT use this monitor for initial X configuration in the future.
Looking through the generated xorg.conf.new file, we see this:
Section "Monitor"
#DisplaySize 370 270 # mm
Identifier "Monitor0"
VendorName "SNY"
ModelName "SONY CPD-G400"
### Comment all HorizSync and VertSync values to use DDC:
HorizSync 30.0 - 107.0
VertRefresh 48.0 - 120.0
Option "DPMS"
EndSection
Let's try to force Xorg to a particular resolution, and see if we have any luck. In the Section "Screen" part of the xorg.conf file, we want to add a couple lines. The added lines are shown in bold:
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
We test as above, and... SUCCESS! We have what appears to be a very nice, high resolution display. Note that ALL that is expected is a mesh pattern (very good for seeing how good your monitor REALLY is and also great for calibrating LCD displays, called the "root weave") and a movable cursor. It is not intended to be functional at this point.
Now, we want to install this xorg.conf file so we can see how well we are really doing with usable running of X.
We can now try X using the normal startx(1) command. It works!# cp xorg.conf.new /etc/X11/xorg.conf
It would probably be good to verify that we are at the resolution and color depth we desire, and also that we are running at a respectable refresh rate. We can do that with the xrandr(1) and xdpyinfo(1) commands. Among other things, xdpyinfo(1) tells us:
[...]
screen #0:
print screen: no
dimensions: 1280x1024 pixels (433x347 millimeters)
resolution: 75x75 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x44
depth of root window: 24 planes
[...]
xrandr(4) tells us:
SZ: Pixels Physical Refresh
*0 1280 x 1024 ( 433mm x 347mm ) *85 75 60
1 1280 x 960 ( 433mm x 347mm ) 85 60
[...]
On some platforms, you will need to disable the console getty(8) to use xdm(1).
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.
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:cwm
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.xconsole -geometry -0+0 -fn 5x7 & oclock -geometry 75x75-0-0 & xsetroot -solid grey & cwm
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.
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.
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.$ startx /usr/local/bin/fluxbox
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]
![[back]](../images/back.gif){kind=small}
www@openbsd.org