May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Exporting DISPLAY in X Windows

News X Window System Recommended Links vnc "Can't open display" Error
Xdefaults Xhost Using xauth Humor Etc


Exporting display in X11 involves two distinct operations (X11 ports should be open if firewall is running. when troubleshooting disable firewall to exclude any interference from it):

Exporting display on the client

The environment variable DISPLAY is of particular importance in X windows because it tells the computer on which machine the graphics is to be displayed.

You should look at the current setting of DISPLAY while you are logged in:


This means that your machine is displaying on its own screen. The command uses different connection protocol then in case localhost:0.0.

The string 0.0 identifies a server number and an optional screen number. In most cases, both of these are zero.

Allowing to accept session on the server with xhost command

You need to allow X11 server to accept remote sessions. The simplest (and the most unsecure) was to accomplish that is by using " xhost + ". Generally this directive should be limited to troubleshooting and test mode.

NOTE: xhost + allows anyone to connect to this Xserver, and is not recommended for security reasons..

If you are lucky then if you launch X application on the client (your remote server, the screen of the application will appear on machineworkstation .

You permit that other machines can display on your using the command xhost. This command is can be included in your .profile file on your LINUX home directory. The syntax is xhost machine name. For example:


Again in test mode you can use "universal opener":

xhost +

You can deny display access by machine




Top Visited
Past week
Past month


Old News ;-)

Using X over the network

X is network transparent. This means that clients can run on a different machine from the server and communicate with it over the network. Clients use the environment variable DISPLAY to decide which server to connect to. If you are sitting in front of an EE machine and have opened a window onto another EE machine the command xdisp, typed on the remote machine, will set $DISPLAY automatically. On other machines you will have to set it yourself. Csh users should use something like

Bash users should use

with abraham replaced by the name of the local machine. NOTE: don't forget the .ee in the display name - from outside the department our machines must be referred to as

Most X clients also support a -display command line option to tell them which server to use. For example you could type

X and OpenWindows are set up to automatically allow you access to a server you have started from any machine in the department. Other people will be unable to access the display, even if the client is running on the same machine as the server.

For machines outside the department, access is not automatic. There are two ways to allow access. The secure way is to use rcp to copy ~/.Xauthority to the remote machine. This has to be done every time you start X. A less secure but simpler way is the xhost command. To allow access from castle you would type

on the local machine.

NOTE: the xhost command allows anyone on castle to open windows on your display, watch what you are doing or even see every key that you type.

If you need to allow someone else access to your display for some reason you should use xhost. This works because xhost authorisation is done on a per-machine basis, rather than the per-user basis that the default MIT MAGIC-COOKIE-1 authorisation uses.

The abilty to run X applications over the network is primarily useful when you want to run an application on a sun4 or castle, either because it is faster or only available for certain architectures, but use a colour display (all of our publically available sun4s are monochrome).

The Slackware Linux Project Slackware Linux Essentials

.Exporting displays

As was previously mentioned, it is possible to run X programs on one computer and display them on another. This is incredibly bandwidth-intensive, so you probably won't want to do this over a modem connection or over very long distances. Additionally, there are security considerations: exporting a display is not a very secure thing to do, since you'll be letting the entire network look at what you're doing. Still, it can be very useful on a local network.

An important thing to note here is the use of the words "client" and "server". When exporting the display, you may become confused as to what's a client and what's a server. We refer to the machine that actually runs the X programs and sends the display information as the "server". The machine that you use to display the remote program is called the "client". When discussing the design of X, this is reversed. The program that displays things is called the "server", while the running program is called the "client". It's not too terribly confusing, but worth pointing out.

For this example, we'll be making use of two computers: golf is a fairly powerful server sitting underneath a desk on one side of a crowded room. It has a lot of RAM and a nice processor in it. In addition, it has lots of X programs on it, but no monitor. On the other side of the room is couch, an old machine with little RAM and not much disk. It is way too weak to run resource-intensive programs like Netscape. couch has two major advantages, though: it has a monitor, and it is sitting right next to the couch so you don't even have to get up to use it. Ideally, you would be able to run Netscape without getting off the couch. Exporting is the answer.

First, log in to couch and start up X. Then open your favorite terminal program (xterm, rxvt, eterm, aterm, or a host of others). The first step to remotely displaying X programs is to set up the client machine so that other machines are allowed to display to the machine. This uses the xhost program to control access. If you are on a secure internal network, you probably don't care who can remotely display programs. In that case, you would just let anyone on the network display:

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

