Cover Image
At the Panyu Square Station of the Guangzhou Metro, there is a library where you can read and study in the subway station.IntroductionWhen developing a graphical desktop under the Linux system, one can often be overwhelmed by a plethora of concepts or terms (GDM3, LightDM, XFCE4, X11, GNOME, Xserver, KDE, Weston, etc.). This article will help clarify the relationships between these terms, which is very beneficial for quickly locating and solving problems in your work.
Display Hierarchy
Display Manager (gdm3/LightDM)
↓ Starts a session with the specified protocol
Desktop Environment (GNOME/XFCE4/KDE)
↓ Runs on the implementation of the display protocol
Display Protocol Layer (X11/Wayland)
↓ Executed by specific implementations (Xserver/Weston)
Display Implementation Layer (Xserver/Weston (Desktop Compositor) + Graphics Driver)
↓ Calls lower-level interfaces (GBM/DRM) and graphics APIs (OpenGL ES/Vulkan)
Hardware Layer (GPU, Video Memory, Display)
Display Manager (gdm3/LightDM)
Function: Responsible for the graphical login interface, starting the specified desktop environment session after user authentication. The display manager loads the session configuration file of the desktop environment (e.g., /usr/share/xsessions/gnome.desktop) at startup, which specifies whether to use X11 or Wayland.
Key Point:
The display manager itself does not directly depend on the display protocol, but the desktop session it starts needs to specify the protocol (X11 or Wayland).
For example: gdm3 can choose to start GNOME on Xorg (X11) or GNOME on Wayland when starting GNOME.
Desktop Environment (XFCE4/GNOME/KDE)
Function: Provides a complete user interface (window manager, taskbar, system tools, etc.).
Key Point:
The desktop environment needs to run on the implementation of the display protocol (e.g., Xserver or Weston).
For example:
XFCE4 defaults to using X11, relying on Xserver for window management and input.
GNOME and KDE support Wayland, relying on their compositors (e.g., Mutter/KWin). The desktop environment’s built-in compositor (like GNOME’s Mutter) directly manages protocol logic.
Display Protocol (X11/Wayland)
Function: Defines the core rules for graphical display, such as window management, input event delivery, and rendering processes.
Key Point:
X11: Based on a client-server model, implemented by Xserver.
Wayland: Managed directly by the compositor for windows and input (e.g., Weston, Mutter), without a separate server.
Implementation of Display Protocol (Xserver/Weston)
Function: Translates protocol logic into specific operations on hardware.
Key Point:
Xserver: Implements the X11 protocol and interacts directly with the GPU driver through the Xorg driver.
Weston: The reference compositor for Wayland, allocates video memory through GBM, renders using Vulkan/OpenGL ES, and ultimately submits to the display hardware via DRM (Direct Rendering Manager).
Clarification of Misunderstandings:Is Weston a necessary component of Wayland?
No. Weston is a reference compositor for the Wayland protocol, used for demonstration and testing. Actual desktop environments typically develop their own compositors (like Mutter, KWin) to integrate more features and optimizations. For instance, GNOME does not require Weston but uses its own Mutter.
Hardware Layer
Function: Includes physical components such as GPU, video memory, and display output interfaces (e.g., HDMI).
Key Point:
The final operations of the display implementation must be transmitted to the hardware through the following components:
Graphics drivers (e.g., Mesa, closed-source NVIDIA drivers).
Video memory management interfaces (e.g., GBM).
Rendering APIs (e.g., OpenGL ES, Vulkan).
The Bridging Role of Intermediate Components
SDL2/GTK/Qt: Applications call graphics APIs (like OpenGL) through these libraries, which are then passed to the display implementation layer.
GBM/EGL: Provides video memory management and OpenGL ES context for Wayland compositors.
Understanding Key Points
Distinction between Protocol and Implementation:The display protocol (like X11/Wayland) is the rules, while the implementation (like Xserver/Weston) is the specific code.
The Necessity of Lower-Level Interfaces:GBM, DRM, and graphics drivers are the bridges connecting software and hardware.
The Role of Graphics APIs:OpenGL ES/Vulkan serve as the rendering interfaces between applications and display implementations.
The final model should emphasize “protocol implementation depends on lower-level interfaces to call hardware”, rather than a simple linear transfer.