Misplaced Pages

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 Window terminology takes the perspective that the X Window program is at the centre of all activity, i.e. the X Window 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 Window 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.

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:

1. Request: the client requests information from the server or requests it to perform an action.
2. Reply: the server responds to a request. Not all requests generate replies.
3. Event: the server sends an event to the client, e.g., keyboard or mouse input, or a window being moved, resized or exposed.
4. 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 Window 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 Window 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

The mechanisms of selections, cut buffers, and drag-and-drop in the X Window System allow a user to transfer data from one window to another. Selections and cut buffer are used (typically) when a user selects text or some other data in a window and pastes in a different window. Drag-and-drop is used when a user selects something in a window, then clicks on the selection and drags it into another window.

Since two different applications may handle the two windows, data transfer requires different clients connected with the same X server to interact. The X Window core protocol includes some types of requests and events that are specific to selection exchange, but the transfer is mainly done using the general client-to-client event sending and window properties, which are not specific to selection transfer.

Users can transfer data of different types between clients: it is usually text, but can also be a pixmap, a number, a list of objects, etc.

Selections and drag-and-drop are active mechanisms: after the user selects data in a window, the client handling the window must actively support a protocol for transferring that data to the application requesting it. Cut buffers, by contrast, provide a passive mechanism: when the user selects some text, its content is transferred to a cut buffer, where it remains even if the application handling the window terminates and the window is destroyed.

Window manager

A window manager is a program that controls the general appearance of windows and other graphical elements of the graphical user interface. Differences in the look of X Window System in different installations stem mainly from the use of different window managers or from different configurations of the window manager.

The window manager takes care of deciding the position of windows, placing the decorative border around them, handling icons, handling mouse clicks outside windows (on the “background”), handling certain keystrokes, etc.

From the point of view of the X server, the window manager operates as a client just like any other client. The initial position and the decorative borders around windows are handled by the window manager using the following requests:

1. an application can request the server not to satisfy requests of mapping (showing) subwindows of a given window, and to be sent an event instead;
2. an application can request changing the parent of a window.

The window manager uses the first request to intercept any request for mapping top-level windows (children of the root window). Whenever another application requests the mapping of a top-level window, the server does not do it but sends an event to the window manager instead. Most window managers reparent the window: they create a larger top-level window (called the frame window) and reparent the original window as a child of it. Graphically, this corresponds to placing the original window inside the frame window. The space of the frame window that is not taken by the original window is used for the decorative frame around the window (the “border” and the “title bar”).

The window manager manages mouse clicks in the frame window. This allows, for example, a user to move or resize the window by clicking and dragging on the border or on the title bar.

The window manager also handles icons and related visual elements of the graphical user interface. Icons do not exist at the level of the X Window core protocol. They are implemented by the window manager. For example, whenever a window has to be “iconified”, the FVWM window manager unmaps the window, and creates a window for the icon name and possibly another window for the icon image. The meaning and handling of icons is therefore completely decided by the window manager: some window managers such as wm2 do not implement icons at all.

Session manager

Roughly, the state of a session is the “state of the desktop” at a given time: a set of windows with their current content. More precisely, it is the set of applications managing these windows and the information that allow these applications to restore the condition of their managed windows if required. A program known as the X session manager saves and restores the state of sessions.

Most recognizably, using a session manager permits a user to log out from an interactive session but to find exactly the same windows in the same state when logging in again. For this to work, the session manager program stores the names of the running applications at logout and starts them again at login. In order for the state of the applications to be restored as well (which is needed to restore the content of windows), the applications must be able to save their state of execution upon request from the session manager and load it back when they start again.

The X Window System includes a default session manager called xsm. Developers have written other session managers for specific desktop systems. Major examples include ksmserver, xfce4-session, and gnome-session for KDE, Xfce, and GNOME respectively.

X display manager

