Hubbry Logo
X.Org ServerX.Org ServerMain
Open search
X.Org Server
Community hub
X.Org Server
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
X.Org Server
X.Org Server
X.Org Server
View on Wikipedia
from Wikipedia

X.Org Server
DeveloperX.Org Foundation
Initial release6 April 2004; 21 years ago (2004-04-06)[1]
Stable release
21.1.18[2] Edit this on Wikidata / 18 June 2025
Repository
Written inC
Operating systemCross-platform
Size3.7 MiB[3]
Available inEnglish
TypeDisplay server
LicenseMIT License
Websitex.org

X.Org Server is the free and open-source implementation of the X Window System (X11) 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.[4] Two such major X libraries exist for X11. The first of these libraries was Xlib, the original C language X11 API,[5] but another C language X library, XCB, was created later in 2001.[6] Other smaller X libraries exist, both as interfaces for Xlib and XCB in other languages, and as smaller standalone X libraries.[citation needed]

The services with which the X.Org Foundation supports X Server include the packaging of the releases; certification (for a fee); evaluation of improvements to the code; developing the web site, and handling the distribution of monetary donations.[citation needed] The releases are coded, documented, and packaged by global developers.[clarification needed]

Software architecture

[edit]
xdpyinfo, a command to show X.Org Server information

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.[7]

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

Device Independent X (DIX)

[edit]

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.[9]

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)

[edit]

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.

2D graphics driver

[edit]

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-*.[10] 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[11] and xf86-video-amdgpu version 1.1.0,[12] the latter including support for their Polaris microarchitecture.

Acceleration architectures
[edit]

There are (at least) XAA (XFree86 Acceleration Architecture),[13] EXA, UXA and SNA.

XAA is an API between the Device-Independent-X (DIX) and the Device-Dependent-X (DDX), a 2D graphics driver, here e.g. with the Linux kernel.

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.[14][15] It was written by Harm Hanemaayer in 1996 and first released in XFree86 version 3.3. It was completely rewritten for XFree86 4.0.[16] 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
[edit]

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.[17] 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.[18][19][20] Glamor requires a 3D driver with support for shaders.[21]

Glamor performance tuning was accepted for Google Summer of Code 2014.[22] Glamor supports Xephyr and DRI3,[23] and can boost some operations by 700–800%.[24] 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.[25]

Virtualization
[edit]

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

[edit]

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.[26] At the XDC 2015 in Toronto, libratbag was introduced as a generic library to support configurable mice.[27][28] 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.[29][30]

Other DDX components

[edit]
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,[31] and were mainlined in version 1.16 of the X.Org Server in 2014.[8] When a user runs an X application from within Weston, it calls upon XWayland to service the request.[32]
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[33] 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.[8]
RandR
RandR (resize and rotate) is a communications protocol written as an extension to the X11[34] 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.[35] It allows for the control of multiple monitors.[36]

IPC

[edit]

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).

Multiseat configuration

[edit]

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 Ctrl+Alt+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 Ctrl+Alt+Fx 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.[37]

There is also Xdmx (Distributed Multihead X).

Adoption

[edit]
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[38] (Visual C++ X-server[39]) 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.[40] 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.[41] 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.[42]

History

[edit]
Main article: Release history of the X Window System
A display server, such as X.Org Server, implements the windowing system 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.[43] X11R6.7.0, the first version of the X.Org Server, was forked from XFree86 4.4 RC2.[1] 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,[44] 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.[45] Both efforts had the long-term goal of bringing new developers to the project. In the words of Alan Coopersmith:[46]

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.[47]

Releases

[edit]
See also: X Window System § Release history, and XFree86 § Release history
Version Date X11 Release Main features
Unsupported: 1.0 21 December 2005[48] X11R7.0 (1.0.1) Initial modularized X server, EXA architecture
Unsupported: 1.1 22 May 2006[49] X11R7.1 (1.1.0) KDrive integration, AIGLX support[50]
Unsupported: 1.2 22 January 2007[51] X11R7.2 (1.2.0) Autoconfiguration, enhanced support for GL-based compositing managers[52]
Unsupported: 1.3 19 April 2007[53] RandR 1.2[54]
Unsupported: 1.4 6 September 2007[55] X11R7.3 (1.4.0) Input hotplugging support[55][56]
Unsupported: 1.5 3 September 2008[57] X11R7.4 (1.5.1) MPX[58]
Unsupported: 1.6 25 February 2009[59] RandR 1.3, DRI2, XInput 1.5[60]
Unsupported: 1.7 1 October 2009[61] X11R7.5 (1.7.1) XInput 2.0, multi-pointer X[62][63]
Unsupported: 1.8 2 April 2010[64] xorg.conf.d, udev input handling[65]
Unsupported: 1.9 20 August 2010[66] X11R7.6 (1.9.3)
Unsupported: 1.10 25 February 2011[67] X Synchronization Fences[68]
Unsupported: 1.11 26 August 2011[69]
Unsupported: 1.12 4 March 2012[70] X11R7.7 (1.12.2) XInput 2.2 (including multi-touch support)[71]
Unsupported: 1.13 5 September 2012[72] New DDX driver API, DRI2 offload, RandR 1.4, OpenGL 3.x+ contexts, removing XAA[73]
Unsupported: 1.14 5 March 2013[74] XInput 2.3[75]
Unsupported: 1.15 27 December 2013[76] DRI3 and Present extensions[77][78]
Unsupported: 1.16 17 July 2014[79] XWayland DDX, GLAMOR acceleration, non-PCI devices support, systemd-logind support (rootless X),[79][80] obtained support for the libinput library in form of a wrapper called xf86-input-libinput[81][82]
Unsupported: 1.17 4 February 2015[83] Integration of the former xf86-video-modesetting generic DRM/KMS driver,[84][85] added support for DRI2 with GLAMOR
Unsupported: 1.18 9 November 2015[86] RandR 1.5
Unsupported: 1.19 15 November 2016[87] Threaded Input, PRIME synchronization, XWayland pointer confinement and warping, Windows DRI extension support[88]
Unsupported: 1.20 10 May 2018[89] Meson build system improvements, GLXVND allows for distinct OpenGL drivers for different X screens, RandR leasing improves Steam VR support
Latest version: 21.1 27 October 2021[90] Meson build system now on par with Autotools, Variable refresh rate support, touchpad gestures via XInput 2.4
Legend:
Unsupported
Supported
Latest version
Future version

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

X.Org Server

View on Grokipedia
from Grokipedia
The X.Org Server is the reference open-source implementation of the (X11) display server, a protocol that enables network-transparent graphical interfaces by distributing user input to client programs and rendering output on displays across operating systems. Initially designed for UNIX and UNIX-like systems on x86 hardware, it evolved from the project through a prompted by restrictive licensing changes in , prioritizing permissive terms to sustain collaborative development. Stewarded by the , a volunteer-driven non-profit, the server employs a modular with loadable drivers for diverse graphics hardware, forming the foundation for desktop environments in distributions and BSD systems for over two decades. Its defining characteristics include device independence and extensibility via extensions like XRender for , yet the core client-server model—where clients can manipulate shared resources—has causally contributed to persistent vulnerabilities, including flaws and privilege escalations, necessitating regular patches. Although feature development has halted in favor of maintenance and fixes amid the rise of Wayland compositors, X.Org Server endures in scenarios requiring broad hardware compatibility, such as with NVIDIA's proprietary drivers, underscoring its entrenched role despite design limitations exposed by modern threats.

Introduction

Definition and Purpose

The is the open-source implementation of the display server, adhering to the X11 protocol and maintained by the as part of collaborative efforts with the community. Designed principally for Unix and operating systems, it originated with support for x86 hardware but has expanded to numerous architectures, serving as the foundational component for graphical user interfaces in environments such as distributions. Its core purpose is to mediate between client applications and physical hardware, managing the rendering of windows, graphics primitives, and text on output devices while processing input from peripherals like keyboards, mice, and touchpads. The server operates in a client-server model where applications (clients) issue protocol requests over local or network connections to request drawing operations, event notifications, and resource allocation, thereby abstracting hardware complexities and enabling modular software design. This architecture supports essential functions including window hierarchy management, event dispatching for user interactions, and bitmap image handling, all executed through a combination of device-independent core logic and pluggable device-dependent modules for hardware specificity. By providing these services, the enables efficient sharing of display resources among multiple processes, fostering extensible graphical without mandating direct client access to low-level drivers.

