Ubuntu 26.04 Drops X11: What Wayland Improves and What Breaks

Ubuntu 26.04 Drops X11: What Wayland Improves and What Breaks

Ubuntu 26.04 makes a significant change to its desktop architecture: the GNOME on Xorg session is no longer available. The login screen no longer offers an X11 session, and the familiar GDM configuration workaround cannot bring it back.

For most desktop users, this is unlikely to cause immediate problems. Wayland has matured considerably, and GNOME now handles everyday desktop operations, display scaling, screen capture, and graphics rendering through its native Wayland implementation.

Developers and system administrators have a different set of concerns. Tools that relied on global keyboard access, window manipulation, screen capture, and X11-specific interfaces may no longer work as expected.

The distinction between X11 and Wayland is architectural, not cosmetic. X11 allows applications to interact with a shared display server. Wayland restricts applications to their own surfaces and delegates display management to the compositor.

That single design decision explains most of Wayland’s advantages—and most of the compatibility problems developers now have to address.

🖥️ 1. Ubuntu 26.04 Removes the GNOME Xorg Session

#

The Ubuntu 26.04 release notes state that Ubuntu Desktop sessions now run exclusively on Wayland because GNOME Shell can no longer run as an X.org session.

The change is immediately visible at the login screen. Previously, clicking the gear icon in the lower-right corner of GDM allowed users to select between GNOME and GNOME on Xorg. Ubuntu 26.04 no longer provides that choice.

The old GDM workaround no longer works

#

On previous Ubuntu releases, users could disable Wayland by editing:

sudo nano /etc/gdm3/custom.conf

The relevant configuration entry was:

#WaylandEnable=false

Removing the comment and restarting GDM forced the login manager to use Xorg:

WaylandEnable=false

This approach no longer restores the GNOME Xorg session in Ubuntu 26.04. The problem is not simply that Canonical changed a configuration option. The GNOME Xorg session itself is no longer provided as an available desktop session.

Changing WaylandEnable cannot restore a session that is no longer installed.

How Ubuntu arrived at this point

#

Ubuntu’s transition to Wayland has taken several years.

• Ubuntu 17.10 introduced Wayland as the default desktop session.
• Ubuntu 18.04 returned to Xorg as the default because of practical compatibility concerns.
• Ubuntu 21.04 switched back to Wayland.
• Systems using proprietary NVIDIA drivers initially received special treatment and continued using Xorg.
• Ubuntu 24.10 removed that NVIDIA-specific exception from the default session selection.

The original concerns were not theoretical. Screen sharing, remote desktop access, and recovery after GNOME Shell crashes were all areas where Xorg offered a more predictable experience at the time.

Wayland gradually addressed these limitations through compositor improvements, desktop portals, PipeWire integration, and better graphics-driver support.

Ubuntu 26.04 represents the next stage of that transition: the standard GNOME desktop no longer provides an Xorg fallback.

⚙️ 2. X11 vs. Wayland: One Architectural Difference Explains Most of It

#

To understand why existing Linux desktop tools behave differently under Wayland, it helps to look at how the two display systems manage applications.

How X11 works

#

X11 dates back to September 1987, with its original development beginning at MIT in 1984.

Its design reflects the computing environment of that period. Multiple users could share a machine through time-sharing, the display was treated as a shared resource, and applications generally operated in an environment where clients were trusted.

The central component is the X Server. It manages the display, keyboard, mouse, window hierarchy, input focus, and other shared graphical resources.

Applications connect to the server and send requests describing graphical operations.

For example, an application can request that the server:

• Draw a rectangle at a specified position.
• Copy one region of the screen to another.
• Create or resize a window.
• Notify the application when a keyboard event occurs.
• Change or inspect window properties.

The X Server coordinates these operations and communicates with connected clients.

In practical terms, applications have access to a considerable amount of information about the shared graphical environment.

How Wayland works

#

Wayland takes a different approach.

It does not expose a global screen object or a shared window tree to ordinary applications. Instead, an application renders its own content into a buffer and submits that buffer to the compositor.

The application is responsible for producing the frame. The compositor decides how that frame participates in the desktop.

This includes:

• Window placement and stacking order.
• Input focus and event delivery.
• Display output selection.
• Resolution and scaling behavior.
• Frame scheduling and presentation.
• Coordination between multiple application surfaces.

The compositor is the central authority for these operations.

An application does not normally get to inspect another application’s window or issue arbitrary commands to the desktop.

The practical difference

#

The architectural distinction can be summarized in one sentence:

X11 lets applications interact with a shared display server, while Wayland lets applications submit their own rendered surfaces to a compositor that controls the desktop.