The program known as the X display manager shows the graphical login prompt in the X Window System. More generally, a display manager runs one or more X servers on the local computer or accepts incoming connections from X servers running on remote computers. The local servers are started by the display manager, which then connects to them to present the user the login screen. The remote servers are started independently from the display manager and connect to it. In this situation, the display manager works like a graphical telnet server: an X server can connect to the display manager, which starts a session; the applications which utilize this session run on the same computer of the display manager but have input and output on the computer where the X server runs (which may be the computer in front of the user or a remote one).

The X Window System ships with XDM as the basic supplied display manager. Other display managers include GDM (GNOME), KDM/SDDM (KDE), WDM (using the WINGs widget set used in Window Maker) and entrance (using the architecture used in Enlightenment v.17).

User interface elements

Early widget toolkits for X included Xaw (the Athena Widget Set, 1983), OLIT (OPEN LOOK Intrinsics Toolkit, 1988), XView (1988), Motif (1980s) and Tk. OLIT and XView function as the base toolkits for Sun's legacy OpenWindows desktop environment.

Motif provides the base toolkit for the Common Desktop Environment (CDE), the desktop environment used on commercial Unix systems such as Solaris, AIX and HP-UX. (Solaris 10 includes both CDE and GNOME, with the latter the preferred desktop environment as of 2010.)

Toolkits developed more recently include Qt (1991- , used by KDE), GTK+ (1997- , used by GNOME), wxWidgets (1992- ), FLTK (1998- ), FOX (1997- ) and fpGUI (2005-current).

Extensions

Scheifler and Gettys designed the X server to be simple but extensible. As such, much functionality now resides in extensions to the protocol.

At the protocol level, every extension can be assigned new request/event/error packet types. Extension features are accessed by client applications through extension libraries. Adding extensions to current X server implementations is reportedly difficult due to a lack of modularity in the server design. It is a long-term goal of the XCB project to automate generating both the client and server sides of extensions from XML protocol descriptions.

The following table provides a partial catalog of extensions that have been developed, sorted roughly by recency of introduction:

Obsolete extensions

See also

• Xlib
• Intrinsics (Xt)
• X Window System core protocol
• X logical font description

Notes

1. "Xorg, Network Connections". X11R7.7 Manual Pages. X.Org foundation. Retrieved 23 December 2023.
2. Client–server model
   • IBM 1994, pp.2-11
   • Maguolo 2005
   • Manrique 2001
   • Stevens 1994, pp.430-433
   • Quercia & O'Reilly 1993, pp.13-17
3. Hopkins, Don (uncredited) (May 1994). Garfinkel, Simson; Weise, Daniel; Strassmann, Steven (eds.). The UNIX-Haters Handbook (PDF). San Mateo, CA, USA: IDG Books. p. 126 The X-Windows Disaster. ISBN 978-1-56884-203-5. OCLC 30681401. Retrieved July 11, 2011. The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance.
4. Raymond, Eric S. (September 30, 2008). "The Unix Hater's Handbook, Reconsidered". Armed and Dangerous. Retrieved July 11, 2011. ICCCM is about as horrible as the authors describe, but that's hard to notice these days because modern toolkits and window managers do a pretty good job of hiding the ugliness from applications.
5. Gettys, James; Karlton, Philip L.; McGregor, Scott (10 December 1990). "The X Window System, Version 11" (PDF). Digital Equipment Corporation and Silicon Graphics Computer Systems. p. 36. Archived from the original (PDF) on 19 October 2023. Retrieved July 11, 2011. X11 does not permit the read back of all information that may have been stored in the server (for example, the X11 protocol does not permit querying the GC state). This makes modularity somewhat harder to accomplish.
6. "X.org libXi Client library for XInput". Retrieved 2010-03-02. libXi - library for the X Input Extension
7. "XC-MISC Extension" (PDF). Archived from the original (PDF) on September 27, 2011. Retrieved 2010-08-02.
8. "Security Extension Specification" (PDF). Archived from the original (PDF) on September 27, 2011. Retrieved 2010-08-02.
9. Disable XFree86-DGA requests except relative mouse motion, until Xinput 2 allows killing it all. X.Org Wiki - Releases/7.6
10. ^ 7.5 release announcement
11. Commit removing XPrint

