For decades, Xorg has been the standard display server across the Linux ecosystem, quietly underpinning nearly every graphical interface since the 1980s. However, as desktop environments evolve and modern security expectations rise, Wayland is increasingly stepping in as its successor. Major distributions such as Fedora, Ubuntu, and Arch-based systems with GNOME and KDE now default to Wayland, signaling a wider shift in the graphical stack. While the transition promises notable benefits in security, performance, and architecture, moving from Xorg to Wayland is not simply a drop-in replacement—it’s a paradigm shift. The migration process demands a deeper understanding of how input, rendering, compositing, and system-level configuration all differ in practice. For Linux users, developers, and system administrators considering this transition, the key lies not just in flipping a session toggle, but in comprehending the behavioral differences and preparing the environment accordingly.
At a glance, Wayland offers a cleaner, more modern graphics stack. It removes many legacy features of Xorg, including the centralized, root-powered server model that exposes global input and window information to any running client. Instead, Wayland compositors operate in a rootless, per-session model, where each client communicates directly with the compositor via Wayland protocols. This architectural difference dramatically enhances security, preventing one application from sniffing keyboard events or hijacking window contents. For the user, this typically translates to more secure input handling and reduced exposure to keystroke logging or input injection attacks—vulnerabilities that Xorg has long struggled to mitigate. However, these same security improvements come with trade-offs in compatibility. Many tools and workflows that depend on legacy input and output mechanisms in Xorg behave differently or cease to function under Wayland unless specifically re-implemented by the compositor.
From a preparation standpoint, the first step is determining whether your system is Wayland-ready. On most modern Linux distributions, this involves checking whether your installed desktop environment and graphics drivers support Wayland sessions. On Fedora or Ubuntu with GNOME, Wayland is typically the default. To verify this, one can inspect the session currently running by using:
bashCopyEditecho $XDG_SESSION_TYPEIf the output reads wayland, then your session is already Wayland-based. If it reads x11, you’re still on Xorg. To switch, log out and select the Wayland session from your display manager—GDM, for example, presents this option in a gear menu next to your user name. KDE’s SDDM also provides a similar session toggle. However, successfully booting into Wayland is only the first step; many users quickly notice differences in behavior, especially around input devices, screen capturing, and graphical performance with third-party applications.
One of the first changes users notice after migrating is input behavior, particularly for peripherals like Wacom tablets, multi-touch trackpads, or specialized keyboards. Xorg treats input devices globally, exposing them to the system and user-space tools like xinput, allowing for configuration from the command line. On Wayland, input devices are managed directly by the compositor and exposed via libinput, making traditional tools like xinput non-functional. Instead, settings must be configured via graphical tools (such as GNOME Settings or KDE Input Device panels) or through compositor-specific configuration files. Users who previously used xinput set-prop to tweak acceleration or device options may now need to rely on libinput debug-events for diagnostics and make changes via the compositor’s configuration interface or tools like gsettings. For instance, to change mouse acceleration settings under GNOME on Wayland, one might use:
bashCopyEditgsettings set org.gnome.desktop.peripherals.mouse accel-profile 'flat'Graphics performance is another area where expectations must be adjusted. Under Wayland, applications render their content using EGL and submit the final buffer directly to the compositor via shared memory or DMA-BUF, depending on driver support. This often results in lower latency and reduced input lag, especially when using a well-optimized compositor like Mutter or KWin. Additionally, screen tearing is largely eliminated due to native support for GPU-based buffer flips and synchronization, a long-standing pain point in Xorg that often required custom xorg.conf tweaks or use of proprietary extensions like ForceCompositionPipeline with NVIDIA. However, the move to Wayland may also reveal regressions, particularly with applications that rely on legacy OpenGL paths or compositing extensions unsupported under Wayland. Tools such as glxgears, xeyes, or xcompmgr no longer operate natively and instead must run through XWayland, the compatibility layer provided to bridge X11 clients on Wayland compositors.
XWayland itself deserves specific attention. While it ensures many X11 applications continue to function without modification, it comes with caveats. Applications running via XWayland cannot access global input like they could under Xorg, and performance can vary, especially with high-refresh-rate displays or complex input scenarios. If an application launches via XWayland, one way to confirm this is by checking its environment variable:
bashCopyEditxprop | grep WAYLAND_DISPLAYIf there’s no Wayland display variable attached to the window, the app is running via XWayland. For applications where native Wayland support is desired, users must rely on upstream developers to implement Wayland clients or support protocols such as xdg-shell and xdg-toplevel. This is particularly relevant for GUI toolkits—GTK 3.20+ and Qt 5.9+ have native Wayland support, but legacy versions do not. Developers building GUI applications should ensure they are using the correct build targets; for Qt apps, this means building with -platform wayland rather than xcb.
Screen recording and window capture workflows also change significantly under Wayland. Unlike Xorg, where tools like ffmpeg, xwd, or import from ImageMagick can capture any window or screen by querying the root window, Wayland restricts access to framebuffers for security. Instead, screen recording must route through xdg-desktop-portal and PipeWire, which securely broker access to the display. Applications like OBS Studio, SimpleScreenRecorder, and GNOME Screenshot must now interface with these APIs rather than directly reading screen data. For example, to screen record under GNOME Wayland using wf-recorder, a user might execute:
bashCopyEditwf-recorder -o $(swaymsg -t get_outputs | jq -r '.[0].name') -f output.mp4This command, albeit designed for Sway, illustrates how Wayland compositors often expose device-specific APIs that vary from one implementation to another—highlighting the lack of universal tooling compared to Xorg’s long-established utilities.
Another preparation step involves evaluating peripheral workflows such as clipboard management, input method editors (IMEs), and window tiling. Under Wayland, clipboard access between applications is managed more securely but can behave differently for command-line utilities like xclip or xsel, which no longer function unless running under XWayland. Users can instead employ Wayland-native alternatives like wl-clipboard. For example:
bashCopyEditwl-copy < file.txt
wl-pasteSimilarly, tiling window managers like i3, dwm, or awesome—long mainstays of power users—are not compatible with Wayland. Migrating users must explore Wayland-native alternatives like sway (i3-compatible) or river, which require new configuration paradigms and ecosystem awareness. It’s not just a matter of porting dotfiles, but re-learning how compositor-specific backends interact with input and output devices, workspaces, and bar systems.
For application developers and sysadmins managing graphical environments in containers or remote environments, the migration demands further attention. Wayland’s design intentionally omits remote desktop support at the protocol level. To replicate X11 forwarding over SSH, one must now rely on protocols such as RDP, VNC, or third-party tools like waypipe. While promising, these are less mature and may introduce latency or application incompatibility. Launching an application from a container that connects to a host Wayland session may look like this:
bashCopyEditWAYLAND_DISPLAY=wayland-0 \
XDG_RUNTIME_DIR=/run/user/1000 \
weston-terminalSuch configurations require careful permissions handling, particularly with container runtimes like Docker, which may lack access to the user’s runtime directory. Conversely, Xorg’s model of simply exporting the DISPLAY variable and enabling xhost remains more straightforward for container graphics.
Despite the challenges, the migration to Wayland is ultimately rewarding, especially for users who value input security, smoother graphical performance, and streamlined compositing. But the path to a fully Wayland-native system requires patience, an awareness of protocol limitations, and a willingness to adapt workflows. Users who prepare by upgrading applications, adopting Wayland-compatible toolkits, and understanding compositor-specific quirks will find the transition smoother. It’s also wise to retain the ability to fall back to Xorg during edge-case scenarios. This can be achieved by keeping both sessions installed and switchable from the login manager, ensuring that when a mission-critical application fails to behave under Wayland, the user is not left without a functioning desktop.
In summary, migrating from Xorg to Wayland is not merely a visual upgrade but a structural realignment of the Linux desktop experience. It involves rethinking how applications talk to the display server, how input is routed and sandboxed, and how graphics data moves between GPU and screen. While many of these changes are invisible to the casual user, those with customized workflows, power-user preferences, or application development responsibilities must prepare proactively. The migration is best approached not as a complete replacement, but as a staged transition—where Xorg and Wayland coexist for a time, gradually handing over responsibilities as the ecosystem matures. In doing so, Linux continues its evolution into a platform that balances both its Unix roots and its forward-looking innovations, offering users the best of both worlds with the flexibility to choose.
