X.Org Server


X.Org Server is the free and open-source implementation of the X Window System display server stewarded by the X.Org Foundation.
Implementations of the client-side X Window System protocol exist in the form of X11 libraries, which serve as helpful APIs for communicating with the X server. Two such major X libraries exist for X11. The first of these libraries was Xlib, the original C language X11 API, but another C language X library, XCB, was created later in 2001. Other smaller X libraries exist, both as interfaces for Xlib and XCB in other languages, and as smaller standalone X libraries.
The services with which the X.Org Foundation supports X Server include the packaging of the releases; certification ; evaluation of improvements to the code; developing the web site, and handling the distribution of monetary donations. The releases are coded, documented, and packaged by global developers.

Software architecture

The X.Org Server implements the server side of the X Window System core protocol version 11 and extensions to it, e.g. RandR.
Version 1.16.0 integrates support for systemd-based launching and management which improved boot performance and reliability.

Device Independent X (DIX)

The Device Independent X is the part of the X.Org Server that interacts with clients and implements software rendering. The main loop and the event delivery are part of the DIX.
An X server has a tremendous amount of functionality that must be implemented to support the X core protocol. This includes code tables, glyph rasterization and caching, XLFDs, and the core rendering API which draws graphics primitives.

Device Dependent X (DDX)

The Device Dependent X is the part of the x-server that interacts with the hardware. In the X.Org Server source code, each directory under "hw" corresponds to one DDX. Hardware comprises graphics cards as well as mouse and keyboards. Each driver is hardware specific and implemented as a separate loadable module.

2D graphics driver

For historical reasons the X.Org Server still contains graphics device drivers supporting some form of 2D rendering acceleration. In the past, mode-setting was done by an X-server graphics device driver specific to some video controller hardware. To this mode-setting functionality, additional support for 2D acceleration was added when such became available with various GPUs. The mode-setting functionality was moved into the DRM and is being exposed through a DRM mode-setting interface, the new approach being called "kernel mode-setting". But the 2D rendering acceleration remained.
In Debian the 2D graphics drivers for the X.Org Server are packaged individually and called xserver-xorg-video-*. After installation the 2D graphics driver-file is found under /usr/lib/xorg/modules/drivers/. The package xserver-xorg-video-nouveau installs nouveau_drv.so with a size of 215 KiB, the proprietary Nvidia GeForce driver installs an 8 MiB-sized file called nvidia_drv.so and Radeon Software installs fglrx_drv.so with a size of about 25MiB.
The available free and open-source graphics device drivers are being developed inside of the Mesa 3D-project. While these can be recompiled as required, the development of the proprietary DDX 2D graphics drivers is greatly eased when the X.Org Server keeps a stable API/ABI across multiple of its versions.
With version 1.17 a generic method for mode-setting was mainlined. The xf86-video-modesetting package, the Debian-package being called xserver-xorg-video-modesetting, was retired, and the generic modesetting DDX it contained was moved into the server package to become the KMS-enabled default DDX, supporting the vast majority of AMD, Intel and NVidia GPUs.
On April 7, 2016, AMD employee Michel Dänzer released xf86-video-ati version 7.7.0 and xf86-video-amdgpu version 1.1.0, the latter including support for their Polaris microarchitecture.
Acceleration architectures
There are XAA, EXA, UXA and SNA.
In the X Window System, XFree86 Acceleration Architecture is a driver architecture to make a video card's 2D hardware acceleration available to the X server. It was written by Harm Hanemaayer in 1996 and first released in XFree86 version 3.3. It was completely rewritten for XFree86 4.0. It was removed again from X.Org Server 1.13.
Most drivers implement acceleration using the XAA module. XAA is on by default, though acceleration of individual functions can be switched off as needed in the server configuration file.
The driver for the ARK chipset was the original development platform for XAA.
In X.Org Server release 6.9/7.0, EXA was released as a replacement for XAA, as XAA supplies almost no speed advantage for current video cards. EXA is regarded as an intermediate step to converting the entire X server to using OpenGL.
Glamor
Glamor is a generic, hardware independent, 2D acceleration driver for the X server that translates the X render primitives into OpenGL operations, taking advantage of any existing 3D OpenGL drivers. In this way, it is functionally similar to Quartz Extreme and QuartzGL for Apple Quartz Compositor.
The ultimate goal of GLAMOR is to obsolete and replace all the DDX 2D graphics device drivers and acceleration architectures, thereby avoiding the need to write X 2D specific drivers for every supported graphic chipset. Glamor requires a 3D driver with support for shaders.
Glamor performance tuning was accepted for Google Summer of Code 2014. Glamor supports Xephyr and DRI3, and can boost some operations by 700–800%. Since its mainlining into version 1.16 of the X.Org Server, development on Glamor was continued and patches for the 1.17 release were published.
Virtualization
There is a distinct and special DDX for instances of the X.Org Server which run on a guest system inside of a virtualized environment: xf86-video-qxl, a driver for the "QXL video device". SPICE makes use of this driver though it works without it as well.
In the Debian repositories it is called xserver-xorg-video-qxl, cf. https://packages.debian.org/buster/xserver-xorg-video-qxl

