XWayland RandR Improvements Land for Better X11 Compatibility in 2026

The X.Org Server development cycle has kicked off for 2026 with a significant merge that addresses long-standing pain points in XWayland's X11 compatibility layer. Michel Dänzer of Red Hat landed a patch series that fundamentally improves how the Resize and Rotate (RandR) extension gets emulated under XWayland, touching on three critical areas that affect daily use for anyone running legacy X11 applications on modern Wayland compositors.

The Sorting Problem That Broke Scripts

For years, XWayland's RandR emulation has presented "fake" modes to X11 clients without any guaranteed ordering. While this might sound like a minor implementation detail, it created real-world friction. Any script parsing xrandr output that assumed modes would be sorted by resolution size would produce unpredictable results. Human operators glancing at the terminal output faced the same cognitive overhead—modes appeared in arbitrary order rather than the logical progression users expect (640x480, 1024x768, 1920x1080, etc.).

The merged code now sorts these fake modes by size, restoring the expected behavior. This might seem trivial, but it's the kind of fix that eliminates hours of debugging across thousands of user workflows. When you're troubleshooting display issues or writing automation scripts, predictable output matters.

Rootless XWayland Gets Smarter About Resolution Selection

Rootless XWayland mode—where X11 windows integrate directly into the Wayland desktop rather than running in their own virtualized environment—received a crucial behavioral change. Previously, when a Wayland compositor applied output scaling (think HiDPI displays where the compositor renders at 2x or 3x resolution), full-screen X11 applications struggled to identify the correct native resolution to use.

The new code ensures the actual output mode appears first as the preferred mode. This means a 4K display scaled to 1080p for UI legibility will still present its true 3840x2160 resolution to X11 applications that need it. Games, CAD software, and other graphics-intensive applications can now request and receive the native resolution they're designed to work with, even when the desktop environment is scaling for usability.

Rotation Support: The Missing Piece

Perhaps the most technically interesting fix addresses rotated display outputs. XWayland's RandR emulation previously failed to properly handle displays physically rotated 90 or 270 degrees. This isn't just about tablet users or portrait monitors—think of development workflows where vertical code viewing is preferred, or digital signage installations.

The rotation fix means X11 applications now receive correct coordinate space information when displays are rotated. Window managers can properly place dialogs, applications respect the rotated coordinate system for input handling, and graphical applications render correctly oriented output.

Why This Matters for the Ecosystem

These changes land in the X.Org Server Git repository, which serves as the foundation for XWayland implementations across all Wayland compositors—GNOME's Mutter, KDE's KWin, Sway, Hyprland, and others. While each compositor implements its own Wayland protocol handling, XWayland itself is a single binary that gets used universally.

The improvements demonstrate the ongoing maturation of the XWayland compatibility layer. We're moving past the "it mostly works" phase into "it works correctly in edge cases" territory. For enterprise deployments, creative professionals, and power users who need legacy X11 applications, these fixes reduce the friction of transitioning to Wayland.

Technical Implementation Details

The patch series modifies how XWayland handles the RandR protocol's mode enumeration and preference reporting. Rather than presenting modes in whatever order the Wayland compositor provides them, XWayland now maintains an internal sorted list. When X11 clients query available modes, they receive this sorted enumeration.

For rootless mode, the preferred mode flag gets set based on the compositor's actual output mode, not the scaled logical mode. This requires XWayland to query the compositor's native output state and present that information correctly to X11 clients while still respecting any scaling the compositor applies for UI purposes.

Rotation handling required changes to coordinate transformation logic. XWayland must now translate between the Wayland compositor's rotated coordinate space and the X11 client's expected unrotated space, ensuring input events and rendering commands get transformed correctly in both directions.

Availability and Future Releases

The code is already merged into the X.Org Server main branch. Distribution maintainers will package these changes in upcoming releases. The timing of the next XWayland feature release hasn't been announced yet, but these improvements will likely appear in X.Org Server 21.2 or whatever version number gets assigned to the 2026 development cycle.

For users running bleeding-edge distributions or building XWayland from source, the benefits are available immediately. For everyone else, this represents another incremental step toward making Wayland a truly viable desktop environment for all use cases, not just the ones that fit neatly into its security model.

The merge request contains the full technical details for those interested in the implementation specifics: XWayland RandR Improvements Merge Request.