Relation to X Window System

The is a networked, client-server protocol for managing bitmap displays, input devices, and on computing systems, originally developed at MIT in the 1980s. The X.Org Server constitutes the primary open-source implementation of the X server—the component that executes on the machine with the physical display hardware—adhering to the X11 protocol specification, which defines the core requests, events, and replies for rendering graphics, handling input, and maintaining window hierarchies. This implementation enables the separation of client applications (which generate draw commands) from the server (which rasterizes them onto screens), supporting where remote clients connect via TCP/IP or Unix domain sockets. Unlike earlier proprietary or closed implementations, the X.Org Server emerged from the codebase following a 2004 fork motivated by licensing disputes and issues, establishing it as the reference server under the stewardship of the and community. It incorporates both device-independent layers for protocol handling and device-dependent modules for hardware-specific drivers, ensuring compatibility with the X Window System's extensible architecture while prioritizing stability for Unix-like operating systems such as and BSD variants. This relation underscores the X.Org Server's role not as the protocol itself but as its runtime enforcer, facilitating features like multi-user sessions and extension mechanisms (e.g., for compositing or security) without altering the underlying X11 wire protocol. The X.Org Server's fidelity to X11 ensures with decades of applications, though it has evolved through modular redesigns—such as the 2010s shift toward runtime loading—to address limitations inherent in the original protocol's , which lacks built-in client-side rendering primitives. Despite criticisms of X11's aging model (e.g., lack of mandatory access controls), the X.Org Server remains the dominant implementation, powering graphical sessions in major distributions as of 2023.

Software Architecture

Device-Independent X (DIX)

The Device-Independent X () layer constitutes the core, hardware-agnostic portion of the X.Org Server, responsible for implementing the X11 protocol logic and managing interactions with client applications. It processes incoming requests from clients over the network or local transport, dispatching operations such as window creation, event handling, and without reference to specific input or output devices. This separation enables portability across diverse operating systems and architectures, as DIX code remains unchanged regardless of underlying hardware. Key functions of include software-based rendering as a fallback mechanism, where it performs bitmap operations and in user space when is unavailable or insufficient. It maintains abstract data structures for windows, pixmaps, and graphics contexts, enforcing protocol semantics like clipping, exposure events, and colormap management. Event processing in DIX involves queuing and distributing input from the device-dependent layer, ensuring delivery to appropriate clients while applying filters for grabs and focus. The main server loop, residing in DIX, orchestrates request dispatching, timer management, and synchronization primitives shared across server generations. DIX interfaces with the Device-Dependent X (DDX) layer through well-defined callbacks and structures, invoking DDX routines for hardware-specific tasks such as drawing primitives to framebuffers or querying device capabilities during initialization. For instance, at server startup, DIX calls DDX's InitOutput() to configure screens and input devices, populating shared structures like screenInfo with device-independent defaults that DDX overrides as needed. This modular boundary, established in early X11 implementations, supports extensions like XRender by providing protocol-level abstractions that DDX can accelerate. Maintenance of DIX focuses on protocol fidelity and performance optimizations, such as reducing event latency through batched processing, without altering device drivers.

Device-Dependent X (DDX)

The Device-Dependent X (DDX) layer in the X.Org Server comprises the hardware- and operating system-specific components that enable interaction with physical devices, such as graphics adapters, framebuffers, keyboards, and pointing devices. Unlike the device-independent layer, which manages protocol handling and core window system logic portably across platforms, the DDX translates abstract requests from the device-independent X () into vendor-specific operations, including screen initialization, colormap management, and for rendering primitives. This separation allows the X server to support diverse hardware configurations while maintaining a consistent interface for applications. In the X.Org implementation, the primary DDX is the XFree86 DDX, derived from the XFree86 project's modular architecture and housed in the hw/xfree86 source directory. This DDX provides entry points such as InitOutput for device probing and initialization, CloseScreen for cleanup, and input processing routines like ProcessInputEvents to handle events from the operating system's event queue. It incorporates sub-drivers for specific hardware, exemplified by the xf86-video-* modules (e.g., xf86-video-intel for Intel GPUs or xf86-video-nvidia for NVIDIA cards), which implement low-level functions for acceleration, mode setting, and output configuration. These drivers are dynamically loaded at runtime, supporting features like multi-head displays and varying pixel depths, with configuration often specified via the xorg.conf file or automatic detection via tools like xrandr. The DDX's design emphasizes portability through a well-defined interface to the DIX, including callbacks for graphics operations (e.g., filling rectangles or drawing lines via hardware-accelerated paths where available) and input extension support, such as for the X Input Extension (XIE) which enables multi-touch and tablet devices. Over time, enhancements in the XFree86 DDX have included support for EXA (X Acceleration) and SNA (Sandybridge's New Acceleration) as 2D renderers to optimize performance on modern GPUs, replacing older mechanisms like the FB dev framebuffer driver. However, the DDX remains tied to legacy X11 paradigms, contrasting with newer compositors that bypass it for direct rendering. This layer's evolution reflects ongoing efforts to balance backward compatibility with hardware advancements, as seen in X.Org Server releases up to version 21.1.0 in 2021, which refined DPI reporting and driver integration without altering core DDX boundaries.

Input and Graphics Drivers

The Device-Dependent X (DDX) layer of the incorporates modular input and graphics drivers to manage hardware interactions specific to the underlying platform and devices. These drivers are implemented as loadable modules, allowing the server to support diverse peripherals without core modifications; the modular design originated in 4.0 and was refined in X.Org releases. Input drivers process events from devices including keyboards, mice, touchscreens, and graphics tablets, converting raw hardware signals into standardized X protocol events for applications. Since X.Org Server version 1.17, released on October 22, 2015, the default driver is xf86-input-libinput, which integrates the libinput library to handle multi-touch gestures, pressure sensitivity, and hotplugging across unified input stacks. Earlier alternatives like xf86-input-evdev, supporting basic event devices since X.Org 1.7 in 2009, and xf86-input-synaptics for touchpad-specific features, remain available but are increasingly supplanted by libinput for its broader compatibility and reduced maintenance overhead. Configuration occurs via sections in xorg.conf or runtime detection, with drivers registering through the server's input extension framework to enable features like multi-seat support. Graphics drivers within the DDX initialize displays, set video modes, and accelerate 2D operations such as bit-blitting and glyph rendering. Hardware-specific modules under the xf86-video- prefix, including xf86-video-intel for integrated graphics (supporting chipsets from i915 onward) and xf86-video-amdgpu for modern GPUs, provide optimized acceleration via direct hardware access. However, starting with X.Org Server 1.18 on March 7, 2016, the generic modesetting driver has been recommended for primary use, delegating mode setting and buffer management to the Linux kernel's (DRM) and Kernel Mode Setting (KMS), which minimizes userspace code and enhances stability across vendors. This shift reflects a broader trend toward kernel-centric graphics stacks, rendering many legacy xf86-video- drivers obsolete for new hardware while retaining them for compatibility with older systems lacking KMS support. Proprietary drivers, such as NVIDIA's, bypass much of the open DDX by implementing custom extensions but adhere to the modular loading interface.

Inter-Process Communication and Extensions

