X.Org Server

File:Xdpyinfo screenshot.png

The X.Org Server implements the server side of the X Window System core protocol version 11 (X11) and extensions to it, e.g. RandR.{{cite web |url=http://cgit.freedesktop.org/xorg/xserver/tree/randr |title=git: xorg-server, RandR}}

Version 1.16.0 integrates support for systemd-based launching and management which improved boot performance and reliability.

The Device Independent X (DIX) 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.{{Cite web|url=https://www.x.org/wiki/Development/Documentation/Glossary/|title=Glossary|website=X.org}}

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.

The Device Dependent X (DDX) 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.

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 (e.g., a GPU). 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" (KMS). 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-*.{{Cite web|url=https://packages.debian.org/stretch/xserver-xorg-video-nouveau|title=Details of package xserver-xorg-video-nouveau in stretch|website=packages.debian.org}} 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{{cite web |url=https://lists.x.org/archives/xorg-announce/2016-April/002684.html |title=[ANNOUNCE] xf86-video-ati 7.7.0 |date=2016-04-07}} and xf86-video-amdgpu version 1.1.0,{{cite web |url=https://lists.x.org/archives/xorg-announce/2016-April/002686.html |title=[ANNOUNCE] xf86-video-amdgpu 1.1.0 |date=2016-04-07}} the latter including support for their Polaris microarchitecture.

There are (at least) XAA (XFree86 Acceleration Architecture),{{cite web|url=http://www.xfree86.org/3.3.6/ark3.html|title=Information for ARK Logic Chipset Users: Acceleration|website=XFree86.org|access-date=22 September 2018|url-status=live|archive-url=https://web.archive.org/web/20180623033423/http://www.xfree86.org/3.3.6/ark3.html|archive-date=23 June 2018}} EXA, UXA and SNA.

File:Linux graphics drivers 2D.svg.]]

In the X Window System, XFree86 Acceleration Architecture (XAA) is a driver architecture to make a video card's 2D hardware acceleration available to the X server.{{cite web |last1=Anholt |first1=Eric |title=High Performance X Servers in the Kdrive Architecture |url=https://www.usenix.org/legacy/event/usenix04/tech/freenix/full_papers/anholt/anholt_html/ |website=www.usenix.org |access-date=14 September 2018}}{{cite web |last1=Wetzel |first1=Robert |title=An acceleration architecture for DOpE |url=http://wwwos.inf.tu-dresden.de/papers_ps/wetzel-diplom.pdf |website=wwwos.inf.tu-dresden.de |access-date=14 September 2018}} It was written by Harm Hanemaayer in 1996 and first released in XFree86 version 3.3. It was completely rewritten for XFree86 4.0.{{cite web|title=Release Notes for XFree86 4.0|url=http://www.xfree86.org/4.0/RELNOTES2.html#6|website=XFree86 Project|date=7 March 2000|access-date=16 September 2018}} 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 (XF86Config or xorg.conf).

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 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.{{cite web|title=What is Glamor?|url=http://www.freedesktop.org/wiki/Software/Glamor/|publisher=FreeDesktop.org|access-date=10 February 2014}} In this way, it is functionally similar to Quartz Extreme and QuartzGL (2D performance acceleration) 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.{{cite web|last=Anholt|first=Eric|title=Building 2D rendering acceleration with OpenGL|url=http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/52-Building_2D_rendering_acceleration_with_OpenGL_-_Eric_Anholt.mp4|publisher=linux.conf.au|access-date=10 February 2014|archive-date=4 March 2016|archive-url=https://web.archive.org/web/20160304064444/http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/52-Building_2D_rendering_acceleration_with_OpenGL_-_Eric_Anholt.mp4|url-status=dead}}{{cite web|last=Packard|first=Keith|title=Brief Glamor Hacks|url=http://keithp.com/blogs/glamor-hacking/|access-date=7 March 2014}}{{cite web |url=http://wiki.x.org/wiki/Events/XDC2013/XDC2013AdamJacksonGLXRewrite/ |title=Adam Jackson - GLX rewrite |date=24 September 2013 |access-date=2014-03-23}} Glamor requires a 3D driver with support for shaders.{{cite web |url=http://xorg.freedesktop.org/wiki/RadeonFeature/ |title=Radeon Feature Matrix |work=freedesktop.org}}

Glamor performance tuning was accepted for Google Summer of Code 2014.{{Cite web|url=http://www.google-melange.com/gsoc/project/details/google/gsoc2014/degasus/5639274879778816|title=Glamor Performance Tuning|access-date=22 April 2014|archive-date=24 September 2015|archive-url=https://web.archive.org/web/20150924023047/http://www.google-melange.com/gsoc/project/details/google/gsoc2014/degasus/5639274879778816|url-status=dead}} Glamor supports Xephyr and DRI3,{{cite web |url=https://www.phoronix.com/scan.php?page=news_item&px=MTYyMjc |title=GLAMOR Xephyr & DRI3 Support Called For Pulling |publisher=Phoronix |date=5 March 2014}} and can boost some operations by 700–800%.{{cite web |url=https://www.phoronix.com/scan.php?page=news_item&px=MTYyODU |title=GLAMOR Patch Bomb Can Boost Some Operations By 700~800% |publisher=Phoronix |date=13 March 2014}} 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.{{cite web |url=http://lists.x.org/archives/xorg-devel/2014-July/043106.html |title=glamor changes for 1.17 |date=17 July 2014}}

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

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.{{Cite web|url=http://who-t.blogspot.com/2014/09/libinput-common-input-stack-for-wayland.html|title=libinput - a common input stack for Wayland compositors and X.Org drivers|first=Peter|last=Hutterer|date=24 September 2014}} At the XDC 2015 in Toronto, libratbag was introduced as a generic library to support configurable mice.{{Cite web|url=https://www.x.org/wiki/Events/XDC2015/Program/hutterer_tissoires_libratbag.html|title=libratbag|website=X.org}}{{Cite web|url=https://www.x.org/wiki/Events/XDC2015/Program/tissoires_input_debug_tools.html|title=Tools to debug a broken input device|website=X.org}} 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.{{cite web |url=http://www.x.org/wiki/Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdf |title=XDC2012: xorg-input-joystick |type=pdf}}{{Cite web|url=https://packages.debian.org/stable/xserver-xorg-input-joystick|title= Details of package xserver-xorg-input-joystick in buster|website=packages.debian.org}}

; {{Anchor|XWayland}} XWayland

: XWayland is a series of patches over the X.Org server codebase that implement an X server running upon the Wayland protocol. The patches are developed and maintained by the Wayland developers for compatibility with X11 applications during the transition to Wayland,{{cite web|title=X Clients under Wayland (XWayland)|url=http://wayland.freedesktop.org/xserver.html|publisher=Wayland Project|access-date=10 February 2014}} and were mainlined in version 1.16 of the X.Org Server in 2014.{{cite web |url=http://lists.x.org/archives/xorg-announce/2014-July/002457.html |title=ANNOUNCE: xorg-server 1.16.0 |publisher=freedesktop.org |date=17 July 2014}} When a user runs an X application from within Weston, it calls upon XWayland to service the request.

{{cite web|title=Wayland|url=https://wiki.archlinux.org/index.php/wayland#XWayland|publisher=Arch Linux Project|access-date=2016-05-09}}

; {{Anchor|XQuartz}} XQuartz

: XQuartz is a series of patches from Apple Inc. to integrate support for the X11 protocol into their Quartz Compositor, in a similar way to how XWayland integrates X11 into Wayland compositors.

; Xspice

: Xspice is a device driver for the X.Org Server. It supports the QXL framebuffer device and includes a wrapper script{{cite web|url=http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/tree/README.xspice |title=XSpice README |publisher=Cgit.freedesktop.org |access-date=2013-10-25}} which makes it possible to launch an X.Org Server whose display is exported via the SPICE protocol. This enables use of SPICE in a remote desktop environment, without requiring KVM virtualization.

; Xephyr

: Xephyr is an X-on-X implementation. Since version 1.16.0, Xephyr serves as the primary development environment for the new 2D acceleration subsystem (Glamor), permitting rapid development and testing on a single machine.

; RandR

: RandR (resize and rotate) is a communications protocol written as an extension to the X11{{cite web|url=http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt|title=The X Resize, Rotate and Reflect Extension Version 1.3.1}} protocol. XRandR provides the ability to resize, rotate and reflect the root window of a screen. RandR is responsible for setting the screen refresh rate.{{cite book |last1=Tyler |first1=Chris |title=X Power Tools |date=2008 |publisher="O'Reilly Media, Inc." |isbn=9780596101954 |pages=86–87 |url=https://books.google.com/books?id=X9YRMIA899gC&q=%22XRandR%22+-wikipedia&pg=PA87 |access-date=14 September 2018 |language=en}} It allows for the control of multiple monitors.{{cite journal |last1=Gultsch |first1=Daniel |title=Dual Image » Linux Magazine |journal=Linux Magazine |date=2009 |issue=106 |url=http://www.linux-magazine.com/Issues/2009/106/Multi-heading-with-RandR}}

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 (IPC) 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 (checksums, byte orders, etc.).

X.Org Server does not use D-Bus.

Sockets are the most common interprocess communication (IPC) method between the processes of the X server and its various X clients. It provides the Application Programming Interface (API) 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 (Transport Layer Interface). Other options for IPC between for the X client-server, require X Window system extensions, for instance the MIT Shared Memory Extension (MIT-SHM).

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 (graphics card or just an output and the attached monitor) 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 (in particular, how X defines the relation between the root window and an output of the graphics card), 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 (output) to the device at bus-id. The bus-id string has the form bustype:bus:device:function (e.g., 'PCI:1:0:0'). 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 {{Key|Ctrl}}+{{Key|Alt}}+{{Key|F7}} 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 {{Key|Ctrl}}+{{Key|Alt}}+{{Key|F}}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 (cf. RandR), 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.{{Cite web|url=https://help.ubuntu.com/community/MultiseatOneCard|title=MultiseatOneCard - Community Help Wiki|website=help.ubuntu.com}}

There is also Xdmx (Distributed Multihead X).

; Unix and Linux

: The X.Org Server runs on many free-software Unix-like operating systems, including being adopted for use by most Linux distributions and BSD variants. It is also the X server for the Solaris operating system. X.Org is also available in the repositories of Minix 3.

; Windows

: Cygwin/X, Cygwin's implementation of the X server for Microsoft Windows, uses the X.Org Server, as do VcXsrv{{cite web|url=https://github.com/marchaesen/vcxsrv |title=VcXsrv Windows X Server |publisher=Github.com |access-date=2024-02-07}} (Visual C++ X-server{{cite web

| url = http://vcxsrv.sourceforge.net/

| title = VcXsrv Windows X Server

| website = SourceForge.net

| access-date = 2013-06-23

| quote = Windows X-server based on the xorg git sources (like xming or cygwin's xwin), but compiled with Visual C++ 2010.}}) and Xming. SSH clients such as PuTTY allow launching of X applications through X11 forwarding on the condition that it is enabled on both the server and client.

; OS X / macOS

: OS X versions prior to Mac OS X Leopard (10.5) shipped with an XFree86-based server, but 10.5's X server adopted the X.Org codebase.[http://lists.apple.com/archives/x11-users/2007/Jun/msg00026.html Re: Xorg in Leopard?] {{Webarchive|url=https://web.archive.org/web/20120213233353/http://lists.apple.com/archives/x11-users/2007/Jun/msg00026.html |date=13 February 2012 }}, From: Ben Byer, Date: 29 June 2007, Apple Mailing Lists Starting with OS X Mountain Lion, (10.8) X11 is not bundled in OS X; instead, it has to be installed from, for example, the open source XQuartz project.{{cite web | url=http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/ | title=Apple Removes X11 in OS X Mountain Lion, Shifts Support to Open Source XQuartz | publisher=MacRumors | date=17 February 2012 | access-date=23 February 2012 |last=Slivka |first=Eric}} As of version 2.7.4, X11.app/XQuartz does not expose support for high-resolution Retina displays to X11 apps, which run in pixel-doubled mode on high-resolution displays.

; OpenVMS

: Current versions of the DECwindows X11 server for OpenVMS are based on X.org Server.{{cite web

| url = https://vmssoftware.com/docs/VSI_OVMS_SPDQS_OS_V842L1I_UPD1.pdf

| title = Software Product Description and QuickSpecs - VSI OpenVMS Version 8.4-2L1 for Integrity servers

| publisher = VMS Software Inc.

| date = July 2019

| access-date = 2021-01-02

}}

{{Main article|X Window System#Release history|l1=Release history of the X Window System}}

File:Schema of the layers of the graphical user interface.svg and serves its clients.]]

The modern X.Org Foundation came into being in 2004 when the body that oversaw X standards and published the official reference implementation joined forces with former XFree86 developers.{{cite web|last=Coopersmith|first=Alan|title=The difference between Xorg and XFree86|url=https://blogs.oracle.com/solaris/the-difference-between-xorg-and-xfree86-v2|date=28 May 2004|access-date=17 September 2018}} X11R6.7.0, the first version of the X.Org Server, was forked from XFree86 4.4 RC2. The immediate reason for the fork was a disagreement with the new license for the final release version of XFree86 4.4, but several disagreements among the contributors surfaced prior to the split. Many of the previous XFree86 developers have joined the X.Org Server project.

In 2005, a great effort was put in the modularization of the X.Org server source code,{{cite web|title=X.Org Foundation Modularization Working Group|url=http://www.x.org/wiki/ModularizationWorkingGroup/|publisher=X.Org Foundation|access-date=6 February 2014}} resulting in a dual release by the end of the year. The X11R7.0.0 release added a new modular build system based on the GNU Autotools, while X11R6.9.0 kept the old imake build system, both releases sharing the same codebase. Since then the X11R6.9 branch is maintained frozen and all the ongoing development is done to the modular branch. The new build system also brought the use of dlloader standard dynamic linker to load plugins and drivers, deprecating the old own method. As a consequence of the modularization, the X11 binaries were moving out of their own /usr/X11R6 subdirectory tree and into the global /usr tree on many Unix systems.

In June 2006, another effort was done to move the X.Org server source codebase from CVS to git.{{cite web|last=Høgsberg|first=Kristian|title=Doing git migration now|date=July 2006 |url=http://lists.x.org/archives/xorg/2006-June/016439.html|access-date=6 February 2014}} Both efforts had the long-term goal of bringing new developers to the project. In the words of Alan Coopersmith:{{cite web|last=Coopersmith|first=Alan|title=Some times it's a book sprint, other times it's a marathon|url=https://blogs.oracle.com/solaris/some-times-its-a-book-sprint%2c-other-times-its-a-marathon-v2|access-date=12 January 2019}}

{{quote|Some of our efforts here have been technological - one of the driving efforts of the conversions from Imake to automake and from CVS to git was to make use of tools developers would already be familiar and productive with from other projects. The Modularization project, which broke up X.Org from one giant tree into over 200 small ones, had the goal of making it possible to fix a bug in a single library or driver without having to download and build many megabytes of software & fonts that were not being changed.}}

In the 7.1 release, the KDrive framework (a small implementation of X written by Keith Packard, which was not based on XFree86 that X.Org developers used as a testing ground for new ideas, such as EXA) was integrated into the main codebase of X.Org server.

In 2008, the new DRI2, based on the kernel mode-setting (KMS) driver, replaced DRI. This change also set a major milestone in the X.Org server architecture, as the drivers were moved out from the server and user space (UMS) to the kernel space.

In 2013, the initial versions of DRI3 and Present extensions were written and coded by Keith Packard to provide a faster and tearing-free 2D rendering. By the end of the year the implementation of GLX was rewritten by Adam Jackson at Red Hat.{{cite web |url=https://www.phoronix.com/scan.php?page=news_item&px=MTQ2OTY |title=The X.Org Server's GLX Is Being Rewritten |date=26 October 2013}}

{{See also|X Window System#Release history|XFree86#Release history}}

{{Portal|Free and open-source software}}

{{Div col|colwidth=25em}}

• Reference implementation{{snd}} part of a standard release package
• X window manager{{snd}} a package that is deliberately kept separate from the X server package
• X video extension
• evdev
• xorg.conf
• XQuartz - An X server for macOS
• Xming - An X server for Windows
• Xenocara

{{div col end}}

{{Reflist|30em}}

{{Commons category}}

• {{Official website|https://www.x.org/}}
• [https://github.com/marchaesen/vcxsrv VcXsrv] - a fully updated X server for Windows
• [https://sourceforge.net/projects/vcxsrv/ VcXsrv] - Sourceforge old repository for Windows

{{XWinSys}}

{{Freedesktop.org}}

Category:X servers

Category:Freedesktop.org

Category:Software forks

Category:Software that uses Meson