Fact-checked by Grok 2 weeks ago

X Window System

The X Window System (commonly referred to as X11 or simply X) is a network-transparent, client-server windowing system designed for bitmap displays, serving as the foundational graphical user interface (GUI) infrastructure for Unix-like operating systems such as Linux and BSD variants.^[1]^[2] It enables multiple applications, known as X clients, to share access to display hardware, input devices like keyboards and mice, and network resources, while the X server handles low-level rendering, event processing, and hardware multiplexing on the local machine.^[1] This architecture allows X clients to run remotely over TCP/IP networks with minimal latency, making it highly portable across diverse computing environments and hardware platforms.^[2]^[3] Developed at the Massachusetts Institute of Technology (MIT) as part of Project Athena, the X Window System originated in 1984 when Bob Scheifler adapted the earlier W Window System by introducing an asynchronous network protocol to support distributed computing.^[3] The initial release occurred in June 1984,^[4] with the influential X Version 10 following in 1986, which rapidly gained adoption as a hardware-independent standard for Unix GUIs.^[5] X Version 11 (X11), released in September 1987, introduced the protocol still in use today and was developed collaboratively by key figures including Scheifler, Jim Gettys, and Smokey Wallace.^[3] Governance evolved from the MIT X Consortium (1988–1993) to the X Consortium (1993–1996), then The Open Group (1997–2004), and finally the X.Org Foundation in 2004, which continues to maintain and evolve the system under open-source licensing.^[3] At its core, X separates mechanism (provided by the server and protocol) from policy (handled by clients and toolkits), promoting flexibility in user interfaces and extensibility through features like the X Input Extension (XInput) for multi-touch and the X Rendering Extension (Render) for advanced graphics.^[1]^[3] The system supports hierarchical windows, pixmaps for off-screen rendering, and libraries such as Xlib for low-level access or higher-level toolkits like Xt and GTK for application development.^[1] Despite its age—reaching 40 years in 2024—X remains relevant for its stability, backward compatibility, and role in modern desktops like GNOME and KDE, though it faces competition from newer systems like Wayland.^[6]^[5]

Fundamentals

Purpose and Capabilities

The X Window System is a client-server protocol designed for bitmap displays on Unix-like operating systems, enabling the management of multiple overlapping windows, graphics rendering, and input device handling through a modular architecture.^[1] It serves as the foundation for graphical user interfaces by allowing applications (clients) to request display output and input events from a server that abstracts the underlying hardware.^[7] Core capabilities include processing keyboard and mouse input via event notifications, supporting pointer motion, button presses, and keycodes mapped to symbolic representations.^[1] The protocol provides basic drawing primitives such as lines, rectangles, arcs, polygons, and text rendering, along with font management through scalable and bitmap fonts accessed via standardized naming conventions.^[7] Inter-client communication is facilitated by selections, a mechanism for data exchange like cut-and-paste, and extensions supporting drag-and-drop operations using target atoms for property insertion.^[8] A defining feature is its network transparency, permitting clients to execute on remote machines while rendering output on a local display server over a network connection, as the protocol treats local and remote interactions equivalently.^[1] Over time, it has evolved from software-based rendering on bitmap displays to integrating hardware acceleration, notably through the Direct Rendering Infrastructure (DRI), which allows clients to access graphics processing units directly for enhanced performance in modern applications.^[1] The system's modularity ensures the server abstracts hardware specifics like display adapters and input devices, while clients concentrate on application logic, promoting portability across diverse platforms.^[1] This separation, rooted in the client-server model, enables independent development of servers for various hardware and clients for specific tasks.^[7]

Key Terminology

The X server is the program that manages the display hardware, processes client requests, and generates events such as input from keyboards or mice, serving as the central component that controls graphical output and input devices.^[7] The X client, in contrast, is an application that connects to the X server via the X11 protocol to request graphical services, such as creating windows or drawing graphics, and may run locally or remotely over a network.^[7] A display refers to the collection of screens and associated input devices managed by a single X server instance, often denoted by an identifier like ":0" to specify the connection endpoint.^[9] In the X Window System, a window is a rectangular region on a screen with a unique identifier, serving as a drawing surface for clients to render text, graphics, or other content, and it can be either input/output (visible and interactive) or input-only (invisible but capable of receiving events).^[7] The root window is the top-level window that covers the entire screen background, acting as the parent container for all other windows on that screen and typically filled with a solid color or pattern.^[9] Protocol interactions involve requests, which are messages sent from clients to the server containing opcodes to perform actions like creating a window or querying server information, formatted as fixed-size packets with a major opcode and data length.^[7] An event is an asynchronous notification from the server to interested clients, such as a key press or window exposure, encoded in 32-byte packets with a type code to report changes in the display state.^[7] An extension provides additional functionality beyond the core protocol, such as advanced rendering capabilities via XRender, by reserving specific opcode ranges (e.g., major opcodes 128–255) for optional features.^[7] Related to user experience, a window manager is a special X client responsible for handling window decorations, placement, resizing, and focus management, enforcing user interface policies without direct control over the server's hardware.^[10] A session manager is another client application that oversees the lifecycle of user sessions, coordinating the startup, shutdown, and state preservation of multiple applications across logins.^[9] A resource denotes any server-managed entity, such as a window, font, or color context, identified by a 32-bit ID allocated through client requests and subject to server-side garbage collection if unused.^[7] The term X11 specifically refers to version 11 of the X Window System protocol, which defines the standard communication rules for client-server interactions and has remained stable since 1987, enabling network-transparent operation.^[11] Implementations like Xorg, however, are specific software packages that provide the X server and related libraries conforming to the X11 protocol, with Xorg serving as the reference implementation maintained by the X.Org Foundation.^[11]

Architecture

Core Components

The X Window System's architecture is built on a modular stack that separates concerns between display management, client communication, and graphical rendering, enabling flexible and extensible software development. At its foundation lies the X server, which acts as the central authority for hardware interaction and resource allocation, while client-side libraries and toolkits provide abstractions for application developers. This separation promotes reusability and portability across diverse hardware and network environments.^[12] The X server is the primary process responsible for managing display hardware, including the framebuffer for output and input devices such as keyboards and mice. It processes incoming requests from clients to create, map, and manipulate windows, maintaining a hierarchical window tree that represents the on-screen layout and a graphics context (GC) for each drawing operation, which defines attributes like line width and fill style. The server also handles event distribution, such as keyboard presses or mouse movements, routing them to the appropriate client windows based on focus and overlap. This hardware abstraction ensures that the server can operate independently of specific client implementations, supporting multiple simultaneous clients on a single display.^[12]^[7] Client libraries form the interface through which applications communicate with the X server using the X protocol. Xlib, the original low-level C library, provides functions for sending requests (e.g., creating windows or drawing primitives) and receiving asynchronous events, buffering them for efficiency over network connections. As a foundational API, it exposes the core protocol directly, allowing fine-grained control over server interactions. Complementing Xlib is XCB (X protocol C-language Binding), a more contemporary library designed as a thread-safe alternative that binds directly to the X protocol without intermediate buffering, reducing latency and improving performance in multi-threaded applications. Both libraries enable clients to run remotely from the server, leveraging the system's network transparency.^[12]^[13]^[14] Above the client libraries sits the intrinsics layer and associated toolkits, which abstract widget-based user interface development. The X Toolkit Intrinsics (Xt) library introduces an object-oriented framework for creating and managing widgets—reusable UI components like buttons or menus—using subclassing mechanisms such as Core, Composite, and Constraint classes to handle geometry, events, and constraints. Xt builds directly on Xlib, providing resource management and application contexts while remaining neutral on visual style or policy, thus allowing extensions for custom widgets. Higher-level toolkits like Xaw (X Toolkit Athena Widgets) extend Xt with a standard set of predefined widgets, simplifying the construction of consistent graphical interfaces without requiring developers to implement low-level drawing.^[15] Graphics capabilities in the X Window System are layered, starting with Xcore for fundamental 2D operations and extending through protocol enhancements for advanced rendering. Xcore, part of the base X protocol, supports basic drawing requests such as lines, arcs, polygons, and text output, executed via graphics contexts to ensure consistent styling across windows. The XRender extension augments Xcore by introducing anti-aliased graphics, alpha blending, and image composition models, enabling smoother visuals and efficient 2D transformations without altering the core protocol. For 3D integration, the GLX (OpenGL Extension to X) library bridges the X server with OpenGL, allowing clients to render hardware-accelerated 3D content into X windows or pixmaps, with direct rendering paths for performance on supported hardware. These layers collectively provide a scalable graphics pipeline, from simple vector drawing to complex scene composition.^[7] A key aspect of this modular design is the server's independence from clients, which permits multiple applications to share the display resources without direct inter-client communication, as all interactions are mediated through the server to maintain isolation and security.^[12]

Client-Server Model

The X Window System employs a client-server model where applications, known as clients, send graphical requests to an X server that manages the display hardware and input devices. Clients issue commands such as creating windows or drawing lines (e.g., via PolyLine requests), while the server processes these asynchronously over reliable byte streams, typically using sockets for local or network communication, and responds with events (like key presses or exposures) or errors. This separation ensures that clients focus on application logic without directly handling hardware details, such as rendering pixels or processing mouse input.^[16]^[17] The model's design provides key benefits, including hardware abstraction by the server, which integrates with the operating system kernel for device management, allowing clients to be portable across diverse platforms like different Unix variants or even remote machines. This enables flexible configurations, such as "fat clients" with substantial local processing or "thin clients" relying heavily on the server for computation, while supporting distributed setups where clients on one system display output on another's server. Furthermore, the server acts as a central mediator, preventing direct client-to-client calls and thus maintaining encapsulation and security in multi-application environments.^[18]^[19]^[20] Inter-client communication occurs exclusively through server-mediated mechanisms to preserve the model's integrity. Properties serve as key-value stores attached to windows, enabling clients to exchange data like window names or state information via operations such as ChangeProperty, which can trigger PropertyNotify events. Selections provide a clipboard-like facility for data transfer, where a client claims ownership of a selection atom (e.g., PRIMARY) using SetSelectionOwner, and other clients request conversion via ConvertSelection, with the server facilitating notifications like SelectionNotify. These indirect pathways ensure coordinated interactions without violating the client-server boundary.^[21]^[16] This architecture, while inspired by earlier systems like Stanford's W window system, was specifically optimized for Unix networking environments through its asynchronous protocol, minimizing latency in distributed scenarios over protocols like TCP/IP.^[20]