The X.Org Server facilitates (IPC) primarily through the X11 protocol, which operates over reliable byte stream connections between clients and the server. These connections support , allowing local clients to use Unix domain sockets for low-latency communication and remote clients to connect via TCP/IP, with the protocol abstracting the underlying transport to ensure consistent behavior. The communication model is full-duplex and asynchronous: clients issue requests (e.g., to create windows or query attributes), which the server processes and responds to with replies or errors containing sequence numbers for matching; meanwhile, the server generates events (e.g., key presses or exposes) that are queued and delivered to subscribed clients without blocking requests. Sequence numbers track request ordering, preventing mismatches in multi-threaded or delayed scenarios, while the protocol's byte-order negotiation (via initial setup bytes) ensures compatibility across heterogeneous systems. For enhanced performance, the core protocol can be augmented by extensions like MIT-SHM (introduced in X11R5 around 1991), which enables segments for direct client-server data transfer, bypassing the stream for bulk operations such as image rendering, though it requires explicit client-server agreement on segment authorization. Local IPC defaults to Unix domain sockets (e.g., /tmp/.X11-unix/X0), providing via xauth cookies and file permissions, while abstract sockets (socket family PF_LOCAL with abstract ) offer namespace isolation without filesystem artifacts, a feature integrated in modern X.Org releases for compatibility with containerized environments. Extensions in the X.Org Server extend the core X11 protocol by allocating major opcodes from 128 to 255, allowing new request types, events, errors, and resources without altering the base specification; each extension defines its own minor opcodes and versioning for backward compatibility. Clients query support using the QueryExtension request, retrieving the extension's name, presence, and major/minor versions before issuing extension-specific requests, with libraries like Xlib or XCB handling initialization transparently. In X.Org implementations, extensions are loaded dynamically as modules (e.g., via xorg.conf or automatic detection) or compiled in, supporting features such as XRender (for anti-aliased 2D rendering, added in X11R6.8 around 2004), GLX (for OpenGL integration via indirect rendering, originating in X11R6 circa 1996), and Damage (for efficient window change notifications). Key modern extensions integral to X.Org Server functionality include XRandR (version 1.0 released 2001, enabling runtime display resizing, rotation, and multi-monitor modes without restarts), Composite (introduced 2004, allowing off-screen buffering for compositing window managers to reduce tearing and enable effects), and XInput2 (XI2, version 2.0 in 2009 with X.Org 1.7, supporting , device properties, and multiple independent pointers for multiseat setups). Synchronization is handled by the SYNC extension (circa 1990s, refined in X.Org), which introduces counters and alarms for precise event timing, such as vsync alignment to prevent . These extensions maintain the protocol's extensibility principle, with over 30 standard ones supported in typical X.Org deployments (queryable via xdpyinfo), though server configuration can disable non-essential ones for security or performance.

Multiseat and Configuration Options

The enables multiseat configurations, allowing multiple independent user sessions to run concurrently on a single host system, each with its own graphics outputs, input devices (such as keyboards and mice), and audio resources. This capability relies on running separate X server instances, typically one per , where a "seat" represents a collection of input and output devices logically grouped for a user, often managed by underlying systems like or systemd-logind for device assignment and hotplugging. Support for multiseat was enhanced in the X server around 2011 with the introduction of the -seat command-line option, which binds an X instance to a specific seat identifier (e.g., seat0 or seat1), preventing cross-seat interference in device access. Configuration for multiseat traditionally involves the xorg.conf file or directory-based snippets in xorg.conf.d, where sections like ServerLayout, InputDevice, Device, Monitor, and Screen define hardware bindings per seat. For static setups without hotplugging, a single xorg.conf can specify multiple ServerLayout sections, each activating distinct GPUs, inputs, and displays via options like BusID for PCI devices and Option "ZaphodHeads" "0,1" for partitioning a single GPU across seats (known as Zaphod mode, though limited for full independence). Modern dynamic configurations favor separate xorg.conf files per seat or command-line invocation (e.g., Xorg :0 -seat seat0 -config /etc/X11/xorg-seat0.conf), integrated with display managers such as GDM or the Multiseat Display Manager (MDM), which automate seat detection and session startup for multiple PCIe graphics cards. USB hotplugging is supported through udev rules assigning devices to seats via attributes like ID_SEAT, enabling plug-and-play for peripherals without restarting servers. Key configuration options relevant to multiseat include ServerFlags directives like Option "AutoAddDevices" "False" to disable automatic device probing and enforce manual seat-specific assignments, alongside input options such as Option "Ignore" "on" for unused devices. Audio and other resources require separate handling, often via or ALSA seat-aware modules to route sound per user session. While effective for environments like educational labs or thin-client servers, multiseat performance depends on hardware isolation (e.g., dedicated GPUs per seat to avoid sharing bottlenecks), and compatibility varies with drivers— ones like may need additional tweaks via nvidia-xconfig. As of X.Org Server releases post-1.10 (circa 2011), these features provide robust, verifiable multi-user support without requiring kernel modifications.

Core Features

Network Transparency

The X.Org Server implements through its adherence to the X11 protocol, enabling client applications executing on remote hosts to connect to the server over a network and interact with local display hardware as if operating locally. This client-server architecture distributes rendering requests from clients to the server, which handles output on the attached display while forwarding input back to the originating clients. The protocol specifies a wire format for requests, , and errors, ensuring compatibility across heterogeneous systems without requiring client-side knowledge of the server's hardware details. Communication occurs primarily over TCP/IP for network connections, with clients initiating a connection by specifying a display identifier in the format hostname:displaynumber[.screennumber], where hostname resolves to the server's . Local connections use Unix domain sockets for efficiency, bypassing network overhead, while remote access leverages IPv4 or addresses as defined in the protocol's address families. The Xlib library, integral to client-side implementation, supports these transports via functions like XOpenDisplay, which abstracts the underlying protocol details. This design originated from the X Window System's core principles, established in X Version 11 (released in September 1987), prioritizing portability and separation of user interface logic from device dependencies. Access control is managed server-side through mechanisms like the xhost utility, which maintains an list of permitted client hosts, though default configurations permit broad access unless explicitly restricted via MIT-MAGIC-COOKIE-1 or similar extensions. For secure remote execution, tools like SSH with X11 forwarding tunnel connections over encrypted channels, mitigating risks of unencrypted protocol exposure. Extensions enhance transparency; for instance, the X Display Manager Control Protocol (XDMCP, specified in 1988) allows remote login sessions where the server queries available displays over UDP broadcasts or indirect queries, facilitating thin-client setups. However, the protocol's request-response model incurs latency from frequent round trips for rendering primitives, such as individual pixel operations, which can degrade performance over high-latency links compared to modern alternatives like RDP that optimize framebuffer updates. Despite this, X.Org Server's implementation remains extensible, supporting auxiliary protocols layered atop X11 for input methods or session management without altering core transparency.

Rendering and Display Management

The X.Org Server's rendering capabilities are rooted in the core X11 protocol, which employs a request-response model where client applications send —such as lines, rectangles, and text—to the server for rasterization and display on hardware. This server-side rendering approach ensures but limits efficiency for modern , as the server lacks native support for client-side rendering until extensions intervene. To address these limitations, the X Rendering Extension (XRender), first specified in version 0.6 around 2001 and refined to version 0.11 by 2008, introduces a composition-based 2D model using picture objects for images with alpha channels, supporting operations like blending, transformation, and glyph rendering for improved and subpixel accuracy. Complementing this, the Composite extension, integrated since X11R6.8 in 2004, redirects window hierarchies to off-screen pixmaps, enabling managers (e.g., those using extension for efficient updates) to perform server-side blending of windows with transparency, shadows, and animations without direct hardware access. These extensions collectively form the basis for damage-tracking , where only changed regions are re-rendered, though performance remains constrained compared to direct GPU rendering in successors like Wayland. Display management in the X.Org Server handles screen layouts, resolutions, and outputs via extensions evolving from static configurations. Early multi-monitor support relied on for spanning a single logical screen across devices, but since X11R6.9 in 2005, the Resize and Rotate (RandR) extension—reaching version 1.4 by —provides dynamic reconfiguration, allowing runtime /removal of monitors, mode setting (e.g., resolutions up to 8K supported in recent drivers), rotation, and topology changes like panning or mirroring without server restarts. RandR 1.4 specifically enables output cloning and per-output , with server versions from 1.13 onward supporting offloading display tasks to secondary GPUs for hybrid setups. Configuration occurs via tools like xrandr, interfacing with kernel modesetting (KMS) drivers for control, ensuring atomic updates to prevent tearing across multiple displays with differing refresh rates (e.g., 60Hz and 144Hz).

Compatibility and Extensibility

The X.Org Server preserves with the X11 protocol, which has remained stable since its major version 11 release in 1987, enabling applications developed decades ago to interoperate with contemporary server implementations without protocol-level modifications. This stability stems from the protocol's design, where core features avoid breaking changes, though minor extensions and server-side optimizations may evolve; for instance, Xwayland provides a for running X11 clients on Wayland compositors while bridging to X.Org Server primitives. Server releases prioritize ABI consistency for loadable modules in stable branches to minimize disruptions for driver vendors, incrementing minor ABI versions only for compatible additions and avoiding incompatible shifts unless necessary for security or functionality. Extensibility is achieved through the X11 protocol's built-in extension mechanism, which allows optional features to be negotiated at connection time without altering the core protocol, as seen in extensions like XRender for efficient 2D anti-aliased rendering and RandR (Resize and Rotate) for dynamic display reconfiguration, including setups and resolution changes. extends the server for integration, enabling hardware-accelerated via vendor-specific drivers, while XInput2 supports advanced input devices with and gesture capabilities. The server's modular architecture further enhances this by loading components such as video drivers, input drivers, and font rasterizers dynamically from separate modules, facilitating updates without rebuilding the entire server; this design, refined since X11R6.7, uses ABI versioning to ensure module compatibility across releases where possible. Extensions like Composite for off-screen rendering and Sync for precise event timing build on this foundation, supporting compositing window managers and synchronized applications.

