As a longtime KWin maintainer, Edmundson frames the decision as basic math: every new Plasma feature has to be implemented and tested twice across two backends, with the X11 half serving users who could already migrate. He describes X11 as 'maintained but not developed' for years — a tax the project no longer wants to pay rather than a viable platform worth preserving.
The editorial argues X11 survived this long not because of demand but because it provided a fallback if Wayland broke. That safety net came with hidden costs — accessibility features, HDR, and the input stack all had to be plumbed through two protocols, and only now can maintainers quantify what keeping the dual path actually cost them.
The piece situates KDE's move within a sector-wide shift: GNOME deprecated its X11 session in mutter earlier this year and Fedora 43 dropped it entirely. KDE held out longer because its power-user base relies on edge cases like Nvidia proprietary drivers, mixed-DPI multi-monitor setups, and x11vnc — but the industry direction is now unambiguous.
By submitting Edmundson's post to Hacker News where it drew 164 points and 192 comments, the submitter surfaced this as a milestone in the broader X11 sunset narrative rather than a KDE-specific quirk. The framing treats it as the next inevitable step after GNOME and Fedora's moves.
KDE developer David Edmundson published a blunt heads-up on his blog: Plasma 6.5 will be the last Plasma release to ship an X11 session. After that, X11 support gets ripped out of the codebase. Wayland becomes the only way to run a Plasma desktop.
Edmundson is not a peripheral voice here — he is one of the maintainers who has spent the last decade keeping KWin's dual-backend architecture alive. His post frames the decision as an engineering judgment, not a political one. The X11 session, he writes, has been in a state of "maintained but not developed" for years. Bugs get patched. Features do not get added. Meanwhile every new piece of Plasma — the global shortcut system, the input stack, the compositor pipeline — has to be implemented twice and tested twice, with the X11 half mostly serving users who could already migrate.
The trigger is not Wayland being finished. The trigger is X11 being a tax the project no longer wants to pay. GNOME quietly made the same call earlier this year, defaulting to Wayland-only on most distros and deprecating the X11 session in mutter. Fedora 43 dropped the GNOME X11 session entirely. KDE held out longer because its user base skews toward power users with edge-case setups — multi-monitor mixed-DPI rigs, Nvidia proprietary drivers, screen recording for streaming, remote desktop via x11vnc. Those are exactly the workflows where Wayland has been weakest.
The interesting part of Edmundson's post is the implicit admission of what *kept* X11 alive this long. It wasn't user demand. It was that ripping out X11 code meant losing the safety net of "well, if Wayland breaks, you can still log in." That safety net has costs the maintainers can finally quantify: every accessibility improvement (screen readers, magnifiers, sticky keys plumbing) has to be wired through two completely different protocols. HDR support, which Plasma 6 shipped before any other desktop, exists only on Wayland. Fractional scaling works correctly only on Wayland. Per-monitor refresh rates, variable refresh rate, tear-free Nvidia output — all Wayland-only.
For the Plasma team, the math is now lopsided: every hour spent on X11 is an hour not spent on the features that make Plasma competitive with macOS and Windows. The Linux desktop has historically lost this trade by trying to be infinitely backwards-compatible. The KDE position now matches what kernel maintainers learned a decade ago — you eventually delete the cruft or you become the cruft.
The community reaction on the HN thread (164 points, hundreds of comments) splits along predictable lines. The "Wayland is finally ready" camp points to the last two years of fixes: global shortcuts via the portal, screen capture via PipeWire, color management protocol merged, input method support landed. The "X11 forever" camp points to specific workflows still broken: NoMachine, x2go, certain VNC servers, some color-calibration tools, and the long tail of one-off scripts that call `xdotool`. Both sides are correct. The question Plasma is answering is not "is Wayland done" but "is X11 worth maintaining for the holdouts." The answer is no.
The Nvidia question deserves its own paragraph. Until the 555 driver series, running Plasma on Wayland with Nvidia proprietary was genuinely painful — explicit sync was missing, suspend/resume corrupted the display, Electron apps rendered with broken cursors. Nvidia shipped explicit sync support in 555 (June 2024) and the worst of those bugs disappeared. By 6.5's release window in late 2026, the 555+ driver line will be roughly two years old. That's the timeline Edmundson is implicitly betting on: by the time X11 goes away, the Nvidia excuse goes away too.
If you administer Plasma desktops — at a workstation farm, a render shop, a university lab, a kiosk deployment — you have a finite migration window. Plasma 6.5 lands in late 2026 on KDE's current cadence. Plasma 6.6 lands roughly four months after that. Treat the X11 session as deprecated *now*, not when 6.6 ships, because the bugs you hit between now and then will not get fixed.
Three concrete audit items. First, screen recording and streaming. If your team uses OBS with X11 capture, switch to the PipeWire backend now and verify it works on every machine. The PipeWire path is better in almost every case (per-window capture, no tearing, lower CPU) but has different permission prompts. Second, remote access. x11vnc is end-of-life on Wayland. The replacements — `wayvnc`, KDE's own RDP server in Plasma 6, or Sunshine for game-streaming-style remote desktop — are good but configured differently. Audit your remote-access dependency now. Third, automation scripts. Anything calling `xdotool`, `wmctrl`, or `xev` will break. The Wayland equivalents are `ydotool`, `wlrctl`, or the KWin scripting API, each with different security models. Inventory your scripts.
For application developers, the deadline is simpler: if your app still requires `DISPLAY` to be set and falls back to nothing on Wayland, you have until late 2026 to fix it before a major distro audience cannot run you. Qt apps mostly handle this transparently. GTK apps mostly handle this transparently. Electron handles it as of recent versions. Custom OpenGL apps using GLX instead of EGL are the long tail that needs work.
The X11 era on Linux desktops ends not with a vote but with a maintenance ledger. GNOME made the call. KDE just put a date on it. XFCE and the smaller desktops will follow on a longer timeline, but the direction is set. What replaces the X11 ecosystem isn't a single Wayland — it's Wayland plus a constellation of portals, PipeWire, libei, and a more security-conscious permission model that more closely resembles how macOS and Android handle desktop access. That's a real upgrade for users and a real porting tax for maintainers. The good news: after 25 years of "the year of the Linux desktop" jokes, the desktop people are finally allowed to delete code instead of just adding it.
Plasma/Wayland Known Significant Issues[1]No ability to save and restore positions of native Wayland windowsReal-fake-session-restored apps don't remember which virtual desktop their windows were onNo full-screen aspect ratio correction"Spare Layouts" feature not implemented"
What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of security paranoia. For example, Chrome "picture in picture" window doesn't stay on top when I click somewhere e
I think the KDE developers in particular have done a great job of pushing Wayland forward and getting features that people want and need added as new protocols. KDE feels a lot smoother and more responsive when using Wayland than when using X11, and by this point most stuff has been updated to work
As someone who shipped my fair share of critical production features, I find this plan raising my eyebrows somewhat. Disabling a feature AND simultaneously removing the codebase for that feature almost never ends well. There will always be some use cases that people haven't thought of.In seriou
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I read this yesterday wanted to raise awareness for it - https://nocoffei.com/?p=451It describes the regression in accessibility software for Linux from x11 to Wayland. Unfortunately, judging by the pace of protocols being accepted, I think we're years out from having a solution.