In the X Window System, a display manager runs as a program, allowing the starting of a session on an X server from the same or another computer. In the X Window System paradigm, the server runs on the computer providing the display and input devices. The server can start a session by itself or can connect to a display manager requesting it to start the session. In the second case, the X server acts as a graphical telnet client while the display manager acts like a telnet server: users start programs from the computer running the display manager, while their input and output take place on the computer where the server (and the user) sits. In the X Window System, the X server runs on the computer in front of the user. The X server may connect to a display manager running on another computer, starting a session which may comprise a variety of programs running on that other computer.

In the X Window System, the X server runs on the computer in front of the user. The X server may connect to a display manager running on another computer, starting a session which may comprise a variety of programs running on that other computer.

When an X server connects to a display manager, that display manager presents the user with a login screen into which to insert username and password. The display manager can run on the same computer as the X server, thus realizing in the X Window System the functionality of init, getty and login on character-mode terminals.

X11 Release 3 introduced X display managers in October 1988 with the aim of supporting the standalone X terminals then just coming onto the market. Various display managers continue in routine use to provide a graphical login prompt on standalone computer workstations running X. X11R4 introduced XDMCP (December 1989) to fix problems in the X11R3 implementation.

How it works

X display managers run on networked computers, accepting incoming requests (the network may comprise a single computer with a loopback interface and no actual network hardware). System administrators can configure a display manager to start a local X server. In this case, the parameters passed to the X server cause this X server to initiate a request to the local display manager. Visually, the user of such a system can watch X server starting and the display manager showing a graphical login widget on the video screen. A session starts when the user successfully enters a valid combination of username and password.

When run remotely, and in particular when the X server runs on an X terminal, an administrator can configure the computer or terminal of the user either to connect to a specific display manager, or to display a list of suitable hosts running potential X display managers. An XDMCP Chooser program allows the user to select a host from among those the terminal can connect to:

  1. a predefined list of hosts and their respective network addresses;
  2. a list of hosts (on the local TCP/IP subnet) that the XDMCP server in turn obtains by a network broadcast

The XDMCP server will often present itself in this list. When the user selects a host from the list, the X server running on the local machine will connect to the selected remote computer's X display manager.

When the session finishes, the display manager resets the X server and (optionally) restarts the whole cycle.

XDMCP protocol

XDMCP (X Display Manager Control Protocol) uses UDP port 177. An X server requests a session to be started on it by sending a Query packet to the display manager. If the display manager allows access for that X server, it responds by sending a Willing packet to the originator. The X server can also send BroadcastQuery or IndirectQuery packets to start a session.

The protocol includes a form authentication. At the protocol level, the display manager has to authenticate with the server. In particular, the X server sends a Request packet to the display manager, which sends back a Accept packet containing another piece of data. The rationale is that the display manager can produce the second piece of data from the first one only if it is in the conditions to be authenticated (for example, it has access to a secret key).

If the authentication succeeds, the X server sends a Manage packet to inform the display manager. From this point on, the interaction between the server and the display manager follows the X Window Protocol. In particular, a connection is set up from the display manager to the X server, and the display manager runs a program for asking the user for a username and password, etc.

Vendor variants

Many vendor X display managers have operated considerably differently. For instance, SCO Open Desktop used scologin not only to control the X session, but also to check for expired passwords and perform some administration tasks.


XDM (the X Window Display Manager) originated in X11R3. This version suffered from several problems, most notably when users switched X terminals off and on. In X11R3, XDM only knew about an X terminal from its entry in the Xservers file, but XDM only consulted this file when it started. Thus every time a user switched a terminal off and on, the system administrator had to send a SIGHUP signal to XDM to instruct it to rescan Xservers.

XDMCP arrived with the introduction of X11R4 (December 1989). With XDMCP, the X server must actively request a display manager connection from the host. An X server using XDMCP therefore no longer requires an entry in Xservers.

X display managers

X supplies XDM as the standard basic display manager. Other display managers include:

  • KDM (KDE)
  • WINGs Display Manager (using the WINGs widget-set used in Window Maker)
  • entrance(using the architecture used in Enlightenment v.17).

See also