History

Origins in X Window System (1980s-1990s)

The , the foundational protocol and architecture for what would become the X.Org Server, emerged in 1984 at the (MIT) under , a U.S. Department of Defense-funded initiative to create tools for educational environments. aimed to integrate workstations from multiple vendors, prompting the need for a hardware-agnostic ; initial efforts focused on displays and to allow remote applications to render locally without . Robert W. Scheifler of MIT's Laboratory for implemented the prototype server in June 1984 for a VS100 , drawing on prior systems like WFS but prioritizing client-server separation where the server managed devices and clients handled application logic. Jim Gettys of collaborated closely, emphasizing simplicity and extensibility in the design. By 1986, X version 10 (X10) was released, introducing core concepts like the device-independent X () layer for protocol handling and device-dependent X (DDX) for hardware adaptation, which separated rendering logic from physical display management to support diverse architectures. This version supported basic window creation, event handling, and bitmap operations but lacked mature extensions for color or fonts. X11, released in September 1987, stabilized the protocol at version 11—still the basis for modern X servers—and added features like multi-window support, asynchronous event processing, and a request-response model over TCP/IP for remote execution. Funding from (DEC) and contributions from vendors like enabled portability testing across systems, with the protocol formalized in releases documented by Scheifler, Gettys, and Ron Newman. The X Consortium, formed in 1988, assumed stewardship, releasing X11R1 through R4 by 1989 to refine server-client communication and introduce rudimentary security via host-based access controls. In the 1990s, X11 evolved through consortium-led releases that addressed scalability for emerging hardware, with X11R5 in November 1991 incorporating the X Toolkit Intrinsics (Xt) for widget-based applications and improved font rendering via the X Font Server (Xfs). X11R6, released in October 1994, added (Inter-Client Exchange) for communication, XDMCP for display management, and extensions like XIE for image processing, reflecting growing adoption on workstations from HP, , and DEC. These advancements emphasized the server's role in abstracting graphics hardware, enabling device-dependent drivers to interface with the core layer for rendering primitives such as lines, arcs, and bitblts. Independent efforts, including early X servers for x86 PCs, laid groundwork for open-source implementations; for instance, X386 in 1987 targeted hardware, influencing later free distributions. By the mid-1990s, X's architecture proved resilient, supporting over 100 vendors and forming the backbone for UNIX desktop environments, though server code remained partially until community-driven forks emerged.

Formation of X.Org Foundation (2004)

The was established on January 22, 2004, as a non-profit corporation incorporated in to oversee the stewardship and advancement of the . It succeeded the X.Org Group previously hosted by The Open Group, which had managed X standards following the dissolution of the original X Consortium in the 1990s. The foundation's charter emphasized fostering the development, evolution, and improvement of graphical display technologies, particularly open-source alternatives to proprietary systems, through community-driven governance open to all contributors. The formation arose amid escalating tensions within the project, which had been the primary steward of X server development since the late . In late , XFree86's core maintainers introduced a restrictive licensing scheme—the XFree86 License 1.1—for its impending 4.4 release, alongside changes that centralized control and alienated contributors by limiting code redistribution freedoms compared to prior X11 licenses. This prompted a group of prominent developers, including those from , SuSE, and other vendors, to the XFree86 4.3 codebase in early 2004, rebranding it under the X.Org banner to preserve permissive licensing and collaborative development. The ensured continuity of X server evolution without the encumbrances, with the foundation providing legal and organizational structure to coordinate releases and funding for activities like developer workshops. By April 2004, the released X11R6.7, marking the first major community-led update since the fork and signaling broad adoption by distributions seeking to avoid XFree86's trajectory. This transition revitalized X development, emphasizing modular architecture and integration with emerging technologies like extensions, while the foundation's open model contrasted with XFree86's decline post-fork. Initial efforts included the first X.Org Developers' Conference from April 28 to 30, 2004, in , to align contributors on priorities.

Key Releases and Evolutions (2004-2020)

The X.Org Server emerged in 2004 following the formation of the X.Org Foundation on January 22, which forked the codebase from XFree86 amid licensing disputes, releasing initial versions such as X11R6.7.0 and X11R6.8.0 on December 29 to maintain open-source compatibility and continuity for Unix-like systems. These early releases focused on stabilizing the server for broad hardware support, incorporating bug fixes and driver enhancements from the XFree86 4.4 branch without restrictive licensing. A pivotal evolution occurred with the approval of the modularization proposal on April 17, 2005, which decomposed the monolithic codebase into independent modules for drivers, libraries, and the server core, enabling parallel development and easier maintenance. This culminated in X11R7.0 on December 21, 2005, the first fully modularized release, with the X.Org Server adopting version 1.0 in January 2006, introducing autotooled builds and integration for simplified compilation across distributions. Subsequent X11R7.1 on May 22, 2006, rolled out the modular server in a unified package, emphasizing independent updates for components like input and rendering extensions. From 2007 to 2010, releases such as X11R7.2 (February 15, 2007) added autoconfiguration for hardware detection, while X11R7.4 (September 23, 2008) improved input event handling and server performance for setups via enhanced RandR support. X11R7.5 (December 19, 2010) and X11R7.6 (December 20, 2010) refined multi-head configurations and GL-based , addressing rendering efficiency for desktop environments. In the 2010s, server versions progressed with X.Org Server 1.7 (2009) introducing XInput 2.0 for and configurable devices, followed by 1.10 (2011) defaulting to modesetting drivers for dynamic resolution changes. By 1.16 (July 2014), integration with systemd-logind enabled seamless session management, and 1.20 (May 5, 2018) incorporated DRI3 protocol versions 1.1 and 1.2 for advanced buffer management and via GLAMOR, alongside fixes for BigReq protocol handling to mitigate resource exhaustion. Maintenance releases through 2020, including 1.20.10, prioritized security patches for vulnerabilities like privilege escalations in virtual framebuffers.

Recent Developments (2021-2025)

In 2021, the X.Org Server released version 21.1 on October 27, incorporating enhancements for rendering pipelines and hardware support while maintaining with X11 clients. Subsequent development shifted toward stability and maintenance, with point releases addressing bugs and vulnerabilities rather than introducing major new features, as upstream efforts increasingly prioritized Wayland for future graphical stacks. Throughout 2022–2024, the project issued incremental updates integrated into distributions, focusing on compatibility fixes for evolving desktop environments and drivers, though no flagship versions were announced, reflecting a stabilization phase amid declining active feature contributions. Security patches were routinely backported, including mitigations for integer overflows and extension handling flaws reported in upstream trackers. In early 2025, version 21.1.16 was released on February 25, specifically to resolve a issue in versions prior to that point, affecting request processing and potentially enabling unauthorized access. This was followed by heightened scrutiny of legacy code paths, culminating in June 2025 disclosures of multiple critical vulnerabilities, such as buffer overflows and privilege escalations in the X server and shared XWayland codebase, which could lead to data leaks or code execution. To address these, version 21.1.17 launched on June 17, patching five CVEs including CVE-2025-49176 (an in Big Requests Extension) and related issues in extension handling. An errata release, 21.1.18, followed on June 18, providing an additional fix for the same CVE. Distributions responded swiftly: updated to 21.1.18 equivalents by August, SUSE issued patches on July 2, and backported fixes for RHEL 7 on July 7. These updates underscored the server's ongoing role as a maintained legacy component, receiving and stability fixes despite halted feature development, ensuring its viability for systems reliant on X11 compatibility layers like XWayland.

Adoption and Impact

Usage in Operating Systems and Distros