Input stack

Under Debian, drivers related to input are found under /usr/lib/xorg/modules/input/. Such drivers are named e.g. evdev_drv.so, mouse_drv.so, synaptics_drv.so or wacom_drv.so.
With version 1.16, the X.Org Server obtained support for the libinput library in form of a wrapper called xf86-input-libinput. At the XDC 2015 in Toronto, libratbag was introduced as a generic library to support configurable mice. xserver-xorg-input-joystick is the input module for the X.Org server to handle classic joysticks and gamepads, which is not meant for playing games under X, but to control the cursor with a joystick or gamepad.

Other DDX components

; XWayland
; XQuartz
; Xspice
; Xephyr
; RandR

IPC

The X.Org Server, and any x-client, each run as distinct processes. On Unix/Linux, a process knows nothing about any other processes. For it to communicate with another process, it is completely and utterly reliant on the kernel to moderate the communication via available inter-process communication mechanisms.
Unix domain sockets are used to communicate with processes running on the same machine. Special socket function calls are part of the System Call Interface. Although Internet domain sockets can be used locally, Unix domain sockets are more efficient, since they do not have the protocol overhead.
X.Org Server does not use D-Bus.
Sockets are the most common interprocess communication method between the processes of the X server and its various X clients. It provides the Application Programming Interface for communication in the TCP/IP domain and also locally only in the UNIX domain. There are several other APIs described in the X Transport Interface, for instance TLI. Other options for IPC between for the X client-server, require X Window system extensions, for instance the MIT Shared Memory Extension.

Multiseat configuration

Multi-seat refers to an assembly of a single computer with multiple "seats", allowing multiple users to sit down at the computer, log in, and use the computer at the same time independently. The computer has multiple keyboards, mice, and monitors attached to it, each "seat" having one keyboard, one mouse and one monitor assigned to it. A "seat" consists of all hardware devices assigned to a specific workplace. It consists of at least one graphics device and a keyboard and a mouse. It can also include video cameras, sound cards and more.
Due to limitation of the VT system in the Linux kernel and of the X core protocol, multi-seat does not work out-of-the-box for the usual Linux distribution but necessitates a special configuration.
There are these methods to configure a multi-seat assembly:
  • multiple Xephyr servers over a host xorg-server
  • multiple instances of an xorg-server
  • * one graphics card per seat
  • * a single graphics card for all seats
The utilized command-line options of the xorg-server are:
  • -isolateDevice bus-id Restrict device resets to the device at bus-id. The bus-id string has the form bustype:bus:device:function. At present, only isolation of PCI devices is supported; i.e., this option is ignored if bustype is anything other than 'PCI'.
  • vtXX the default for e.g. Debian 9 Stretch is 7, i.e. by pressing ++ the user can switch to the VT running the xorg-server.
Only the user on the first monitor has the use of vt consoles and can use ++x to select them. The other users have a GDM login screen and can use xorg-server normally, but have no vt's.
Even though a single user can utilize multiple monitors connected to the different ports of a single graphics card, the method which is based on multiple instances of the xorg-server seems to require multiple PCI graphics cards.
It is possible to configure multi-seat employing only one graphics card, but due to limitations of the X protocol this necessitates the usage of X Display Manager Control Protocol XDMCP.
There is also Xdmx.