KDE Plasma 6.8 Without an X11 Session: What XWayland Preserves

Your old X11 applications have not vanished

The phrase “KDE removes X11” can sound as though an entire shelf of familiar software has just become museum material. I like old software, but that is not what this release does. The important distinction is between the desktop session you log into and the protocol an individual application uses.

Plasma 6.8 retires the Plasma X11 login session. Legacy X11 applications can generally continue through XWayland inside a Wayland session. KDE’s 14 October 2026 release announcement also says KDE applications retain X11 support. Other desktops and previously released Plasma versions are separate projects and releases.

This guide is a decision aid, with source and package checks dated 5 November 2026. It contains no new benchmarks from Cthulhu, my Arch Linux desktop with AMD Radeon graphics, and no claim that Plasma 6.8 is installed there. A successful migration is measured by your actual work, including the obscure shortcut you use fifty times a day.

X11, Wayland, KWin and the login screen

X11 is the long-established display protocol behind traditional Linux graphical sessions. An X server connects applications to input and displays; a window manager arranges windows, while compositing adds the final visual composition. Modern rendering has evolved considerably around that architecture. Its age alone is not an explanation of either its strengths or its limitations.

Wayland defines communication between applications and a compositor. In this architecture the compositor is also the display server. In Plasma, KWin handles that role, integrating window management, input routing and presentation. An application provides content for its surfaces; the compositor decides how those surfaces appear on the available outputs. The Wayland architecture documentation explains the relationship.

The display manager is the login interface that starts a chosen session. It is not the same component as KWin. Losing “Plasma (X11)” from that chooser does not mean the login manager itself cannot start another desktop’s X11 session. Nor does a working login screen prove that every application backend has been tested.

Two application paths, one desktop

The original diagram shows two paths. A native Wayland application communicates with KWin directly using Wayland. An X11 application communicates with XWayland, which acts as a Wayland client of KWin. KWin then presents both alongside one another through the graphics stack and displays.

XWayland is an X server, not a simplistic translation of every X11 capability into a global Wayland equivalent. It preserves many ordinary application behaviors. Desktop components designed to control the whole X server, including replacement X11 window managers, do not automatically become managers of native Wayland windows.

It also does not automatically isolate X11 applications from one another when they share one XWayland server. Native Wayland’s boundaries and compatibility support can coexist without making every legacy process a fully sandboxed process. This matters when discussing security advantages honestly.

What changed in 6.8, and why

Developer David Edmundson’s 2 June 2026 transition explanation identifies Plasma 6.7 as the last release with the Plasma X11 session. It distinguishes removal of session-specific code from continued XWayland support and KDE application compatibility on other desktops. The October release announcement confirms the shipped transition.

Maintaining two desktop paths consumes engineering and testing effort. Focusing KWin and Plasma development on one architecture can simplify future work. That is a project-maintenance argument, not proof that every specialized workflow is already equivalent. The developer explanation acknowledges that scripts, tools and habits may need changes.

Wayland’s compositor-centered approach provides a useful basis for per-output scaling, different refresh rates and modern presentation features. HDR and color management still depend on the compositor, application, driver and display path. A protocol name alone does not establish correct color or reduced latency for a particular machine.

Security changes also affect behavior. An ordinary application should not freely read every other window or inject arbitrary input across the desktop. Some X11 utilities relied on precisely those capabilities. Replacing the capability with an explicit desktop service can preserve the user’s task while changing the tool that performs it.

Check the session you are actually using

Run these read-only checks in a terminal inside your graphical session. An SSH shell, a stale tmux environment or a manually modified environment can describe something else. Start with the broad session type:

echo "$XDG_SESSION_TYPE"

A typical value is wayland or x11. Empty output is inconclusive. Next inspect the display connection variables:

echo "$WAYLAND_DISPLAY"

echo "$DISPLAY"

A populated DISPLAY in a Wayland session is normal when XWayland is available. It does not turn the whole desktop into an X11 session. Likewise, a session capable of running native Wayland clients can also run applications that choose an X11 backend.

On a system using systemd-logind, and when XDG_SESSION_ID is set for the relevant session, this supplies another view:

loginctl show-session "$XDG_SESSION_ID" -p Type

If that variable is empty, identify the appropriate session with loginctl list-sessions rather than substituting a random ID. These are diagnostic observations, not compatibility tests. An application’s own diagnostics may be needed to establish its rendering backend.

Compatibility is a workflow question

This matrix describes architectural expectations and checks, not a certification of every application release. “Typically works” still needs testing with your packages. “Depends” means the application, compositor, portal or driver must implement the relevant path.

A failure to capture native windows from an X11-only utility can be an architectural limitation, not a Plasma 6.8 regression. Conversely, a crash in a particular package deserves its own bug report. Avoid merging those two categories into “Wayland is broken” or “your workflow is invalid.”

