Preparing for KDE Plasma's Last X11-Supported Release

Original Article ↗ Hacker News Discussion ↗

KDE has announced that Plasma 6.8 will be its last release with full X11 support, accelerating the Linux desktop’s shift toward Wayland-only setups. Many users report that Wayland now delivers smoother graphics, better frame pacing, HDR, and modern input features, but others highlight regressions and missing capabilities for accessibility tools, automation, remote desktop, gaming edge cases, and niche workflows that still depend on X11’s permissive model. Commenters also question KDE’s telemetry-based claim that the vast majority of Plasma 6 users are already on Wayland, and argue over whether it’s prudent to remove X11 support before Wayland protocols and compositors fully cover existing use cases.

Overall sentiment on the Wayland transition

  • Many commenters report Plasma on Wayland now feels smoother, more responsive, with better frame pacing and fewer visual glitches than X11 on modern hardware.
  • Others say Wayland sessions still crash, feel laggy, or cause nausea/latency discomfort; some reverted to X11 or other DEs.
  • Several people argue the main benefit is simplifying KDE’s codebase and removing X11-era hacks; critics counter that this is being done at users’ expense.

Compatibility, regressions, and missing features

  • Common pain points:
    • Window behavior: no native support yet for restoring exact window positions, shading/rolling up, some multi-monitor placement workflows, and some “always on top” / PiP behaviors without manual rules.
    • Automation / integration: lack of global window control and input injection breaks tools such as advanced voice control (e.g., Talon), scripting, CAD pointer-warping, color pickers, and various “embed another app’s window” use cases.
    • Clipboard managers, screen sharing, and some screen-recording/streaming workflows remain brittle or compositor-specific.
    • Some hardware-specific issues: older GPUs (Pascal, old AMD), touchpads under libinput, backlight control on some laptops, and keyboard LED control.

Accessibility concerns

  • Strong concern that removing X11 before equivalent Wayland accessibility protocols are mature will lock out blind or mobility-impaired users.
  • Current Wayland accessibility support is described as partial and fragmented across compositors; X11 is still needed for some screen readers, magnifiers, and voice-driven input.
  • Some argue security-focused restrictions (no global window control, no arbitrary input) were designed without adequately planning for accessibility/automation needs.

Gaming, remote desktop, and special setups

  • Several users say games generally work fine via XWayland and point to Steam Deck and gaming distros using Wayland by default.
  • Others claim many older or niche games, multi-display simulators, and virtual pinball / multi-display rigs rely on X11-style window placement and break or require complex workarounds.
  • Remote desktop: current Wayland/KRdp flows are seen as less robust than mature X11+VNC/xrdp/Xvfb stacks, especially for headless/VM/cloud desktops.

Process, telemetry, and ecosystem fragmentation

  • Some distrust internal Wayland usage metrics and see them as biased or opaque.
  • Fragmentation across multiple Wayland compositors and many optional protocols is a recurring complaint; behavior and feature availability can differ widely.
  • A number of users expect X11 forks and X11-focused desktops (e.g., Trinity, “Xlibre”, tiling WMs) to persist for years as an escape hatch.