ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Fun with Xorg

by Dru Lavigne
12/07/2006

Chapter 5 of the FreeBSD Handbook provides an excellent overview for understanding and configuring the X Window system. Today's article goes beyond the Handbook to demonstrate some of the cool things you can do with your FreeBSD system and other systems running X.

Getting the Most out of your Video Card

While Xorg -configure does a good job of configuring video cards, the X drivers don't provide automatic support for DRI (Direct Rendering Interface), DRM (Direct Rendering Manager), or OpenGL (OPEN Graphics Library)--meaning you're probably not getting the most out of your video hardware.

The dri and linux_dri packages provide these missing features by installing FreeBSD kernel loadable modules for several cards:

Card/Chipset Module Name
Intel i810 i810
Intel i830 i830 (not available in linux_dri)
Intel i915 i915
ATI Mach64 mach64
Matrox Gxxx mga
ATI Rage128 r128
ATI Rage200 r200
ATI Rage300 r300
ATI Radeon radeon
S3 Savage savage
SiS 3xx sis
Voodoo 3dfx tdfx

Note: if you have a NVidia card and want to use the binary-only driver, instead make install the nvidia-driver port as it needs to compile against your kernel.

Depending upon the software you have installed, these DRI modules may already be on your system. Check with the command:

# pkg_info | grep dri

If you receive your prompt back with no output, or the output mentions only linux_dri, install the dri package:

# pkg_add -r dri

Once you have it installed, add a few lines to the end of /etc/X11/xorg.conf:

Section "DRI"
    Mode 0666
EndSection

Note: if that file doesn't exist, then:

# cp /root/xorg.conf.new /etc/X11/xorg.conf

Finally, double-check that Xorg will load dri and glx; if these lines don't exist, add them to the Section "Module" portion of /etc/X11/xorg.conf:

# grep dri /etc/X11/xorg.conf
    Load  "dri"

# grep glx /etc/X11/xorg.conf
    Load  "glx"

Loading and Testing the Kernel Module

Now you're ready to determine which kernel module to load. First, figure out which video card Xorg wants to use:

# grep Name /etc/X11/xorg.conf
    VendorName   "IBM"
    ModelName    "IBM G72"
    VendorName  "ATI Technologies Inc"
    BoardName   "Rage 128 Pro Ultra TF"

Compare that output to the earlier table. This system needs to use the r128 module. If I issue this command at Alt-F1 (the console), a successful driver load will display as bright white text:

# kldload r128
drm0: <ATI Rage 128 Pro Ultra TF (AGP)> port 0xd000-0xd0ff mem 0xf4000000-0xf7ff
ffff,0xfbefffff irq 10 at device 0.0 on pci1
info: [drm] AGP at 0xf0000000 64MB
info: [drm] Initialized r128 2.5.0 20030725

Once your driver successfully loads, start an X session as a regular user and check the OpenGL rendering capabilities from within the GUI:

% glxinfo | grep rendering
direct rendering: Yes

Once you have rendering enabled, add a line to /boot/loader.conf as the superuser so the driver automatically loads when the system boots. My line looks like:

r128_load="YES"

Replace r128 with the module name for your video card and double-check the file for typos.

3d-Desktop is an xgl-ish desktop switcher and a cool way to test your DRI:

# pkg_add -r 3ddesktop

Once installed, run it from the GUI as a regular user:

% 3ddesk

Use your arrow keys to rotate the cube of desktops and Enter or Space to bring a desktop into the foreground.

Nesting Xservers

When you install X, you get a whole suite of interesting utilities, many of which you may not be aware of. One of these is Xnest, which allows you to run multiple window managers simultaneously. Confirm that you have Xnest installed with:

# pkg_info|grep nest
xorg-nestserver-6.9.0_1 Nesting X server from Xorg

If you just get your prompt back, install the program with the command:

# pkg_add -r xorg-nestserver

Here is an example of how to use Xnest. On a system already configured for KDE, I installed three additional window managers:

# pkg_add -r windowmaker
# pkg_add -r xfce
# pkg_add -r fluxbox

Note: Window Managers for X provides screenshots of hundreds of window managers. On FreeBSD, you can see which window managers are available at the Freshports X11 window managers listing.

Once installed, start the GUI as a regular user. In my case, I see the KDE desktop. I can use Xnest to start windowmaker, which will appear as just another window with "Windowmaker" in the title bar:

% Xnest :1 -ac -name Windowmaker & wmaker -display :1

Note: X assigns the first window manager you start (in my case, KDE) a display number of :0. In this example, windowmaker gets the second display, :1, which Xnest nests within the original display.

To start two more window managers, bump up the display number and specify the name of the window manager:

% Xnest :2 -ac -name XFCE & xfce -display :2
% Xnest :3 -ac -name Fluxbox & fluxbox -display :3

Figure 1 shows all four window managers running simultaneously.

Thumbnail, click for full-size image.
Figure 1. Four window managers running simultaneously through Xnest (click for full-size image)

Distributed Multihead

One of X's design goals was to work in a networked environment, so there are several cool things you can do if you have access to multiple systems running X. It is remarkably easy for X systems to share display information, so I recommend performing these experiments within a home LAN behind an internet firewall.

One experiment allows you to spread a single display across multiple monitors using DMX (Distributed Multihead X). Start by installing the package on all the systems that will share the display:

# pkg_add -r xorg-dmx

For security reasons, FreeBSD systems don't participate on an X network by default, so temporarily change this behavior. Close any open X sessions and restart X with the option:

% startx -listen_tcp

Verify that X is listening on the network:

# sockstat -4 | grep Xorg
root    Xorg    33811 1  tcp4   *.6000    *.*

Now that X is listening, you have to tell it to accept incoming connections. The lazy approach is to run on all the systems:

% xhost +
access control disabled, clients can connect from any host

This message means exactly that; anyone can connect to your X display, which is why a firewall between you and the internet is important. It makes more sense to allow only the specific IP(s) of the systems you are experimenting with:

% xhost -
access control enabled, only authorized clients can connect

% xhost +192.168.1.1
192.168.1.1 being added to access control list

% xhost
access control enabled, only authorized clients can connect
INET:192.168.1.1

A good place to start is with an example of sharing a display between two monitors. 192.168.1.1 has the desktop I wish to display and 192.168.1.2 is the second system. I have configured both systems to accept X connections from each other.

From the GUI on 192.168.1.1, I run the command:

% startx -- /usr/X11R6/bin/Xdmx :1 -display 192.168.1.1:0 -display \
192.168.1.2:0 +xinerama -noglxproxy

Note that this is one long command. Don't include the \ when you type it in. You'll also receive an error if you don't give the full path name to Xdmx.

This command starts a new shared display (:1) that overrides the current display on both systems. The server will accept keyboard and mouse input from the first IP address, but it will work on either monitor. If you move your mouse, it can move onto the second monitor. While there, you can right-click on the second monitor and change the wallpaper for the entire display. When you wish to go back to your original displays, press Ctrl-Alt-Backspace. Any changes that you made in the shared display won't affect the two original displays.

man Xdmx provides many options for experimentation. A Developer Works article entitled "Distributed Multihead Support with Linux and Xdmx" contains instructions for adding monitors vertically, as well as some good troubleshooting tips.

Monitor Other Systems

Once you've configured systems to allow X connections from each other, it is trivial to monitor activity on other systems. I installed a watcher program on 192.168.1.1:

# pkg_add -r xwatchwin

Every time a window (or window manager) opens in X, it receives a window ID. In order to watch another system, you need to know the ID of the window you wish to view. As an example, if I want to watch 192.168.1.2's KDE session, from 192.168.1.2's GUI, I can determine the window ID by typing:

% xwininfo
xwininfo: Please select the window about which you
      would like information by clicking the
      mouse in that window.

If I click the desktop, this is the first line of output:

xwininfo: Window id: 0x1200008 "KDE Desktop"

In this case, "KDE Desktop" is the window ID. It is worth noting that the default window ID names are easily guessable. This is the reason why we use firewalls and why X shouldn't listen on the network by default.

I can watch everything that happens during that remote KDE session by typing one command on 192.168.1.1:

% xwatchwin -u 1 192.168.1.2 KDE Session

The update switch (-u 1) will refresh the display every second. Figure 2 shows the result.

Thumbnail, click for full-size image.
Figure 2. Watching a remote window (click for full-size image)

Conclusion

If you found this article interesting, read man X (note the capital X), which details many of the programs that come with the X window manager. Each of these will run easily on your own system, but you may have to delve a bit deeper into man Xsecurity if you want to experiment with other systems within your firewall-protected network.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.


Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.