Network Protocol and Remote Access

The X Window System protocol, version 11 (X11), was standardized in 1987 as part of the first release of X11 by MIT.^[22] This binary protocol operates over reliable byte streams, typically TCP/IP, with the server listening on port 6000 plus the display number (e.g., port 6000 for display :0).^[7] Messages are structured as typed, fixed-format packets: requests from clients to the server (e.g., CreateWindow), replies from the server to clients (e.g., QueryTree), and asynchronous events from the server (e.g., KeyPress or Expose).^[7] Data types include 32-bit signed integers (INT32) for coordinates and dimensions, ensuring precise representation of graphical elements like window positions.^[7] The protocol enables remote execution where clients run on one machine and connect to a server on another, rendering graphics locally on the display machine while handling input remotely—a reversal of typical client-server terminology.^[7] This network transparency supports scenarios like running applications on a remote compute server and displaying them on a local workstation. X forwarding in SSH tunnels these connections securely, proxying X protocol traffic through an encrypted channel to forward graphical output and input events. For bandwidth reduction, the Low Bandwidth X (LBX) extension provided compression but has been deprecated since X11R7.1 due to poor performance compared to alternatives like SSH compression.^[23] Security relies on mechanisms like MIT-MAGIC-COOKIE-1 authentication, where clients present a 128-bit shared secret from an authority file (managed by xauth) during connection setup.^[24] Host-based access control via xhost allows or denies connections by IP address or hostname, providing basic filtering.^[24] However, the protocol transmits data unencrypted, exposing it to eavesdropping on open networks; sensitive information like keystrokes or screen contents can be intercepted without encryption.^[24] The XSecurity extension, introduced for modern needs, classifies clients as trusted or untrusted, restricting untrusted ones from actions like input injection or full-screen grabs to mitigate intra-session attacks.^[25] Networked use introduces performance challenges, primarily latency from synchronous round-trip message exchanges—for instance, each input event or drawing request requires client-server acknowledgment, amplifying delays over high-latency links.^[26] Mitigations include offloading rendering to the client via extensions like XRender for local computation of graphics, reducing server load and traffic.^[7] Proxy servers such as Xpra address persistent remoting by maintaining a virtual display session on the server, compressing and caching updates to minimize round-trips and support seamless detachment/reattachment over varying connections.^[27]

User Interaction

Graphical User Interfaces

The X Window System itself provides no built-in graphical user interface, relying entirely on separate client applications to generate and manage all visual elements, including windows, menus, and icons. This design allows flexibility in implementing diverse GUI paradigms but requires additional software layers to create a usable desktop experience.^[7] Window managers serve as essential X clients that govern the layout, focus, resizing, and decorative elements of application windows, enabling coherent user interaction across the display. Stacking window managers, such as the original twm and Metacity (integrated with GNOME), permit windows to overlap in a traditional, floating arrangement, mimicking physical desktop stacking for flexible positioning. In contrast, tiling window managers like i3 automatically divide the screen into non-overlapping regions, arranging windows in a grid-like fashion to optimize space usage and often emphasizing keyboard-driven workflows for efficiency. These managers adhere to conventions outlined in the Inter-Client Communication Conventions Manual (ICCCM) to ensure predictable behavior and compatibility with other X components.^[8] Desktop environments extend window managers by bundling them with complementary tools like task panels, file managers, and desktop icons, forming a unified interface for everyday computing tasks. For instance, GNOME employs the Mutter window manager to handle window operations while providing session management through the X Session Management Protocol (XSMP), which coordinates application state saving and restoration across logins. Similarly, KDE Plasma uses KWin for advanced window handling, and XFCE leverages Xfwm4 alongside lightweight panels for resource-efficient operation. These environments collectively deliver cohesive GUIs by integrating X's core services with user-centric features.^[28] Compositing capabilities enhance GUI aesthetics and performance through X extensions, allowing effects like window transparency, drop shadows, and smooth animations without full-screen repaints. The XComposite extension redirects entire window hierarchies to off-screen storage, enabling compositing managers to blend content dynamically, while the Damage extension optimizes this process by notifying clients only of modified screen regions, reducing unnecessary redraws and improving efficiency on resource-constrained systems.^[29]^[30] Theming in X-based GUIs is managed via the X resource database, a centralized mechanism for defining customizable attributes such as colors, fonts, and cursor styles that applications can query at runtime. This database, populated using tools like xrdb, supports per-application or system-wide configurations to achieve consistent visual themes. Interoperability is maintained through standards like ICCCM for basic client-window manager interactions and the Extended Window Manager Hints (EWMH) for advanced features, such as virtual desktops and taskbar integration, ensuring themes apply uniformly across diverse desktop environments.^[31]^[8]^[32]

Input and Event Handling

The X Window System processes input from devices such as keyboards and mice by generating events that are delivered asynchronously to interested clients. These events are queued in the server's event queue if the client is not immediately ready to process them, ensuring non-blocking operation even under load.^[7] Common event types include KeyPress and KeyRelease for keyboard input, ButtonPress and ButtonRelease for mouse buttons, MotionNotify for pointer movement, and Expose for regions requiring redrawing due to uncovering.^[7] Clients select which events to receive via the event-mask attribute on windows, allowing targeted handling without overwhelming the application.^[7] Event propagation follows a hierarchical model where device-related events originate at the source window and bubble up to ancestor windows, including the root, unless intercepted. Propagation can be halted if the event type is included in the do-not-propagate-mask of the source window or any ancestor, preventing unnecessary delivery to parent containers.^[7] Synthetic events, generated by clients using the SendEvent request, mimic real input for testing or automation and follow the same propagation rules.^[7] The focus model determines how keyboard input is directed, with two primary modes defined in the core protocol: pointer focus, where input follows the mouse pointer position (set via PointerRoot in SetInputFocus), and server focus, where the server explicitly assigns focus to a specific window or none.^[7] Window managers extend this with policies such as strict focus, requiring explicit user action like a click to change focus, and sloppy focus, where the pointer entering a window shifts focus automatically but may retain it when the pointer moves to the root window or desktop edges.^[8] Focus changes generate FocusIn and FocusOut events to notify affected clients.^[7] Device support extends beyond core keyboard and pointer through extensions like XKB for keyboard mapping, which allows dynamic configuration of layouts, variants, and options to handle international input and custom behaviors.^[33] The XInput2 extension enables multi-pointer functionality, treating devices such as graphics tablets and touchscreens as independent masters with their own cursors and focus, delivering device-specific events like raw axis data without emulating core pointer behavior.^[34] Grab mechanisms provide fine-grained control for scenarios like modal dialogs, where pointer or keyboard grabs (via GrabPointer or GrabKeyboard requests) temporarily block input to other windows.^[7] Active grabs freeze the device until released, with synchronous modes queuing events until explicitly allowed, while passive grabs activate on specific conditions like key combinations.^[7] These ensure exclusive input capture, such as preventing background interactions during critical user operations.^[7]

Implementations

Major Server Implementations

The major server implementations of the X Window System are predominantly open-source efforts coordinated by the X.Org Foundation, underscoring the protocol's reliance on community-driven development for cross-platform compatibility and hardware support. These implementations handle display rendering, input device management, and network transparency, with a focus on modularity to accommodate diverse operating systems and graphics hardware.^[35] Xorg stands as the primary reference implementation of the X server, forked from XFree86 in 2004 amid licensing disputes and maintained as the de facto standard for Unix-like systems. As of October 2025, the latest release is xorg-server 21.1.20, addressing security vulnerabilities and maintaining support for modern hardware.^[36] Its modular design allows dynamic loading of specialized drivers, such as those for NVIDIA and Intel graphics hardware, facilitating broad hardware acceleration and extensibility without recompiling the core server. Xorg incorporates the Direct Rendering Infrastructure (DRI), a framework that permits client applications to perform GPU-accelerated rendering directly on hardware, bypassing the server for improved performance in graphics-intensive tasks. Additionally, it supports XWayland, a compatibility layer that embeds X11 applications within Wayland-based environments.^[37]^[38]^[39]^[40]^[41] XFree86, developed starting in 1992, served as Xorg's predecessor and played a pivotal role in the widespread adoption of graphical interfaces on Linux and other Unix-like operating systems during the 1990s by providing robust support for PC-compatible hardware. Its evolution halted following the 2004 fork due to controversial licensing changes in version 4.4, which restricted redistribution and prompted the open-source community to migrate to Xorg.^[42]^[37] XQuartz represents the macOS-specific adaptation of the X.Org server, delivering X11 functionality through integration with Apple's interface via the quartz-wm window manager. However, as of 2025, it faces compatibility issues with the latest macOS versions, such as refresh problems on window resize and visual glitches on Apple Silicon, though it still supports legacy X11 software including clipboard sharing.^[43]^[44] Cygwin/X ports the X Window System to Microsoft Windows using the Cygwin POSIX compatibility layer, which emulates a Unix-like API to enable execution of X11 clients in modes like multi-window or rootless integration with the Windows desktop. This implementation supports features such as clipboard synchronization between X and Windows, remote XDM logins, and hardware acceleration via DirectDraw, making it suitable for POSIX-compliant graphical workflows on non-Unix platforms.^[45]^[46]

