Some questions refuse to die, and “is Wayland ready yet” is the desktop Linux version of that immortality, asked with the same suspicious tone since roughly 2008, and the reason it keeps getting asked is that the answer was “no, specifically” for a very long time, where the specific no meant your screen sharing was broken, your global hotkeys were gone, your tray icon vanished, and your HDR panel was a very expensive SDR panel, so the people who got burned in 2019 are still quoting those burns in 2026 as if nothing moved. Something moved, and since we ship three Qt 6 / Kirigami apps, a Tauri 2 PDF editor, and a small egui utility, all of which run on Plasma 6 over Wayland on our own machines every working day, the state of things is a report we can write from evidence rather than folklore, which is the only way the question deserves to be answered.
Window management: the compositor is in charge, and that is mostly fine
The mental model that has to die first is the X11 one, where any client could ask where any window was, move it, resize it, raise it, and read its title, which was convenient for scripting and catastrophic for security in exactly equal measure, because the same API that powered your tiling helper powered every keylogger’s window-snooping feature. On Wayland the compositor owns all of that, xdg-shell does not even give a window its own global coordinates, and the practical consequence for an app author is that you stop commanding and start declaring, so the identity of your window becomes the thing you control rather than its position, which is why this comment sits in grexa-gui/src/main.rs next to the desktop file name:
// Wayland's `app_id` and X11's `WM_CLASS` map to this string.
That one string decides whether the task switcher groups your window correctly, whether the icon resolves, and whether pinning the app behaves, and getting it wrong produces the classic “generic Wayland icon in the panel” bug that users file as “your app looks broken on KDE,” which is really the compositor failing to match your window to any desktop entry it knows about. The good news on Plasma 6 is that the compositor side of the bargain got genuinely good: KWin remembers window positions across sessions on its own, per-screen scale factors on mixed-DPI setups actually composite instead of smearing, and the one rough edge we did hit, a window that could strand itself when minimized to the tray and restored, we fixed by handling the KDE/Wayland restore path explicitly in Realistic Mouse Jiggler, because a utility you cannot summon back when someone walks up to your desk is worse than no utility at all.
The tray: one protocol survived, and Plasma implements it properly
The tray is where the X11-to-Wayland transition killed the most code with the least mourning, because the old XEmbed system tray was an early-2000s X11 artifact that let applications reparent their windows into the panel, and it is simply gone, full stop, no compatibility shim, no fallback. What survived is the freedesktop StatusNotifierItem protocol, where the app describes an icon, a menu, and a state over D-Bus and the host shell renders it, and our jiggler speaks it through the ksni crate, which gives KDE Plasma users a fully native tray with zero special-casing on our side, while GNOME users get an honest note that they need an AppIndicator extension, because GNOME’s refusal to ship a tray by default is a GNOME decision and not something a small app should paper over with hacks.
Plasma’s tray story is strong enough that we also maintain a small fork of tail-tray, a Tailscale tray menu built specifically for KDE, and the fork exists for the least glamorous reason imaginable, CI plumbing for the packages our own machines run, but it would not exist at all if the StatusNotifierItem path on Plasma were flaky, since nobody maintains packaging for a surface they do not trust. Twenty years ago the Linux tray was a graveyard of half-rendered XEmbed icons and balloon tips that outlived their applications, and the modern equivalent is a D-Bus protocol with an actual specification, which is the kind of boring progress that never makes a release highlight and makes every daily driver better.
HDR and color management: real at last, with a vendor-shaped hole
This is the section that would have been pure fiction five years ago, because Plasma 6 on Wayland is the first Linux desktop where HDR and color management are not a science project, and the color pipeline is real enough that the failure modes moved down the stack from “the desktop does not understand color” to “your hardware lies about itself.” The cleanest example from our bench is the Samsung ATNA60HU06 OLED in the Razer Blade 16 (2026), a panel that can do full 1107-nit HDR but ships with an EDID that does not expose the HDR metadata block the kernel actually reads, so the entire software stack, Plasma’s HDR toggle, the color-management protocol, the works, was sitting there ready and the panel was declining to introduce itself.
The fix we landed on was a custom EDID firmware overlay that re-encodes the panel’s HDR and colorimetry data into the CTA-861 block the kernel parses, loaded through the standard drm.edid_firmware mechanism, which means no daemon, no ICC profile workaround, and no kernel patch, just the truth about the hardware presented in the dialect the stack expects. There is a dedicated post coming on that overlay because the details deserve their own space, but it belongs in this report as the proof point for the actual 2026 state of things: the desktop side of HDR on Plasma 6 is done enough that when it does not work, you should now suspect the firmware table before you suspect the compositor, and that inversion of the old debugging order is the single biggest change since the X11 days, when color management meant a per-app LUT loader and prayer.
Global input: the thing that genuinely got harder
Honesty requires one section that goes the other way, because global input capture and synthetic input are where Wayland made apps work harder on purpose, since the X11 model of “any client can grab any key and inject any event” was the feature and the keylogger in the same trench coat. The sanctioned path for global hotkeys is now the XDG GlobalShortcuts portal, where the app requests bindings at runtime and the user sees a system dialog granting them, and KDE ships a working implementation of it, so the mechanism exists and is not a checkbox stub, but it does mean the hotkey your app registered silently in 2015 is now a permission the user grants explicitly, which is correct behavior that nonetheless costs engineering time.
Synthetic input is the sharper edge, and it is the entire product category for Realistic Mouse Jiggler, so we felt this one directly: the Linux path reads bindings straight from /dev/input/event* with the user in the input group, and prefers ydotool for cursor movement when it is installed, because ydotool’s uinput daemon is the closest thing Wayland has to a blessed path for programmatic input, none of which is as simple as the old X11 call and all of which is more auditable than it. One guardrail from that work is worth repeating in any discussion of global input: left click cannot be assigned as a start/stop binding in the jiggler, ever, so the app can never eat the one button you need to reach its own controls, the kind of rule you only write down after someone on the team locks themselves out of exactly that.
What still bites
The rough edges we hit in 2026 are not in Qt or in KWin, they are in the webview stack, and we documented both of them in the Kanoprii post because scars belong in writing: the XDG desktop-portal file picker can hang WebKitGTK on some Wayland stacks, not crash, hang, which is the worst failure mode for a modal dialog, so Kanoprii defaults to in-app path entry on Wayland with KANOPRII_NATIVE_DIALOGS=1 as the escape hatch, and some multi-GPU Wayland setups die with Gdk Error 71 the moment zero-copy presentation kicks in, so the app sets WEBKIT_DISABLE_DMABUF_RENDERER=1 at startup unless you have set it yourself, keeping GPU compositing on and disabling only the path that crashes. Neither of those is a Plasma bug and neither is a Wayland protocol bug, they are WebKitGTK meeting specific driver and portal combinations, but they arrive wearing Wayland’s clothes in the bug tracker, which is worth remembering when you read that “Wayland broke someone’s app,” because the compositor is usually the messenger.
The other honest entry on the debit side is session restore and window positioning for apps that want X11-style control, because if your workflow depends on scripting exact window geometry from outside the app, Wayland’s answer is that the compositor owns that and KWin’s scripting API is where the capability lives now, which is a real migration cost for a certain kind of power user and pretending otherwise would make the rest of this report suspect.
The verdict, since you asked the question
So the 2026 answer to “is it ready” is that the question itself went stale, because the stack we ship on daily, Qt 6 and Kirigami for the substantial apps, Tauri for the PDF editor, egui for the utility, works on Plasma 6 over Wayland with a short and shrinking list of documented workarounds, and the nature of what broke changed from “the desktop cannot do this” to “this one library on this one GPU stack needs a default flipped,” which is the difference between an immature platform and a mature platform with vendor-shaped potholes. Back in the X11 years we accepted invisible insecurity and invisible inconsistency as the price of everything sort of working everywhere, and the modern equivalent is explicit permissions, declared identity, and a compositor that says no, a trade we would make again without hesitating, because the bugs we chase now get fixed in the open instead of living forever as folklore about why the Linux desktop is not ready. It is ready, it has been ready on Plasma for a while, and the remaining work is ours: flipping the right defaults, writing the scars into the README, and stopping quoting 2019 at a 2026 stack.