全部博文（96）
分类： LINUX
2010-07-05 18:32:51
Communication between server and clients is done by exchanging packets over a . 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 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 . 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, four types of packets are exchanged between client and server over the channel:
Request and reply packets have varying length, while event and error packets have a fixed length of 32 .
Request packets are numbered sequentially by the server as soon as it receives them: the first request from a client is numbered 1, the second 2, etc. The least significant 16 bits of the sequential number of a request is included in the reply and error packets generated by the request, if any. They are also included in event packets to indicate the sequential number of the request that the server is currently processing or has just finished processing.
What is usually called a window in most 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 , , , 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 (a hierarchy). The root of this tree is the , 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 screen (though can be larger, in which case the user can pan around the visible area), 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.
Windows that can be shown on the screen and used for drawing are of the
first kind. The second kind of windows are never shown on the screen;
they are used only to receive input.
The decorative frame and (possibly including buttons) that is usually seen around windows are created by the , 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 , 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 argument, this program shows the tree of subwindows of a window, along with their identifiers and geometry data.
A 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 . 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 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 , and the server accesses them either directly via the local 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 ) and the space a specific string takes when drawn with a specific font.
xfontsel 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 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 allow 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 or libraries and the extension. No specification on client-side fonts is given in the core protocol.
All data about windows, pixmaps, fonts, etc. are stored in the server. The client knows of these objects—integers it uses 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 a window with a given identifier. The identifier can be later used by the client to request, for example, a string to be drawn in the window. The following objects reside in the server and are known by the client via a numerical identifier:
WindowPixmapFontColormap (a table of colors, described below)Graphic contextThese objects are called resources. When a client requests the creation of one such resource, it also specifies an identifier for it. For example, for creating a new window, the client specifies both the attributes of the window (parent, width, height, etc.) and the identifier to associate with the window.
Identifiers are 32-bit with their three most significant bits equal to zero. Every client has its own set of identifiers it can use for creating new resources. This set is specified by the server as two integers included in the acceptance packet (the packet it sends to the client to inform it that the connection is accepted). Clients choose identifiers that are in this set in such a way they do not clash: two objects among windows, pixmaps, fonts, colormaps, and graphic contexts cannot have the same identifier.
Once a resource has been created, its identifier is used by the client to request operations about it to the server. Some operations affect the given resource (for example, requests to move windows); others ask for resource data stored from the server (for example, requests for the attributes of windows).
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 0x1e00021 and passes this number 0x1e00021
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 : this program creates a subwindow, storing its identifier in an , and calls ; this program draws the content of the file to show in this window.
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.
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 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 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.
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. In this example, the server does not send any reply because the client requests do not generate replies. These requests could generate errors.
0x0000002b) and which identifiers the client can create.0x00200000 (this request, like the other requests of this example, does not generate replies from the server)0x0000002b) with identifier 0x00200001, size 200x200, position (10,10), etc.0x00200001, specifying it is interested in receiving Expose and KeyPress events.0x00200001 to be mapped (shown on the screen)Expose eventPolyFillRectangle request with window 0x00200001 and graphic context 0x00200000If the window is covered by another window and uncovered again, assuming that backing store is not maintained:
Expose event to tell the client that the window has to be drawn againPolyFillRectangle requestIf a key is pressed:
KeyPress event to the client to notify it that the user has pressed a keyAt the protocol level, a color is represented by a 32-bit unsigned integer, called a pixelvalue. The following elements affect the representation of colors:
In the easiest case, the colormap is a table containing a triple in each row. A pixelvalue x represents the color contained in the x-th row of the table. If the client can change the entries in the colormap, this representation is identified by the PseudoColor visual class. The visual class StaticColor is similar, but the client cannot change the entries in the colormap.
There are a total of six possible visual classes, each one
identifying a different way for representing an RGB triple with a
pixelvalue. PseudoColor and StaticColor are two. Another two are GrayScale and StaticGray, which differ in that they only display shades of grey.
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. According to this color representation, a pixelvalue is converted into an RGB triple as follows:
This mechanism requires the colormap to be composed of three separate tables, one for each . The result of the conversion is still a triple of intensity values. The visual classes using this representation are the DirectColor and TrueColor ones, differing on whether the client can change colormaps or not.
These six mechanisms for representing colors with pixelvalues all require some additional parameters to work. These parameters are collected into a visual type, which contains a visual class and other parameters of the representation of colors. Each server has a fixed set of visualtypes, each one associated with a numerical identifier. These identifiers are 32-bit unsigned integers, but are not necessarily different from identifiers of resources or atoms.
When the connection from a client is accepted, the acceptance packet sent by the server contains a sequence of blocks, each one containing information about a single screen. For each screen, the relative block contains a list of other blocks, each one relative to a specific color depth that is supported by the screen. For each supported depth, this list contains a list of visualtypes. As a result, each screen is associated a number of possible depths, and each depth of each screen is associated a number of possible visual types. A given visual type can be used for more screens and for different depths.
For each visual type, the acceptance packet contains both its identifier and the actual parameters it contains (visual class, etc.) The client stores this information, as it cannot request it afterwards. Moreover, clients cannot change or create new visual types. Requests for creation of a new window include the depth and the identifier of the visual type to use for representing colors of this window.
Colormaps are used regardless of whether the hardware controlling the screen (e.g., a ) uses a , which is a table that is also used for representing colors. Servers use colormaps even if the hardware is not using a palette. Whenever the hardware uses palettes, only a limited number of colormaps can be installed. In particular, a colormap is installed when the hardware shows colors according to it. A client can request the server to install a colormap. However, this may require the uninstalling of another colormap: the effect is that windows using the uninstalled colormap are not shown with the correct color, an effect dubbed color flashing or technicolor. This problem can be solved using standard colormaps, which are colormaps with a predictable association between pixelvalues and colors. Thanks to this property, standard colormaps can be used by different applications.
The creation of colormaps is regulated by the convention. Standard colormaps are regulated by the ICCCM and by the specification.
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 , , and and as well the colour systems. ,
Atoms are 32-bit integers representing . 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 , and a value. Properties are similar to in , 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. 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 window manager specification , window managers should store the identifier of the currently in the property named _NET_ACTIVE_WINDOW of the root window. The , which contain
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.
/, 7, and { are associated to three different keysyms.In the X Window System, every individual, physical key is associated a number in the range 8–255, called its keycode. A keycode only identifies a key, not a particular character or term (e.g., "Page Up") among the ones that may be printed on the key. Each one of these characters or terms is instead identified by a keysym. While a keycode only depends on the actual key that is pressed, a keysym may depend, for example, on whether the Shift key or another was also pressed.
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. 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".
While the translation from keycodes to keysyms is done by the client, the table that represents this association is maintained by the server. Storing this table in a centralized place makes it accessible to all clients. Typical clients only request this mapping and use it for decoding the keycode and modifiers field of a key event into a keysym. However, clients can also change this mapping at will.
A modifier is a key that, when pressed, changes the interpretation of other keys. A common modifier is the : when the key that normally produces a lowercase "a" is pressed together with Shift, it produces an uppercase "A". Other common modifiers are "Control", "Alt", and "Meta".
The X server works with at most eight modifiers. However, each modifier can be associated with more than one key. This is necessary because many keyboards have duplicated keys for some modifiers. For example, many keyboards have two "Shift" keys (one on the left and one on the right). These two keys produce two different keycodes when pressed, but the X server associates both with the "Shift" modifier.
For each of the eight modifiers, the X server maintains a list of
the keycodes that it consider to be that modifier. As an example, if
the list of the first modifier (the "Shift" modifier) contains the
keycode 0x37, then the key that produces the keycode 0x37 is considered a shift key by the X server.
The lists of modifier mappings is maintained by the X server but can be changed by every client. For example, a client can request the "" to be added to the list of "Shift" modifiers. From this point on, this key behaves like another shift modifier. However, the keycode corresponding to F1 is still generated when this key is pressed. As a result, F1 operates as it did before (for example, a help window may be opened when it is pressed), but also operates like the shift key (pressing "a" in a text editor while F1 is down adds "A" to the current text).
The X server maintains and uses a modifier mapping for the mouse buttons. However, the buttons can only be . This is mostly useful for exchanging the leftmost and rightmost button for users.
The xmodmap program shows and changes the key, modifier, and mouse button mappings.
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:
A client can establish a grab over the keyboard, the pointer, or both. A request for grabbing can include a request for freezing the keyboard or the pointer. The difference between grabbing and freezing is that grabbing changes the recipient of events, while freezing stops their delivery altogether. When a device is frozen, the events it generates are stored in a queue to be delivered as usual when the freeze is over.
For pointer events, an additional parameter affects the delivery of events: an event mask, which specifies which types of events are to be delivered and which ones are to be discarded.
The requests for grabbing include a field for specifying what happens to events that would be sent to the grabbing client even if it had not established the grab. In particular, the client can request them to be sent as usual or according to the grab. These two conditions are not the same as they may appear. For example, a client that would normally receive the keyboard events on a first window may request the keyboard to be grabbed by a second window. Events that would normally be sent to the first window may or may not be redirected to the grab window depending on the parameter in the grab request.
A client can also request the grab of the entire server. In this case, no request will be processed by the server except the ones coming from the grabbing client.
Other requests and events in the core protocol exist. A first kind of requests are 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 , which is however mostly governed by other protocols. Other requests are about the input focus and the shape of the cursor. 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 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 . 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 () 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 access to the host access list. The host-based access method is considered insecure.
Most client programs communicate with the server via the client library. In particular, most clients use libraries such as , , , or which in turn use Xlib for interacting with the server. The use of Xlib has the following effects:
XFlush;XGetWindowAttributes;XNextEvent) and the call blocks (for example, XNextEvent blocks if the queue is empty.)Higher-level libraries such as (which is in turn used by and ) allow the client program to specify the 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 , provide asynchronous access to the protocol, allowing better latency hiding.
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 (, , etc.) Graphical user interface elements are defined by client libraries realizing . Inter-client communication is covered by other standards such as the and 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 , which are programs that control the appearance of the windows and the general of the graphical user interface. Yet another issue where inter-client communication is to some extent relevant is that of .
How a user session starts is another issue that is not covered by the core protocol. Usually, this is done automatically by the . The user can however also start a session manually running the or programs.