Client Libraries and Toolkits

Client libraries and toolkits provide the primary interface for applications to interact with the X Window System, abstracting the underlying X protocol to simplify development while ensuring portability across different implementations. These libraries handle essential tasks such as establishing connections to the X server, managing resources like windows and graphics contexts, and processing events, allowing developers to focus on application logic rather than low-level protocol details.^[14] Toolkits build upon these libraries to offer higher-level abstractions, including widget sets for user interfaces, which further enhance code reusability and cross-platform compatibility.^[47] At the low level, Xlib serves as the foundational C-language interface to the X protocol, providing a procedural API for connection management, request dispatching, and error handling.^[48] It enables direct control over X server interactions, such as drawing primitives and event loops, but its synchronous nature can introduce threading challenges in multi-threaded applications due to non-reentrant design.^[49] To address these limitations, XCB (X protocol C-language Binding) offers an alternative low-level library that is event-driven and asynchronous, reducing latency and avoiding many of Xlib's thread-safety issues by allowing non-blocking operations and better integration with modern programming models.^[13]^[14] Mid-level abstractions include the Xt Intrinsics, part of the X Toolkit, which introduce an object-oriented framework for building widgets and managing application resources, sitting atop Xlib to provide callbacks, geometry management, and translation of X events into higher-level actions.^[47] Another example is XView, developed by Sun Microsystems as an object-oriented toolkit derived from SunView, emphasizing ease of use for creating graphical applications with built-in support for panels, scrollbars, and menus under the OPEN LOOK interface guidelines.^[50] High-level toolkits extend these foundations with comprehensive widget libraries for rapid UI development. GTK+ (GIMP Toolkit) is a cross-platform widget toolkit originally designed for the X Window System, using the GDK (GIMP Drawing Kit) layer to abstract display backends, including X11, and facilitating ports to alternatives like Wayland for improved portability.^[51] Qt, a C++ framework widely used in environments like KDE, supports X11 through its platform abstraction, providing signals and slots for event handling alongside rich UI components such as dialogs and layouts.^[52] Motif, standardized by the Open Group, serves as the GUI toolkit for the Common Desktop Environment (CDE), offering a set of widgets based on Xt Intrinsics with features like 3D appearance and drag-and-drop support.^[53] These libraries and toolkits manage protocol intricacies, including error recovery and resource deallocation, to ensure robust application behavior.^[54] They often incorporate X-specific extensions, such as the Double Buffer Extension (DBE), to enable features like flicker-free animations through off-screen buffering, which toolkits expose via simplified APIs.^[55] This layered approach not only promotes code reuse but also supports migration to non-X systems, as seen in GTK+'s backend-agnostic design.^[51]

Specialized Devices and Terminals

The X Window System has been adapted for specialized hardware through implementations targeting diskless X terminals, which were diskless devices running a minimal X server and booting over the network to provide graphical access in enterprise environments during the 1990s.^[56] These terminals, such as those from Network Computing Devices (NCD), relied on the X protocol's network transparency to connect to remote hosts via protocols like BootP, allowing users to run X applications without local processing power.^[57] For example, the NCD HMX model, introduced before February 1996 at a price of $3,495, used an 88k CPU family and exemplified the era's focus on cost-effective, centralized computing for offices and labs.^[58]^[59] In embedded systems, particularly those with constrained resources like IoT devices or personal digital assistants (PDAs), stripped-down X servers such as TinyX were developed to optimize for low RAM and CPU usage.^[60] TinyX, released as part of XFree86 4.0 in May 2000, provides a small-footprint X server suitable for resource-limited environments, emulating essential X functionality without the overhead of full desktop implementations.^[60]^[61] It supports applications requiring graphical output in embedded contexts, such as industrial controls or early mobile devices, by minimizing memory demands and focusing on core protocol handling.^[62] Virtualization extensions of the X server enable operation in headless or nested environments, addressing needs for testing and isolation. Xvfb (X virtual framebuffer), an X server that runs without physical display hardware or input devices, emulates a framebuffer in virtual memory to perform all graphical operations internally, making it ideal for automated testing, batch processing, or server-side rendering.^[63]^[64] Similarly, Xephyr serves as a nested X server that operates as an application within an existing X display, outputting to a host window and supporting modern extensions via its kdrive-based architecture; this allows for isolated sessions, such as running untrusted applications or debugging without affecting the primary desktop.^[65] Contemporary adaptations continue on low-power hardware like the Raspberry Pi, where variants of the X.org server provide graphical interfaces optimized for single-board computers in educational, hobbyist, and embedded projects.^[66] These implementations leverage the X protocol for remote access and lightweight desktops, such as in Raspbian distributions, enabling X11 forwarding over SSH for efficient resource use in headless setups. Containerized X environments, often using tools like Xvfb, further support cloud-based desktops by virtualizing displays for distributed computing.^[63] A key client for these specialized setups is xterm, the standard terminal emulator for the X Window System, which facilitates remote sessions by running as a separate process and displaying output over the network via the X protocol.^[67] This allows users on thin clients or embedded devices to interact with command-line interfaces on distant servers, maintaining compatibility across varied hardware configurations.^[67]

Limitations and Criticisms

User Interface and Accessibility Challenges

The X Window System lacks native compositing capabilities in its core protocol, leading to screen tearing artifacts during window movements or updates unless mitigated by extensions such as the Composite extension, which enables off-screen buffering for smoother rendering.^[68] This absence of built-in synchronization with display refresh rates exacerbates tearing, particularly in graphics-intensive applications or with certain graphics drivers, requiring users to rely on window manager compositors or driver-specific options for vertical sync (VSync) enforcement.^[69] Window managers in the X ecosystem implement diverse focus models, as outlined in the Inter-Client Communication Conventions Manual (ICCCM), which defines standards for input focus handling but allows variations such as click-to-focus, focus-follows-mouse, or globally active input.^[8] However, inconsistencies arise when window managers deviate from these conventions, resulting in unpredictable behaviors like erroneous input redirection or focus races where multiple windows compete for input, often due to uncoordinated event processing.^[70] Accessibility support in the X Window System is partial and relies heavily on the Assistive Technology Service Provider Interface (AT-SPI), a toolkit-neutral bridge that exposes application UI elements to assistive technologies like screen readers.^[71] While AT-SPI enables integration with tools such as the Orca screen reader, which provides voice output and basic magnification through GNOME's Accessibility Toolkit (ATK), there is no built-in support for features like screen magnification or high-contrast rendering at the X server level, forcing dependence on external applications and extensions.^[72] This architecture introduces latency in event processing, particularly for voice output in Orca, as AT-SPI's asynchronous communication can delay responses and render the interface unresponsive during complex interactions.^[73] Customization of the user interface is constrained by varying adherence to standards like ICCCM and the Extended Window Manager Hints (EWMH) across different window managers, such as Openbox or i3, leading to application incompatibilities where widgets or dialogs fail to render correctly or respond to user inputs as expected.^[74] For instance, non-compliant managers may ignore client hints for window placement or resizing, causing layout disruptions in cross-desktop applications. In modern contexts, the X Window System exhibits inadequate native support for touch and gesture inputs, with the XInput extension providing basic multitouch event handling but locking touch sequences to the initiating window, preventing fluid gestures like cross-window scrolling.^[75] This results in lag for gesture recognition and conflicts with legacy input emulation (e.g., emulating mouse scrolls), necessitating third-party extensions or toolkit-level workarounds for usable touch interfaces on devices like tablets.

Network and Performance Issues

The X Window System's network transparency, while a core feature, introduces significant latency issues in remote graphical user interfaces due to its reliance on synchronous client-server requests that require multiple round trips over the network. For instance, simple interactions like typing or mouse movements can exhibit noticeable delays over wide area networks (WANs), where even modest latencies of 50-100 ms amplify the effects of these round trips, making remote sessions feel unresponsive. This synchronous nature stems from the protocol's design, where many operations, such as drawing primitives or handling events, block until acknowledged by the server, exacerbating delays in high-latency environments.^[26] Bandwidth consumption in X11 is notoriously high because the protocol transmits uncompressed bitmaps and raw pixel data for graphical elements, leading to inefficient use of network resources, especially for image-heavy applications. Over low-bandwidth links, this verbosity can result in sluggish performance, with even basic window updates requiring kilobytes per frame without optimization. Partial mitigations exist through third-party compression techniques, such as the NX protocol, which employs differential updates, caching, and lossy compression to reduce data transfer by factors of 10-100x in typical scenarios, though it requires additional proxy software and may introduce minor artifacts.^[77]^[78] Security weaknesses in X11's networked operation further compound performance concerns, as the default authentication mechanism uses unencrypted MIT-MAGIC-COOKIE-1 cookies that are vulnerable to interception on unsecured networks. When combined with SSH X11 forwarding, this can enable attacks where a compromised remote server steals the cookie to hijack the local display session, injecting malicious input or exfiltrating screen contents without the user's knowledge. By default, X11 lacks built-in encryption for protocol traffic, relying on external tunnels like SSH for protection, but misconfigurations or untrusted forwards can expose sessions to man-in-the-middle exploits.^[79] Recent security audits as of 2025 continue to highlight vulnerabilities, such as integer underflows in the XInput extension (e.g., CVE-2020-14346) and out-of-bounds reads in the core server (e.g., CVE-2025-0425), potentially allowing remote code execution or denial-of-service in networked clients.^[80]^[81] X11's scalability suffers in networked high-DPI environments and video streaming scenarios without specialized extensions, as the core protocol does not natively support efficient rendering at resolutions beyond 96 DPI, leading to blurred or computationally intensive scaling that strains remote connections. For video, the XVideo (XV) extension provides hardware-accelerated overlays to mitigate bandwidth demands by bypassing full bitmap transmission, but its absence or incompatibility in remote setups results in poor frame rates and high CPU usage for software decoding over the network.