On the other hand, you might want to do this using machines that are on an insecure network (the Internet, a college network, or anything else that you don't have control over). You certainly don't want just anyone to connect. xhost allows you to be selective about who can display:

 couch$ xhost + golf.foc golf.foc being added to access control list

Now, only golf.foc (the server mentioned earlier) can display programs to couch. You can see who has access to display programs by running xhost with no arguments:

 couch$ xhost access control enabled, only authorized clients can connect INET:golf.foc INET:localhost INET:couch.foc LOCAL:

This is all you have to do to set up the client end of things. The next step is to set up the server so that it knows to display programs somewhere other than the monitor. Since the server doesn't have a monitor on it (and therefore doesn't have X running), it'll need to know where to display.

Setting up the server is not very difficult either. After connecting, you'll need to modify the $DISPLAY environment variable. By default, it will probably not be set to anything. You'll need to set $DISPLAY to the value of the remote host, plus a number that represents which X session to display to. You will almost always have only one X session running, so dealing with that variable shouldn't be an issue.

Here's how the $DISPLAY variable would be set on our example server using Bash as the shell. Other shells would use a different syntax, but the value should be the same.

 golf$ export DISPLAY=couch.foc:0.0

That's all there is to setting up the server side of things. Now you just stay logged into the server and run X programs from there. All the screen output from the program will get sent across the network to the client machine, even though it's running on a computer across the room.

 golf$ netscape &

This would run netscape off the server machine, but since the DISPLAY variable is set to couch, everything will get displayed there. You don't even have to get up to run those big X programs on your old terminal. One important note about this: the server machine will have to have all the X libraries and other support files needed to run the program. However, you won't need an X server or a /etc/XF86Config file, since nothing is getting displayed to the server.

Afterwards, you might want to disable display exporting by removing the server from your client's access control list:

 couch$ xhost - golf.foc golf.foc being removed from access control list couch$

You can see how this a great way to share computing resources. But be careful, you may be the host of many X programs for many remote computers and not even know it

From John Hinsley on Wed, 29 Mar 2000

Q: I use telnet from my Linux box at home to use the HP_UX boxes at university. No problems with telnet, but is there a way to get it to export the X display so that I can use tools other than command line ones?

John Hinsley

Short answer: Use ssh instead.

The default for telnet is to preserve a number of environment settings, including TERM, and DISPLAY. (Any recent telnet daemon should also perform some sanitization on these variables to prevent some degenerate values from being propagated through them to a potentially vulnerable program).

So, if you issue a 'set', 'env' or 'printenv' command and look you might find that your DISPLAY variable IS set. However, it's probably set to the wrong thing.

When you run 'startx' on the local system, it sets your DISPLAY variable to something like: DISPLAY=:0.0 X client programs seeing this value under Linux or UNIX will attempt to connect to the X server via a local UNIX domain socket (one of those nodes in the a filesystem whose permissions/type starts with an "s" in a "long" 'ls' output). That works for the local processes talking to the local X server.

However, to start a remote process that needs to talk to your local X server you must set the DISPLAY variable to a hostname and display number. What you need is something like


Programs that are linked against X libraries will automatically search their environment for a DISPLAY value. If it specifies a hostname or IP address, they will attempt to open a TCP connection (Internet domain socket) instead of a local file/node (UNIX domain socket) connection. Specifically they will try to connect to port 6000 for :0.0, and 6001 for ...:1.0, etc. (Incidentally, the .0 in :0.0 or localhost:0.0 refers to a possible display number. Some X servers support multiple displays/monitors, and these address each of the displays as 0.0, 0.1, 1.0, 1.1 etc).

So, one solution is to use the following sort of command (assuming that you are using a Bourne compatible shell like 'bash' which is the Linux default):

DISPLAY=your.local.hostname:0.0 telnet to.your.remote...

... this variation of the familiar syntax sets this value for the DISPLAY in the environment of the following command (that is on the same line as the assignment, and NOT separated with one of the normal command delimiters, like the semicolon).

Naturally you'd probably put this into whatever function, alias, or shell script you are using to start these telnet sessions. You could use a more portable syntax like:

DISPLAY=`hostname`:0.0 telnet ...

... where the backtick (command substitution) expression is used to fill in the blank. This will allow those shell scripts, etc to adapt to whatever system you copy them to, and will save you from having to fix all of them if you change hostname (and ISP).

Of course, these days your machine's hostname might not match anything that your ISP has set for you. So you might want to extract your IP address and use that instead of your idea of your hostname. I'll leave the extraction of your IP address from the output of the 'ifconfig' command using sh, awk, PERL, TCL or whatever, as an exercise to the reader, it's not difficult (*).