Think of X11 as a restaurant where individual chefs can walk into the dining area and instruct the staff where to put dishes. Wayland is closer to a central kitchen: each chef prepares a dish and sends it to the pickup counter, while a separate coordinator decides where it goes.

The difference affects far more than graphics rendering. It determines how applications interact with windows, capture input, record screens, and automate desktop operations.

🚀 3. What Wayland Actually Improves

#

Wayland’s benefits are direct consequences of giving the compositor control over the desktop and limiting what individual applications can access.

Three areas stand out: display synchronization, application isolation, and multi-monitor handling.

Tear-free rendering and frame presentation

#

With traditional X11 configurations, applications can draw into a shared display environment without a compositor coordinating the final presentation.

This can produce screen tearing.

When a monitor refreshes while a new frame is being written, the upper portion of the screen may show one frame while the lower portion shows another. The result is a visible horizontal discontinuity, particularly when moving windows or scrolling quickly.

Desktop environments addressed this problem by introducing compositors.

Tools and components such as picom, Mutter, and KWin can render windows into intermediate buffers and combine them before presenting the final image.

Wayland makes the compositor part of the normal display architecture rather than treating it as an optional addition.

Applications submit completed buffers, and the compositor controls when and how those buffers are presented. This gives the desktop a more consistent approach to frame synchronization and reduces the opportunities for tearing.

There is another performance benefit: direct scanout.

When a fullscreen application’s buffer can be displayed directly on a compatible output, the compositor may bypass its normal composition process. This reduces unnecessary rendering work and memory-bandwidth consumption.

The actual benefit depends on the GPU, driver, compositor, display configuration, and application. It can be particularly useful for fullscreen video playback and gaming.

Application isolation and desktop security

#

X11’s original security model assumes that connected applications generally trust one another.

This assumption creates problems on modern desktops.

Under a conventional X11 session, a client with access to the display server may be able to:

• Capture the contents of other windows.
• Observe keyboard input from other applications.
• Inject synthetic keyboard and mouse events.
• Inspect parts of the shared window environment.

These operations do not necessarily require root privileges.

The same capabilities support legitimate software such as accessibility tools, screenshot utilities, and desktop automation frameworks. However, they also make it difficult to prevent malicious applications from monitoring user activity.

An application that can observe global keyboard input may capture sensitive information without exploiting a separate vulnerability.

Wayland changes the default security boundary.

Ordinary applications receive access to their own surfaces and the input events intended for them. They cannot arbitrarily inspect other applications’ buffers or monitor global keyboard input through the standard protocol.

Access to sensitive desktop operations must instead be mediated by the compositor or an authorized desktop interface.

This does not make Wayland immune to security vulnerabilities. Compositor bugs, malicious extensions, privileged input devices, and overly permissive portals remain potential attack surfaces.

However, it establishes a much better default isolation model than the traditional X11 architecture.

Per-monitor scaling and refresh rates

#

Mixed-DPI environments have always been awkward under X11.

Consider a workstation with two displays:

• A 27-inch 4K monitor.
• A 24-inch 1080p monitor.

The displays have different pixel densities, so they need different scaling settings to produce similar physical text sizes.

X11’s traditional display model makes independent scaling difficult. Workarounds often involve global scaling, application-specific adjustments, or rendering everything at a common logical resolution.

These approaches can produce blurry text and inconsistent window sizes.

Wayland allows the compositor to manage scaling independently for each output.

This makes it easier to combine displays with different resolutions, refresh rates, and scaling factors.

Fractional scaling is also supported by modern Wayland compositors. GNOME can use scaling values such as 125%, 150%, and 175%, rather than restricting users to integer multipliers.

HDR and variable refresh rate support also benefit from the more modern display architecture, although actual availability depends on the compositor, graphics driver, display hardware, and application.

The result is a desktop model better suited to current multi-monitor hardware.

🔧 4. Where Wayland Breaks Existing Developer Workflows

#

Wayland’s security and display architecture come with a compatibility cost.

Tools that previously relied on unrestricted access to the X Server must now use explicit desktop interfaces, compositor-specific APIs, or lower-level input mechanisms.

This is where developers are most likely to encounter problems.

Global keyboard and mouse automation

#

This is probably the most noticeable difference for users with existing automation scripts.

Under X11, tools such as xdotool could send keyboard events, move the mouse, click arbitrary coordinates, and interact with other windows.

Similarly:

• wmctrl could inspect and manipulate windows.
• xbindkeys could register global keyboard shortcuts.
• Scripts could use X11 window IDs to target specific applications.

These workflows depend on the shared access model of X11.

Wayland does not expose an equivalent global window-control interface to ordinary applications.

As a result, an existing script such as:

