A display is an abstraction that represents the input and output devices controlled by a single server. Usually a display consists of a keyboard, a pointing device, and one or more screens. A screen is an abstraction that represents a single bitmapped output device.

Each client creates one or more windows on one or more screens of a given display. A window is a rectangular area of the screen on which the client displays output. Windows are arranged in hierarchies of children and parents. The server maintains a tree of windows for each screen. The top-level window is the root window of the screen. Each client typically creates at least one window as a child of the root window, and any other client windows are descendants of these top-level client windows. Windows may overlap, and the server maintains a stacking order for all windows on a screen. A child window may extend beyond the boundaries of its parent, but output is clipped or suppressed outside the parent's borders.

A client asks the server to create and destroy windows, but the windows themselves are resources controlled by the server. The server maintains other resources, including the following:

Each client opens a connection to one or more servers. Clients and servers interact by means of requests, replies, errors, and events. A client sends a request to the server asking it to take some action, such as creating a window or drawing a line into a pixmap. Some requests, such as requests for information, cause the server to generate replies to the client. A request that results in an error condition may cause the server to generate an error report to the client. The server executes requests from each client in the order in which it receives the requests from that client, although the server may execute requests from other clients at any time.

The server notifies clients of changes of state by means of events. An event may be a side effect of a client request, or it may have a completely asynchronous cause, such as the user's pressing a key or moving the pointer. In addition, a client may send an event, through the server, to another client.

Each client asks the server to send that client events of particular types that occur with respect to particular windows. The server generally reports an event with respect to some window. For example, the keyboard is conceptually attached to a window, known as the focus window. When the user presses a key, the server usually reports an event with respect to the focus window. If a client has asked the server to send it events of type KeyPress occurring with respect to some window, the server sends that client an event whenever the user presses a key while that window has the focus.

From the point of view of a client reading events from the server, events that result from that client's own requests arrive in the order in which it makes the requests. However, those events may be interspersed with events that result from other causes, such as user input or another client's actions. Furthermore, the client may buffer requests and the server may buffer events before actually transmitting them, so an event may arrive long after the client makes the request that generates the event.

The point is that for the most part event processing in X is inherently asynchronous. Most client applications continually loop, reading an event, processing the event (possibly making requests during the processing), and then reading another event. The client cannot assume, for example, that a given input event was generated after a given client request just because the client read the event after it made the request. Many events have timestamps that indicate when the server actually generated the events. A client that depends on the temporal ordering of events must often examine these timestamps.