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.