Another problem with using straight IP addresses is that you might be going through some sort of IP masquerading (NAT --- network address translation) between your local system and the remote.

There is a better way!

USE ssh!

ssh will automatically handle your DISPLAY variable for you. When you establish a remote shell session using ssh it creates it's own version of the DISPLAY variable, one which points "localhost:10" (or localhost:11, etc).

What? Yep! You read that right. Your ssh client tells the remote sshd (daemon/server) to pretend to be the "10th (or later) X server" on the remote system. The the sshd will listen for X protocol activity on TCP port 6010 (or 6011, 6012, etc) and relay that through to your local X server. This feature of ssh is called X11 port forwarding. It is completely transparent and automatic.

On top of that all the traffic between your remote X clients and your local display server is encrypted from the time it gets to the remote sshd (X proxy) until it gets to your local ssh client process. It can't be sniffed or spoofed (not without some heretofore unheard of cryptanalysis or the application of a WHOLE LOT or brute computing force).

Also, when you install and configure ssh you can put one or more public keys in the ~/.ssh/authorized_keys on each of the remote systems to which you want access. So long as you keep the corresponding private keys secure on your system, you can safely access your remote accounts without a password. It's as convenient as 'rsh' and as safe as Kerberos (possibly more so).

You can even publish one or more ssh public identities. Then anyone who wants to let you access an account on any of their systems can just add that to the authorized_keys file there. Possession of the public key can let them let you in, while not directly compromising the security of any other sites to which you have access.

On top of all that you can also use the 'scp' program as a "secure 'rcp'." That's a way to copy files to and from a remote system using basically the same syntax as a 'cp' command and without having to start up a copy of ftp or C-Kermit, etc.

It's also possible to set up ssh tunnels and run any number of common protocols through them.

