In computing, the X Window System (commonly: X11, or X) is a network-transparent windowing system for bitmap displays. This article details the protocols and technical structure of X11.

Client–server model and network transparency

X uses a client–server model. An X server program runs on a computer with a graphical display and communicates with various client programs. The X server acts as a go-between for the user and the client programs, accepting requests on TCP port 6000 plus the display number for graphical output (windows) from the client programs and displaying them to the user (display), and receiving user input (keyboard, mouse) and transmitting it to the client programs.

In X, the server runs on the user's computer, while the clients may run on remote machines. This terminology reverses the common notion of client–server systems, where the client normally runs on the user's local computer and the server runs on the remote computer. The X terminology takes the perspective that the X program is at the centre of all activity, i.e. the X program accepts and responds to requests from applications, and from the user's mouse and keyboard input. Therefore, applications (on remote computers) are viewed as clients of the X server program.

The communication protocol between server and client runs network-transparently: the client and server may run on the same machine or on different ones, possibly with different architectures and operating systems. A client and server can communicate securely over the Internet by tunneling the connection over an encrypted connection.Client–server model IBM 1994, pp.2-11 Maguolo 2005 Manrique 2001 Stevens 1994, pp.430-433 Quercia & O'Reilly 1993, pp.13-17

Design principles Bob Scheifler and Jim Gettys set out the early principles of X as follows (as listed in Scheifler/Gettys 1996): Do not add new functionality unless an implementor cannot complete a real application without it. It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion. The only thing worse than generalizing from one example is generalizing from no examples at all. If a problem is not completely understood, it is probably best to provide no solution at all. If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also Worse is better.) Isolate complexity as much as possible. Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.

The first principle was modified during the design of X11 to: Do not add new functionality unless you know of some real application that will require it.

X has largely kept to these principles since. The X.Org Foundation develops the reference implementation with a view to extension and improvement of the implementation, whilst keeping it almost entirely compatible with the original 1987 protocol.

Core protocol

Communication between server and clients is done by exchanging packets over a network channel. The client establishes the connection, sending the first packet. The server answers by sending back a packet stating the acceptance or refusal of the connection, or with a request for a further authentication. If the connection is accepted, the acceptance packet contains data for the client to use in the subsequent interaction with the server.

After connection is established, the client and the server exchange four different types of packets over the channel:

Request: the client requests information from the server or requests it to perform an action. Reply: the server responds to a request. Not all requests generate replies. Event: the server sends an event to the client, e.g., keyboard or mouse input, or a window being moved, resized or exposed. Error: the server sends an error packet if a request is invalid. Since requests are queued, error packets generated by a request may not be sent immediately.

The X server provides a set of basic services. The client programs realize more complex functionalities by interacting with the server.

Windows

What other graphical user interfaces usually call a window is a top-level window in the X Window System. The term window is also used for windows that lie within another window, that is, the subwindows of a parent window. Graphical elements such as buttons, menus, icons, etc. are all realized using windows.

A window can only be created as a subwindow of a parent window. This causes the windows to be arranged hierarchically in a tree. The X server automatically creates the root of the tree, called the root window. The top-level windows are exactly the direct subwindows of the root window. Visibly, the root window is as large as the screen, and lies behind all other windows.

Identifiers

The X server stores all data about windows, fonts, etc. The client knows identifiers of these objects – integers it can use as names for them when interacting with the server. For example, if a client wishes a window to be created, it requests the server to create one and (in case of success) gets in return an identifier the server associated with the newly created window. The identifier can be later used by the client to request, for example, a string to be drawn in the window.

Identifiers are unique to the server, not only to the client; for example, no two windows have the same identifier, even if created by two different clients. A client can access any object given its identifier, even if another client created the object.

Attributes and properties

Every window has a predefined set of attributes and a set of properties, all stored in the X server and accessible to the clients via appropriate requests. Attributes are data about the window, such as its size, position, background color, etc. Properties are pieces of data that are attached to a window. Unlike attributes, properties have no meaning at the level of the X core protocol. A client can store arbitrary data in a property of a window.