Portals and PipeWire: permission instead of unrestricted capture

Desktop portals provide standard interfaces for tasks mediated by the desktop. An application can request screen sharing; the desktop backend presents the selection or permission interaction. In Plasma, the KDE portal backend is part of the integration to check. An installed portal package and an application actually using the interface are separate requirements.

The ScreenCast portal returns selected capture streams through PipeWire. PipeWire transports the media; it does not independently decide that an arbitrary application may record everything. Screen capture and audio output also use related infrastructure without being the same diagnostic problem. For sound problems, the Linux Audio Rescue guide examines that other path.

There are also portal interfaces for global shortcuts and remote desktop. Their existence is not proof of universal implementation. Check both ends: the application’s support and the desktop backend supplied by the distribution.

Remote assistance deserves extra care. Sharing an already logged-in desktop, reaching a locked machine and starting an unattended headless session are different capabilities. Test the exact one you need before relying on it remotely. A working local screen-share dialog does not prove that reconnecting after a reboot will work.

Choose your Wayland readiness checks

This private guide narrows the checklist to a use case. It never returns an automatic “compatible” result. Without JavaScript, expand any of the sections below. With JavaScript, selecting a role opens its checks; “all” restores the complete set.

Debian, Arch, Ubuntu and Fedora do not update together

An upstream release date does not change every installed desktop overnight. The following package-page snapshot was checked on 5 November. It describes the referenced repositories, not every backport, architecture or locally installed machine. Package revision prefixes such as Debian’s epoch are packaging information, not part of the Plasma marketing version.

On Debian/Ubuntu, apt-cache policy plasma-desktop distinguishes installed and candidate versions. Arch users can inspect pacman -Q plasma-desktop; Fedora users can inspect rpm -q plasma-desktop. These read-only queries do not establish the whole KWin, driver and portal stack. Follow the distribution’s normal supported upgrade process and avoid partial package mixes.

AMD, NVIDIA, mixed monitors and gaming

AMD systems commonly rely on a kernel driver, Mesa and the compositor working together. NVIDIA proprietary-driver setups add their own integration requirements. “AMD works” and “NVIDIA fails” are both too broad to guide an actual installation. GPU generation, driver branch, XWayland, KWin, connectors and application backend all matter.

KDE’s NVIDIA guidance discusses EGL integration, DRM modesetting and explicit synchronization. Treat older minimum-version statements as historical requirements, not recommendations to install an obsolete driver. Use the maintained driver supported by your distribution and hardware. This guide does not prescribe a global kernel-parameter rewrite.

For a concrete version-scoped example, NVIDIA’s 580.178.04 Wayland known-issues chapter documents limits in nvidia-settings and particular GLX paths. That is documentation for that driver branch, not a list of defects newly introduced by Plasma 6.8. Read the release notes for your installed driver before turning an old workaround into a new system-wide setting.

For multiple displays, test the intended combination of scale, refresh rate and orientation. Then repeat after suspend, unplugging a dock and reconnecting a display. Fractional scaling can expose differences between native and XWayland applications. Text sharpness, pointer coordinates and capture resolution matter as much as whether a window opens.

For games, compare the same title, settings and runtime under controlled conditions if performance matters. Average FPS alone can hide frame-pacing or input problems. Overlays and recording may exercise another path entirely. No measurements were performed on Cthulhu for this article, so there is no invented latency or benchmark advantage to report.

A migration plan with a real recovery path

1. List essential applications, shortcuts, devices and remote-access requirements.
2. Record the current distro, session, Plasma/KWin and driver versions.
3. Read the distribution’s upgrade notes and application-specific documentation.
4. Test on a supported session or suitable spare/live environment; hardware tests need real hardware.
5. Exercise the workflow checklist, including assistive technology and recovery access.
6. Upgrade through supported repositories and keep a usable backup and administration route.
7. Report a reproducible blocker with versions and conditions to the relevant project.

Once 6.8 is installed, “select Plasma X11” is no longer a recovery plan for that release. A separate supported desktop, console access or a tested restore may be appropriate. Remaining temporarily on a supported older distribution is legitimate when essential work is blocked. Forcing scattered old Plasma packages into a new system is a different and much riskier proposition.

If you are planning a broader move to Linux, use this checklist alongside the Linux Migration Companion to inventory essential applications. Changing operating systems and changing session architecture are separate decisions; identifying indispensable workflows helps with both.

The useful conclusion is practical: X11 application compatibility survives, while assumptions about controlling the whole desktop deserve review. Plasma’s transition changes the session architecture. Whether it fits your machine is answered by the tasks you can complete reliably, not by a protocol argument on the Internet.