|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
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.
X is based on a client-server model. An X server program runs on a computer with a graphical display and communicates with various client programs. The server acts as a go-between for the user and the client programs, accepting requests for graphical output (windows) from the client programs and showing them to the users, 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 a different machine. This is the reverse of the common configuration of client-server systems, where the client runs on the user's computer and the server runs on a remote computer. This reversal often confuses new X users. The X Window terminology takes the perspective of the program, rather than the end-user or the hardware: the remote programs connect to the X server display running on the local machine, and thus act as clients; the local X display accepts incoming traffic, and thus acts as a server.
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 system updater runs on a remote server but is controlled from the user's machine. Note that the remote application runs just as it would locally.
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.
Bob Scheifler and Jim Gettys set out the early principles of X as follows (as listed in Scheifler/Gettys 1996):
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 reference implementation is developed with a view to extension and improvement of the implementation, whilst remaining almost entirely compatible with the original 1987 protocol.
Communication between server and clients is done by exchanging packets over a network channel. The connection is established by the client, which sends 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, four types of packets are exchanged by the client and the server over the channel:
The X server provides a set of basic services. The client programs realize more complex functionalities by interacting with the server.
A possible placement of some windows: 1 is the root window, which covers the whole screen; 2 and 3 are top-level windows; 4 and 5 are subwindows of 2. The parts of window that are outside its parent are not visible.
What is usually called a window in other graphical user interfaces 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 root of the tree is called the root window, which is automatically created by the server. 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.
All data about windows, fonts, etc. is stored in the server. 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 a window with a given identifier. The server creates a window and associates it with the identifier. 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 the object has been created by another client.
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 pieces of data that are attached to a window. Contrary to 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 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 is used for storing the name for
the window; window managers typically read this property and display the
name of the window at the top of it.
The properties of a window can be shown using the xprop
program. In particular, xprop -root shows the properties of
the root window, which include the
X
resources (parameters of programs).
Events are packets sent by the server to the client to communicate that something the client may be interested in has happened. 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 are used to notify clients of keyboard or mouse input, of the creation of new windows, etc.
Some kinds of events are always sent to client, but most kinds of event 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 event but not in mouse-related events.
The way colors are handled in the X Window System sometimes confuses users, and historically several different modes have been supported. Most modern applications use TrueColor (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 for representing a single color in most graphic operations, called a pixelvalue. When transferring primary colors intensity, a 16 bits integer is used for each colour component. The following representations of colors exist; not all of them may be supported on a specific device.
Most client programs communicate with the server via the Xlib client library. In particular, most clients use libraries such as Xaw, Motif, GTK+, or Qt which in turn use Xlib for interacting with the server.
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. These protocols are instead governed by a separate set of inter-client communication conventions.
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. This specification has been considered 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 a specific protocol can be built at the top of it. In particular, the X Session Management protocol (XSMP) is a protocol based on ICE that mandates over 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.
Newer conventions are included in the freedesktop specifications, 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 be run in a subwindow of another application.
Selections, cut buffers, and drag-and-drop are the mechanisms used in the X Window System to 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 the two windows may be handled by two different applications, data transfer requires two 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.
Data to be transferred between clients can be of different types: 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 some text has been selected in a window, the client handling the window must actively support a protocol for transferring the data to the application requesting it. Cut buffers, by contrast, are 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.
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 are mainly due to the use of different window managers or 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 is not different
from the other clients. The initial position and the decorative borders
around windows are handled by the window manager using the following requests:
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 to move or resize the window when the user clicks and drags on the border or on the title bar.
The window manager is also responsible for the handling of 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 window manager FVWM 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.
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. An X session manager is a program that saves and restores the state of sessions.
The most recognizable effect of using a session manager is the possibility of logging out from an interactive session and then finding 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.
Other session managers have been developed for specific desktop systems:
for example, ksmserver is the default session manager of
KDE.
The X display manager is the program that 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 and 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 programs of 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).
XDM is the basic display manager supplied with the X Window System. Other display manager include GDM (GNOME), KDM (KDE), WDM (using the WINGs widget set used in Window Maker) and entrance (using the architecture used in Enlightenment v.17).
Early widget toolkits for X included Xaw (the Athena Widget Set), OLIT (OPEN LOOK Intrinsics Toolkit), XView, Motif and Tk. OLIT and XView are the base toolkits for Sun's legacy OpenWindows desktop environment.
Motif provides the base toolkit for the Common Desktop Environment (CDE), which is 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 now the preferred desktop environment.)
More modern toolkits include Qt (used by KDE), GTK+ (used by GNOME), wxWidgets, FLTK and FOX.
The X server was designed 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 though extension libraries. Adding extensions to current X server implementations is reportedly difficult due to a lack of modularity in the server design.[citation needed] 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 is a partial list of extensions that have been developed, sorted roughly by recency of introduction:
| Extension | Description and notes |
|---|---|
| Composite | Off-screen rendering of entire window hierarchies, allowing applications and composition managers to do effects anywhere along the way. Required for things like alpha transparency for windows and drop shadows. |
| Damage | Tracks modified regions of windows, and minimizes bandwidth use required to keep the display up to date. |
| XFixes | Several protocol changes. |
| Extended-Visual-Information (EVIE) | Allows client to determine information about core X visuals beyond what the core protocol provides. |
| Distributed Multihead (DMX) | Communicates with DMX X server. |
| XvMC | Offloading video motion compensation to a GPU that supports it. |
| GLX | Support for rendering OpenGL within windows. |
| XRender | Hardware accelerated image compositing with alpha blending. |
| Resize and Rotate (RANDR) | Dynamically change the size, reflection, rotation and refresh rate of an X screen. |
| Xinerama | Splitting the desktop across multiple monitors. |
| Display Power Management Signaling (DPMS) | Allows controlling monitor power saving modes. |
| XPRINT | |
| X keyboard extension | Enhanced keyboard layout handling. |
| DOUBLE-BUFFER | Gives flicker-free animation. |
| RECORD | |
| MIT-SHM | Use of shared memory to improve performance. |
| SYNC | Provides timers and synchronizes clients (e.g. running on different hosts and operating systems) from within the X server. Created because of errors introduced by the network. |
| XTEST | |
| XInputExtension | Support for input devices such as graphic tablets. |
| BIG-REQUESTS | Enables requests exceeding 262140 bytes in length. |
| XC-MISC | |
| X video extension | Support for hardware video overlays and hardware-based video scaling on playback. Also called Xv (not to be confused with the xv program). |
| Shape | Support for non-rectangular and partially transparent (binary, no alpha opacity) windows. |
| DEC-XTRAP | |
| MIT-SCREEN-SAVER | |
| MIT-SUNDRY-NONSTANDARD | Support for various backwards compatibility features for clients which used early implementations of X11. For compatibility with Pre-X11R4 clients. |
| SECURITY | |
| TOG-CUP | Provides colormap utilization policy. |
| X-Resource | |
| XC-APPGROUP | |
| XFree86-Bigfont | |
| XFree86-DGA | Provides direct linear framebuffer access (direct graphics access). |
| XFree86-Misc | |
| XFree86-VidModeExtension | Dynamically configures modelines and gamma. |
| Extension | Description and notes |
|---|---|
| Low Bandwidth X (LBX) | Replaced by X tunneled over a secure shell connection, proved faster than LBX. |
| PEX | "PHIGS Extension to X"; support for PHIGS 3D scene graph API. GLX with OpenGL is frequently used instead. |
| XImage Extension | MIT-SHM is used instead. |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