xdotool mousemove 800 450 click 1
xdotool key ctrl+s

may fail under a native Wayland session.

One alternative is ydotool, which generates input events through the Linux input subsystem using /dev/uinput.

For example:

ydotool mousemove 800 450
ydotool click 0xC0

However, this approach has additional requirements.

The process needs permission to access the virtual input device, and granting that access can have security implications. It should not be treated as a drop-in replacement for xdotool in every environment.

For window management, desktop-specific interfaces are often more appropriate. GNOME extensions and D-Bus interfaces can expose some operations, while KDE provides its own integration mechanisms.

The important distinction is that Wayland deliberately avoids offering a universal API for arbitrary application-to-window interaction.

Screenshots and screen recording

#

X11 applications could generally capture the screen without asking the user for permission each time.

Wayland removes that unrestricted access.

The standard desktop approach uses xdg-desktop-portal to request access to screen contents.

A typical screen-capture workflow looks like this:

1. The application requests screen-capture access through the portal.
2. The portal presents a permission dialog.
3. The user selects the display or window to share.
4. The portal provides the application with an approved capture stream.
5. PipeWire transports the video frames.

This architecture allows the desktop environment to control what an application can record.

It also means that applications must implement the appropriate portal integration.

OBS Studio introduced usable Wayland screen-capture support in version 28.0, released in September 2022. Modern OBS versions can capture Wayland desktops through the portal and PipeWire.

For developers, the main consideration is that screenshot and recording software must use the supported capture interfaces rather than assuming direct access to the framebuffer.

The exact behavior can still vary between GNOME, KDE Plasma, and other desktop environments because portal implementations and supported features are not identical.

Input methods and text-input protocols

#

Input methods introduce another compatibility issue.

Under X11, input method frameworks such as Fcitx and IBus could observe and process keyboard events through the X11 input infrastructure.

Wayland does not provide unrestricted global keyboard interception.

Instead, input methods communicate with applications through dedicated text-input protocols and toolkit integrations.

The application must support the relevant interface for the input method to work correctly.

If the application does not implement the expected protocol, problems may include:

• The candidate window not appearing.
• Incorrect candidate positioning.
• Pre-edit text not being displayed properly.
• Keyboard events being processed incorrectly.
• Inconsistent behavior between native and compatibility applications.

This can affect Electron applications, older Java software, and applications built with outdated GUI toolkits.

For Electron applications, explicitly enabling native Wayland support may help:

electron --ozone-platform=wayland

For applications that do not work correctly with their native Wayland backend, using XWayland may be a better option.

The exact solution depends on the application version, toolkit, input method framework, and available protocol support.

Legacy X11 applications and XWayland

#

Wayland does not require every application to be rewritten immediately.

XWayland provides a compatibility layer for existing X11 software.

It runs as a Wayland client while presenting an X Server-compatible interface to legacy applications.

An older application connects to XWayland as if it were communicating with a traditional X Server. XWayland then integrates the application’s output into the Wayland desktop.

This allows many existing X11 applications to continue working without modification.

However, compatibility has limits.

The main costs fall into three areas.

Rendering and performance overhead

XWayland introduces an additional compatibility layer between the legacy application and the native Wayland compositor.

The overhead is often negligible for ordinary desktop applications, but complex graphics workloads can expose differences in performance or frame handling.

Scaling limitations

Legacy X11 applications may not understand fractional scaling.

Depending on the compositor and application configuration, XWayland may render an application at one scale and then have the compositor scale its output.

This can make text and interface elements appear blurry, particularly on mixed-DPI displays.

Clipboard and drag-and-drop compatibility

Clipboard integration and drag-and-drop operations must cross the XWayland boundary.

Most common workflows work, but edge cases involving selections, clipboard ownership, multiple windows, and application-specific behavior can still produce inconsistent results.

XWayland is a compatibility mechanism, not a complete replacement for a native Wayland implementation.

Protocol fragmentation across desktop environments

#

X11 benefited from a relatively unified protocol specification.

Wayland deliberately keeps its core protocol small. Features outside the core are implemented through extensions and additional protocols.

This gives compositors room to evolve independently, but it also creates interoperability challenges.

GNOME, KDE Plasma, and wlroots-based environments do not necessarily support identical extensions or implement every feature in the same way.

The differences become especially visible in operations that require access beyond an application’s own window:

• Global keyboard shortcuts.
• Screen capture and recording.
• Window activation and manipulation.
• Remote desktop integration.
• Input method support.
• Display management.

For developers maintaining cross-desktop applications, supporting Wayland is therefore not just a matter of implementing one protocol. It often requires testing against multiple compositors and portal implementations.