Architectural Drawbacks

The core X Window System protocol, finalized in 1987, has proven inadequate for contemporary computing demands, necessitating a proliferation of extensions to incorporate essential features such as multi-monitor support through the RandR extension.^[82] This post-hoc addition of functionality, including rendering improvements via the XRender extension, has resulted in architectural bloat, as the original protocol lacks modern abstractions for efficient graphics handling, such as alpha compositing or anti-aliasing.^[83] Consequently, server implementations must manage an expanding array of extensions, complicating integration and increasing overall system complexity without a unified evolution of the core design.^[82] The extreme modularity of X's client-server model, while enabling network transparency, imposes strict separation that historically hindered direct hardware access, particularly for graphics processing units prior to the introduction of the Direct Rendering Infrastructure (DRI) extension.^[82] This design forces all rendering through the server, leading to inefficiencies in resource-intensive applications and requiring extensions to bypass limitations, which further fragments the architecture rather than resolving foundational issues.^[83] Backward compatibility commitments have locked the protocol into 1980s-era assumptions, such as rudimentary bit-blit graphics and a core font system incompatible with Unicode, necessitating external libraries like Xft for modern text rendering.^[82] These constraints prevent comprehensive updates to the core without risking disruption to legacy applications, perpetuating an outdated foundation amid evolving hardware and software paradigms.^[82] The maintenance burden is exacerbated by fragmented development across multiple server implementations and the accumulation of legacy code in libraries like Xlib, resulting in slow adoption of critical updates, including security enhancements.^[82] Additionally, X lacks built-in power management capabilities, relying instead on the external DPMS extension to control display signaling for energy conservation.^[84]

Alternatives

Modern Competitors

Wayland has emerged as the primary modern competitor to the X Window System, serving as a display server protocol that shifts the role of the traditional X server to the compositor, which acts as the central server for rendering and input management.^[85] This design enables direct rendering from clients to the display hardware, bypassing the intermediary X server and reducing latency, while forgoing built-in network transparency in favor of local efficiency—remote access can be added via extensions if needed.^[86] Key advantages include a smaller attack surface due to the absence of default remote capabilities, which prevents unauthorized client-to-client interactions, and improved support for high-DPI displays through integrated scaling handled by the compositor.^[87] Additionally, Wayland provides more seamless input handling, with compositors mediating events to enhance security and responsiveness.^[88] As of 2025, Wayland has achieved significant adoption, powering approximately 70-75% of sessions in major Linux distributions such as those using GNOME and KDE Plasma 6, with compatibility maintained through XWayland, a compatibility layer that allows X11 applications to run under Wayland compositors.^[89] ^[90] Mir, developed by Canonical, represents another alternative focused on Ubuntu and embedded environments, prioritizing security through application isolation and sandboxing to limit the impact of vulnerabilities.^[91] Although initially positioned for desktop use, Mir has evolved toward IoT and specialized Linux devices, offering a lightweight compositor with support for touch and multi-input scenarios while maintaining compatibility with Wayland protocols in recent versions.^[92] Niche competitors include DirectFB, a graphics library tailored for embedded systems that provides hardware acceleration and input abstraction without the overhead of a full windowing system like X, making it suitable for resource-constrained devices but not as a general desktop replacement.^[93] In web-based contexts, technologies like WebRender serve as rendering engines for browsers such as Firefox, leveraging GPU acceleration for efficient 2D graphics composition independent of traditional display servers.^[94]

Transition and Compatibility

One key strategy for transitioning from the X Window System to modern alternatives like Wayland involves compatibility layers such as XWayland, which enables the execution of legacy X11 applications within a Wayland environment. XWayland functions as a full X11 server that operates as a client of the Wayland compositor, intercepting X11 protocol requests from applications and translating them into equivalent Wayland protocol calls to render windows and handle input. This approach allows users to adopt Wayland compositors like GNOME's Mutter or KDE Plasma's KWin without immediately rewriting or abandoning existing X11-based software, providing a seamless bridge during migration.^[41]^[95] Hybrid environments further facilitate the shift by supporting both X11 and Wayland sessions within major desktop environments, often with automatic fallback mechanisms. For instance, GNOME and KDE Plasma offer Wayland as the default session in recent distributions, utilizing XWayland to run X11 clients transparently when native Wayland support is unavailable, while tools like the Weston reference compositor enable isolated testing of Wayland applications and compatibility scenarios without disrupting the primary display server. These setups allow administrators and developers to experiment with Wayland incrementally, such as running GNOME or KDE sessions that revert to X11 only for specific hardware or software constraints.^[96]^[97] Despite these aids, transitioning presents challenges, particularly for legacy applications that rely on X11-specific features, such as certain CAD software like KiCad, which may encounter rendering or input issues under Wayland until fully ported. Networked applications that depend on X11 forwarding over SSH also require additional proxies, like waypipe, to tunnel Wayland protocol traffic, as native X11 forwarding is not directly supported and can introduce latency or compatibility gaps in remote workflows. These hurdles underscore the need for careful planning in enterprise or specialized environments where full X11 dependency persists.^[88]^[98] Looking ahead, major Linux distributions are pursuing gradual deprecation of X11, with Fedora achieving a Wayland-only GNOME session in its Fedora Linux 43 release in October 2025, removing the legacy X11 backend while retaining XWayland for compatibility. This milestone reflects broader industry trends toward phasing out pure X11 setups, targeting X-free environments by 2025 in key projects. Meanwhile, the X11 protocol remains in maintenance mode for existing servers, receiving security fixes but with active development efforts redirected toward Wayland protocol extensions to support evolving display and input requirements.^[96]^[99]

History

Predecessors and Influences

The development of the X Window System was shaped by several pioneering graphical user interfaces and distributed computing environments from the late 1970s and early 1980s, which addressed the limitations of text-based terminals and introduced concepts like bitmapped displays and networked windows.^[100] The Xerox Alto, introduced in 1973 at Xerox PARC, was a foundational influence through its bitmapped display, which allowed for the rendering of arbitrary graphics and text as pixels, enabling the first practical demonstration of overlapping windows, icons, and a mouse-driven interface.^[100] This pixel-oriented approach to graphics, distinct from vector-based systems, provided a model for high-resolution, interactive displays that later window systems, including X, would adopt to support rich visual environments.^[100] A more direct predecessor was the W Window System, developed at Stanford University in the early 1980s by Paul Asente and Brian Reid as a bitmap-based graphical user interface for Unix workstations. W introduced a hierarchical window model where windows could overlap and contain subwindows, along with an event-driven architecture that notified applications of user inputs like mouse movements and keyboard events. This event model directly inspired X's core mechanism for handling user interactions, emphasizing simplicity in protocol design to facilitate portability across hardware. However, X deliberately diverged from W by rejecting low-level raster operations—such as bitblits for direct pixel manipulation—in favor of higher-level primitives like lines and rectangles, to enhance network transparency and reduce protocol complexity in distributed settings. The Andrew Project, a distributed computing initiative at Carnegie Mellon University starting in 1982, further influenced X's architectural choices, particularly in supporting networked environments.^[101] Andrew's window manager, WM, predated X and featured asynchronous communication that allowed remote applications to update local displays without blocking, a paradigm X adopted to enable seamless operation over networks.^[101] This influence addressed the growing need for campus-scale computing where users accessed resources from multiple workstations, prioritizing functional separation between applications and display hardware. By the mid-1980s, proprietary graphical systems like SunView and NeWS from Sun Microsystems highlighted the fragmentation in Unix environments, underscoring the demand for an open, standardized alternative. SunView, launched in 1985, was an early GUI toolkit for Sun workstations that emphasized programmer-friendly abstractions for window management and event handling, but its tight integration with Sun hardware limited portability. Similarly, NeWS (Network-extensible Window System), introduced in 1986, incorporated PostScript for server-side rendering, offering advanced graphics but introducing unnecessary complexity, such as server-maintained tracking of application states, which X designers rejected to maintain a lean, client-driven protocol. These systems, while innovative, exemplified the risks of vendor lock-in, motivating X's focus on device independence and open collaboration to unify Unix graphical interfaces.

Origins and Early Development

