Cmpt 471 An Introduction to X January 12, 2001

An Introduction to the X Window System

❅ You might ask “Why are we starting a networking course by exploring the operation of the X Window System?”

❆ First, you’ll have better control over your work environment if you un- derstand how X Windows is organised. ❆ Second, you’ll be required to perform a number of basic system admin- istration tasks during the course of the semester. If you understand how X Windows is integrated into the startup sequence of Linux, it’ll make life just that much easier. ❆ Third, the X Window System is a neat networked application, and you might want to play with it at some later time.

❅ You’ve almost certainly heard about X Windows, and likely used a computer which uses X to provide a graphical user interface (GUI) on the console. But what, exactly, is X Windows, and how does it work?

❅ The foundation of the X Window System is the X procotol. It’s a communi- cations protocol that’s specialised for the activities associated with a GUI — creating windows, presenting graphical and textual output, and reacting to keyboard and mouse input.

❅ The X protocol can run over any transmission medium that provides a re- liable byte stream. In the Unix world, the medium is usually one of the interprocess communication mechanisms (pipes, shared memory) available to two processes running on the same host, or a TCP connection over a network.

❅ The X Window System uses a client-server architecture. Clients are applica- tion programs, and the server is the X server.

X protocol

display application X Server keyboard (client) (server) mouse

hardware hardware independent dependent

1 Cmpt 471 An Introduction to X January 12, 2001

As far as the client is concerned, all it needs to do is exchange messages with the X server using the (mostly) hardware-independent X protocol. (Some details, such as colour capability, screen size, etc., are not hidden because doing so would make the server much more complicated and make it difificult for the client to control the screen presentation.) Conceptually, the X server has two layers. A hardware-independent layer handles communication with the client using the X protocol. A hardware- dependent layer takes care of translating X protocol messages into the proper commands for the specific graphics hardware, and translates key and button presses into messages to be sent to the client.

❅ In a more general context, the X server can handle communication with many different applications, and the applications can be running on the computer which is physically connected to the display, or they can be run- ning on other computers which can establish a network connection to the computer which has the display. Here’s a picture:

2 Cmpt 471 An Introduction to X January 12, 2001

application application #2 #1

display TCP/IP X Server protocol keyboard (server) stack mouse

local applications can use interprocess application communication #3 HostA network

remote applications communicate with the server over the network

HostB

TCP/IP application protocol #4 stack

The important point is that the application can run on any host that can establish a connection to the X server, and the output will appear on the display controlled by that X server. It’s also worth noting that if there are multiple displays attached to a host, a single X server process can manage all of them. Each display is identified by a number, starting from 0.

❅ To ease the work of programming applications, there are supporting libraries. A typical application would have three layers:

3 Cmpt 471 An Introduction to X January 12, 2001

application code

toolkit library

Xlib library

to X server

Code that implements the application function sits in the top layer. When it needs to create objects (windows, scroll bars, buttons, etc.), it calls subrou- tines in the toolkit library. These subroutines are often tailored to provide a uniform ‘look and feel’ to GUI objects created with the toolkit. Subrou- tines in the toolkit in turn call subroutines in Xlib to perform the primitive operations of the X protocol. ❅ Now, if you start to think about the interaction of the clients and the X server, you’ll no doubt start to have some questions. ❅ “How does the application find the X server?” In a Unix environment, there are two common ways of telling the application how to connect to the X server. One is by setting an environment variable, DISPLAY, and the other is by starting the application with a command line parameter (which would override the value of DISPLAY). For an application running on the same host as the display (and the X server which controls the display) it’s a matter of using whatever mechanisms are available for interprocess communication (a named pipe, for instance). When specifying the local display, the host name can be omitted. For example, :0 specifies display 0 on the local host, by convention the workstation console. (And, since this is the default, you don’t actually have to set anything to get your application to place a window on the workstation console.) If the application is to connect to the X server on some other host, it needs to be told the host name and display number. To tell an application running on HostB to use display 0 on HostA, you must set the DISPLAY variable to HostA:0, or provide the same information as a command line parameter. The X server listens at a well-known port number (6000 + N, where N is the number of the display), and this, together with the host name, gives the application enough information to establish a TCP connection to the remote X server. ❅ “Given that all the applications were written independently, and may be com- pletely unaware of each other, who coordinates their actions on the display?” The first thing to say is “not the X server.”

4 Cmpt 471 An Introduction to X January 12, 2001