There's also an ssh-agent program. This is a way of allowing you to login, start up one shell under the ssh-agent, give it your passphrase (in effect unlocking your local private key) and having all your other ssh commands in all of descendent processes, including those on remote systems all automatically use the "unlocked" key. When you exit that one ssh-agent shell or X session, you've effectively "locked" the key back up. (It's actually a rather clever hack).

Oh, yeah! That X11 forwarding trick works right through any IP masquerading, NAT, or applications proxying. It's just more traffic between your ssh client and the remote daemon multiplexed in band with the rest of your session.

It makes no sense to use rsh or telnet in the modern world. We should all switch to more secure protocols like ssh, Kerberos etc. (Ironically, the emergence of IPSec and the future of ubiquitously secure DNS may eventually make the 'net safe for plain telnet and rsh protocols. But that's a different story.)

RE: ssh exporting display

thanks for the responses:

I have no problem starting X programs and seeing them display on the remote
machine, and X11 Forwarding is on in the sshd_config.  what i am trying to do
is export the entire desktop from the server to the remote machine.

someone told me that this was possible using this series of commands:
#X :1 &
xterm -display :1
ssh (server ip)
run xsession

this doesn't work, and the version i've tried is:
#X :1 &&
xterm -display :1
ssh (server ip)
run xsession

this results in a complaint: xterm Xt error: Can't open display:

I hope all this clears up any confusion about my question, and brings us
closer to an answer.
thanks again,

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Jesse Goerz
Sent: Tuesday, August 21, 2001 8:00 AM
To: [email protected]
Subject: Re: ssh exporting display

On Tuesday 21 August 2001 02:57, Adam Ingram-Goble wrote:
> Hi all!
> 	I'm having trouble and after exhausting everything else i could think of
> i'm asking it here.  I want to use ssh to login to my homeserver, and
> export an xsession to my laptop.  when i execute startx, it doesn't throw
> any errors, and i can see in top that the gnome login got started just
> fine, but all i see on the laptop is the xfree setup messages scrolling
> by.  i have no idea how to approach this problem because i've tried #
> export
> DISPLAY=(laptop):1 in addition to just trying # startx, but i get no
> *love*.....
> any help/direction on resolving this is appreciated.  note that i am
> this from the console (outside of X on my laptop....gdm is disabled so i
> boot to text).
> thanks
> adam

Is X Forwarding allowed on your server?  I believe it's off by default. Check
/etc/ssh/sshd_config on your server.

Exporting display

> The second user needs to know both the display ($DISPLAY), and have
> xauth access to it. Again assuming :0 is your active session:
> o User 2 runs: export DISPLAY=:0
> o User 1 queries xauth: "xauth list | grep :0"
> o User 2 adds this display to their xauth list. I'd suggest cut and
> paste through the X Windows clipboard:
> xauth add <xauth cookie for display :1>"

For more information: man xauth.

I personally prefer sudo (apt-get install sudo), put yourself into /etc/sudoers as:

your-user-name ALL=(ALL) ALL

That way you can launch _any_ program as root from an user X-session.
You could be more restrictive with your permissions if you don't need
more than a few commands as root.

What to Do with X By Sandra Henry-Stocker

In a University of Maryland class, circa 1979, I first heard about windows (with respect to computers, of course). At that time, most computers, when you logged into them, looked like ASCII terminals - no Windows (notice the capitalization). The idea of having multiple active sessions on a single screen was fascinating. When I first encountered the X Windowing System, many years later, I realized the concept had taken a great leap forward. The windows could be running on many different systems and sending their displays to my local screen.

These days, my company mandated PC runs, not only Windows NT but also X Windowing System software (Exceed - Currently, my PC monitor stands in for my SPARCstation 20 (with its still dead frame buffer). As much as I've watched the evolution from low res screen fonts to crisp images and international alphabets, I am still somewhat amazed, and a bit disoriented, by the conjunction of multiple systems sharing a single screen and a single keyboard.

The particular setup I employ involves a series of telnet sessions and Xterms vying for my attention, plus a couple of desktop tools residing on the NT box. I quickly found I had to use color and window banners to remind me which window was connected to which system. My favorite Exceed command is now:

DISPLAY=;export DISPLAY;/usr/openwin/bin/xterm -ls -sl 2000 -sb -bg darkblue -fg white -fn 9x15 -title boson &

This command gives me a pleasant blue xterm with a label and a readable font.

Exceed seems to take care of the xhost+ command I would normally run on one Unix system to allow another to use its display. The command above, which is run on the SS20 (i.e., the Unix system with a non- working monitor), sets its display to the PC and starts an xterm window with the proper display characteristics.

Of course, xterms are just the beginning of what you can do with your X server. You can run all of the typical desktop tools -- like File Manager, Image Tool, and the like. Once you have enough tools running on your PC, it becomes even more difficult to remember that the system serving up the windows is not running Unix. I may even have trouble deciding what to run on my Sun monitor and what to run on my PC monitor when the refurbished frame buffer arrives to breathe life back into my Sun monitor. Going back to two keyboards and two screens might seem like more of an annoyance than a benefit.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


  1. Remote X
  2. Configuring and Troubleshooting X
  3. Installing and Upgrading X

Recommended Papers

Created May 28, 1998
Last updated June 18, 2000
Development stage: Alpha


  1. Set DISPLAY variable (set DISPLAY="")
  2. Allow hosts to connect to your X server (xhost
  3. Start up a font server on the server side by typing xfs &.
  4. If you need to, set the address of the font server on the client side.
  5. On a terminal (telnet, ssh, rsh) on the remote host, type in the name of the program you want to run (gimp, netscape, and xv are a few).

This page is going to help you run X programs on another computer, but display it on your X session. This is especially helpful if you have a slow machine on your LAN or want to display X applications on a Windows machine.

I've been bugged and bugged and bugged by people who cry out about the security problems with this, from problems with xhost to lack of encryption--but note that this is intended for a home network. I will try to point out what you should do if you are very concerned about security even in a home environment.

Client Side (X Server Side) Configuration

On your client side (the computer you want to display and use the program) you need something that allows the display of X programs. On a Linux/Unix machine you'll probably just need to have something like XFree86 or MetroX; any standard X server will do, as long as it displays and starts up fine on your computer. If it's a Windows machine, you need to download an X server. Two that I know of are XWin32 and MI/X. You can look for more at Tucows, under server daemons, I think.

You should allow connections from the server side so that the programs can display. If you're using Unix/Linux on the client side, that can be done by typing xhost +server.side, to allow the hostname "server.side" to connect. You'll probably need to change the hostname to whatever the hostname of your Linux box is. With ssh you can just connect to the server and type the name of the program without setting xhost or $DISPLAY. I think it works by exporting the DISPLAY variable and automatically setting xhost to allow applications to be run from the server side. If $DISPLAY isn't set on the client side, I don't think it will be exported to the server side so that applications display on your screen. Thanks to Todd Cohen for pointing this out. If anyone can provide more information on this please let me know.

If you're using XWin32 you need to set Options -> XHost to the IP address of the machine with the X applications in XUtil32. With MI/X I don't recall having to set the host but my memory isn't fresh.

Font Setup

If the fonts that came with your X server don't work or you want to use the server side fonts, then set the font server to be the hostname of the server on port 7100. In XWin32 it's in XUtil32's Fonts -> Path dialog box; click on "Add Font Server" and in place of "xfs" use the hostname or IP address of the font server. For me I had the font server point to on port 7100. If you're using a Linux/Unix box as your client, I'm not sure but I think you can use the command line xset +fp, if is the font server. If that command works for anybody, let me know.

A font server must be running on the server side. Read on to find out how to start it up.

Let me know if you find something useful to add to the information here.

Server Side Configuration

While on the server side (the machine that has the programs that you want to run), set and export the $DISPLAY variable by typing export DISPLAY="client.side:0". You can get into the server machine using telnet, rsh, or ssh.

If you're using a shell other than "bash" on the server side, set the variable accordingly. Most standard Linux distributions now use "bash".


To have the fonts that are on your X server be used on the client side, you should start up a program called xfs as root. That's the X font server.

To have the X font server started up everytime you boot up your system, just put the path to the xfs executable in /etc/rc.d/rc.local. On my system, xfs is in /usr/X11R6/bin/xfs, so I have the line "/usr/X11R6/bin/xfs &" in /etc/rc.d/rc.local. The ampersand ("&") makes it a background process so that it doesn't tie up the server side by running in the foreground and preventing other tasks from being done.

Running the Program

After the client and server side setup, you should be able to run any program for X. You can try programs such as "xv", "xbill", or "netscape". They should run and display on the client side.

Author's Notes

Running remote X sessions through a standard dialup connection to the Internet is very slow. It will still work, but it's just way too slow.

MI/X seems to have trouble with fonts on my brother's Windows 95 system. It is missing some fonts that are commonly used, so "xgalaga" and "gimp" (as well as other Gtk+ applications) won't run. Instead, I just use XWin32, although that takes a while to start up and is crippleware (2 hour session limit). You also can't use it on more than one machine (node) on your network at the same time.

When saving files, you have to save them on the server side.

Related Pages

Configuring and Troubleshooting X

Last modified: July 16, 1999
Development stage: Beta

This section is guaranteed to be long, so if you want to read the whole thing, it's your choice. This includes just some basic things for Red Hat 5.2, based on XFree86 version This information should also work for other Linux distributions.

I'm assuming you already have XFree86 installed, along with its libraries. If not, install them. In Red Hat, TurboLinux, Mandrake, SuSE, and Stampede, they come in RPM files that start with "XFree86". If you want to install the files from the tarred and gzipped form, read Upgrading and Installing X.

  1. What's an X Server?
  2. Configuring X
  3. A Common Error Message
  4. The Infamous Gray Screen
  5. Alias to Start X
  6. Turning Off Virtual Desktop
  7. Additional Fonts
  8. Mouse Trouble
  9. Newer Cards

What's an X Server?

An X server is sort of like a video driver (that's the best I can explain it...) that the system uses to run the graphical user interface. There are too many changing X servers to list here, but there are SVGA, VGA, and Monochrome, which are the most basic. There are also commercial X servers which I know virtually nothing about.

The X server you choose to use depends on the type of chip your video card uses to process graphics. It also determines how many colors will be displayed in X (the amount of video memory you have also determines that). When you key in startx and the error under "A Common Error Message" appears, you should make sure that you installed the server that you configured for.

The X server I used was the S3V. That stands for S3 ViRGE, since my Diamond Stealth 3D 2000 used that chip. When I got a Creative Labs Graphics Blaster Riva TNT (PCI), I switched to the SVGA server because the SVGA server was the one that had support for the Riva TNT chipset.

Configuring X

If there is any kind of error given when you execute the startx script, you probably should run Xconfigurator or xf86config. These will configure the keyboard, the mouse, the video card, the monitor, and some other stuff so that X will run properly. The settings are stored in a file called XF86Config. On my system, it's in /etc/X11/XF86Config. You can edit that with a text editor such as pico, vi, joe, jed, or emacs.

A lot of people have trouble configuring X, especially beginners and long-time text mode users. The best thing to do when there are no manuals available is to guess. It might take a few hundred tries, but using defaults will usually get you by. For example, I didn't know which RAMDAC and Clockchip setting to use when eventually I read the little comments/tips on the screen and decided to try not using a RAMDAC or Clockchip setting for my card. It turns out that I wasn't supposed to use those settings in the first place.

It will help you greatly if you know your hardware settings or have your hardware manuals handy. If not, experiment.

A Common Error Message

The following error message is very common among new users, and often very confusing as well:

_X11TransSocketUNIXConnect: Can't connect: errno = 111
giving up.
xinit:  Connection refused (errno 111):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.

Solution One

One solution to this is to install the server you chose for your video card's chipset (the type and brand of chip it uses to process video information). In Red Hat, you install the RPM package that describes which server it is by the first few characters in its filename. The common X servers are as following, with their RPM package filenames in parentheses:

To avoid as much trouble as possible, install these RPM packages if you're using Red Hat.

  1. XFree86-3.3.2-8.i386.rpm - XFree86
  2. XFree86-devel-3.3.2-8.i386.rpm - Lets you compile stuff
  3. XFree86-libs-3.3.2-8.i386.rpm - X libraries
  4. XFree86-SVGA-3.3.2-8.i386.rpm - 256 color X server
  5. XFree86-100dpi-fonts-3.3.2-8.i386.rpm - Fonts
  6. XFree86-75dpi-fonts-3.3.2-8.i386.rpm - Fonts
  7. Xconfigurator-3.57-2.i386.rpm - Helps with configuring X

For more information on installing and upgrading X, you might want to read Installing and Upgrading X.

If you want to run at more than 256 colors use another X server that is made especially for the type of chip that's on your video card. The special X servers are made for the newer PCI video cards, but ISA graphics accelerator cards could possibly also use the special X servers.

Solution Two

Another possible cause for the "_X11TransSocketUNIXConnect" error is that the mode that is chosen (or the mode that you set it to) is not valid. This can be because of monitor settings that are too high or too low for your video card. I discovered this when I set my monitor's hsync (horizontal sync) and vsync (vertical sync) ranges to settings that were too high, although I had the proper X server for my card. Then I tried them really low, and then I was allowed into X--but the resolution was very low. I finally decided on something in the middle and that seemed to work.

Those monitor settings (hsync and vsync ranges I think) will also have an effect on what resolution you can run at. Again, setting those too low will get X to make you run at a very low resolution, so that everything looks huge and blocky. Try entering your own ranges if your monitor manual has the settings. You can also select what type of monitor you have from XFree86's list of monitors. My MAG Innovision DX15T was not listed but something close was, the DX1595, and it had the exact hsync and vsync ranges that my monitor had (when I finally found it in the manual).

Otherwise, you can try the lowest setting and work your way up, try the highest setting and work your way down, or choose something in the middle and see if your monitor supports it. Be careful: if the setting you choose is too high, you could seriously damage your monitor.

The Infamous Gray Screen

Many people encounter the problem of starting X (startx), seeing an X-shaped mouse-pointer-thingy, a gray screen, and being taken back to text mode with no window manager loading and no error messages. If it doesn't take you back to text mode, try the Ctrl-Alt-[Backspace] combination.

The way I found I could solve this was to create a .xinitrc in my home directory and putting the line exec afterstep in it. That seemed to work fine and it loaded the AfterStep window manager. As you can probably figure out, you'll have to replace afterstep with whatever window manager you're using. If I wanted to use fvwm, I'd put in exec fvwm instead.

Now suppose you want to run multiple window managers; of course, you can run only one at a time in each X session, but you don't want to type everything in again. The solution is to type in the startup lines of each window manager then comment out all the ones that you don't want to use, leaving one line uncommented so that it'll run. Here's how my .xinitrc file looks like:

# exec afterstep
# exec fvwm95-2
if [ -f $HOME/GNUstep/Library/WindowMaker/.workspace_state ]; then
	sh $HOME/GNUstep/Library/WindowMaker/.workspace_state &
exec wmaker

That is set to run WindowMaker when I start up, and the commented lines, the ones with the pound signs (#) at the beginning of the lines, are ignored. If you leave everything commented out, it'll give you the gray screen with the X-shaped mouse, so if that happens, you should know what to look for. :)

Alias to Start X

On my system, I start X by typing x at the prompt, and it starts up in 24 bits per pixel mode when I do that. I can type startx -- -bpp 24, but that takes time to type up. I can do this because I added a line to /etc/bashrc that goes like this:

alias x='startx -- -bpp 24'

Of course, if you prefer to run at some other video mode other than 24 bits per pixel (16.7 million colors, I think) then you would replace "24" with 15, 16, 32, or whatever you may wish to run as the default.

With Slackware, you might have to edit /etc/profile instead of /etc/bashrc if it doesn't look in /etc/bashrc when a user logs in. I don't think aliases are supposed to go in /etc/profile, but it works.

Turning Off Virtual Desktop

XFree86 usually annoys new users with something called virtual desktop. This can be described as a screen bigger than the one displayed, so that when a user moves the mouse to the edge of the screen, it scrolls down instead of staying there.

Only after using Linux for a year did I discover how to turn that off. Yeah, it gives me more desktop space, but as new users frequently complain, it's annoying. :)

Anyway, the way I turned it off was by finally finding the right place to edit in the /etc/X11/XF86Config file. The following is the area that you should edit:

Section "Screen"
    Driver      "accel"
    Device      "Diamond Stealth 3D 2000"
    Monitor     "My Monitor"
    Subsection "Display"
        Depth       8
        Modes       "800x600"
        ViewPort    0 0
        Virtual     800 600
    Subsection "Display"
        Depth       16
        Modes       "800x600"
        ViewPort    0 0
        Virtual     800 600
    Subsection "Display"
        Depth       24
        Modes       "800x600" "640x480"
        ViewPort    0 0
        Virtual     800 600
    Subsection "Display"
        Depth       32
        Modes       "800x600" "640x480"
        ViewPort    0 0
        Virtual     800 600

This can be found towards the end of the file. At first I heard of people editing this file and successfully getting the results that they wanted; I tried it, but I edited the wrong part of the file and that didn't make a difference at all.

Anyway, the way I got rid of my virtual desktop was to set it to be the same resolution as the resolution I was running at. In my case that was 800 by 600 (all modes from 8 bpp to 32 bpp). You can also try commenting out the lines starting with "Virtual" by putting a pound sign (#) at the beginning of the line.

Additional Fonts

Most people might not be satisfied with the fonts included with the standard distribution of X, so if you're one of them, read Zach Beane's tutorial on adding fonts to X.

The fonts themselves are available from They're scalable Adobe Type1 fonts, which means that they won't get jagged when enlarged to large font sizes.

You can also get a couple of packages containing fonts from They're the .tar.gz files.

With Zach Beane's tutorial, it's also possible to add other types of fonts, such as 75dpi and 100dpi.

Mouse Trouble

There are a lot of possible problems people might encounter with mice. Just make sure you have it pointing to the correct device (usually /dev/ttyS0, which is COM1 under DOS and Windows) when the X configuration utility that you use (xf86config, Xconfigurator, etc.) asks you where your mouse is. If you have a PS/2 mouse, use /dev/psaux.

If you want to edit /etc/X11/XF86Config, look under the section "Pointer". Here's what it looks like:

Section "Pointer"
    Protocol    "Microsoft"
    Device      "/dev/ttyS0"

If it's on another device, such as COM2 under DOS, it would be /dev/ttyS1. COM3 under DOS/Windows would then be /dev/ttyS2, and so on.

andres salomon wrote in to say that if your PS/2 mouse doesn't work in X but works in normal text mode, you should try killing the GPM mouse services (killall gpm as root should do the trick). He also mentioned a workaround, which he didn't successfully use. It's adding /dev/gpmdata to /etc/X11/XF86Config, supposedly, and starting GPM with the "-R" flag.

Fotis Karpenissiotis wrote, "I had several problems using a Microsoft Mouse (Serial Mouse 2.0A) under XFree86 3.3.2. (Under 3.3.1 it worked fine). The solution I found was to start gpm using:

gpm -t ms -R

and the following lines in XF86Config:

Section "Pointer"
       Protocol    "MouseSystems"
       Device      "/dev/gpmdata"

That's about all the information I can give about mouse trouble and their solutions right now, but if you've got a different problem and a different solution then please let me know.

Newer Cards

Dragoon and Larry Elmore wrote in with tips reminding those of us with newer cards to head over to SuSE creates a Linux distribution, but they also create X servers for video cards/chipsets that XFree86 has not included yet. The XFree86 Project only releases new X servers every six months, so in that time span in between, SuSE releases stuff. It's worth checking out if you're not having much luck with that new video card and X.

If you have anything from NVidia, find their Open Source XFree86 patches/modifications on their website at This includes support for cards with Riva TNT and Riva TNT2.

If you can't find an X server for your card using any of the above methods, just about the last thing you can try is going to your card or chipset maker's website. Unfortunately, some video card companies do not like to cooperate with the XFree86 project.

Send any and all feeback to [email protected]. Feedback is welcome and highly encouraged. You can also make use of the help form or guestbook, which is really more like a feedback form.

Installing and Upgrading X

Last updated: September 17, 1999
Development stage: Beta

When Linux users refer to X, they mean the graphical interface for Unix systems. More information about XFree86 (a free implementation of X) is at You need to be in X in order to run many graphical applications. It is what you would use to create the equivalent of a Windows desktop under Linux.

The subject of writing here is XFree86, the "new" version at the time of the last major update. There are various reasons one would want to upgrade their version of X. The latest release might have better hardware support. Alternatively, one might want the updated X applications and libraries. Lastly, it could be that some people do not feel comfortable when they are not using the latest version of a software package. If you do not have X installed, this is also the page to read.

The first step to upgrade your version of X is to back up your old one, just in case the procedure on this page does not work. (If you do not have enough disk space nor want to go through the trouble, there is really no need to worry about it. It is just a good habit to develop). You can do this by changing your working directory to /usr/X11R6 which should work in most systems. Your system might be different, but that is the way it is laid out on my machine.

If you do not have X installed yet, just create an X11R6 directory as a subdirectory in /usr/.

This is how your X directory (/usr/X11R6/ in most systems) should look like if you already have X installed:


To back it up, I suggest you tar and gzip them into one file and keep it in there. On my system, I named it x11r6.old.tar.gz to make it easy to tell what it contains later on. I did that by typing this in /usr/X11R6:

# tar -czvf x11r6.old.tar.gz bin doc include lib man

Running Multiple Sessions of X

Created on December 11, 1997
Last updated: October 3, 1998

I think this is very, very neat. I got it off of Linux Gazette Issue 23. Let me know if it works for you.

I would think that a lot of people would want to know how to run multiple X sessions; sometimes you have a different user who wants to log in and use X, but you're tied up downloading the newest version of WindowMaker with Netscape inside your own X session. Or something like that.

The solution? Run multiple X sessions. This can be done with only a few extensions to your command line. For your first X session, all you had to do was type startx, or if you run in high color mode like I do, you might have to type startx -- -bpp 24. That defaults to running it on screen 0, which is really your first X session.

What you want to do is make X run in screen 1 for the second, screen 2 for the third, screen 3 for the fourth, and so on. Here's how you would start a second X session:

startx -- :1

Now, if you run in high color mode, you would enter the proper paramaters after the :1 part of the command line. If you wanted to run in 24 bits per pixel (16.7 million colors), you would type startx -- :1 -bpp 24 as your full command line.

If you want to start yet another X session, a third one, you would type startx -- :2 and startx -- :2 -bpp 24 for 24 bit color. After that, you would use the numbers 3, 4, and 5 for additional X sessions.

Switching Between X Screens

You probably have a default number of 6 virtual consoles. Those are how many logins you can have in plain text mode, basically. If you have F12, you would probably have 6 "empty" screens if you're not running X.

Your first X session, as you may already know, is accessible by pressing Alt-F7 (use the left Alt key). For your second, it's Alt-F8. For the third, Alt-F9, and so on. This is what you would do to switch from text mode to an X screen.

If you want to switch from one X screen to another, you'll have to use Ctrl-Alt and then whatever F-key you'd normally use. For example, if you want to access X screen number 3, you'd press Ctrl-Alt-F9 from an existing X session. From text mode, you'd only have to press Alt-F9.


Tim Briggs previously sent in an e-mail concerning his frustration starting more than one X. He included it with a script, but then he sent in another version which is much cleaner and has a few improvements over his old one, which was previously posted here.


if [ $# -eq 0 ]      # check to see if arguements are given (color depth)
       then a=16    # default color depth
        else a=$1    # use given arguement

if [ $a -ne 8 -a $a -ne 16 -a $a -ne 24 ]
                echo "Invalid color depth. Use 8, 16, or 24."
        exit 1

for display in 0 1 2 3 4 5    # checks for open display, starts X on next available
        if [ ! -f "/tmp/.X$display-lock" ]
                        exec startx -- :$display -bpp $a
echo "No displays available."
exit 1

The way I manage multiple X seesions is put stuff in alias form in /etc/bashrc. You'll probably want to use Tim Brigg's script.

alias x="startx -- -bpp 24 -quiet &"
alias x2="startx -- :1 -bpp 24 -quiet &"
alias x3="startx -- :2 -bpp 24 -quiet &"
alias x4="startx -- :3 -bpp 24 -quiet &"
alias x5="startx -- :4 -bpp 24 -quiet &"
alias x6="startx -- :5 -bpp 24 -quiet &"

If you want to, go ahead and copy that to paste in your /etc/bashrc. You'll need to log out and log in again for the changes to take effect after changing that, and from then on those aliases will be carried in to all new logins.

When I type x it starts up my first X session. Then it starts up to 5 more X sessions. The first one is referred to as session 0, although it's actually number one. That's fairly common in Unix.

It's also worth noting that I put the ampersand ("&") at the end of the startx command line in order to make it run in the background. That way it frees up a text mode console for me instead of keeping it and making me log in again on another virtual terminal.


KOI-8 Step-By-Step for the X Window System



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: February 10, 2021