The X.Org Server functions as the reference implementation of the protocol for graphical display management in numerous operating systems, with widespread integration in distributions and BSD variants. It provides the foundational layer for X11-based sessions, enabling network-transparent rendering and compatibility with legacy applications across these platforms. As of 2025, despite the gradual shift toward Wayland compositors in some environments, X.Org remains a core component in distributions prioritizing X11 support for stability and broad hardware compatibility. In major distributions, X.Org is included in package repositories and serves as the default or selectable backend for desktop environments like , Plasma, and when operating in X11 mode. For instance, has utilized Wayland as the default for since version 25 in 2016, yet X.Org configurations persist for users requiring specific X11 features, configurable via system settings or session selectors. Similarly, stable releases package X.Org as the primary X server, supporting its use in default installations with environments such as or , where X11 sessions remain an option alongside emerging Wayland support. , while transitioning to Wayland as the default display server in version 25.10 released in October 2025, retains X.Org for compatibility in earlier releases and as a fallback for applications incompatible with Wayland. BSD operating systems extensively rely on X.Org for graphical interfaces. FreeBSD's details the installation and configuration of the Xorg server as the open-source provider, integrated into its ports and packages system for desktop use. OpenBSD employs X.Org to deliver X11 services, with emphasizing its role in providing graphics to environments. NetBSD and similarly adopt X.Org as their standard X server implementation, supporting X11 across various hardware architectures. This persistence in distros stems from X.Org's maturity in handling diverse drivers and extensions, though adoption statistics indicate a mixed landscape: for example, approximately 27% of Plasma 6 users in mid-2025 still default to X11 sessions amid Wayland's performance advantages on modern hardware. Overall, X.Org's usage underscores its role in maintaining in ecosystems where full Wayland migration remains incomplete due to application and driver dependencies.

Role in Desktop Environments

The X.Org Server functions as the primary display server in desktop environments, managing the core graphical output to screens, processing input from peripherals like keyboards and mice, and facilitating communication between client applications via the X11 protocol. Desktop environments such as , Plasma, and XFCE build upon this foundation, with their components— including panels, file managers, and session managers—operating as X11 clients that request rendering and event handling from the server. The server abstracts hardware details, enabling portability across diverse graphics drivers while providing extensions for features like and damage tracking, which window managers integrate to handle overlapping windows and visual effects. In , the Mutter compositor leverages X.Org for session management and input routing, utilizing X11's Composite and XFixes extensions to enable prevention and workspace switching, though has defaulted to Wayland sessions since version 40 in 2020 with plans to remove native X11 support in version 49 released in 2025. Plasma's similarly interfaces with X.Org for client-side decorations and virtual desktop handling, supporting X11 as an option alongside Wayland, where telemetry data from 2025 indicates 82% of participating users have adopted Wayland sessions. Lighter desktop environments like and continue to rely heavily on X.Org for their core functionality, with window managers such as Xfwm4 and directly querying the server for geometry and event propagation without advanced layers. This integration allows desktop environments to focus on policies and theming, delegating low-level rendering and support to X.Org's device-dependent layers, which adapt to hardware via drivers like those for , , and NVIDIA GPUs. Despite ongoing transitions to Wayland compositors, X.Org remains essential for backward compatibility through XWayland, enabling legacy X11 applications to render within modern desktop sessions as of 2025.

Ecosystem of Drivers and Tools

The X.Org Server employs a modular architecture for drivers, enabling support for diverse hardware through device-dependent X (DDX) modules loaded dynamically at runtime. Graphics drivers, typically named xf86-video-*, interface with the server's rendering pipeline and hardware-specific kernel modules; prominent open-source examples include xf86-video-modesetting for generic kernel mode-setting (KMS) support across modern GPUs, xf86-video-nouveau for NVIDIA cards, and xf86-video-amdgpu for AMD hardware. These drivers facilitate 2D acceleration via extensions like Glamor, which provides hardware-independent rendering using OpenGL ES. Input drivers form another core component, with xf86-input-evdev serving as a generic interface to Linux's /dev/input/event* devices, supporting keyboards, mice, tablets, and touchpads without requiring per-device configuration. This driver, introduced around 2009, handles raw events from the kernel, enabling multi-seat setups and hotplugging. Subsequent developments led to xf86-input-libinput, which integrates the libinput library for enhanced multitouch gestures, calibration, and configuration, effectively deprecating older specialized drivers like xf86-input-synaptics and xf86-input-keyboard by 2020. Legacy drivers persist in niche scenarios but are discouraged in favor of libinput for better compatibility with Wayland transitions. Proprietary drivers, such as NVIDIA's (xserver-xorg-video-nvidia), bypass open-source alternatives like Nouveau for superior performance in 3D workloads and integration, though they introduce compatibility issues with X.Org updates. and maintain fully open-source stacks, with Mesa providing the userspace component for / atop X.Org drivers. Accompanying tools enhance configuration and diagnostics; xrandr manages setups and resolutions dynamically post-server startup, while xinput queries and modifies properties. The xorg-x11-server-utils package bundles utilities like xdpyinfo for server information, xev for event testing, and iceauth for handling. These command-line tools, integral since X11R6, remain essential for scripting and troubleshooting in distributions.

Criticisms and Technical Challenges

Security Vulnerabilities and Fixes

The X.Org Server has been subject to numerous security vulnerabilities, primarily memory corruption flaws such as heap buffer overflows, use-after-free conditions, and out-of-bounds accesses in its handling of client requests, extensions, and rendering code. These issues frequently enable local denial-of-service attacks or privilege escalations, exploiting the server's privileged execution context on Unix-like systems. The codebase's maturity and extensibility contribute to such risks, with over 100 CVEs assigned since 2000, though many are low-severity and require local access. Recent critical vulnerabilities include CVE-2024-9632, a heap-based in the ESM module permitting local , disclosed on October 30, 2024, and addressed in subsequent server patches. In June 2025, five high-severity flaws in X.Org X Server and Xwayland—encompassing out-of-bounds writes and data leaks—were fixed via coordinated releases, with issuing updates under USN-7573-1 to versions mitigating risks. Earlier, February 2025 patches resolved multiple issues, including animated cursor extension bounds checks (CVE-2025-49175), in xorg-server updates. Historical examples demonstrate persistent patterns: CVE-2023-1393, a use-after-free in keyboard handling enabling local escalation, rated moderate by and patched in 2023 server releases; and CVE-2020-25697, lacking for certain X11 clients, allowing control takeover and fixed in xorg-x11-server updates. October 2024 fixes in xorg-server 21.1.14 targeted pre-21.1.14 versions for similar defects. The X.Org security team coordinates remedies through embargoed disclosures and versioned patches, urging users to apply updates promptly via distribution packages.
CVE IDDescriptionDisclosure DateAffected VersionsFix Release
CVE-2024-9632Heap , local priv. esc.Oct 2024Prior to patched buildsxorg-server post-21.1.13
CVE-2025-49175Out-of-bounds in X Rendering (cursors)Jun 2025X.Org X Server < updatedJune 2025 security fixes
CVE-2023-1393Use-after-free, local priv. esc.2023X.Org Server variants2023 server patches
CVE-2020-25697Unauthenticated client control2020xorg-x11-server < fixedPost-1.20.10 updates
Vulnerabilities are tracked via the CVE system, with fixes disseminated through X.Org announcements and vendor-specific errata, such as Red Hat's RHSA-2025:10360 for extended support releases. Ongoing maintenance emphasizes rapid patching despite the project's shift toward Wayland compatibility layers like Xwayland, which inherit some risks.

Code Complexity and Maintenance Burden

The X.Org Server codebase, comprising approximately 323,662 lines of code as of 2023, has accumulated significant complexity over decades of evolution from the original X11 implementation, incorporating layers for device-independent operations, operating system interfaces, and hardware-specific drivers. This structure supports features like , extensible protocols via extensions, and compatibility with diverse hardware, but results in intertwined dependencies that complicate refactoring and introduce potential for subtle bugs, as evidenced by intricate subsystems such as pointer acceleration handling. Maintenance efforts are strained by a small pool of active contributors, with development activity reaching a two-decade low in prior years before a spike in that primarily involved code reverts rather than net progress, adding 11,998 lines while removing 14,680. Corporate entities like have highlighted the dual-stack burden of sustaining both X.Org and Wayland, involving extensive cycles—such as weeks for bug fixes—that escalate costs amid ongoing patching for legacy vulnerabilities dating back decades. The imperative for backwards compatibility perpetuates unused or deprecated code paths, hindering simplification; for instance, support for obsolete drivers and protocols bloats the server without yielding proportional benefits in modern single-user, local-display environments. This has led to perceptions of the project as effectively in , reliant on infrequent volunteers for critical fixes, prompting forks like XLibre in 2025 to alleviate perceived stagnation without upstream coordination.

Performance Limitations

