X Window System core protocol: Difference between revisions

Revision as of 21:55, 18 September 2019

Latest revision as of 14:33, 25 March 2025

(23 intermediate revisions by 20 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, [[wikt: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 packets 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 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/2006010200000020060102002339/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 |author2=Stephen Gildea |year=1994 |format=PDF |work=[[Digital Equipment Corporation]] |publisher=[[X Consortium]] |url-status=dead |archiveurlarchive-url=https://web.archive.org/web/20050328124653/http://www.xfree86.org/current/xlfd.pdf |archivedatearchive-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">[{{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 271:

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]].

=== 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.

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 ==

Line 286 ⟶ 289:

== 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}}