References

1. Manrique, Daniel (May 23, 2001). "The X Window System Architecture: overview". X Window System Architecture Overview HOWTO. The Linux Documentation Project. Retrieved July 13, 2011.
2. Maguolo, Filippo (December 16, 2005). "The Architecture of X-Window". Lessons in Linux. Mount Kisco, NY, USA: John F. Moore. Retrieved July 13, 2011.
3. Stevens, W. Richard (1994). "30.5 X Window System" (PDF). TCP/IP Illustrated (PDF). Addison-Wesley professional computing series. Vol. 1, TheProtocols (1 ed.). Boston, MA, USA: Addison-Wesley. 30.5 X Window System. ISBN 978-0-201-63346-7. OCLC 246049781. Retrieved July 13, 2011.
4. IBM Corporation, International Technical Support Center (July 1994). "1.2 X Concepts" (PDF). TCP/IP for MVS, VM, OS/2 and DOS: X Window System Guide (PDF). IBM Redbooks (Second ed.). Research Triangle Park, NC, USA: IBM. X Concepts. Retrieved July 13, 2011.
5. Quercia, Valerie; O'Reilly, Tim (1993) . X Window System User's Guide : for X11 release 5. Definitive guides to the X Window System. Vol. 3. Sebastopol, CA, USA: O'Reilly & Assoc. ISBN 978-1-56592-014-9. OCLC 682229836. LCC QA76.76.W56 Q47. Retrieved July 14, 2011. archive.org has the 1990 edition.

Further reading

• Robert W. Scheifler and James Gettys: X Window System: Core and extension protocols, X version 11, releases 6 and 6.1, Digital Press 1996, ISBN 978-1-55558-148-0
• "An Introduction to X11 User Interfaces". Archived from the original on 3 January 2007.
• Introduction to X Windows
• Gettys, Jim (9 December 2003). "Open Source Desktop Technology Road Map". Archived from the original on 2 January 2006.

External links

• X.Org Foundation (official home page)
• X.Org Foundation wiki
• X Window System Internals
• Kenton Lee's pages on X Window and Motif Archived 2013-05-20 at the Wayback Machine
• X11 Extension tutorial

v t e X Window System
Architecture	Core protocol X Window selection X Window authorization X11 color names X Input Method Wayland
Extensions	X Image Extension X keyboard extension RandR X Rendering Extension Shape extension Shared memory extension X Display Manager Control Protocol X video extension X-Video Motion Compensation AIGLX GLX Multi-Pointer X Display PostScript Composite Extension Xinerama
Components and notable implementations	Display servers X.Org Server Cygwin/X X-Win32 X386 XFree86 XDarwin Xming Xsgi Xsun Xgl Xephyr XQuartz XWayland Client libraries Xlib XCB X Toolkit Intrinsics Display managers Session managers GDM KDM SDDM XDM LightDM LXDM Entrance WDM Window managers (comparison) Compositing Compiz KWin Metacity Mutter Xfwm Enlightenment Stacking 4Dwm AfterStep amiwm Blackbox CTWM cwm Fluxbox FLWM FVWM IceWM Matchbox mwm olwm Openbox Qvwm Sawfish swm tvtwm twm vtwm WindowLab Window Maker wm2 Tiling awesome dwm i3 Ion ratpoison wmii xmonad StumpWM larswm
Standards	ICCCM EWMH XDS freedesktop.org
Applications	xcalc xclock xedit xload xterm xeyes Desktop environments (comparison)

• X Window System
• Application layer protocols
• Remote desktop protocols
• X Window extensions