HN Debrief

Preparing for KDE Plasma's Last X11-Supported Release

  • Linux
  • Developer Tools
  • Accessibility
  • Infrastructure
  • Open Source

The post lays out KDE Plasma’s timetable for ending native X11 support. Plasma 6.7 is framed as the last release where KDE will ship X11 sessions, with the rationale being simple: carrying both X11 and Wayland paths burns developer time, slows performance work, and blocks Wayland-only features. The post also cites KDE telemetry showing the large majority of recent Plasma users are already on Wayland, though even the post notes the number drops once older Plasma 5 users are included.

If your team relies on Linux desktop workflows that touch accessibility tools, automation, remote desktops, kiosk setups, or precise window management, you should test them on Wayland now instead of assuming XWayland covers the gap. KDE’s direction is clear, so the real decision is whether to invest in Wayland-specific integrations, standard protocol work, or an X11-based fallback plan before the cutoff arrives.

Discussion mood

Mixed but tense. Plenty of people said Plasma on Wayland now works well for ordinary desktop use and that KDE is right to stop carrying two stacks. The dominant mood was still frustration because the remaining gaps hit advanced workflows, accessibility, automation, remote desktop, and niche hardware cases, which makes the migration feel solved for mainstream use but not for the users most likely to notice breakage.

Key insights

  1. 01

    Talon exposes the protocol bottleneck

    The Talon developer made the underlying problem uncomfortably clear. Partial Wayland support can be hacked together today with compositor-specific code, but full support for a voice control and accessibility tool needs a broad API surface that works across KDE, GNOME, and wlroots. That shifts the story from one app maintainer dragging their feet to an ecosystem problem where standards work is the real blocker. The KDE-side reply asking for a concrete capability list also suggests this is one of the few places where focused protocol work could actually move things forward instead of generating another abstract Wayland argument.

    If you depend on accessibility or automation tools, make a feature-by-feature inventory now and map each item to an existing protocol or a missing one. If you build platform software, the fastest useful contribution is often a precise API gap list, not another complaint about Wayland in general.

      Attribution:
    • lunixbochs #1 #2
    • buovjaga #1
  2. 02

    Bespoke compositor hacks versus standards

    A useful fault line emerged over strategy. One camp argued the only practical path is to ship KDE-specific or compositor-specific integrations first, because users need working software now. The other camp argued that this just recreates the exact fragmentation everyone is complaining about, and that the painful but correct path is standard Wayland protocols accepted in wayland-protocols and then implemented across compositors. That is the core product choice here. Short-term usability and long-term portability are in direct tension.

    If you ship Linux desktop tooling, decide explicitly whether you are building for KDE first or for Wayland broadly. A KDE-specific plugin may be the only route to near-term adoption, but you should treat it as a bridge and budget for protocol standardization work later.

      Attribution:
    • kelnos #1
    • tuna74 #1 #2
  3. 03

    Remote desktop is still not boring

    Several comments cut through the generic feature talk and focused on headless and unattended remote access. X11’s stack may be ugly, but Xvfb, VNC, xrdp, and fixed-resolution automation are predictable enough for cloud desktops, VMs, and remote administration. KRdp and current Plasma Wayland remote workflows still depend too much on a live logged-in session and have rough edges around startup, reconnection, display sizing, and unattended use. That is not a niche annoyance. It is a deployment blocker for managed environments.

    If you run developer workstations, lab machines, or remote desktops on Linux, validate your headless and unattended workflows before any Plasma 6.8 migration. Assume that “screen sharing works” is not the same thing as “remote desktop is production-ready.”

      Attribution:
    • aniou #1
    • gjvc #1
    • outofpaper #1
  4. 04

    Wayland broke old window management assumptions

    The most persuasive complaints were not about ideology but about ordinary desktop behavior that used to be trivial. Multi-display apps, picture-in-picture, reopening windows in the same place, and pinned utility windows all rely on window position and policy controls that Wayland intentionally restricted. Some of this is coming back through xdg-session-management and other extensions, but support is new, optional, and inconsistent. That makes the desktop feel unfinished in exactly the places where users expect muscle memory to survive upgrades.

    Audit any app or internal tool that depends on window placement, sticky windows, kiosk layouts, or reopening state. On Wayland, you can no longer assume those behaviors are part of the base platform, so you may need desktop-specific workarounds or a different UX.

      Attribution:
    • MegaDeKay #1
    • kelnos #1
    • ranger_danger #1
  5. 05

    KDE's Wayland numbers need context

    Commenters did not really dispute that Wayland is now the default for Plasma 6 users. What they pushed back on was how representative the headline figure is. The post’s strongest number covers only the latest Plasma release and comes from opt-in metrics, while the broader number including older Plasma 5 users is much lower. That does not invalidate KDE’s direction, but it does change the interpretation. It means adoption is high among current, default-path users, not that X11 has vanished from the real installed base.

    Treat KDE’s telemetry as evidence of direction, not proof your own user base is ready. If you support Linux customers, segment by distro, hardware age, and Plasma version before assuming Wayland usage looks like KDE’s charts.

      Attribution:
    • ceayo #1
    • justinclift #1
    • LtWorf #1
    • superkuh #1
  6. 06

    Wayland is stronger in appliances than desktops

    One sharp observation was that Wayland shines when you control the whole stack. Embedded systems and single-purpose devices can pair an app with a minimal compositor and get exactly the window routing they want. The pain starts when you expect a general-purpose desktop where arbitrary third-party apps can discover displays, place windows, and cooperate in flexible ways. In other words, Wayland’s model is cleanest for products and weakest for the messy, programmable desktop culture Linux users built on X11.

    If you are building a kiosk, handheld, or appliance-like product, Wayland is usually an advantage. If you are building general desktop utilities or cross-desktop power-user tooling, budget more time for platform variance and missing privileges.

      Attribution:
    • kmeisthax #1
    • bombela #1
  7. 07

    Foreign-window embedding quietly dies on Wayland

    A less obvious casualty is cross-process window embedding. One commenter described using XEmbed to wrap a legacy full-screen application inside a GTK control shell and avoid a major rewrite. Another pointed out that mpv and similar integrations run into the same problem. On Wayland, that pattern mostly disappears unless you write a custom compositor or redesign around in-process libraries. That closes off a whole class of pragmatic integration work that old desktop teams used to rely on.

    If you maintain legacy desktop software or internal tools that compose separate GUI processes into one shell, assume you will need a redesign on Wayland. Plan for library embedding, IPC-driven rewrites, or compositor ownership instead of hoping for a drop-in replacement.

      Attribution:
    • l72 #1
    • feverzsj #1
    • magicalhippo #1