Coordinating the actions of the windows on the display is the job of the window manager. It’s the window manager that provides functions such as resizing a window, moving it around on the screen, etc., with a uniform ‘look and feel’. Otherwise, each application would need to provide this functional- ity, and it would vary from application to application depending on the whims and preferences of the person who wrote the application. If you want to get a good picture of just what services the window manager provides, as opposed to what the X server provides, try the ‘Failsafe’ session thenexttimethatyoulogintoaworkstation.Thisisasinglexterm window displayed by the X server, with no window manager present. But the window manager is just another X application, talking to the X server. Which begs the next question . . .

❅ “How does the window manager actually coordinate the activities of the win- dows on the screen?” Simplified, the X server provides two capabilities, redirection and reparent- ing. Redirection allows a client which wants to act as a window manager to in- struct the X server to redirect certain X protocol requests to the window manager without acting on them. In particular, these are requests which would change the window configuration on the screen — window creation, resize, front/back, etc. The window manager examines these requests, alters them (if necessary) to conform to the look and feel of the window manager, and then sends the request back to the X server for action. If the original application needs to be notified of the result, the X server will send it an appropriate message. Reparenting means that when the X server forwards a window creation re- quest to the window manager, the window manager will create a new window (often called the window frame, or decoration) and enclose your window in the frame. The frame provides the things you expect the window manager to provide — a title bar, menu buttons, resize handles, etc.

❅ For example, here’s the sequence of events when you resize a window using the mouse. You place the mouse on the region of the window frame that’s used for resiz- ing the window. The X server sees the button presses, and because they’re in the frame region it relays them to the window manager. The window manager sends instructions to the X server to enlarge the window frame to the appropriate size. It also instructs the X server to send an event to the application, telling it to enlarge its window and redraw the contents to fit the

5 Cmpt 471 An Introduction to X January 12, 2001

new size. The application is expected to cooperate and respond in a timely manner. ❅ Admittedly the boundaries are a bit fuzzy, but the net effect of all this is that an X application written to conform to standards (notably, the Inter- Client Communication Conventions standard) can run under pretty much any window manager that observes the same standards, though the decora- tion supplied by the window manager might clash with the style of the toolkit used by the application. ❅ A final question is “What protection do I have from accidental or malicious misuse of my local display?” The short answer is “not much, typically.” The X server is typically configured to allow connections on a host by host basis. If you want an application on HostB to be allowed to display a window on your display on HostA, you need to tell the X server that it should accept connections from applications on HostB (using the xhost command). But this opens the way for any application on HostB, not just the one that you’re running. If malicious abuse is a worry, there are some additional possibilities, though they are less convenient than the more open host-based mechanism. And X protocol messages are not normally encrypted, so there’s always the possi- bility of snooping and spoofing. Typically, the host-based system is sufificient in the absence of malicious intent, since the whole point of running an application is to see the result. It doesn’t make much sense to send the window to a display other than the one you’re sitting at. ❅ It’s also important to keep in mind that communication by X protocol be- tween computers is not encrypted. Anyone who can listen to a network link and who understands the X protocol can monitor protocol interactions and delete, modify, or add messages. ❆ If you’re looking for better protection when running X protocol on a network, you should look at ssh, the secure remote shell, and related commands. ❆ ssh allows you to make a secure connection to a remote computer. It encrypts everything, including the initial exchange of id and password which authenticates you to the remote host. ❆ Later, if you start an application on the remote host which opens an X protocol connection back to your local host, the exchange of X protocol messages is encrypted and tunnelled through the secure connection.

6 Cmpt 471 An Introduction to X January 12, 2001

Controlling Your X Environment

❅ Now that you know how the X Window System works, it’s time to consider how it’s integrated with the unix login sequence.

❅ Recall that we were looking at a line in /etc/inittab, and that line was about to start a program called /etc/X11/prefdm to monitor for activity on virtual console 7.

❆ If you go to /etc/X11 and use ‘ls -l’onprefdm, you’ll see that it’s actually a symbolic link to gdm, the Gnome Display Manager. ❆ Most unix systems have several options for display managers. For our Linux system, check /etc/rc.d/rc.sysinit to see the alternatives and how this link is established. The actions described below are typical for any X display manager. ❆ When gdm starts, it starts an X server and then starts two client pro- grams. One of them, called the ‘greeter’, is responsible for the nice GUI login screen. ❆ Under the ‘Options’ menu, you can select the type of session (really, the specific window manager) that you prefer. You’ll also need to convince the greeter that you’re a legitimate user by supplying your id and pass- word. ❆ In the Network Lab, the default window manager is something called Enlightenment. Running on top of it is a desktop environment called Gnome.

