Протокол X Window System: Основы и принципы работы

none

The X Window System core protocol is the base protocol of the X Window System, which is a networked windowing system for bitmap displays used to build graphical user interfaces on Unix, Unix like, and other operating systems. The X Window System is based on a client–server model: a single server controls the input/output hardware, such as the screen, the keyboard, and the mouse; all application programs act as clients, interacting with the user and with the other clients via the server. This interaction is regulated by the X Window System core protocol. Other protocols 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, 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 MIT in 1984 (its 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, such as the ICCCM and the freedesktop. org specifications, and are typically enforced automatically by using a given widget set.

What is usually called a window in most graphical user interfaces is called a top level window in the X Window System. The term window is also used to denote windows that lie within another window, that is, the subwindows of a parent window. Graphical elements such as buttons, menus, icons, etc. can be realized using subwindows. A client can request the creation of a window. More precisely, it can request the creation of a subwindow of an existing window. As a result, the windows created by clients are arranged in a tree (a hierarchy). The root of this tree is the root window, which is a special window created automatically by the server at startup. All other windows are directly or indirectly subwindows of the root window. The top level windows are the direct subwindows of the root window. Visibly, the root window is as large as the virtual desktop, and lies behind all other windows. The content of a window is not always guaranteed to be preserved over time. In particular, the window content may be destroyed when the window is moved, resized, covered by other windows, and in general made totally or partly non visible. In particular, content is lost if the X server is not maintaining a backing store of the window content. The client can request backing store for a window to be maintained, but there is no obligation for the server to do so. Therefore, clients cannot assume that backing store is maintained. If a visible part of a window has an unspecified content, an event is sent to notify the client that the window content has to be drawn again. Every window has an associated set of attributes, such as the geometry of the window (size and position), the background image, whether backing store has been requested for it, etc. The protocol includes requests for a client to inspect and change the attributes of a window. Windows can be InputOutput or InputOnly. InputOutput windows can be shown on the screen and are used for drawing. InputOnly windows are never shown on the screen and are used only to receive input. 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 managers, 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 xwininfo program. Passing it the tree command line argument, this program shows the tree of subwindows of a window, along with their identifiers and geometry data.

A pixmap is a region of memory that can be used for drawing. Unlike windows, pixmaps are not automatically shown on the screen. However, the content of a pixmap (or a part of it) can be transferred to a window and vice versa. This allows for techniques such as double buffering. Most of the graphical operations that can be done on windows can also be done on pixmaps. Windows and pixmaps are collectively named drawables, and their content data resides on the server. A client can however request the content of a drawable to be transferred from the server to the client or vice versa.

The client can request a number of graphic operations, such as clearing an area, copying an area into another, drawing points, lines, rectangles, and text. Beside clearing, all operations are possible on all drawables, both windows and pixmaps. 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. Such fonts are stored as files, 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. The names of the fonts are arbitrary strings at the level of the X Window core protocol. The X logical font description conventions 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 xlsfonts program prints the list of fonts stored in the server. The xfontsel program shows the glyphs of fonts, and allows 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. Such fonts are rendered by the client, not by the server, with the support of the Xft or cairo libraries and the XRender extension. No specification on client side fonts is given in the core protocol.

Events are packets sent by the server to a client to communicate that something the client may be interested in has happened. For example, an event is sent when the user presses a key or clicks a mouse button. Events are not only used for input: for example, events are sent to indicate the creation of new subwindows of a given window. Every event is relative to a window. For example, if the user clicks when the pointer is in a window, the event will be relative to that window. The event packet contains the identifier of that window. 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 Expose 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 Expose event to notify the client that a part of the window has to be drawn. Most kinds of events are sent only if the client previously stated an interest in them. This is because clients may only be interested in some kind of events. For example, a client may be interested in keyboard related events but not in mouse related events. Some kinds of events are however sent to clients even if they have not specifically requested them. Clients specify which kinds of events they want to be sent by setting an attribute of a window. For example, in order to redraw a window when its content has been destroyed, a client must receive the Expose events, which inform it that the window needs to be drawn again. The client will however be sent Expose events only if the client has previously stated its interest in these events, which is done by appropriately setting the event mask attribute of the window. Different clients can request events on the same window. They can even set different event masks on the same window. For example, a client may request only keyboard events on a window while another client requests only mouse events on the same window. This is possible because the server, for each window, maintains a separate event mask for each client. However, there are some kinds of events that can only be selected by one client at time for each window. In particular, these events report mouse button clicks and some changes related to window management. The xev program shows the events relative to a window. In particular, xev id WID requests all possible events relative to the window of identifier WID and prints them.

Atoms are 32 bit integers representing strings. The protocol designers introduced atoms because they represent strings in a short and fixed size: while a string may be arbitrarily long, an atom is always a 32 bit integer. 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 fixed size of atoms was exploited by specifying a fixed size for events, namely 32 bytes: fixed size packets can contain atoms, while they cannot contain long strings. Precisely, atoms are identifiers of strings stored in the server. They are similar to the identifiers of resources (Windows, Pixmaps, etc.) but differ from them in two ways. First, the identifiers of atoms are chosen by the server, not by the client. In other words, when a client requests the creation of a new atom, it only sends the server the string to be stored, not its identifier; this identifier is chosen by the server and sent back as a reply to the client. The second important difference between resources and atoms is that atoms are not associated with clients. Once created, an atom survives until the server quits or resets (this is not the default behavior of resources). Atoms are identifiers and are therefore unique. However, an atom and a resource identifier can coincide. The string associated with an atom is called the atom name. The name of an atom cannot be changed after creation, and no two atoms can have the same name. As a result, the name of an atom is commonly used to indicate the atom: “the atom ABCD” means, more precisely, “the atom whose associated string is ABCD.” or “the atom whose name is ABCD.” A client can request the creation of a new atom and can request for the atom (the identifier) of a given string. Some atoms are predefined (created by the server with given identifier and string). Atoms are used for a number of purposes, mostly related to communication between different clients connected to the same server. In particular, they are used in association with the properties of windows, which are described below. The list of all atoms residing in a server can be printed out using the program xlsatoms. In particular, this program prints each atom (the identifier, that is, a number) with its name (its associated string).

Every window has a predefined set of attributes and a set of properties, all stored in the 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 arbitrary pieces of data 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 are similar to variables in imperative programming languages, in that a client can create a new property with a given name and 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. The name, type, and value of a property are strings; more precisely, they are atoms, that is, strings stored in the server and accessible to the clients via identifiers. A client application can access a given property by using the identifier of the atom containing the name of the property. Properties are mostly used for inter client communication. For example, the property named WM NAME (the property named by the atom whose associated string is "WM NAME") is used for storing the name of windows. Window managers 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, window managers should store the identifier of the currently active window in the property named NET ACTIVE WINDOW of the root window. 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. The xprop program prints the properties of a given window; xprop root prints the name, type, and value of each property of the root window.

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 selection, which is however mostly governed by other protocols. Other requests are about the input focus and the shape of the 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 no operation request to the server.

The X Window core protocol was designed to be extensible. The core protocol specifies a mechanism for querying the available extensions and how extension requests, events, and errors packets are made. In particular, a client can request the list of all available extensions for data relative to a specific extension. The packets of extensions are similar to the packets of the core protocol. The core protocol specifies that request, event, and error packets contain an integer indicating its type (for example, the request for creating a new window is numbered 1). A range of these integers are reserved for extensions.

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. During the regular interaction between a client and a server, the only requests related to authentication are about the host based access method. In particular, a client can request this method to be enabled and can request reading and changing the list of hosts (clients) that are authorized to connect. Typical applications do not use these requests; they are used by the xhost program to give a user or a script access to the host access list. The host based access method is considered insecure.

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 (buttons, menus, etc.). Graphical user interface elements are defined by client libraries realizing widget toolkits. Inter client communication is covered by other standards such as the ICCCM and freedesktop specifications. 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. 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 managers, 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 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. The user can however also start a session manually running the xinit or startx programs.