Against the grain

  1. 01

    The security case is real

    A smaller but credible set of comments pushed back on the idea that Wayland’s restrictions are just dogma. Their point was that X11 was never a meaningful isolation boundary, modern desktop apps are large and vulnerable, and supply-chain or memory-corruption attacks turn any trusted app into an attacker. From that perspective, reducing ambient powers in the window system is overdue. The failure is not the security model itself, but how slowly the ecosystem is adding controlled ways to re-enable legitimate workflows.

    Do not dismiss Wayland’s constraints as pointless if you handle sensitive data or untrusted apps. The practical move is to ask for narrow, permissioned capabilities rather than assume the old unrestricted model will or should come back.

      Attribution:
    • gf000 #1
    • orbital-decay #1 #2
  2. 02

    For many users the transition is already done

    Amid the complaints, a lot of people reported that current Plasma Wayland on mainstream hardware feels effectively finished. They cited better frame pacing, smoother resizing, easier scaling, HDR progress, fewer tearing issues, and no obvious regressions in normal use. That matters because it suggests KDE is not forcing a migration from a clearly broken platform. It is cutting off a minority of demanding workflows after the default path has already become acceptable for a broad base of users.

    If your environment is a standard laptop or desktop setup, retest current Plasma Wayland instead of relying on impressions from a year or two ago. The pain is now concentrated in specific workflows, not in baseline desktop usability.

      Attribution:
    • bityard #1
    • fhars #1
    • ahartmetz #1
    • hgoel #1
  3. 03

    Applications should not own window policy

    Some commenters defended Wayland’s stance on always-on-top and picture-in-picture. Their argument was that window behavior should belong to the compositor and the user, not to apps that can abuse it for spammy overlays or fake dialogs. In that framing, Chrome-style PiP is a workaround inherited from weaker window management on other operating systems, not a capability the app should automatically control. The right missing piece is user-facing window-manager UX, not restoring blanket application authority.

    If you build desktop apps, design for window-manager cooperation rather than assuming your app can dictate z-order and placement. If you run KDE internally, you may get a better result by teaching users compositor rules and shortcuts than by waiting for apps to recover old privileges.

      Attribution:
    • thesuitonym #1 #2
    • zarzavat #1

In plain english

CAD ↩
Computer-Aided Design, software used to create precise 2D or 3D designs for physical objects.
compositor ↩
The part of a graphics system that combines windows, layers, effects, and the cursor into the final image shown on the display.
GNOME ↩
A popular open source desktop environment for Linux systems.
HDR ↩
High Dynamic Range, image and display formats that support a wider range of brightness and contrast than standard displays.
KDE Plasma ↩
A Linux desktop environment that provides the graphical interface for interacting with the system.
KRdp ↩
KDE’s remote desktop implementation based on the Remote Desktop Protocol.
PIP ↩
Performance improvement plan, a formal process employers use to document and manage an employee seen as underperforming, often a precursor to termination.
pointer warp ↩
A feature that lets software move the mouse pointer programmatically to a specific position.
Talon ↩
A voice control and automation tool used for dictation, scripting, and hands-free computer control, especially for accessibility.
VNC ↩
Virtual Network Computing, a way to remotely view and control another computer’s desktop screen.
Wayland ↩
A modern display server protocol used on Linux desktops.
wlroots ↩
A library used to build Wayland compositors, powering projects such as Sway and Hyprland.
X11 ↩
A windowing system for Unix-like operating systems that provides the basic graphical display framework for many desktop environments.
xdg-session-management ↩
A Wayland protocol for saving and restoring application and window session state.
XEmbed ↩
An X11 protocol that lets one application embed another application’s window inside its own interface.
Xvfb ↩
X Virtual Framebuffer, a headless X11 server that renders graphics in memory instead of to a physical display.

Reference links

Accessibility and migration pain points

KDE status and release context

Remote desktop and security background

Alternative tools and projects

  • gamescope
    Used to explain how Steam Deck handles gaming with a custom compositor rather than plain desktop KDE Wayland
  • river window management blog post
    Background on a Wayland compositor design suggested as a model for separating compositing from window management
  • river
    Recommended by an AwesomeWM user as a workable Wayland tiling migration path
  • SomeWM issue for Vicious widget support
    Shows active effort to make an AwesomeWM-like Wayland path more compatible with existing widget ecosystems