The X.Org Server's synchronous client-server protocol introduces substantial transport latency, as most operations require round-trip requests between clients and the server, even over local Unix domain sockets. This latency dominates performance in rendering and input handling, with legacy Xlib exacerbating the issue through blocking calls, though asynchronous interfaces like XCB can mitigate it by factors up to 50 in specific tests such as querying atom lists. The protocol's lack of built-in compositing and synchronization to vertical retrace results in screen tearing during dynamic content updates unless mitigated by external compositing window managers, which add computational overhead and additional latency from buffering. Historically single-threaded until version 1.19 in 2018, the server struggles with concurrent client demands, leading to responsiveness lags in multi-application scenarios like opaque window resizes that incur double round trips. In high-demand workloads such as gaming or real-time graphics, these architectural traits manifest as elevated input lag—often exceeding that of direct-rendering alternatives—and inefficient resource utilization, including elevated CPU consumption from frequent polling or state tracking. The design's origins in networked environments impose unnecessary indirection for local use, with linear access patterns hindering cache locality compared to tiled modern approaches, further bottlenecking 2D operations that constitute over 90% of typical workloads like fills and blits.

Controversies

Community Conflicts and the XLibre Fork (2025)

In early 2025, tensions within the X.Org development community escalated, primarily revolving around contributions from Enrico Weigelt, who accounted for the majority of commits to the Xserver repository in 2024. Weigelt, a prominent independent developer, proposed extensive code cleanups, security enhancements, and new features, but faced resistance from core maintainers associated with and , who oversee much of the project's infrastructure via . He publicly accused these entities of suppressing X11 development in favor of Wayland, blocking merges of substantial improvements, and removing him from project mailing lists and repositories. These disputes culminated in Weigelt forking the Xserver codebase on June 5, 2025, creating XLibre as an independent continuation of X11 development amid the transition toward Wayland. Critics within the broader community, including discussions on Hacker News, attributed the split to personality clashes and concerns over the scale of Weigelt's proposed changes, which some viewed as destabilizing rather than consensus-driven. Weigelt countered that X.Org's structure stifled innovation and new contributors, positioning XLibre as a more inclusive alternative focused on revitalizing X11. The fork retained backward compatibility while integrating previously rejected patches, such as ABI-specific driver support, xcb-based Xnest refactoring, and backports from XWayland. XLibre's inaugural release, version 25.0.0.0, arrived on June 21, 2025, incorporating over 3,000 commits since the prior X.Org milestone, including the new Xnamespace extension for client isolation across domains, fixes for multiple CVEs, code cleanups, and enhancements to driver support including for NVIDIA hardware. By mid-2025, the attracted more than 30 contributors and early adoption in distributions like , which provided testing ISOs emphasizing systemd-free environments. While X.Org continued minimal maintenance releases amid ongoing patches, XLibre positioned itself as a proactive path for X11's longevity, amid debates over whether the fork addressed genuine stagnation or amplified fringe grievances.

Debates on Replacement by Wayland

Wayland, initiated in 2008 by Kristian Høgsberg as a protocol to address X11's architectural shortcomings such as insecure network transparency and inefficient rendering, has positioned itself as the intended successor to the X.Org Server. Proponents argue that Wayland's client-side compositing eliminates the server-side rendering vulnerabilities inherent in X11, where applications could access other clients' buffers, thereby enhancing security in multi-user environments. Additionally, Wayland reduces latency through direct GPU access by clients, yielding measurable performance gains in input handling and frame rendering on modern hardware, as evidenced by benchmarks showing lower overhead compared to X11's server-mediated model. Critics contend that Wayland's minimalist design sacrifices essential X11 functionalities without adequate equivalents, leading to persistent compatibility hurdles. For instance, features like seamless remote desktop access via X11's native protocol support are fragmented in Wayland, often requiring compositor-specific extensions or fallbacks like XWayland, which undermines the protocol's claims by embedding X11 remnants. Screen sharing and capture, critical for video calls and , remain unreliable without universal protocols; while integration has improved this by 2025, legacy applications and drivers continue to encounter tearing, scaling artifacts, and input lag in multi-monitor setups. These gaps have fueled resistance, particularly among users reliant on stable, feature-complete environments, with surveys indicating that X11 retains preference in professional workflows involving legacy software or high-customization needs. The debate intensified in 2025 amid accelerating corporate-driven adoption, as distributions like and defaulted to Wayland sessions in and , while 10 deprecated X.Org entirely. This shift prompted the June 2025 launch of XLibre, a hard of X.Org by its leading contributor, motivated by upstream neglect and prioritization of Wayland; XLibre 25.0 introduced code cleanups, bug fixes, and enhancements like improved driver support, signaling community intent to sustain X11 independently. Distros such as Artix and have begun packaging XLibre, highlighting a schism where Wayland's progress—bolstered by protocols like explicit sync for compatibility—is weighed against X11's battle-tested ecosystem, with adoption statistics showing Wayland comprising roughly 50-60% of new installs in major environments but X11 persisting in conservative or specialized setups.

Claims of Obsolescence

Claims that the X.Org Server has become obsolete primarily arise from its foundational design originating in the 1980s, which prioritizes and client-server architecture ill-suited to modern local display requirements, leading to inefficiencies such as synchronous protocol operations and inherent vulnerabilities like unauthorized access to client events. These architectural limitations, including 16-bit coordinate constraints and raciness in event handling, are argued to hinder support for contemporary features like high-resolution scaling and touch interfaces without extensive workarounds. In 2020, open-source graphics developer Eric Anholt publicly described the X.Org Server as "," citing reduced corporate investment in its core development, with resources shifting toward Wayland and compatibility layers like XWayland, resulting in minimal feature advancements beyond security patches. This perspective gained traction amid observations that major releases since around 2010 have focused predominantly on bug fixes and vulnerability remediation rather than architectural modernization, exacerbating perceptions of stagnation. Major Linux distributions have reinforced these claims through policy shifts: Red Hat announced in 2023 plans to cease X.Org maintenance starting in 2025, favoring Wayland as the default; Ubuntu followed in June 2025 by phasing out X11 in favor of Wayland for GNOME sessions; and the GTK toolkit deprecated its X11 backend in February 2025, signaling intent for removal in GTK 5. Proponents argue Wayland addresses X11's obsolescence by offering a leaner protocol with built-in compositing, improved security isolation, and native support for fractional scaling and variable refresh rates, rendering X.Org's extensions like GLAMOR increasingly redundant for new hardware. Critics of X.Org's viability further point to persistent exposures, with five critical CVEs disclosed in 2025 affecting both X.Org Server and XWayland, enabling potential data leaks and remote code execution, which underscore the challenges of patching a decades-old without fundamental redesign. While X.Org continues to receive updates via the X.Org Foundation's security team, the of broad contributor engagement—contrasted with Wayland's growth—fuels assertions that it no longer meets the demands of evolving desktop environments.

Future Prospects

Ongoing Maintenance and Security Updates

The X.Org Server continues to receive regular point releases focused on stability and security, with version 21.1.18 issued in June 2025 to address vulnerabilities in the core server and related components like Xwayland. Earlier in the year, version 21.1.17 was released on June 17, 2025, alongside Xwayland 24.1.7, to mitigate a batch of disclosed flaws including use-after-free errors and buffer overflows that could enable or crashes. These updates follow a February 25, 2025, release of 21.1.16, which fixed multiple issues affecting servers prior to that version, demonstrating sustained development effort amid ongoing usage in distributions. Security advisories remain a priority, with the X.Org Foundation maintaining an active reporting mechanism via [email protected] and publishing fixes for newly discovered CVEs. In 2025, several critical vulnerabilities were patched, including CVE-2025-26600 (a use-after-free in input handling) and heap overflows in rendering functions, often coordinated with vendors like and for rapid distribution integration. For instance, issued updates for xorg-x11-server in July and May 2025 to resolve high-severity issues rated with CVSS scores indicating potential remote code execution risks under specific conditions. These efforts underscore a commitment to backporting fixes to stable branches, even as the codebase's legacy complexity necessitates targeted rather than sweeping changes. Distributions such as and continue to incorporate these upstream patches promptly, with Debian's unstable branch adopting 21.1.18 by August 2025 and security teams addressing CVEs like 2025-49175 ( in BigRequest handling). This maintenance sustains compatibility for legacy X11 applications, particularly in enterprise environments reliant on stable graphics stacks, while Xwayland bridges gaps to Wayland compositors without halting X.Org's independent evolution. Overall, the project's viability persists through volunteer and corporate contributions, prioritizing empirical risk mitigation over deprecation despite competitive display protocols.