The X Window System originated in the summer of 1984 at the Massachusetts Institute of Technology (MIT), specifically within the Laboratory for Computer Science, as a response to the need for a flexible display environment for debugging distributed applications like the Argus system. Robert W. Scheifler, a researcher at MIT, initiated the project by adapting code from the earlier W window system developed at Stanford University, replacing its synchronous protocol with an asynchronous one to improve performance and suitability for network use. This effort was part of the broader Project Athena, aimed at creating distributed computing resources for education, and quickly involved Jim Gettys from Digital Equipment Corporation (DEC), who contributed to its evolution. The initial release, X version 1, was announced by Scheifler on June 19, 1984, via an email to the Project Athena mailing list, describing a basic implementation for the VS100 display that supported window creation, input handling, and simple applications like a text editor.^[4]^[102] The core goals of X from its inception were to achieve network transparency, allowing applications to run on one machine while displaying on another without modification; hardware and device independence, enabling portability across diverse systems; and placement in the public domain to encourage widespread adoption and collaboration, avoiding the proprietary restrictions of contemporary systems like Sun's SunView or DEC's UIS. By late 1984, the system had progressed to support bitmap displays and basic graphics, but early versions lacked full networking. This changed with version 10, released in 1985 and further refined by 1986, which introduced robust network support over protocols like TCP, DECnet, and Chaosnet, using a client-server model where the server handled display and input while clients managed application logic. The design emphasized minimalism in the core protocol, providing low-level facilities for windows, events, and resources, while leaving higher-level features like user interfaces to separate toolkits.^[103]^[102] The name "X" derived from its position as the successor to the W window system in the alphabetical lineage, reflecting an experimental and evolutionary approach rather than a completely new invention. Early adoption accelerated through contributions from industry partners: DEC provided hardware testing on VAXstations and personnel support, while Sun Microsystems, after initial reservations about network overhead, began integrating X into its workstations and contributing to protocol refinements by 1986. This collaboration culminated in the freezing of the X11 protocol design in late 1986, stabilizing the core specifications ahead of its full release in 1987, which incorporated input from multiple vendors to ensure interoperability and extensibility. By this point, X had transitioned from a MIT prototype to a de facto standard for Unix-like systems, with implementations running on high-end workstations and terminals alike.^[103]^[6]

Organizational Evolution

The stewardship of the X Window System transitioned from academic origins to structured industry-led governance in the late 1980s, beginning with the formation of the MIT X Consortium in 1988 as a non-profit, member-funded organization established by the Massachusetts Institute of Technology to oversee technical and administrative development.^[104] This consortium was supported through membership fees from major vendors, including IBM and Digital Equipment Corporation (DEC), without imposing license fees on users or implementers.^[104] Under its leadership, the consortium coordinated the release of key protocol versions, including X11 Release 4 in 1989, Release 5 in 1991, and Release 6 in 1994, fostering standardization and adoption across Unix workstations.^[105] In 1993, the MIT X Consortium was succeeded by the X Consortium, Inc., an independent, not-for-profit Delaware membership corporation that assumed responsibility for enhancing and maintaining the X Window System standards.^[106] This entity shifted toward greater commercialization of the standards process while remaining non-profit, continuing the work of its predecessor by managing ongoing development and releases through the mid-1990s.^[105] By 1996, the X Consortium began winding down its operations, transferring stewardship of the X Window System to The Open Group—a consortium formed earlier that year through the merger of the Open Software Foundation and X/Open Company—at the start of 1997.^[107] The Open Group completed the X11 Release 6.3 (codenamed Broadway) in late 1996, introducing enhancements for web-based interactive applications, and emphasized conformance testing and branding for international standards, including integration with Unix certification programs.^[108]^[104] Parallel to these formal organizations, the XFree86 project emerged in the early 1990s as a volunteer-driven initiative to adapt the X Window System for Intel PC hardware, which was underserved by the consortium's workstation-focused efforts.^[109] Initiated in April 1992 by developers including David Wexelblat, David Dawes, Glenn Lai, and Jim Tsillas, XFree86 provided a freely redistributable X server implementation based on the MIT X distribution, operating independently to improve performance and hardware support for Unix-like systems on personal computers.^[110] A key aspect of this organizational phase was the evolution of the X Window System's licensing, which shifted in the mid-1980s from an initial proprietary model to an open, MIT-like license starting with X Version 6 in 1985, formalized in the X11 releases from 1987 onward.^[111] This change, influenced by Project Athena collaborators at MIT, DEC, and IBM, addressed concerns over public domain releases—such as potential liability issues raised by IBM—by permitting free use, modification, and distribution while requiring retention of copyright notices, thereby encouraging broader contributions without restrictive terms.^[111]

Recent Developments and Maintenance

In 2004, the X.Org Foundation was established as a nonprofit organization to oversee the development and maintenance of the X Window System implementation, known as Xorg, with a focus on advancing open-source graphics drivers and facilitating compatibility with emerging protocols like Wayland.^[112]^[113] This entity succeeded the earlier X.Org Group and emphasized collaborative efforts across the free software community to ensure the stability and evolution of X on platforms such as Linux and BSD.^[114] The formation of Xorg stemmed from a fork of the XFree86 project in 2004, prompted by controversial licensing changes in XFree86 version 4.4 that introduced restrictions incompatible with the GNU General Public License, leading major distributions to adopt the more permissively licensed Xorg branch.^[115]^[116] This transition stabilized graphics support on Linux systems by reinstating a fully open-source codebase, enabling widespread adoption and ongoing improvements in hardware acceleration.^[117] Throughout the 2010s and 2020s, maintenance efforts prioritized security enhancements and incremental features, including patches for vulnerabilities such as CVE-2023-3138 in libX11, which addressed improper validation in extension initialization, and CVE-2023-6377 in xorg-x11-server, mitigating out-of-bounds memory access.^[118]^[119] Additionally, support for ARGB visuals was refined to enable per-pixel alpha transparency in 32-bit depth windows, allowing compositing managers to handle semi-transparent elements more effectively without crashing legacy applications.^[120] These updates reflect a shift toward robustness rather than major innovations, with the X.Org Foundation also developing bridges like XWayland to support X applications under Wayland compositors.^[112] Amid the rise of Wayland as a modern alternative in the 2020s, X's primacy has declined, with many Linux distributions defaulting to Wayland for new sessions while retaining X for legacy compatibility, particularly in scientific computing environments where remote X forwarding remains essential for visualizing data from high-performance clusters.^[6]^[121] As of November 2025, the xorg-server 21.1.20 release, issued in October 2025, underscores this maintenance-oriented approach with security fixes for multiple vulnerabilities in the X.Org Server and XWayland, including issues enabling privilege escalation that date back to 1994, while introducing no significant new features.^[122]^[36] This release highlights X's role as a stable, if aging, foundation for existing ecosystems.^[123]

Release History

Major Protocol Versions

The X Window System protocol originated with experimental versions X1 through X9, developed internally at MIT between 1984 and 1986, which introduced foundational elements such as bitmaps for simple graphics and font handling for text rendering.^[103] These early iterations were primarily non-free and shared informally among collaborators, focusing on basic window management without full network support.^[124] X10, released in 1985, marked the first network-capable version of the protocol, enabling distributed client-server interactions over Unix systems and supporting asynchronous communication for improved responsiveness.^[103] It was standardized through discussions at the Lakeside Conference, where vendors agreed on its core design to promote interoperability across hardware platforms like Digital's VAXstations.^[125] This version established the bitmap display model and window hierarchy that became hallmarks of the system.^[103] The X11 protocol debuted with Release 1 (R1) in September 1987, solidifying the core protocol with a focus on stability, client-generated resource identifiers for efficient startup, and support for direct-color displays alongside multiple virtual colormaps.^[22] Subsequent releases refined these foundations: R2 in March 1988 added initial extensions for input handling; R3 in October 1988 introduced multibuffering; R4 in December 1989 enhanced font management and color allocation; R5 in September 1991 improved inter-client communication; and R6 in May 1994 incorporated shapes for non-rectangular windows and backing store mechanisms to preserve obscured content.^[126]^[127]^[128] These updates from R2 to R6 emphasized practical enhancements like kerning in text rendering and offscreen graphics without altering the major version number.^[103] Extensions effectively served as de facto protocol "versions" by adding specialized functionality while maintaining backward compatibility. The XRender extension, released in 2000, provided 2D acceleration through RGB-based image compositing, alpha blending, and anti-aliasing, replacing the older pixel-value model to enable efficient transparency and sub-pixel rendering.^[129] Similarly, the XFixes extension, introduced in 2003, added damage notifications to inform clients of screen region changes, along with fixes for selection ownership and cursor management.^[130] X11R7, initially released in April 2004, bundled the protocol with emerging desktop specifications from the FreeDesktop.org initiative, integrating standards for theming, clipboard management, and accessibility without introducing major core changes.^[131] Since then, the X11 protocol has seen no significant revisions to its core, with development shifting toward modular extensions and server optimizations to support modern hardware.^[132]

Key Implementation Releases

The fourth release of the X Window System, X11R4, arrived in December 1989 from the MIT X Consortium and marked significant advancements in server architecture and display capabilities, including enhanced color management to handle truecolor visuals and colormap allocation more efficiently.^[128]^[133] These features enabled more flexible configurations for networked environments and improved rendering on color displays, laying groundwork for broader adoption in graphical workstations.^[133] X11R5, released in September 1991, provided refinements to inter-client communication and introduced extensions like PEX for 3D graphics, along with improved color management via Xcms.^[134]^[135] The X11R6 release in May 1994 brought further refinements, including the X Image Extension (XIE) for server-side image processing operations such as filtering and geometry manipulations, reducing communication overhead for graphics-intensive applications.^[136]^[137] These additions enhanced user interaction and visual quality, making X more competitive with contemporary windowing systems. Following the 2004 fork from XFree86, the Xorg project delivered its first major modular implementation with Xorg 1.0 in January 2005, restructuring the X server into loadable components for drivers, extensions, and input handling to improve maintainability, portability, and community-driven development.^[138]^[139] This modularity facilitated easier updates to hardware support and reduced the monolithic codebase that had hindered prior releases. Xorg 7.7, released in July 2010 as part of X11R7.7, integrated enhancements to the EXA (X Acceleration) architecture, optimizing 2D acceleration for modern graphics hardware by streamlining pixmap handling and fallback mechanisms, which boosted performance in composite window managers and reduced tearing in dynamic environments.^[140]^[141] In November 2022, Xorg 21.1 emphasized security hardening, incorporating fixes for vulnerabilities in input handling and property access while maintaining compatibility with the X11 protocol, reflecting ongoing efforts to address legacy risks in deployed systems.^[142]^[143] Subsequent releases, such as Xorg-server 21.1.19 in October 2025, continued this focus with additional security patches for issues in the X Keyboard extension and resource cleanup, ensuring stability amid the transition to alternatives like Wayland.^[122] The XCB library reached version 1.15 in May 2022, refining asynchronous event handling through optimized protocol marshaling and reduced latency in reply queuing, which improved responsiveness for applications leveraging direct X protocol access over traditional Xlib.^[144]^[145]

