X Window System core protocol: Difference between revisions

Revision as of 06:44, 10 March 2014

Latest revision as of 14:33, 25 March 2025

(45 intermediate revisions by 33 users not shown)

Line 1:

{{Short description|none}}

[[Image:X11.svg|thumb|100px|The X Window System logo]]

The '''X Window System core protocol'''<ref name="sche-gett">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 |1-55558-148-X}}</ref><ref name="rfc 1013">RFC 1013</ref><ref name="intr">Grant Edwards. [http://www.visi.com/~grante/Xtut/ An Introduction to X11 User Interfaces] {{Webarchive|url=https://web.archive.org/web/20070103060448/http://www.visi.com/~grante/Xtut/ |date=2007-01-03 }}</ref> is the base protocol of the [[X Window System]], which is a [[Computer network|networked]] [[windowing system]] for [[bitmap]] displays used to build [[graphical user interface]]s on [[Unix]], [[Unix-like]], and other [[operating system]]s. The X Window System is based on a [[client–server model]]: a single [[Server (computing)|server]] controls the [[input/output]] hardware, such as the [[Computer screen|screen]], the [[Computer keyboard|keyboard]], and the [[Computer mouse|mouse]]; all application [[Computer program|program]]s act as [[client (computing)|client]]s, interacting with the [[user (computing)|user]] and with the other clients via the server. This interaction is regulated by the X Window System core protocol. Other [[protocol (computing)|protocol]]s related to the X Window System exist, both built at the top of the X Window System core protocol or as separate protocols.

In the X Window System core protocol, only four kinds of packets are sent, [[Asynchronywikt:asynchronously|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. ''Replies'' are sent by the server to provide such data. ''Events'' are sent by the server to notify clients of user activity or other occurrences they are interested in. ''Errors'' are packetpackets sent by the server to notify a client of errors occurred during processing of its requests. Requests may generate replies, events, and errors; other than this, the protocol does not mandate over a specific order in which packets are sent over the network. Some extensions to the core protocol exist, each one having its own requests, replies, events, and errors.

X originated at [[Massachusetts Institute of Technology|MIT]] in 1984 (its {{As of|2006|alt=current}} release X11 appeared in September 1987). Its designers [[Bob Scheifler]] and [[Jim Gettys]] set as an early principle that its core protocol was to "create mechanism, not policy". As a result, the core protocol does not specify the interaction between clients and between a client and the user. These interactions are the subject of separate specifications,<ref name="gett">Jim Gettys. [http://freedesktop.org/~jg/roadmap.html Open Source Desktop Technology Road Map] {{webarchive |url=https://web.archive.org/web/20060102002339/http://freedesktop.org/~jg/roadmap.html |date=January 2, 2006 }}</ref> such as the [[ICCCM]] and the [[freedesktop.org]] specifications, and are typically enforced automatically by using a given [[widget set]].

== Overview==

[[File:X client server example.svg|frame|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.]]

Communication between server and clients is done by exchanging packets over a [[channelcommunication (communications)channel|channel]]. The connection is established by the client (how the client is started is not specified in the protocol). The client also sends the first packet, containing the [[byte order]] to be used and information about the version of the protocol and the kind of authentication the client expects the server to use. 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.

[[Image:Xcore-overview.svg|thumb|200px|An example interaction between a client and a server.]]

Line 40 ⟶ 41:

The decorative frame and [[title bar]] (possibly including buttons) that is usually seen around windows are created by the [[window manager]], not by the client that creates the window. The window manager also handles input related to these elements, such as resizing the window when the user clicks and drags the window frame. Clients usually operate on the window they created disregarding the changes operated by the window manager. A change it has to take into account is that [[re-parenting window manager]]s, which almost all modern window managers are, change the parent of top-level windows to a window that is not the root. From the point of view of the core protocol, the window manager is a client, not different from the other applications.

Data about a window can be obtained by running the <code>xwininfo</code> program. Passing it the <code>-tree</code> [[command-line]] argument]], this program shows the tree of subwindows of a window, along with their identifiers and geometry data.

== Pixmaps and drawables ==

Line 54 ⟶ 55:

Most requests for graphic operations include a ''graphic context'', which is a structure that contains the parameters of the graphic operations. A graphic context includes the foreground color, the background color, the font of text, and other graphic parameters. When requesting a graphic operation, the client includes a graphic context. Not all parameters of the graphic context affect the operation: for example, the font does not affect drawing a line.

The core protocol specifies the use of server-side fonts.<ref name="font-faq">[http://www.faqs.org/faqs/fonts-faq/part15/ comp.fonts FAQ: X11 Info]</ref> Such fonts are stored as [[Computer file|file]]s, and the server accesses them either directly via the local [[filesystem]] or via the network from another program called ''font server''. Clients can request the list of fonts available to the server and can request a font to be loaded (if not already) or unloaded (if not used by other clients) by the server. A client can request general information about a font (for example, the font ascent) and the space a specific string takes when drawn with a specific font.{{cn|date=March 2025}}

[[Image:Xfontsel.png|thumb|450px|The <code>xfontsel</code> program allows the user to view the glyphs of a font.]]

The names of the fonts are arbitrary strings at the level of the X Window core protocol. The [[X logical font description]] conventions<ref name="logi-font">{{cite web|url= http://www.xfree86.org/current/xlfd.pdf |title= X Logical Font Description Conventions |accessdateaccess-date= 2005-12-30 |author= Jim Flowers |coauthorsauthor2= Stephen Gildea |year= 1994 |format= PDF |work= [[Digital Equipment Corporation]] |publisher= [[X Consortium]] |url-status=dead |archive-url=https://web.archive.org/web/20050328124653/http://www.xfree86.org/current/xlfd.pdf |archive-date=March 28, 2005 }}</ref> specify how fonts should be named according to their attributes. These conventions also specify the values of optional properties that can be attached to fonts.

The <code>xlsfonts</code> program prints the list of fonts stored in the server. The <code>xfontsel</code> program shows the glyphs of fonts, and allowallows the user to select the name of a font for pasting it in another window.

The use of server-side fonts is currently considered deprecated in favour of client-side fonts.<ref name="herr-hopf">Matthieu Herrb and Matthias Hopf. [http://www.openbsd.org/papers/eurobsd2005/herrb-hopf.pdf New Evolutions in the X Window System].</ref> Such fonts are rendered by the client, not by the server, with the support of the [[Xft]] or [[Cairo (graphics)|cairo]] libraries and the [[XRender]] extension. No specification on client-side fonts is given in the core protocol.

Line 81 ⟶ 82:

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. In particular, it can also access resources created by any other client, even if their identifiers are outside the set of identifiers it can create.

As a result, two clients connected to the same server can use the same identifier to refer to the same resource. For example, if a client creates a window of identifier <code>0x1e00021</code> and passes this number <code>0x1e00021</code> to another application (via any available means, for example by storing this number in a file that is also accessible to the other application), this other application is able to operate on the very same window. This possibility is for example exploited by the X Window version of [[Ghostview]]: this program creates a subwindow, storing its identifier in an [[environment variable]], and calls [[Ghostscript]]; this program draws the content of the [[PostScript]] file to show in this window.<ref name="ghos-inte">[http{{Cite web|url=https://www.gnu.org/software/gv/manual/html_node/Interface-with-ghostscript.html Ghostview: |title=Interface with ghostscript] - GNU gv Manual|website=www.gnu.org}}</ref>

Resources are normally destroyed when the client that created them closes the connection with the server. However, before closing connection, a client can request the server not to destroy them.

Line 93 ⟶ 94:

A client can request the server to send an event to another client; this is used for communication between clients. Such an event is for example generated when a client requests the text that is currently selected: this event is sent to the client that is currently handling the window that holds the selection.

The <code>Expose</code> event is sent when an area of a window of destroyed and content is made visible. The content of a window may be destroyed in some conditions, for example, if the window is covered and the server is not maintaining a backing store. The server generates an <code>Expose</code> event to notify the client that a part of the window has to be drawn.

[[Image:Xevents.svg|thumb|450px|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.]]

Line 159 ⟶ 160:

A part of the X colour system is the X Color Management System (xcms). This system was introduced with X11R6 Release 5 in 1991. This system consists of several additional features in xlib, found in the Xcms* series of functions. This system defines device independent color schemes which can be converted into device dependent RGB systems. The system consists of the xlib Xcms* functions and as well the X Device Color Characterization Convention (XDCCC) which describes how to convert the various device independent colour systems into device dependent RGB colour systems. This system supports the [[CIEXYZ]], [[xyY]], [[CIELUV]] and [[CIELAB]] and as well the [[TekHVC]] colour systems.

[http://insar.stanford.edu/~lharcke/programming/Xcms/] {{Webarchive|url=https://web.archive.org/web/20111005224650/http://insar.stanford.edu/~lharcke/programming/Xcms/ |date=2011-10-05 }}, [http://tronche.com/gui/x/xlib/color/]

== Atoms ==

Line 183 ⟶ 184:

Properties are mostly used for inter-client communication. For example, the property named <code>WM_NAME</code> (the property named by the atom whose associated string is <code>"WM_NAME"</code>) is used for storing the name of windows. [[Window manager]]s typically read this property to display the name of windows in their title bar.

Some types of inter-client communication use properties of the root window. For example, according to the [[freedesktop]] window manager specification,<ref name="free-desk">[http{{Cite web|url=https://www.freedesktop.org/wiki/Specifications/wm-spec/?action=show&redirect=Standards%2Fwm/wm-spec|title=wm-spec|website=www.freedesktop.org}}</ref> Freedesktopwindow managers should store the identifier of the currently [[active window]] managerin specificationthe property named <code>_NET_ACTIVE_WINDOW</code> of the root window. The [[X resources]], which contain [[parameter (computer science)|parameter]]s of programs, are also stored in properties of the root window; this way, all clients can access them, even if running on different computers.

</ref> window managers should store the identifier of the currently [[active window]] in the property named <code>_NET_ACTIVE_WINDOW</code> of the root window. The [[X resources]], which contain [[parameter (computer science)|parameter]]s of programs, are also stored in properties of the root window; this way, all clients can access them, even if running on different computers.

The <code>xprop</code> program prints the properties of a given window; <code>xprop -root</code> prints the name, type, and value of each property of the root window.

Line 198:

# the current state of the modifiers (Shift, Control, etc.) and mouse buttons

[[Image:Xkeyboard.svg|left|thumb|400px|HowTranslation afrom keycode is translated into ato keysym.]]

The server therefore sends the keycode and the modifier state without attempting to translate them into a specific character. It is a responsibility of the client to do this conversion. For example, a client may receive an event stating that a given key has been pressed while the Shift modifier was down. If this key would normally generate the character "a", the client (and not the server) associates this event to the character "A".

Line 216:

== Grabs ==

A ''grab'' is a condition in which all keyboard or mouse events are sent to a single client. A client can request a grab of the keyboard, the mouse, or both: if the request is fulfilled by the server, all keyboard/mouse events are sent to the grabbing client until the grab is released. The other clients will not receive these events.

When requesting a grab, a client specifies a ''grab window'': all events are sent to the grabbing client as if they were relative to the grab window. However, the other clients do not receive events even if they have selected them in the grab window. There are two kinds of grabs:

;* ''active :'' the grab takes place immediately

;* ''passive :'' the grab takes place only when a previously specified key or mouse button is pressed and terminates when it is released

[[Image:Xgrab.svg|thumb|450px|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.]]

Line 236 ⟶ 235:

== Other ==

Other requests and events in the core protocol exist. The first kind of requests is relative to the parent relationship between windows: a client can request to change the parent of a window, or can request information about the parenthood of windows. Other requests are relative to the [[X Window selection|selection]], which is however mostly governed by other protocols. Other requests are about the [[Focus (computing)|input focus]] and the shape of the [[pointer (computinguser WIMPinterface)|pointer]]. A client can also request the owner of a resource (window, pixmap, etc.) to be killed, which causes the server to terminate the connection with it. Finally, a client can send a [[NOP (code)|no-operation]] request to the server.

== Extensions ==

Line 246 ⟶ 245:

== Authorization ==

{{main article|X Window authorization}}

When the client initially establishes a connection with the server, the server can reply by either accepting the connection, refusing it, or requesting [[authentication]]. An authentication request contains the name of the authentication method to use. The core protocol does not specify the authentication process, which depends on the kind of authentication used, other than it ends with the server either sending an acceptance or a refusal packet.

Line 253 ⟶ 252:

==Xlib and other client libraries ==

{{main article|Xlib}}

Most client programs communicate with the server via the [[Xlib]] client library. In particular, most clients use libraries such as [[Xaw]], [[Motif (software)|Motif]], [[GTK+]], or [[Qt (toolkit)|Qt]] which in turn use Xlib for interacting with the server. The use of Xlib has the following effects:

Line 259 ⟶ 258:

# Xlib makes the client synchronous with respect to replies and events:

## the Xlib functions that send requests block until the appropriate replies, if any is expected, are received; in other words, an X Window client not using Xlib can send a request to the server and then do other operations while waiting for the reply, but a client using Xlib can only call an Xlib function that sends the request and wait for the reply, thus blocking the client while waiting for the reply (unless the client starts a new thread before calling the function);

## while the server sends events [[wikt:asynchronous|asynchronous]]ly, Xlib stores events received by the client in a [[Queue (data structure)|queue]]; the client program can only access them by explicitly calling functions of the X11 library; in other words, the client is forced to block or [[busy waiting|busy-wait]] if expecting an event.

# Xlib does not send requests to the server immediately, but stores them in a queue, called the ''output buffer''; the requests in the output buffer are actually sent when:

## the program explicitly requests so by calling a library function such as <code>XFlush</code>;

Line 265 ⟶ 264:

## the program asks for an event in the event queue (for example, by calling <code>XNextEvent</code>) and the call blocks (for example, <code>XNextEvent</code> blocks if the queue is empty.)

Higher-level libraries such as [[X Toolkit Intrinsics|Xt]] (which is in turn used by [[Xaw]] and [[Motif (software)|Motif]]) allow the client program to specify the [[callback (computer science)|callback function]]s associated with some events; the library takes care of polling the event queue and calling the appropriate function when required; some events such as those indicating the need of redrawing a window are handled internally by Xt.

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

==Unspecified parts==

==What the X Window System core protocol does not specify==

The X Window System core protocol does not mandate over inter-client communication and does not specify how windows are used to form the visual elements that are common in graphical user interfaces ([[Button (computing)|button]]s, [[Menu (computing)|menu]]s, etc.). Graphical user interface elements are defined by client libraries realizing [[widget toolkit]]s. Inter-client communication is covered by other standards such as the [[ICCCM]] and [[freedesktop]] specifications.<ref name="free-desk" />

Inter-client communication is relevant to [[X Window selection|selections, cut buffers, and drag-and-drop]], which are the methods used by a user to transfer data from a window to another. Since the windows may be controlled by different programs, a protocol for exchanging this data is necessary. Inter-client communication is also relevant to [[X window manager]]s, which are programs that control the appearance of the windows and the general [[look-and-feel]] of the graphical user interface. Yet another issue where inter-client communication is to some extent relevant is that of [[X session manager|session management]].

The X Window System core protocol does not mandate over inter-client communication and does not specify how windows are used to form the visual elements that are common in graphical user interfaces ([[Button (computing)|button]]s, [[Menu (computing)|menu]]s, etc.) Graphical user interface elements are defined by client libraries realizing [[widget toolkit]]s. Inter-client communication is covered by other standards such as the [[ICCCM]] and [[freedesktop]] specifications.<ref name="free-desk" />

=== Session management ===

Inter-client communication is relevant to [[X Window selection|selections, cut buffers, and drag-and-drop]], which are the methods used by a user to transfer data from a window to another. Since the windows may be controlled by different programs, a protocol for exchanging this data is necessary. Inter-client communication is also relevant to [[X window manager]]s, which are programs that control the appearance of the windows and the general [[look-and-feel]] of the graphical user interface. Yet another issue where inter-client communication is to some extent relevant is that of [[X session manager|session management]].

Yet another issue where inter-client communication is to some extent relevant is that of [[X session manager|session management]].

How a user session starts is another issue that is not covered by the core protocol. Usually, this is done automatically by the [[X display manager (program type)|X display manager]]. The user can however also start a session manually running the [[xinit]] or [[startx]] programs.

== See also ==

*[[X Window System protocols and architecture]]

*[[Xlib]]

*[[X Toolkit Intrinsics|Intrinsics]]

*[[Xnee]] can be used to sniff the X Window System protocol

== References ==

{{reflistReflist|30em}}

== External links ==

*[http://www.x.org/ X.Org Foundation] (official home page) - [http://xorg.freedesktop.org/wiki/ Mirror] with the ___domain name 'freedesktop.org'.

*[httphttps://xwindow.angelfire.com/ X Window System Internals]

*[http://www.rahul.net/kenton/bib.html Kenton Lee's pages on X Window and Motif] {{Webarchive|url=https://web.archive.org/web/20130520013725/http://www.rahul.net/kenton/bib.html |date=2013-05-20 }}

*[http://www.x.org/releases/current/doc/xproto/x11protocol.html X Window System Protocol, Version 11 (current Release)]

{{XWinSys}}

[[Category:X Window System|*core protocol]]

{{Link GA|zh}}