Guide to X11/Starting Sessions

From Wikibooks, open books for an open world
Jump to navigation Jump to search

Authors · History · Print · License

Introduction · Configuring · Building · Starting Sessions · Starting Programs · Fonts · Window Managers · Xt Clients · Political History · References and Links

Supplements: Commands

Edit this template

Starting Sessions[edit | edit source]

This chapter describes how to start an X11 session.

This chapter will answer the following questions:

  • What are the different methods for starting X11?
  • How does one start X11 and a window manager?
  • How does one control which window manager and programs will start?
  • Is there a way to make fonts appear nicer?

Methods to start X11[edit | edit source]

Recall that X11 consists of an X server and several clients. If you only start the X server, you obtain a blank screen. What one needs is a way to start the X server plus some default clients such as a window manager.

First, some Unix consoles give a text-only login prompt. In this case, first login as normal to obtain your Unix shell, then use a xinit or startx command to start the X server and default clients at your shell.

Second, some Unix consoles have a graphical login prompt! In this case, the system boot scripts have started an X server already; a program called the display manager has drawn a graphical user interface that lets you type a username and password. In this case, when you login, you start using X11 immediately.

Third, some systems are using a graphical environment that is not X11. For example, Mac OS X has its native Quartz system. In Mac OS X, you start the X11.app program, which is an X server that lets X clients appear on the same desktop as your other Mac programs. Similar programs exist for Microsoft Windows (which is not a Unix platform).

xinit and startx[edit | edit source]

There is a program startx, which launches X11. It is simple to use:

$ startx

This gives you some default environment. However, if you want to customise your default environment, using xinit might be easier. The startx script looks for several files (~/.Xresources, ~/.Xmodmap, ...) and loads them; the files it uses are different on each system, so you might have to read the startx script on your system to understand what it does.

In contrast, the xinit program only starts an X server and runs a ~/.xinitrc script. There is no need to remember whether your system calls it ".Xresources" or ".xresources" or ".xrdb"; you can simply specify the exact behavior that you want in your "~/.xinitrc".

Using xinit without an .xinitrc[edit | edit source]

If you broke your ".xinitrc", or do not have one yet, then you can start one. For example:

these will work
$ xinit /usr/X11R6/bin/xterm
$ xinit $(which xterm)
this will NOT work
$ xinit xterm

This will start an X server and the program called "xterm", which you can use to start more X clients. The last line fails (even if "xterm" is in your PATH) because xinit assumes that it is an argument, not a program. You must have a slash / somewhere in the name of the program.

If you have KDE, you can find your startkde script:

$ which startkde
/usr/local/bin/startkde

Then you can start KDE:

$ xinit /usr/local/bin/startkde

This will let you use Konqueror to find your ".xinitrc" and Kate to edit it. (When browsing your home directory, check "Show Hidden Files" in the View menu.)

If you see a message like:

$ xinit
/bin/ksh: xinit: not found

...then you need to add /usr/X11R6/bin to your PATH environment variable.

How to write .xinitrc[edit | edit source]

If you do not specify a program with a slash, then "xinit" uses your .xinitrc script in your home directory.

$ xinit            # starts .xinitrc
$ xinit xterm      # passes "xterm" as argument to .xinitrc

Before using "xinit", one needs a file called .xinitrc in their home directory. Because the filename starts with a dot, the file is normally invisible. There are ways to handle invisible files from the shell:

$ cd               # changes current directory to home directory
$ ls -a            # list all files, including dotfiles
$ ls .xinitrc      # list the .xinitrc file
$ vi .xinitrc      # edit .xinitrc using vi
$ emacs .xinitrc   # edit it using Emacs

An ".xinitrc" is simply a Bourne shell script. You could try running it with sh .xinitrc, but it would fail unless you already started the X server. You put in commands like you would type at the Unix shell. If you fail to understand this, try starting with the examples below.

Here is a simple, one-line example of an ".xinitrc":

exec startkde

A "startkde" command starts the KDE desktop environment. This command does not finish until you logout of KDE. Normally the shell would wait for KDE to finish, then run the next command. The "exec" prefix to this command tells the shell that this is the last command, so the shell does not need to wait to run a next command. The "exec" is optional in this case.

Here is a more complex example of an ".xinitrc":

ulimit -Sn 512
/usr/bin/mixerctl monitor.master=5,5
/usr/X11R6/bin/xmodmap -e 'keycode 107 = BackSpace'
case "$#" in
0)
  exec sh /etc/X11/xinit/xinitrc
  ;;
*)
  session="$1"
  shift
  exec "$session" "$@"
 ;;
esac

# NOTREACHED
exec /usr/X11R6/bin/xterm

The first line, "ulimit -Sn 512", is a Bourne shell command to increase the soft limit "-S" on open files "-n" to 512. (Use ulimit -a, or if your shell is not a Bourne shell, use sh -c 'ulimit -a' , to see your default limit.) The next command, /usr/bin/mixerctl monitor.master=5,5, sets the sound volume on a OpenBSD or NetBSD system to 5 on both the left and right channels. On other Unix systems, the command will be different. There are many other commands that one could add.

The third line, "/usr/X11R6/bin/xmodmap -e 'keycode 107 = BackSpace'" (or just "xmodmap -e 'keycode 107 = BackSpace'"), adjusts the keymap. For users that only make a few adjustments, this might by easier than loading a .Xmodmap file. (You can load such a file with xmodmap ~/.Xmodmap.)

The remaining lines form a Bourne Shell "case" statement. These process the command-line arguments to enable the following:

$ xinit gnome-session # start GNOME
$ xinit startkde,GNOME # start KDE
$ xinit fvwm,KDE# start window manager fvwm
$ xinit xtermfvwm       # start an xterm without a window manager

Note that because none of the programs have a slash in them, they are handled by the ".xinitrc" script, not directly by "xinit".

xdm[edit | edit source]

Example ~/.xsession:

. ~/.profile

managers=startkde,fvwm,wmaker
prompt="Welcome, $USER@$(hostname), select window manager:"

# miscellaneous setup
xmodmap -e 'keycode 107 = BackSpace'
test -f /usr/local/GNUstep/System/Makefiles/GNUstep.sh &&
        . /usr/local/GNUstep/System/Makefiles/GNUstep.sh

manager="$(xmessage -buttons "$managers" -print -center "$prompt")"
test -z "$manager" && exec fvwm
exec "$manager"

Making screenshots[edit | edit source]

The standard utility to dump an image of an X Window is xwd(1), xwd produces an XWD image. It can be invoked in the following way:

xwd -root -out root.xwd

xwd can also be used to dump a single window selected with the mouse or provided with the -id option followed by the corresponding window id; for further info see man 1 xwd [1]. When run remotely, xwd is useful for taking screen shots of modal menus in action. The GIMP can be used to convert an XWD file to other more common formats such as PNG; equivalently, the command-line utility xwdtopnm, part of the Netpbm utility suite, can be used to convert the XWD file to PNM format, from which it can be converted to any common format, for example with the following pipeline:

xwd | xwdtopnm | pnmtopng > screendump.png

It is also possible to convert an XWD image into many other formats using the convert utility (available here): convert root.xwd root.XYZ, where XYZ is a typical filename-extension for a desired format.