A property is characterized by a name, a type, and a value. Properties resemble variables in imperative programming languages, in that the application can create a new property with a given name and of a given type and store a value in it. Properties are associated to windows: two properties with the same name can exist on two different windows while having different types and values.

Properties are mostly used for inter-client communication. For example, the property named WM_NAME stores the name for the window; window managers typically read this property and display the name of the window at the top of it.

The xprop program can display the properties of a window. In particular, xprop -root shows the properties of the root window, which include the X resources (parameters of programs).

Events

Events are packets sent by the server to the client to communicate that something has happened which may interest the client. A client can request the server to send an event to another client; this is used for communication between clients. For example, when a client requests the text that is currently selected, an event is sent to the client that is currently handling the window that holds the selection.

The content of a window may be "destroyed" in some conditions (for example, if the window is covered). Whenever an area of destroyed content is made visible, the server generates an Expose event to notify the client that a part of the window has to be drawn.

Other events can serve to notify clients of keyboard or mouse input, of the creation of new windows, etc.

Some kinds of events are always sent to a client, but most kinds of event are sent only if the client previously stated an interest in them, because clients may only be interested in some kind of events. For example, a client may be interested in keyboard-related event but not in mouse-related events.

Color modes The way the X Window System handles colors can sometimes confuse users, and historically several different modes have been supported. Most modern applications use full color (24-bit color, 8 bits for each of red, green and blue), but old or specialist applications may require a different color mode. Many commercial specialist applications use PseudoColor.

The X11 protocol actually uses a single 32-bit unsigned integer - called a pixelvalue - for representing a single color in most graphic operations. When transferring the intensity of primary colors, a 16 bit integer is used for each color component. The following representations of colors exist; not all of them may be supported on a specific device. DirectColor: A pixel value is decomposed into separate red, green, and blue subfields. Each subfield indexes a separate colormap. Entries in all colormaps can be changed. TrueColor: Same as DirectColor, except that the colormap entries are predefined by the hardware and cannot be changed. Typically, each of the red, green, and blue colormaps provides a (near) linear ramp of intensity. GrayScale: A pixel value indexes a single colormap that contains monochrome intensities. Colormap entries can be changed. StaticGray: Same as GrayScale, except that the colormap entries are predefined by the hardware and cannot be changed. PseudoColor (Chunky): A pixel value indexes a single colormap that contains color intensities. Colormap entries can be changed. StaticColor: Same as PseudoColor, except that the colormap entries are predefined by the hardware and cannot be changed.

Xlib and other client libraries

Most client programs communicate with the server via the Xlib client library. Beside Xlib, the XCB library operates more closely to X protocol. In particular, most clients use libraries such as Xaw, Motif, GTK+, or Qt which in turn use Xlib for interacting with the server. Qt switched from Xlib to XCB with the 5.0 release, but client programs were almost entirely unaffected by this change.

Inter-client communication

The X core protocol provides mechanisms for communication between clients: window properties and events, in particular the client-to-client message events. However, it does not specify any protocol for such interactions. Instead, a separate set of inter-client communication conventions governs these protocols.

The Inter-Client Communication Conventions Manual specifies the protocol for the exchange of data via selections and the interaction of applications with the window manager. Some have considered this specification difficult and confusing; consistency of application look and feel and communication is typically addressed by programming to a given desktop environment.

The Inter-Client Exchange protocol (ICE) specifies a framework for building protocols for interaction between clients, so that programmers can build a specific protocol on top of it. In particular, the X Session Management protocol (XSMP) is a protocol based on ICE that governs the interaction between applications with the session manager, which is the program that takes care of storing the status of the desktop at the end of an interactive session and recovering it when another session with the same user is started again.

The freedesktop specifications include newer conventions, including the drag-and-drop convention Xdnd (used for transferring data by selecting it and dragging in another window) and the embedded application convention Xembed (which details how an application can run in a subwindow of another application).

Selections, cut buffers, and drag-and-drop