❅ Once you’ve selected the type of session you want and typed your id and password for the greeter, it terminates and gdm begins to execute a series of scripts.

❅ A quick word about naming conventions — if you poke around in /etc/X11, you’ll notice that there are directories named for each possible display man- ager. Under each of these directories, the structure will vary, but somehow the display manager will be able to find commands (usually shell scripts) for actions to perform before your login shell starts, when your login shell starts, and after your login shell exits. For gdm, these scripts are found in directories named PreSession, Sessions, and PostSession, respectively. If you selected the Default session while in- teracting with the greeter, then the script named Default will be executed. Otherwise, gdm looks for a script named for the type of session, and falls back to the Default file if it doesn’t exist.

7 Cmpt 471 An Introduction to X January 12, 2001

❅ The script to execute before your login shell is started is found in /etc/X11/gdm/PreSession.

❆ The most important function that this script performs is to transfer ownership of the console to your user id. (Up to now, it’s been owned by the root user id, for security.)

❅ After the pre-session work is finished, gdm begins to establish the proper environment for your login shell. It will execute the commands in the shell initialisation file and the .login file just as in a normal login. Then it will look in the Sessions directory for the appropriate session script.

❆ A little poking around will show you that eventually the default session executes /etc/X11/xdm/xsession. ❆ This script establishes an initial database of X resources, and perhaps does some modification of the key mappings on the keyboard. ❆ Once it’s finished with these, it looks to see if you specified a particular session to the greeter. If so, the appropriate startup script is executed. (Yes, we’ve been following the Default session, but there are other ways to reach this script. Explore!) ❆ If this is a Default session, then you get the opportunity to take control, as the next file to be executed (if it’s present) is a .xsession file in your home directory.

❅ Your .xsession file can add, undo, or redo, any and all of the actions in the system .xsession file. Why would you want to do this?

❅ The X resource database is the means by which you customize X applica- tions. The program xrdb is used to read and modify this database.

❆ A well written X application will consult this database for an enormous range of parameters — colors, fonts, initial window size and position, to name a few, plus whatever application-specific parameters are appropri- ate. Well documented X applications will tell you the names of all these resources in the man page or other documentation. Many applications will come with a default resource specification file. ❆ Unfortunately, not all X applications are well written or well documented, but with experience you can make intelligent guesses. This is helped by the use of common toolkits — once you know how to control resources used in the toolkit functions, you can usually construct the appropriate resource name for a given application.

❅ The program xmodmap is used to modify key mappings on the keyboard.

8 Cmpt 471 An Introduction to X January 12, 2001

❆ PC keyboards have a different notion of the correct position for the caps lock and control keys than do Sun keyboards. If you’re used to one, the other will drive you crazy. This is where you can move them to the ‘correct’ position. ❆ Do you want to use the mouse with your left hand? This is one place where that adjustment can be made. (But also consult the options of your window manager; most modern window managers allow you to specify left- or right-handed mousing.) ❅ As a final action, your .xsession script should call a window manager startup script, just as in /etc/X11/xdm/xsession. ❅ Eventually, when you quit the window manager, gdm grabs control again and executes a script from /etc/gdm/PostSession. ❆ Analogous to the presession script, the most important function of the postsession script is to return ownership of the console to the root id. ❅ When the postsession script has finished execution, gdm will finish execution, and init (remember init?) will immediately restart it. The greeter will reappear on the console screen, ready to accept a new login. ❅ A few closing words about controlling Enlightenment and Gnome. ❆ The documentation is sketchy, at best, and (regrettably) our RedHat re- lease includes an obsolete release of Enlightenment which is not com- patible with more recent and better-documented releases. Still, with a little imagination you can get things done. ❆ Much of the control you’ll need is available from the Gnome and En- lightenment control windows. Look in the menus, under the obvious headings. ❆ Both Gnome and Enlightenment will construct large hidden directories in your home directory. If you look inside these directories, you’ll find that they’re full of (mostly) text files which control menus, screen con- figurations, etc.. These files can be copied, deleted, and editted with a standard text editor. ❆ The Gnome desktop menu is constructed as a directory subtree under the directory .gnome/apps. ❆ The Enlightenment root menu is specified in the file .enlightenment/menus.cfg. ❆ Don’t be afraid to experiment! The worst that can happen is you’ll trash your current environment. Make a back-up before you do anything rash.

9