References

[1]
The X New Developer's Guide: X Window System Concepts - X.Org
Jul 14, 2013 · The X Window System is a client/server system where the X server controls hardware access for multiple client applications. The X server ...Is Client / Server · In Practice · Displays and Screens · Window System Objects
[2]
X(7x) manual page - X.Org
The X Window System is a network transparent window system which runs on a wide range of computing and graphics machines.
[3]
The X Window System: A Brief Introduction
Mar 29, 2006 · X was born in May 1984, when Bob Scheifler substituted an asynchronous protocol for the synchronous protocol of the W Window System (W) and ...
[4]
The X Windowing System - catb. Org
First, in 1987-1988 X established itself as the standard graphics engine for Unix machines, a hardware-independent neutral platform on top of which to build ...
[5]
40 years later, X Window System is far more relevant than anyone ...
Jun 21, 2024 · X Window System, which turned 40 years old earlier this week, was something you had to know how to use to work with space-facing instruments back in the early ...
[6]
X Window System Protocol - X.Org
The protocol contains many management mechanisms that are not intended for normal applications. Not all mechanisms are needed to build a particular user ...
[7]
Inter-Client Communication Conventions Manual - X.Org
The goal of the ICCCM Version 2.0 effort was to add new facilities, to fix problems with earlier drafts, and to improve readability and understandability, ...
[8]
Glossary - X Window System User's Guide for X11 R3 and R4 of the ...
Glossary access control list X maintains lists of hosts that are allowed access to each server controlling a display. By default, only the local host may ...
[9]
Glossary - Solaris X Window System Developer's Guide
This book provides detailed information for software developers interested in interfacing with the Solaris X server. Read this book for detailed information ...
[10]
Red Hat Enterprise Linux 10 plans for Wayland and Xorg server
Nov 27, 2023 · ... X11 is a protocol that will continue to be supported through Xwayland, while the Xorg Server is one of the implementations of the X11 protocol.
[11]
Xlib - C Language X Interface
The X Window System is a network-transparent window system that was designed at MIT. X display servers run on computers with either monochrome or color bitmap ...
[12]
Basic Graphics Programming With The XCB Library - X.Org
Drawing in a window can be done using various graphical functions (drawing pixels, lines, rectangles, etc). In order to draw in a window, we first need to ...
[13]
The X New Developer's Guide: Xlib and XCB - X.Org
Jul 14, 2013 · Xlib and XCB have different design goals, and were developed in different periods in the evolution of the X Window System. Most application ...
[14]
X Toolkit Intrinsics - C Language Interface
Summary of each segment:
[15]
X Window System Protocol
Summary of each segment:
[16]
Chapter 7. The X Window System | Red Hat Enterprise Linux | 4
The X Window System uses a client-server architecture. The X server (the Xorg binary) listens for connections from X client applications via a network or local ...Missing: definitions | Show results with:definitions
[17]
3. The X Window System Architecture: overview
X was designed with a client-server architecture. The applications themselves are the clients; they communicate with the server and issue requests, also ...
[18]
X Window System Overview - Oracle Solaris 11.1 Desktop ...
The X Window System uses a client-server architecture. It enables multiple programs to share and access a common set of hardware.
[19]
[PDF] Section F.1.1 Display Management: The X Window System - MIT
Oct 29, 1986 · The X window system is based on a client-server model; this model follows naturally from requirements two and three in the previous section. ...
[20]
Inter-Client Communication Conventions Manual - X.Org
All properties used to reply to SelectionRequest events must be placed on the requestor window. In either case, if the data comprising the selection cannot be ...
[21]
X11R1 - X.Org
Dec 7, 2014 · The X Window System version 11 is intended to be able to support virtually all known instances of raster display hardware and reasonable future ...
[22]
6. Deprecated components and removal plans - X.Org
The LBX extension is disabled by default now, although the code still ships in the 7.1 server. Compared to other solutions like NX and SSH, LBX has generally ...
[23]
Security - X.Org
Aug 25, 2013 · The authentication methods currently supported in the X.Org xserver are: MIT-MAGIC-COOKIE-1: The most popular scheme, in which a certain string ...
[24]
Security Extension Specification - X.Org
The Security extension provides enhanced X server security, should not be exposed to untrusted clients, and introduces secure and insecure extensions.
[25]
X Window System Network Performance - keithp.com
Apr 7, 2003 · One round trip is required to get the protocol op-code, and typically a second round trip to get a version number of the extension ...
[26]
xpra home page
Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.
[27]
X Session Management Protocol - X.Org
The purpose of the X Session Management Protocol (XSMP) is to provide a uniform mechanism for users to save and restore their sessions.
[28]
XCOMPOSITE - X.Org
The composite extension provides several related mechanisms: Per−hierarchy storage, The rendering of an entire hierarchy of windows is redirected to off−screen ...Missing: System | Show results with:System
[29]
DAMAGE Extension Protocol Version 1.1 - X.Org
The precise reason for this architecture is to enable the Composite extension which provides multiple pixel storage areas for the screen contents. 3.1 Additions ...
[30]
XRDB(1) manual page - X.Org
Xrdb is used to get or set the contents of the RESOURCE_MANAGER property on the root window of screen 0, or the SCREEN_RESOURCES property on the root window of ...
[31]
Extended Window Manager Hints - Freedesktop.org Specifications
Sep 29, 2006 · This is Draft version 1.4.draft-2 of the Extended Window Manager Hints (EWMH) spec, updated Fri September 29, 2006.
[32]
The XKB Configuration Guide - X.Org
The easiest and the most natural way to specify a keyboard mapping is to use the rules component. As its name suggests it describes a number of general rules.
[33]
X Input Extension Version 2.0 - X.Org
The enter/leave and focus in/out model is described in the core protocol specification, Section 11. (EnterNotify, LeaveNotify events). For enter and leave ...
[34]
X.Org
May 4, 2023 · The X.Org project provides an open source implementation of the X Window System. The development work is being done in conjunction with the freedesktop.org ...Download · X.Org Foundation · Documentation · Releases/7.7Missing: XCB | Show results with:XCB
[35]
The difference between Xorg and XFree86 - Oracle Blogs
May 28, 2004 · The biggest difference between those two releases is that XF86 4.4 contains code that is covered by the new XFree86 license 1.1, while X.Org does not.
[36]
https://www.phoronix.com/news/X.Org-Server-3-Vuln-Oct-2025
[37]
Drivers - X.Org
Aug 25, 2013 · Look here to check if your graphics card / chipset is supported. The pages are named like the driver modules and sorted by manufacturer.
[38]
IntroductoryCourse · freedesktop.org - Nouveau
Aug 7, 2025 · The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window ...Missing: Xorg | Show results with:Xorg
[39]
Chapter 5. X11 Application Support - Wayland
Xwayland compatibility compared to a native X server will probably never reach 100%. Desktop environment (DE) components, specifically X11 window managers, are ...
[40]
XFree86 definition by The Linux Information Project (LINFO)
Jan 16, 2006 · This was followed by a controversial change2 in licensing, beginning with the release of XFree86 4.4 in February 2004, that added a clause that ...
[41]
XQuartz
The XQuartz project is an open-source effort to develop a version of the X.Org X Window System that runs on macOS.Releases · Support · Contributing · Bug Reporting
[42]
[PDF] Cygwin/X Frequently Asked Questions
Feb 18, 2023 · What is Cygwin/X? Cygwin/X is a port of the X Window System to Cygwin. Cygwin provides a UNIX-like API on the. Win32 platform. 1.2. What is ...
[43]
Features - Cygwin/X
Fullscreen Mode - Fullscreen mode allows the entire display to be taken over by Cygwin/X, which works particularly well when logging into a remote XDM server.Missing: port POSIX emulation
[44]
X Toolkit Intrinsics – C Language Interface - X.Org
The Intrinsics are a programming library tailored to the special requirements of user interface construction within a network window system, specifically the X ...
[45]
Xlib - C Language X Interface
The X Window System supports one or more screens containing overlapping windows or subwindows. A screen is a physical monitor and hardware that can be color ...
[46]
[PDF] Xlib − C Language X Interface - X.Org
Our thanks go to Jim Fulton (MIT X Consortium) for designing and specifying the new Xlib functions for Inter-Client Communication Conventions (ICCCM) support.
[47]
[PDF] XView Developer's Notes - Oracle Help Center
The OPEN LOOK and Sun™ Graphical User Interfaces were developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts ...
[48]
Using GTK on the X11 Window System
Using GTK on the X11 Windows System. On UNIX, the X11 backend is the default build for GTK. So you don't need to do anything special when compiling it, ...
[49]
Qt for Linux/X11 | Qt 6.10 - Qt Documentation
Platform support for Linux/X11 ... In addition, building graphical Qt applications requires Qt for X11 Requirements, and OpenGL libraries and headers installed.
[50]
Open Motif Data Sheet
Mar 19, 2003 · The Motif toolkit is based on the X11 Intrinsics, a toolkit framework provided with the X Window System. The Intrinsics have been specified as a ...
[51]
[PDF] X Toolkit Intrinsics — C Language Interface - X.Org
Communication with Window and Session Managers. The revision of the Inter-Client Communication Conventions Manual as an X Consortium stan- dard has resulted ...
[52]
Double Buffer Extension Library - X.Org
The Double Buffer Extension (DBE) provides a standard way to utilize double-buffering within the framework of the X Window System.
[53]
Category:NCD - Terminals Wiki
Apr 11, 2019 · Network Computing Devices, more commonly referred to as simply NCD, manufactured X window system terminals from 1989 through the 1990s.
[54]
Collected information on X terminals.
This document describes how an X terminal manufactured by NCD (Network Computing Devices) can be connected to and booted from a UNIX host using BootP (boot ...
[55]
NCD HMX - Terminals Wiki
Jul 30, 2019 · The NCD HMX terminal was introduced sometime before February, 1996 at a price of $3,495.
[56]
NCD X-Terminal - GeekDot
Sep 14, 2010 · The 88k CPU family wasn't only used in workstations/servers. They also found their way into some X-Terminals, like those from NCD.
[57]
Tiny-X: an embeddable X Window server - LinuxDevices
May 20, 2000 · Tiny-X, a small footprint X Window server implementation for embedded systems, is now available as part of XFree86 4.0.
[58]
X11 server - ArmadeusWiki
Jan 20, 2023 · An X11 server, like TinyX/Xfbdev, is used in some embedded systems, especially in low RAM systems, for applications needing reuse.
[59]
TinyX: Small Featured X Server - Hacker News
TinyX hits a very sweet spot for otherwise underpowered or obsolete machines. You can of course spend €50 and get a RasPi that can handle a more complex / ...Missing: embedded | Show results with:embedded
[60]
XVFB - X.Org
Xvfb is an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory.
[61]
xvfb(1): virtual framebuffer X server for X - Linux man page - Die.net
Xvfb is an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory.
[62]
Debian -- Details of package xserver-xephyr in sid
Xephyr is an X server that can be run inside another X server, much like Xnest. It is based on the kdrive X server, and as a result it supports newer extensions ...
[63]
Enable X11 Forwarding on Raspberry Pi - LinuxConfig
Sep 22, 2025 · Enabling X11 forwarding on the Raspberry Pi will allow you to run graphical applications on the device from your remote PC.
[64]
XTERM – Terminal emulator for the X Window System
Each xterm window runs as a separate process. Some may run on remote machines, using the X protocol to display on a local machine, while others may run and ...
[65]
The X New Developer's Guide: Modern Extensions To X - X.Org
Jul 14, 2013 · The X Window System has evolved over time via the X11 protocol's extension mechanism, which allows defining new protocol requests, events and errors that ...<|separator|>
[66]
Why is video tearing such a problem in Linux?
Feb 4, 2015 · Screen tearing appears mostly because of two reasons - drivers that aren't there yet, and lack of vsync with certain window managers. As for ...Missing: native | Show results with:native
[67]
(PDF) Why X is not our ideal window system - Academia.edu
The research demonstrates that window manager races can lead to inconsistent focus and colormap management, often resulting in erroneous user input handling ...Missing: incompatibilities | Show results with:incompatibilities
[68]
Assistive Technology Service Provider Interface [AT-SPI] (Open A11y)
AT-SPI is a toolkit-neutral interface between applications and assistive technologies, enabling tools to interact with GUI controls for accessibility.
[69]
Orca Screen Reader and Magnifier - Oracle Solaris 11 Desktop ...
The gnome-mag service has incorporated support for smoother full-screen magnification, which relies upon newer extensions in the X Window System server.Missing: latency | Show results with:latency
[70]
Modernizing accessibility for desktop Linux - LWN.net
May 6, 2024 · Usually this works via an accessibility API such as the Assistive Technology Service Provider Interface (AT-SPI) for open-source systems. AT-SPI ...Missing: X | Show results with:X
[71]
Extended Window Manager Hints - Freedesktop.org Specifications
Nov 29, 2011 · This spec defines interactions between window managers, compositing managers, applications, and the utilities that form part of a desktop environment.
[72]
The life story of the XInput multitouch extension - LWN.net
Mar 7, 2012 · The XInput multitouch extension provides for multitouch input events to be sent from the device to the appropriate window on the desktop.Missing: XInput2 | Show results with:XInput2
[73]
X/Blueprints/Multitouch - Ubuntu Wiki
Mar 7, 2010 · Integrates low-level support for certain models of touchscreen devices and exposes basic multitouch functionality on them to allow Ubuntu to be ...
[74]
The Wayland Situation: Facts About X vs. Wayland (Phoronix)
Jun 8, 2013 · The protocols used for network transparency should be ... (uncompressed bitmap data) is mandated, everything else is negotiated per session.
[75]
The Arrival of NX, Part 4 - Linux Journal
Aug 9, 2005 · ... X11 wire protocol to NX requests and handles compression and de-compression of traffic. How Effective Is NX? At first glance it may seem as ...Missing: reduction | Show results with:reduction
[76]
[PDF] X11 Forwarding of SSH considered harmful - GIAC Certifications
Apr 9, 2004 · E.g. it is shown in this paper how to use forwarded X11 cookies to gain unauthorized access from the remote SSH server to the local X server.Missing: eavesdropping | Show results with:eavesdropping
[77]
https://lwn.net/Articles/553415/
[78]
[PDF] The (Re)Architecture of the X Window System
Composite, which controls which sub- hierarchies within the window tree are rendered to separate buffers. • Damage, which tracks modified areas with windows, ...
[79]
None
### Summary of Shortcomings of Core X Rendering Architecture and How Extensions Address Them
[80]
X Display Power Management Signaling (DPMS) Extension Protocol ...
This extension provides X Protocol control over the VESA Display Power Management Signaling (DPMS) characteristics of video boards under control of the X Window ...Missing: native | Show results with:native
[81]
Why Wayland is the future. - Nullrequest
Feb 17, 2025 · This model allows for interesting solutions, like running applications on another computer over the network by communicating with an X11 server, ...<|separator|>
[82]
Advantages of Wayland over X11 - Linux.org
Apr 7, 2024 · Wayland offers improved performance, reduced input lag, and a cleaner design compared to X11. However, adoption has been slow due to the need for application ...Missing: protocol | Show results with:protocol
[83]
Wayland, XWayland, X11 and the future - Zorin Forum
Jun 7, 2025 · XWayland is just a compatibility bridge, not a crutch, allowing X11 apps to run on Wayland while its ecosystem matures. Wayland often ...
[84]
Wayland Will Never Be Ready For Every X11 User - Hackaday
Jul 28, 2025 · In X, the protocol is implemented by the server, and that means you can poke at all the various bits independently of the WM. In Wayland by ...
[85]
The Great X11-to-Wayland Migration
Jun 26, 2025 · The move from X11 to Wayland represents one of the most significant changes in how Linux handles graphics and windowing.
[86]
State of Linux Windowing Systems: Is Wayland Good in 2025?
Mar 27, 2025 · Wayland is largely in-place as the display server for most major Linux distributions. ... Wayland adoption is increasing and bugs are down.
[87]
Mir Display Server - Canonical
Mir is the fast, open and secure display server to unlock next-generation user experiences. Mir runs on a range of Linux powered devices including ...
[88]
canonical/mir: The Mir compositor - GitHub
Mir simplifies the complexity that shell authors need to deal with: it provides a stable, well tested and performant platform with touch, mouse and tablet input ...
[89]
DirectFB2 Aims To Resurrect DirectFB For Embedded Systems
Jan 27, 2022 · The DirectFB library had been a popular option for embedded systems in running off the Linux frame-buffer to avoid the full overhead of an X11 ...
[90]
servo/webrender: A GPU-based renderer for the web - GitHub
WebRender is a GPU-based 2D rendering engine written in Rust. Firefox, the research web browser Servo, and other GUI frameworks draw with it.
[91]
Understanding Xwayland - Part 1 of 2 | subdiff.org Blog
Jun 23, 2017 · It's a single binary containing an Xserver with a special backend written to communicate with the Wayland compositor active on your system.
[92]
Fedora Linux 43 is here!
Oct 28, 2025 · If you are a GNOME desktop user, you'll also notice that the GNOME is now Wayland-only in Fedora Linux 43. GNOME upstream has deprecated X11 ...
[93]
weston - the reference Wayland server - Ubuntu Manpage
XWayland provides backwards compatibility to X applications in a Wayland stack. XWayland is activated by instructing weston to load the XWayland module, see ...
[94]
KiCad and Wayland Support - Lobsters
Jun 17, 2025 · The reason it reads like an anti-Wayland piece is that it tells users “Wayland is broken, please switch to an X11 session” while it turns out KiCad runs fine ...Missing: challenges migrating<|separator|>
[95]
X11 Session Removal FAQ – Rust in Peace - GNOME Blogs
Jun 23, 2025 · No, the Xorg Server is still very much maintained, however its feature development is halted. It still receives occasional bugfixes and there ...Missing: maintenance shifted
[96]
How the Graphical User Interface Was Invented - IEEE Spectrum
Sep 1, 1989 · More than 1200 of the experimental Alto, developed in 1973 by the Xerox Palo Alto Research Center, were distributed to test its windows, menus, ...
[97]
CMU's Andrew project: a retrospective - ACM Digital Library
The X window system. ACM Trans. Graphics 5, 2 (1987). Digital Library · Google ... Tanenbaum describes the motivation, development, and market impact of the MINIX ...Missing: influence | Show results with:influence
[98]
Debut of X - Talisman
Scheifler) To: window@athena Subject: window system X Date: 19 Jun 1984 0907-EDT (Tuesday) I've spent the last couple weeks writing a window system for the ...Missing: Bob | Show results with:Bob
[99]
[PDF] The X Window System
The window hierarchy models the now-familiar “stacks of papers” desktop. For a given window, its subwindows can be stacked in any order, with arbitrary overlaps ...
[100]
The X window system | ACM Transactions on Graphics
An overview of the X Window System is presented, focusing on the system substrate and the low-level facilities provided to build applications and to manage ...Missing: Bob | Show results with:Bob
[101]
X Consortium Definition - The Linux Information Project
Jul 30, 2005 · The MIT X Consortium was established in January 1988 by the Massachusetts Institute of Technology (MIT) as a non-profit, member-funded ...Missing: history IBM R6
[102]
XCONSORTIUM - X.Org
The X Consortium was an independent, not-for-profit Delaware membership corporation. It was formed in 1993 as the successor to the MIT X Consortium.
[103]
XConsortium - X.Org
Sep 15, 2013 · The X Consortium was an independent, not-for-profit Delaware membership corporation. It was formed in 1993 as the successor to the MIT X Consortium.
[104]
X Press Release - X Consortium transfer to TOG - The Open Group
Founded in 1993 as successor to the MIT X Consortium, the X Consortium enhances and maintains the X Window System. In 1995, the X Consortium was named prime ...
[105]
X11R6.3 (Broadway) Overview - The Open Group
Broadway, was the code name for a ground-breaking initiative evolving the X Window System for creating and accessing interactive applications on the World ...Missing: stewardship 1996
[106]
XFree86 Announces Formation of the XFree86 Project, Inc.
XFree86 was initiated in April, 1992, by David Wexelblat, David Dawes, Glenn Lai and Jim Tsillas, to enhance the performance and reliability of X11R5 on the ...
[107]
The Complete Guide to XFree86 - R. Couri Hay
The primary difference lies in their licensing and development history. X.Org Server was forked from XFree86 in 2004 due to a controversial license change in ...Missing: predecessor Xorg
[108]
The mysterious history of the MIT License | Opensource.com
Apr 26, 2019 · The X Window System specifically provides the basic framework for "drawing and moving windows on the display device and interacting with a mouse ...
[109]
X.Org Foundation
May 31, 2017 · The X.Org Foundation researches, develops, and supports a free graphics stack, including DRM, Mesa, Wayland, and the X Window System. It formed ...Missing: 2020s | Show results with:2020s
[110]
What Is X.Org Foundation? - Computer Hope
Feb 27, 2019 · The X.Org Foundation (X.Org for short) is a non-profit organization founded in January 2004. Its stated purpose is to "research, develop, ...
[111]
XORGFOUNDATION
It was formed in 2004 as the successor to the X.Org Group at The Open Group. The purpose of the X.Org Foundation is to foster the development, evolution, and ...Missing: history | Show results with:history
[112]
X is now free of XFree86 - The Register
New licensing terms from XFree86 have finally convinced the power brokers to endorse a XOrg's fork, although XFree86 maintainer David Dawes says ...
[113]
XFree86 - DRI
Jul 20, 2016 · In 2004 XFree86 changed to a more restrictive license for the 4.4 ... license change, which with some additional work was released as Xorg 6.7.
[114]
Xorg and Its Evolution on UNIX-like Systems
Aug 7, 2024 · In the early 1990s, as personal computing and open-source software gained traction, the XFree86 project emerged. XFree86 aimed to bring the X ...
[115]
https://www.theregister.com/2004/04/15/x11_fork/
[116]
RHSA-2024:0009 - Security Advisory - Red Hat Customer Portal
Jan 2, 2024 · X.Org is an open-source implementation of the X Window System. It ... BZ - 2253291 - CVE-2023-6377 xorg-x11-server: out-of-bounds ...Rhsa-2024:0009 - Security... · Red Hat Insights Patch... · Affected Products
[117]
[PDF] Release Notes for X11R6.9 and X11R7.0 - X.Org
XLIB SKIP ARGB VISUALS, was added to the X11 library to hide this visual from applications that mistakenly try to use it. If an application fails only when ...
[118]
Using the X Window System — UIUC NCSA ICC User Guide
The X Window System allows a program on one computer to open windows on another. To use it, establish a secure connection and enable X11 forwarding. Windows ...Missing: XPe PDA
[119]
[ANNOUNCE] xorg-server 21.1.12
### Summary of xorg-server 21.1.12 Release Notes
[120]
x11-servers/xorg-server: X.Org X server and related programs
x11-servers/xorg-server: Update to 21.1.12 Release notes: https://lists.x.org/archives/xorg-announce/2024-April/003499.html Security: CVE-2024-31080 CVE ...
[121]
Package "xorg-server" (noble 24.04) - UbuntuUpdates
Version: 2:21.1.12-1ubuntu1.5, 2025-10-31 04:07:17 UTC. xorg-server (2:21.1.12-1ubuntu1.5) noble-security; urgency=medium. * SECURITY UPDATE: Use-after-free ...
[122]
[PDF] A Political History of X - keithp.com
X as Corporate Tool. ○ Jim Gettys and Smokey Wallace. ○ Write X11, release under liberal terms. ○ Displace SunView. ○ “Reset the market”. ○ Digital ...
[123]
What's the story behind the name "X11"?
Jun 7, 2017 · X is the X Window System, which at its core is a protocol; the number identifies the version of the protocol. X1 was released in 1984 inside MIT ...
[124]
X11R2 - X.Org
Dec 7, 2014 · The document X Window System Protocol, Version 11 is the final authority on what is and is not part of the core X Window System protocol.
[125]
X11R3 - X.Org
Dec 7, 2014 · The X Toolkit Intrinsics (frequently refered to as Xt) have been reviewed by the X Consortium and are now part of the X standard. Any vendor ...<|separator|>
[126]
X11R4 - X.Org
Dec 7, 2014 · X11R4 was the fourth release of the X Window System, Version 11 from MIT. It was released in December 1989, with the following changes excerpted ...
[127]
Design and Implementation of the X Rendering Extension - keithp.com
Apr 24, 2001 · The development of this extension has occurred in an entirely open fashion, with input solicited from all areas of the window system community.
[128]
XFIXES - X.Org
Xfixes is a simple library designed to interface the X Fixes Extension. This extension provides application with work arounds for various limitations in the ...Missing: System date
[129]
X11R7.0 Release - X.Org
Sep 15, 2013 · The first major version release of the X Window System in more than a decade, X11R7.0 is the first release of the complete modularized and ...
[130]
Release Notes for X11R7.7 - X.Org
This release is the eighth modular release of the X Window System™. The next full release will be X11R7.8 and is expected in 2013.
[131]
RELNOTES.txt - X.Org
The X Window System is a portable, network- transparent window system originally developed at MIT. It can be used on a wide variety of raster display devices, ...
[132]
X11R5 - X.Org
Dec 7, 2014 · X11R5 was the fifth release of the X Window System, Version 11, released in September 1991, introducing the X Font Service Protocol.
[133]
[PDF] Technical Standard Window Management (X11R5)
Although the X Window System also provides a protocol extension mechanism to allow for additional features, these features are not standardized and will ...Missing: XIE | Show results with:XIE
[134]
[PDF] X window system version 11 release 5 (X window system protocol
... do-not-propagate-mask. SETofDEVICEEVENT override-redirect. BOOL colormap ... Event propagation. Device-related events propagate from the source window to ...
[135]
Installing fonts - X.Org
The X11R6.8 server supports scalable fonts in four formats: Type 1, Speedo, TrueType and CIDFont. This section only applies to the former three; for information ...
[136]
[PDF] Technical Standard X Window System (X11R6): Protocol
Terminology. The following terms are used in this document: can. Describes a permissible optional feature or behavior available to the user or application ...
[137]
Index of /archive/individual/xserver - X.Org
xorg-server-21.1.12.tar.gz.sig, 2024-04-03 20:54, 310. xorg-server-21.1.12.tar ... 2025-02-25 19:00, 8.5M. xorg-server-21.1.16.tar.gz.sig, 2025-02-25 19:00 ...
[138]
Xorg releases | Challenge everything! - GNOME Blogs
Feb 23, 2007 · module versions in Xorg modular releases ... The XFree86 servers are derived from X386 1.2, which was the X server distributed with X11R5.
[139]
Release Notes for X11R7.7 - X.Org
These release notes contain information about features and their status in the X.Org Foundation X11R7.7 release.
[140]
EXA - X.Org
The EXA architecture is designed to make accelerating the Render extension simple and efficient, and results in various performance tradeoffs compared to XAA.Missing: 7.7 2010
[141]
[ANNOUNCE] xorg-server 21.1.10
Dec 13, 2023 · ... release contains fixes for CVE-2023-6377 and CVE-2023-6478 as reported in today's security advisory: https://lists.x.org/archives/xorg ...[ANNOUNCE] xorg-server 21.1.7Issues in X.Org X server prior to 21.1.9 and Xwayland prior to 23.2.2More results from lists.x.org
[142]
Security Advisories - X.Org
CVE-2020-14344: The X Input Method (XIM) client implementation in libX11 has some integer overflows and signed/unsigned comparison issues that can lead to heap ...
[143]
[ANNOUNCE] libxcb 1.15 - Mailing Lists - X.Org
[ANNOUNCE] libxcb 1.15. Matt Turner mattst88 at gmail.com. Tue May 3 22:18:36 UTC 2022. Previous message (by thread): [ANNOUNCE] xcb-proto 1.15 ...Missing: async | Show results with:async
[144]
xcb
Sep 30, 2024 · XCB is a C-language binding for the X protocol, replacing Xlib with a small footprint, latency hiding, and direct protocol access.Missing: async | Show results with:async