🛠️ 5. X11 Tools and Their Wayland Replacements

#

Moving an existing Linux desktop workflow to Wayland requires replacing some X11-specific utilities.

The following table covers common tools and practical alternatives.

Check the current session type

#

Before troubleshooting an application, determine whether the current desktop session is using Wayland or X11.

Run:

echo "$XDG_SESSION_TYPE"

Typical output:

wayland

or:

x11

You can also inspect the desktop environment:

echo "$XDG_CURRENT_DESKTOP"

For additional session information:

loginctl show-session "$XDG_SESSION_ID" -p Type -p Desktop

This helps distinguish a native Wayland application from an X11 application running through XWayland.

Clipboard operations with wl-clipboard

#

For command-line clipboard access, install wl-clipboard:

sudo apt install wl-clipboard

Copy text:

echo "Hello Wayland" | wl-copy

Read the clipboard:

wl-paste

This is a straightforward replacement for common xclip and xsel workflows.

However, it assumes that the application is running in a Wayland session with the appropriate clipboard integration.

Force individual applications to use XWayland

#

Not every application needs to run natively on Wayland.

If a GTK application has rendering or input problems, try:

GDK_BACKEND=x11 application-name

For Qt applications:

QT_QPA_PLATFORM=xcb application-name

These variables request the X11 backend. Under Ubuntu 26.04, the application will generally use XWayland rather than a native Xorg desktop session.

This is useful when a specific application has a broken native Wayland implementation but works correctly through the compatibility layer.

The approach does not restore an Xorg desktop session, and it cannot fix problems caused by missing XWayland support or application-specific incompatibilities.

🔍 6. What to Do After Upgrading to Ubuntu 26.04

#

The right migration strategy depends on how much your workflow relies on X11-specific functionality.

There are three common scenarios.

Scenario 1: Normal desktop usage

#

If you mainly use a browser, terminal, office applications, media players, and development tools, the default Wayland session should be sufficient.

Most mainstream Linux applications already support Wayland natively or work through XWayland.

There is no reason to change desktop environments simply because the Xorg option has disappeared.

Scenario 2: You depend on a native Xorg session

#

Some workflows still require an Xorg desktop session.

Examples include:

• Legacy automation frameworks.
• Applications that require unrestricted global keyboard access.
• Older GUI applications with incomplete Wayland support.
• Window-management scripts built around X11 window IDs.
• Specialized testing and remote-control environments.

If native Xorg compatibility is a hard requirement, consider installing a different Ubuntu desktop environment that still provides an Xorg session.

Possible options include:

• Kubuntu with KDE Plasma, where an X11 session is available.
• Xubuntu with Xfce.
• Ubuntu MATE.
• An i3-based desktop environment configured for Xorg.

Availability depends on the desktop version and installed session packages. Check the actual login-screen session options rather than assuming every installation provides both backends.

Changing the desktop environment is different from restoring GNOME on Xorg. It does not reverse Ubuntu 26.04’s GNOME session decision.

Scenario 3: Only a few applications have problems

#

If the desktop works normally but one or two applications behave incorrectly, troubleshoot those applications individually.

Start by checking whether the application has a native Wayland backend.

For GTK:

GDK_BACKEND=x11 application-name

For Qt:

QT_QPA_PLATFORM=xcb application-name

For Electron:

electron --ozone-platform=x11

These options can route applications through XWayland, allowing them to retain much of their traditional X11 behavior without requiring the entire desktop to run on Xorg.

For automation and screenshot tools, look for supported Wayland interfaces rather than assuming an X11 compatibility setting will solve the problem.

The same principle applies to input methods: check the application’s toolkit and text-input protocol support before changing the desktop environment.

📚 7. Further Technical Reading

#

For developers maintaining Linux desktop applications, the following resources provide useful background on the architecture and compatibility changes:

• PUDN Club — Technical resources and development notes covering software engineering and Linux-related topics.
• KAD8 — Technical articles and development resources covering Linux, programming, and system administration.

The official Wayland documentation and X.Org documentation are also useful when investigating protocol behavior, compositor responsibilities, and legacy application compatibility.

X11’s last complete release was X11R7.7 in 2012. Development did not stop entirely, but subsequent work has largely focused on maintenance rather than introducing a new architectural direction.

Wayland is now the primary development target for modern Linux desktop graphics. Ubuntu 26.04 makes that direction explicit by removing the GNOME Xorg session.

For application developers, the practical requirement is straightforward: stop treating the X Server as a global desktop-control API. Use compositor-supported interfaces for display management, portals for screen capture, supported text-input protocols for input methods, and application-specific APIs for automation.

The desktop’s security boundary has changed. Existing tools must adapt to it.