X Window System core protocol

In the X Window System core protocol, only four kinds of packets are sent, asynchronously, over the network: requests, replies, events, and errors.

Requests are sent by a client to the server to ask it to perform some operation (for example, create a new window) and to send back data it holds.

Requests may generate replies, events, and errors; other than this, the protocol does not mandate a specific order in which packets are sent over the network.

Its designers Bob Scheifler and Jim Gettys set as an early principle that its core protocol was to "create mechanism, not policy".

The server answers by sending back a packet stating the acceptance or refusal of the connection, or with a request for a further authentication.

From the point of view of the core protocol, the window manager is a client, not different from the other applications.

Passing it the -tree command-line argument, this program shows the tree of subwindows of a window, along with their identifiers and geometry data.

Windows and pixmaps are collectively named drawables, and their content data resides on the server.

[7] Such fonts are rendered by the client, not by the server, with the support of the Xft or cairo libraries and the XRender extension.

The server generates an Expose event to notify the client that a part of the window has to be drawn.

In particular, these events report mouse button clicks and some changes related to window management.

The following is a possible example of interaction between a server and a program that creates a window with a black box in it and exits on a keypress.

The following elements affect the representation of colors: In the easiest case, the colormap is a table containing a RGB triple in each row.

There are a total of six possible visual classes, each one identifying a different way for representing an RGB triple with a pixelvalue.

The two remaining visual classes differ from the ones above because they break pixelvalues in three parts and use three separate tables for the red, green, and blue intensity.

The visual classes using this representation are the DirectColor and TrueColor ones, differing on whether the client can change colormaps or not.

Colormaps are used regardless of whether the hardware controlling the screen (e.g., a graphic card) uses a palette, which is a table that is also used for representing colors.

This system consists of several additional features in xlib, found in the Xcms* series of functions.

Atom brevity was exploited by mandating their use in the kinds of packets that are likely to be sent many times with the same strings; this results in a more efficient use of the network.

The X resources, which contain parameters of programs, are also stored in properties of the root window; this way, all clients can access them, even if running on different computers.

In the X Window System, every individual, physical key is associated a number in the range 8–255, called its keycode.

When a key is pressed or released, the server sends events of type KeyPress or KeyRelease to the appropriate clients.

These events contain: The server therefore sends the keycode and the modifier state without attempting to translate them into a specific character.

Typical clients only request this mapping and use it for decoding the keycode and modifiers field of a key event into a keysym.

The xmodmap program shows and changes the key, modifier, and mouse button mappings.

When a device is frozen, the events it generates are stored in a queue to be delivered as usual when the freeze is over.

During the regular interaction between a client and a server, the only requests related to authentication are about the host-based access method.

Lower-level libraries, such as XCB, provide asynchronous access to the protocol, allowing better latency hiding.

Graphical user interface elements are defined by client libraries realizing widget toolkits.

[10] Inter-client communication is relevant to selections, cut buffers, and drag-and-drop, which are the methods used by a user to transfer data from a window to another.

The X Window System logo
In this example, the X server takes input from a keyboard and mouse and displays to a screen. A web browser and a terminal emulator run on the user's workstation, and a terminal emulator runs on a remote server but under the control of the user's machine. Note that the remote application runs just as it would locally.
An example interaction between a client and a server.
A possible placement of some windows: 1 is the root window, which covers the whole screen; 2 and 3 are top-level windows; 4 and 5 are subwindows of 2. The parts of a window that are outside its parent are not visible.
Anatomy of a FVWM window. The white area is the window as created and seen by the client application.
The xfontsel program allows the user to view the glyphs of a font.
An example of event: when a key is pressed in a window, an event is generated and sent to a client depending on its window event mask, which the client can change.
This key always generates the same keycode , but the symbols / , 7 , and { are associated to three different keysyms .
Translation from keycode to keysym.
If the pointer or the keyboard are frozen, the events they generate are blocked in a queue. If they are grabbed, their events are rerouted to the grabbing client instead of the window that normally receives them. Pointer events can be discarded depending on an event mask.
The shape extension allows oclock to create a round window.