XLibre Fork and Alternative Paths

In June 2025, the XLibre project forked the X.Org Server codebase to pursue aggressive modernization amid perceived stagnation in upstream development. Initiated on June 5, 2025, by Enrico Weigelt—a leading contributor who accounted for the majority of commits in the prior year—the fork targets reduction, security hardening, performance improvements, and feature enhancements absent from X.Org releases, including backporting features from Xwayland and better driver support for hardware such as NVIDIA. By mid-June, over 30 contributors had joined, implementing cleanups like removal of deprecated modules and addition of the Xnamespace extension for improved namespace isolation. XLibre's inaugural release, version 25.0, launched on June 21, 2025, incorporating performance optimizations and driver compatibility fixes to address longstanding X.Org limitations, such as inefficient rendering pipelines, while preserving backward compatibility with the X11 protocol to support use cases like remote desktops, complex multi-monitor setups, gaming with NVIDIA hardware, and legacy software. The fork's rationale, as articulated by Weigelt, centers on escaping "toxic elements" in X.Org governance, including resistance to refactoring from corporate stakeholders like , which allegedly prioritized minimal maintenance over innovation. Post-announcement tensions escalated on June 6, 2025, with reports of developers blocking XLibre-aligned patches in upstream repositories, underscoring community fractures. Adoption has begun in niche distributions; integrated XLibre for testing by late June 2025, bundling it in live images to evaluate stability on systemd-free systems. Proponents view XLibre as a viable lifeline for X11-dependent workflows, such as legacy scientific applications and remote desktop protocols, where Wayland's compatibility gaps persist. Critics, however, question its long-term traction given X.Org's entrenched vendor support and the fork's early-stage risks, including potential fragmentation of driver ecosystems. Beyond XLibre, alternative sustenance paths for X.Org include vendor-driven patches from entities like and , which continue sporadic fixes despite reduced core commits—totaling under 100 in 2024. Some advocate internal reforms, such as decentralizing governance via subprojects, to revive upstream activity without forking. Hybrid approaches, like bolstering XWayland (an X11 compatibility layer atop Wayland), offer transitional maintenance by leveraging Wayland's momentum while preserving X.Org binaries, though this defers rather than resolves X11's architectural debt. No other major X.Org forks have materialized as of October 2025, positioning XLibre as the primary divergent effort amid broader ecosystem shifts.

Long-Term Viability Amid Wayland Transition

The transition to Wayland as the primary display protocol for desktops has accelerated by 2025, with major environments like announcing the removal of native X11 sessions in favor of Wayland-only defaults, citing parity or superiority in functionality. Despite this shift, X.Org Server's viability persists through its integration via XWayland, a that runs X11 applications under Wayland compositors by embedding core X server logic, ensuring seamless execution without native X11 dependency. This mechanism, developed by X.Org maintainers, addresses immediate needs, as Wayland's client-side rendering model lacks direct equivalents for certain X11 features like global input handling or legacy extensions. Adoption data indicates Wayland as the default session in distributions such as (since 2016, with refinements through 2025), , and Plasma environments, where over 80% of users in surveyed and deployments opt for Wayland by early 2025. However, X11 retains fallback status in environments like and certain enterprise setups, where full Wayland migration faces hurdles including driver compatibility and application-specific issues, such as screen sharing or multi-monitor configurations requiring X11's . X.Org's maintenance burden has thus evolved into targeted security patching and stability fixes rather than feature development, with upstream contributors from and sustaining the codebase to support XWayland's requirements. Critics argue that Wayland's protocol design introduces persistent incompatibilities, such as binary-level breaks for X11-dependent tools and the absence of a complete 1:1 replacement ecosystem, potentially prolonging X.Org's necessity for specialized workflows in scientific computing, embedded systems, or BSD derivatives. No formal end-of-life has been declared for X.Org, and its modular architecture allows selective evolution tied to compositor needs, suggesting long-term viability as a legacy runtime rather than a primary server, bolstered by community-driven forks addressing niche divergences. This hybrid model mitigates risks of abrupt obsolescence, though resource allocation favors Wayland protocols, limiting X.Org to stabilization roles amid declining native usage.

