In computing, xterm is the standard terminal emulator for the X Window System. A user can have many different invocations of xterm running at once on the same display, each of which provides independent input/output for the process running in it. Xterm originated prior to the X Window System, it was written as a stand-alone terminal emulator for the VAXStation 100 by Mark Vandevoorde, a student of Jim Gettys, in the summer of 1984, when work on X started. It became clear that it would be more useful as part of X than as a standalone program, so it was retargeted to X; as Gettys tells the story, "part of why xterm's internals are so horrifying is that it was intended that a single process be able to drive multiple VS100 displays."After many years as part of the X reference implementation, around 1996 the main line of development shifted to XFree86, it is now maintained by Thomas Dickey. Many xterm variants are available. Most terminal emulators for X started as variations on xterm. Early versions emulated the VT102 and Tektronix 4014.
Versions added control sequences for DEC and other terminals such as: VT220: Added in patch 24. VT320: Added in patch 24. VT420: DECSTR was added in patch 34. VT520: Although not emulated, parts of VT520 features were implemented. Controls DECSMBV and DECSWBV for setting the margin- and warning-bell volume was added in patch 254; as with most X applications, xterm can be customized via global X resources files, per-user resource files, or command-line arguments. Most of the command-line options correspond to resource settings. While the name of the program is xterm, the X resource class is XTerm; the uxterm script overrides this. Xterm does not have a menu bar. To access xterm's three menus, users hold the control key and press the left, middle, or right mouse button. Support for a "toolbar" can be compiled-in. Supported terminal control functions include: ANSI X3.64 Digital Equipment Corporation VT family:VT52 VT102 VT220Tektronix family:Tektronix 4014In addition to protocols used in commercially available terminal machines, xterm added a few protocols that have been adopted by other terminal emulators, such as: Mouse tracking: Support for buttons 4 and 5 was added in patch 120.
16-colour terminal protocol: Added in patch 39. 256 colors terminal protocol: Added in patch 111. 88-colour terminal protocol: Added in patch 115. Custom colour palette: Ability to specifying the RGB values for palette entries was added in patch 111. Comparison of terminal emulators luit, a character set converter invoked automatically by xterm when necessary Vttest, vt100/vt220/xterm test utility Official website This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later
X Window System
The X Window System is a windowing system for bitmap displays, common on Unix-like operating systems. X provides the basic framework for a GUI environment: drawing and moving windows on the display device and interacting with a mouse and keyboard. X does not mandate the user interface – this is handled by individual programs; as such, the visual styling of X-based environments varies greatly. X originated at the Massachusetts Institute of Technology in 1984; the X protocol has been version 11 since September 1987. The X. Org Foundation leads the X project, with the current reference implementation, X. Org Server, available as free and open source software under the MIT License and similar permissive licenses. X is an architecture-independent system for remote graphical user interfaces and input device capabilities; each person using a networked terminal has the ability to interact with the display with any type of user input device. In its standard distribution it is a complete, albeit simple and interface solution which delivers a standard toolkit and protocol stack for building graphical user interfaces on most Unix-like operating systems and OpenVMS, has been ported to many other contemporary general purpose operating systems.
X provides the basic framework, or primitives, for building such GUI environments: drawing and moving windows on the display and interacting with a mouse, keyboard or touchscreen. X does not mandate the user interface. Programs may use X's graphical abilities with no user interface; as such, the visual styling of X-based environments varies greatly. Unlike most earlier display protocols, X was designed to be used over network connections rather than on an integral or attached display device. X features network transparency, which means an X program running on a computer somewhere on a network can display its user interface on an X server running on some other computer on the network; the X server is the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X server is running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user's computer to request the rendering of graphics content and receive events from input devices including keyboards and mice.
The fact that the term "server" is applied to the software in front of the user is surprising to users accustomed to their programs being clients to services on remote computers. Here, rather than a remote database being the resource for a local app, the user's graphic display and input devices become resources made available by the local X server to both local and remotely hosted X client programs who need to share the user's graphics and input devices to communicate with the user. X's network protocol is based on X command primitives; this approach allows both 2D and 3D operations by an X client application which might be running on a different computer to still be accelerated on the X server's display. For example, in classic OpenGL, display lists containing large numbers of objects could be constructed and stored in the X server by a remote X client program, each rendered by sending a single glCallList across the network. X provides no native support for audio. X uses a client–server model: an X server communicates with various client programs.
The server sends back user input. The server may function as: an application displaying to a window of another display system a system program controlling the video output of a PC a dedicated piece of hardwareThis client–server terminology – the user's terminal being the server and the applications being the clients – confuses new X users, because the terms appear reversed, but X takes the perspective of the application, rather than that of the end-user: X provides display and I/O services to applications, so it is a server. The communication protocol between server and client operates network-transparently: the client and server may run on the same machine or on different ones with different architectures and operating systems. A client and server can communicate securely over the Internet by tunneling the connection over an encrypted network session. An X client itself may emulate an X server by providing display services to other clients; this is known as "X nesting". Open-source clients such as Xnest and Xephyr support such X nesting.
To use an X client application on a remote machine, the user may do the following: on the local machine, open a terminal window use ssh with the X forwarding argument to connect to the remote machine request local display/input service The remote X client application will make a connection to the user's local X server, providing display and input to the user. Alternatively, the local machine may run a small program that connects to the remote machine and starts the client application. Practical examples of remote clients include: administering a remote machine graphically using a client application to join with large numbers of other terminal users in collaborative workgroups running a computationally intensive simulation on a remote machine and displaying the results on
X session manager
In the X Window System, an X session manager is a session management program, a program that can save and restore the current state of a set of running applications. From the point of view of an X session manager, a session is a “state of the desktop” at a given time: a set of windows with their current content. More a session is the set of clients managing these windows or related to them and the information that allows these applications to restore the condition of these windows if required; the most recognizable effect of using a session manager is the possibility of logging out from an interactive session and finding the same windows in the same state when logging in again. For this to work, the session manager program stores the names of applications that are running at logout and starts them again at login. Moreover, for the state of the applications to be restored as well, the applications must be able to save their state of execution upon request from the session manager and load it back when started again.
In general, a session can be saved or loaded at any time if the user is not logging in or out. It is possible to save a number of different sessions and loading one of them at user's choice. Sessions can be specified by providing the list of applications that compose the session; as a result, the user has the possibility of saving a set of different sessions, either by storing the state of execution of the running applications or by explicitly listing the applications that compose a session. This way, the user can decide to load a given session. In order for a session to include the state of an application, the application must be able to store and load its current state when appropriate. A protocol named X Session Management Protocol specifies how applications and session managers interact. Of particular importance is that the window manager is able to communicate with the session manager, as the window manager is responsible for the placement of windows and the existence of icons. Applications that cannot store their state can be included in a session, but they do not preserve their state across sessions.
The X Window System includes. Other session managers have been developed for specific desktop systems: for example, ksmserver is the default session manager of KDE; the XSMP is a subprotocol of the Inter-Client Exchange Protocol. The client starts the protocol by connecting to the session manager. How the session manager is located on the network is system-dependent: in a POSIX system, the environment contains a variable SESSION_MANAGER. Therefore, when a client is launched, its environment must contain this variable with an appropriate value; the protocol takes into account two facts: in order for a session to be restarted properly, not only the applications running in it must be restarted, but they must be restarted in such a way they restore their previous state. Different instances of the same application may be active at the same time in the same or in different sessions, these instances most have different states of execution. For example, the user may have launched a text editor on file /etc/passwd on file letter.txt in the same session, on file todo.txt in another session.
In order for the sessions to be restored properly, different instances of the same application must be recognized as different by the session manager. For this reason, the session manager chooses a unique identifier for each instance of each application; this way, the session manager is able to distinguish between the text editor, running on /etc/passwd and the text editor running on todo.txt if they are two instances of the same program. The identifiers must be unique. In particular, they must be unique across all sessions managed by the session manager: the identifier of the text editor running on /etc/passwd is different not only from the same text editor running on letter.txt but different from the text editor running on todo.txt in another session. The identifier of a client remains the same if the session is shut down and restarted; the main parts of the protocol of session management are: the session manager chooses a unique identifier for every client the session manager requests clients to save their state a client specifies how it has to be started again in order for the state to be restored The last point is possible because the session manager maintains a set of properties for every client.
These pieces of information can be modified by the client at any time. One of these properties is named RestartCommand, contains the information on how the client has to be started again; when the session manager requests a client to save its state, the application proceeds as follows: it saves its state in such a way that the states of two different instances can be distinguished. For example, a property specifies; when asking a client to save its state, the window manager can specify whether the local or global state has
Simple Login Manager is a graphical display manager for the X Window System that can be run independently of any window manager or desktop environment. SLiM aims to be light configurable, suitable for machines on which remote login functionalities are not needed. SLiM was forked from Per Lidén's Login.app program, with contributions from Martin Parm for PAM-related classes. SLiM is developed by Simone Rota and Johannes Winkelmann, is maintained by Nobuhiro Iwamatsu; as of March, 2016, SLiM seems to be abandoned. It is not compatible with systemd; as of September, 2016, GhostBSD 10.3 replaced GDM with SLiM. SLiM supports the following features: PNG and XFT support for alpha transparency and anti-aliased fonts External themes support Configurable runtime options: X server, login / shutdown / reboot commands Single or double input control Can load predefined user at startup Configurable welcome / shutdown messages Random theme selection SLiM has the following dependencies: X11 libpng libjpeg freetype GDM, the GNOME display manager KDM, the KDE display manager Other display managers SLiM at GitHub Old official website
X display manager (program type)
In the X Window System, an X display manager is a graphical login manager which starts a session on an X server from the same or another computer. A display manager presents the user with a login screen. A session starts when a user enters a valid combination of username and password; when the display manager runs on the user's computer, it starts the X server before presenting the user the login screen, optionally repeating when the user logs out. In this condition, the DM realizes in the X Window System the functionality of getty and login on character-mode terminals; when the display manager runs on a remote computer, it acts like a telnet server, requesting username and password and starting a remote session. X11 Release 3 introduced display managers in October 1988 with the aim of supporting the standalone X terminals, 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 the X Display Manager Control Protocol in December 1989 to fix problems in the X11R3 implementation.
A display manager can run on the same computer where the user sits—starting one or more X servers, displaying the login screen at the beginning and every time the user logs out—or on a remote one, working according to the XDMCP protocol. The XDMCP protocol mandates that the X server starts autonomously and connects to the display manager. In the X Window System paradigm, the server runs on the computer providing the display and input devices. A server can connect, using the XDMCP protocol, to a display manager running on another computer, requesting it to start the session. In this 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 sits. An administrator can configure an XDMCP Chooser program running on the local computer or X terminal to connect to a specific host's X display manager or to display a list of suitable hosts that the user can choose from.
Most implementations enable such a list to contain: a predefined set of hosts and their respective network addresses, and/or a set of hosts that the XDMCP Chooser determines by a network broadcast to the available display managers. When the user selects a host from the list, the XDMCP Chooser running on the local machine will send a message to the selected remote computer's display manager and instruct it to connect the X server on the local computer or terminal; the X Display Manager Control Protocol uses UDP port 177. An X server requests. If the display manager allows access for that X server, it responds by sending a Willing packet back to the X server; the display manager must authenticate itself to the server. To do this the X server sends a Request packet to the display manager, which returns an Accept packet. If the Accept packet contains the response the X server expects, the display manager is authenticated. Producing the correct response might require the display manager to have access to a secret key, for example.
If authentication succeeds, the X server sends a Manage packet to inform the display manager. The display manager displays its login screen by connecting to the X server as a regular X client. During the session, the server can send KeepAlive packets to the display manager at intervals. If the display manager fails to respond with an Alive packet within a certain time, the X server presumes that the display manager has ceased running, can terminate the connection. One problem with XDMCP is that to telnet, the authentication takes place unencrypted. If snooping is possible, this leaves the system vulnerable to attack, it is more secure to use an ssh tunnel for X traffic. XDM originated in X11R3; this first version, written by Keith Packard of the MIT X Consortium, had several limitations, the most notable of, that it could not detect 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. With XDMCP, the X server must request a display manager connection from the host. An X server using XDMCP therefore no longer requires an entry in Xservers; the X Window System supplies XDM as its standard display manager. Programmers have developed other X display managers, both commercial and free, offering additional functionality over the basic display management: SDDM, the successor of the KDM, written in C++11, theming via QML GDM LightDM, a lightweight, cross-desktop themeable desktop display manager by Canonical Ltd. KDM allows the user to graphically select a window manager or desktop environment in the login screen Qingy ultralight and configurable graphical login independent on X Window XDM-OPTIONS for XDM. Easy full install, Xhost Phonebook, X Login, X Desktop Chooser, menu-reconfig, repair utils.
LDM, the Display Manager of the Linux Terminal Server Project MDM, a graphical display manager developed for Linux Mint. dtlogin scologin checks for expired passwords and performs some administrati
XDarwin was a display server supporting the X Window System ported to run on the Mac OS X and Darwin operating systems. It permitted the use of programs written for X11 on those operating systems. XDarwin was ported by the XonX project, an offshoot project created by XFree86 developers, it is integrated in the upstream source code of the XFree86 and Xorg servers, where it is maintained. XDarwin required an X window manager to run. For this task, a window manager called. More recent versions of XDarwin can run in rootless mode, to say that it integrates with the native window manager instead of requiring such a program for X. Before the introduction of Apple's X11.app, XDarwin was the only X11 server available for OS X. According to the XonX project, X11.app itself contains code from XDarwin. Programs such as OpenOffice.org use XDarwin to run in the X11 windowing environment, either in a rootless or full-screen mode. A version of the program was created for Mac OS X Panther or higher that runs in the native Aqua interface.
MacX – X11 support on Classic Mac OS X.org – Official home of the X Window System X on Darwin and Mac OS X from X11R7.0 documentation XonX project OroborOSX
Simple Desktop Display Manager
Simple Desktop Display Manager is a display manager for the X11 and Wayland windowing systems. SDDM was written from scratch in C++11 and supports theming via QML. SDDM is free and open-source software subject to the terms of the GNU General Public License version two or later. In 2013, Fedora KDE members decided to default to SDDM in Fedora 21. KDE chose SDDM to be the successor of the KDE Display Manager for KDE Plasma 5; the LXQt developers recommend SDDM as a display manager. GDM, the default graphical login program of GNOME LightDM, the default graphical login program of Ubuntu