References

  1. https://www.x.org/releases/current/doc/man/man1/Xorg.1.xhtml
  2. https://www.x.org/
  3. https://machaddr.substack.com/p/xorg-and-its-evolution-on-unix-like
  4. https://www.x.org/wiki/
  5. https://www.x.org/wiki/Development/Security/
  6. https://lists.x.org/archives/xorg-announce/2024-October/003545.html
  7. https://ubuntu.com/security/notices/USN-7573-1
  8. https://blogs.gnome.org/alatiera/2025/06/23/x11-session-removal-faq/
  9. https://discussion.fedoraproject.org/t/please-dont-remove-xorg-yet/92757
  10. https://www.x.org/archive/X11R7.6/doc/man/man1/Xserver.1.xhtml
  11. https://magcius.github.io/xplain/article/x-basics.html
  12. https://linux.die.net/man/1/xorg
  13. https://www.x.org/releases/X11R7.7-RC1/doc/xproto/x11protocol.html
  14. https://wiki.archlinux.org/title/Xorg
  15. https://www.x.org/releases/X11R7.6/doc/xorg-server/Xserver-spec.html
  16. https://www.x.org/wiki/Development/Documentation/Glossary/
  17. https://docs.oracle.com/cd/E19683-01/816-0279/serverintro-91783/index.html
  18. https://www.x.org/releases/current/doc/xorg-server/ddxDesign.html
  19. https://www.x.org/releases/current/doc/xorg-server/Xserver-spec.html
  20. https://lists.x.org/archives/xorg-announce/2021-October/003115.html
  21. https://www.x.org/wiki/XOrgInputDriverSpec/
  22. https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml
  23. https://www.x.org/archive/X11R7.5/doc/intel.html
  24. https://www.linuxfromscratch.org/blfs/view/11.2-systemd/x/x7driver.html
  25. https://www.linuxfromscratch.org/blfs/view/12.2-systemd/x/xorg-server.html
  26. https://dri.freedesktop.org/wiki/DDX/
  27. https://www.x.org/wiki/Projects/Drivers/
  28. https://datatracker.ietf.org/doc/rfc1013/
  29. https://www.x.org/releases/current/doc/libX11/libX11/libX11.html
  30. https://www.x.org/wiki/guide/using-extensions/
  31. https://www.x.org/wiki/guide/extensions/
  32. https://www.x.org/wiki/Development/Documentation/Multiseat/
  33. https://lists.x.org/archives/xorg-devel/2011-July/023932.html
  34. https://wiki.gentoo.org/wiki/Multiseat
  35. https://wiki.archlinux.org/title/Xorg_multiseat
  36. https://www.x.org/archive/X11R6.7.0/doc/X.7.html
  37. https://www.x.org/docs/man/man.pdf
  38. https://www.x.org/archive/X11R7.0/doc/html/RELNOTES4.html
  39. https://www.x.org/releases/current/doc/renderproto/renderproto.txt
  40. https://www.x.org/releases/current/doc/man/man3/Xcomposite.3.xhtml
  41. https://download.nvidia.com/XFree86/Linux-x86_64/396.51/README/xcompositeextension.html
  42. https://www.x.org/releases/current/doc/
  43. https://download.nvidia.com/XFree86/Linux-x86_64/510.47.03/README/randr14.html
  44. https://wiki.gentoo.org/wiki/Xorg/Multiple_monitors
  45. https://unix.stackexchange.com/questions/644520/are-x11-release-versions-backwards-compatible
  46. https://unix.stackexchange.com/questions/333669/why-is-x11-still-version-11
  47. https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server
  48. https://www.x.org/wiki/XorgModuleABIVersions/
  49. https://www.x.org/wiki/guide/communication/
  50. https://www.x.org/archive/X11R6.7.0/doc/RELNOTES6.html
  51. https://arstechnica.com/gadgets/2024/06/the-x-window-system-is-40-archaic-as-heck-and-still-relevant/
  52. https://www.phoronix.com/review/x11_25_years
  53. https://www.cl.cam.ac.uk/~pr10/iui/scheifler86.pdf
  54. http://www.bitsavers.org/pdf/dec/_Books/_Digital_Press/Scheifler_X_Window_System_C_Library_and_Protocol_Reference_1988.pdf
  55. https://lwn.net/Articles/602876/
  56. https://www.x.org/archive/X11R7.5/doc/man/man7/XOrgFoundation.7.html
  57. https://www.computerhope.com/jargon/x/xorg-foundation.htm
  58. https://lwn.net/Articles/79808/
  59. https://dri.freedesktop.org/wiki/XFree86/
  60. https://www.theregister.com/2004/04/15/x11_fork/
  61. https://www.x.org/wiki/XorgFoundation/
  62. https://lwn.net/Articles/79302/
  63. https://www.x.org/wiki/Events/History/
  64. https://www.x.org/wiki/Releases/History/
  65. https://www.x.org/archive/individual/xserver/
  66. https://lists.x.org/archives/xorg-modular/2005-April/000154.html
  67. https://www.x.org/wiki/PressReleases/X11R6970Released/
  68. https://www.x.org/releases/
  69. https://www.x.org/wiki/Releases/
  70. https://www.phoronix.com/news/X.Org-Server-1.20-Features
  71. https://lists.x.org/archives/xorg-announce/2018-February/002842.html
  72. https://www.phoronix.com/news/X.Org-Server-1.20-Feature-List
  73. https://security-tracker.debian.org/tracker/source-package/xorg-server
  74. https://lists.x.org/archives/xorg-announce/2025-February/003585.html
  75. https://insinuator.net/2025/06/disclosure-multiple-vulnerabilities-xserver-xwayland/
  76. https://lists.x.org/archives/xorg-announce/2025-June/003609.html
  77. https://lists.x.org/archives/xorg/2025-June/062055.html
  78. https://lists.x.org/archives/xorg-announce/2025-June/003612.html
  79. https://www.suse.com/support/update/announcement/2025/suse-su-202502207-1/
  80. https://access.redhat.com/errata/RHSA-2025:10360
  81. https://blogs.gnome.org/alatiera/2025/06/
  82. https://unix.stackexchange.com/questions/760422/x-server-implementation-vs-linux-distributions
  83. https://docs.fedoraproject.org/en-US/quick-docs/configuring-xorg-as-default-gnome-session/
  84. https://www.webpronews.com/ubuntu-25-10-adopts-wayland-as-default-display-server/
  85. https://docs.freebsd.org/en/books/handbook/x11/
  86. https://www.openbsd.org/faq/faq11.html
  87. https://www.x.org/archive/X11R7.5/doc/platforms/NetBSD.html
  88. https://www.dragonflybsd.org/docs/handbook/X/
  89. https://twit.tv/posts/tech/great-x11-wayland-migration
  90. https://www.gamingonlinux.com/2025/06/multiple-security-issues-in-the-x-org-x-server-and-xwayland-disclosed-new-versions-released/
  91. https://unix.stackexchange.com/questions/345344/difference-between-xorg-and-gnome-kde-xfce
  92. https://unix.stackexchange.com/questions/63118/role-and-architecture-of-xorg-x-server-and-interaction-with-other-software
  93. https://pointieststick.com/2025/06/21/about-plasmas-x11-session/
  94. https://www.reddit.com/r/linux_gaming/comments/1jbrc9x/82_of_kde_users_who_opted_into_telemetry_use/
  95. https://www.netbsd.org/docs/guide/en/chap-x.html
  96. https://www.x.org/archive/individual/driver/
  97. https://www.x.org/wiki/Development/Documentation/XorgInputHOWTO/
  98. https://gitlab.freedesktop.org/xorg/driver/xf86-input-evdev
  99. https://www.linuxfromscratch.org/blfs/view/svn/x/x7driver.html
  100. https://www.gentoo.org/support/news-items/2020-04-03-deprecation-of-legacy-x11-input-drivers.html
  101. https://www.reddit.com/r/NetBSD/comments/1bfcbm5/xorg_anyone_still_using_xf86inputkeyboard/
  102. https://packages.debian.org/sid/xserver-xorg-video-nvidia
  103. https://www.reddit.com/r/Amd/comments/qpzbli/thank_you_for_open_source_drivers/
  104. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/6.2_technical_notes/xorg-x11-server-utils
  105. https://packages.debian.org/sid/x11-xserver-utils
  106. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xorg
  107. https://www.cvedetails.com/version-list/88/8600/1/X.org-Xorg-server.html?order=0
  108. https://lists.x.org/archives/xorg-announce/2025-February/003584.html
  109. https://access.redhat.com/security/cve/cve-2023-1393
  110. https://nvd.nist.gov/vuln/detail/CVE-2020-25697
  111. https://lists.x.org/archives/xorg-announce/2024-April/003505.html
  112. https://www.reddit.com/r/archlinux/comments/14vswau/why_wayland_pulls_more_dependencies_compared_to/
  113. https://www.phoronix.com/news/Xorg-Server-Pointer-Accel
  114. https://www.phoronix.com/news/X.Org-Server-2024-GitStats
  115. https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts
  116. https://news.ycombinator.com/item?id=24921971
  117. https://news.ycombinator.com/item?id=38639022
  118. https://news.ycombinator.com/item?id=44199502
  119. https://www.x.org/wiki/Development/Documentation/Performance/
  120. https://lists.freedesktop.org/archives/xorg-devel/2009-November/003403.html
  121. https://theserverhost.com/blog/post/x11-vs-wayland
  122. https://superuser.com/questions/1217280/why-is-x11-forwarding-so-inefficient
  123. https://linuxgenie.net/wayland-vs-x11-performance-comparison/
  124. https://www.linux.org/threads/advantages-of-wayland-over-x11.49441/
  125. https://www.linuxmo.com/wayland-vs-x11-the-battle-of-display-protocols/
  126. https://linuxiac.com/xlibre-xserver-project-plans-revival-of-x11/
  127. https://lists.x.org/archives/xorg-devel/2025-June/059400.html
  128. https://lists.x.org/archives/xorg-devel/2025-June/059396.html
  129. https://github.com/X11Libre/xserver
  130. https://www.phoronix.com/news/XLibre-25.0-Released
  131. https://linux.slashdot.org/story/25/06/28/054245/x11-fork-xlibre-released-for-testing-on-systemd-free-artix-linux
  132. https://www.theregister.com/2025/06/10/xlibre_new_xorg_fork/
  133. https://www.cbtnuggets.com/blog/technology/devops/wayland-vs-xorg-wayland-replace-xorg
  134. https://www.phoronix.com/news/Wayland-Q1-2025
  135. https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
  136. https://www.howtogeek.com/is-wayland-good-in-2025/
  137. https://www.reddit.com/r/linuxquestions/comments/1lmt287/waylands_shortcomings_in_2025/
  138. https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-doesnt-love-me-back-post-4-wayland-is-growing-up-and-now-we-dont-have-a-choice/
  139. https://forums.opensuse.org/t/xlibre-is-a-fork-of-the-xorg-xserver-with-lots-of-code-cleanups-and-enhanced-functionality/185990
  140. https://dev1galaxy.org/viewtopic.php?id=7236
  141. https://news.ycombinator.com/item?id=26418992
  142. https://www.osnews.com/story/132507/its-time-to-admit-it-the-x-org-server-is-abandonware/
  143. https://news.ycombinator.com/item?id=38447613
  144. https://forums.freebsd.org/threads/the-no-future-of-x-org-freebsd-becomes-headless.91235/
  145. https://ubuntu-mate.community/t/ubuntu-joins-the-movement-x11-officially-being-phased-out/29460
  146. https://www.phoronix.com/news/GTK-X11-Now-Deprecated
  147. https://www.reddit.com/r/linuxquestions/comments/1lsu1rk/wayland_or_xorg_what_are_the_pros_and_cons_of_each/
  148. https://linuxsecurity.com/news/security-vulnerabilities/critical-flaws-x-org-xwayland
  149. https://www.phoronix.com/news/X.Org-Server-21.1.17
  150. https://www.x.org/releases/individual/xserver/
  151. https://access.redhat.com/errata/RHSA-2025:7165
  152. https://launchpad.net/debian/%2Bsource/xorg-server/%2Bchangelog
  153. https://tracker.debian.org/xorg-server
  154. https://forums.linuxmint.com/viewtopic.php?t=452003
  155. https://hackaday.com/2025/07/28/wayland-will-never-be-ready-for-every-x11-user/
Add your contribution
Related Hubs
User Avatar
No comments yet.