For years, the Linux desktop community has been migrating from the aging X11 display server to Wayland, a modern replacement that promises better security, smoother graphics, and a cleaner architecture. Compositors like GNOME’s Mutter and KDE’s KWin have matured significantly. Screen sharing works. Fractional scaling works. Gaming performance has improved. But one critical piece of desktop infrastructure remains conspicuously absent: session management.
And it’s not a minor gap. It’s the kind of thing that makes power users curse under their breath every time they reboot.
Session management — the ability for a desktop environment to save the state of running applications and restore them after a logout or restart — was a solved problem under X11. The X Session Management Protocol (XSMP), standardized in the 1990s, allowed compliant applications to register with a session manager, save their state, and be relaunched with that state intact. It wasn’t perfect. Many apps ignored it. But the protocol existed, the infrastructure was there, and desktop environments like KDE and XFCE made real use of it.
Under Wayland, there is no equivalent. Not yet.
A Protocol Vacuum That Nobody Has Filled
As It’s FOSS recently detailed, the absence of a standardized session management protocol in Wayland is one of the display server’s most significant remaining shortcomings. The Wayland protocol itself is deliberately minimal — it handles display, input, and compositing, and leaves everything else to extensions. That design philosophy has served it well in many areas, with protocols like xdg-decoration and xdg-output filling gaps through community-driven standardization under the wayland-protocols umbrella.
Session management hasn’t received the same treatment. There’s no xdg-session-management protocol. No formal proposal has gained traction across major compositors. The problem sits in a no-man’s-land between the compositor, the desktop environment, and individual application toolkits like GTK and Qt.
The technical challenge is real. Under X11, the session manager could identify windows, track which application owned them, and communicate directly with those applications through a shared protocol. Wayland’s security model intentionally prevents this kind of cross-client snooping. A compositor doesn’t expose one application’s windows to another. That’s a feature, not a bug — but it makes the old approach to session management fundamentally incompatible with Wayland’s architecture.
So what would a Wayland-native session management protocol look like? The It’s FOSS analysis points to several requirements: applications need a way to advertise that they support session saving, a standardized method for serializing their state, and a mechanism for the compositor or a session daemon to orchestrate the save-and-restore cycle. Each of these touches different layers of the stack. Getting GNOME, KDE, wlroots-based compositors, and toolkit developers to agree on a single approach is — to put it charitably — a coordination problem of considerable scale.
Some desktop environments have taken partial steps. KDE Plasma has long supported session restoration, and its Wayland session carries over some of that capability, though it relies on application-level cooperation and KDE-specific mechanisms rather than a cross-desktop standard. GNOME, by contrast, has historically been less invested in session restore, with its developers favoring a model where applications manage their own state internally — think of how GNOME’s text editor remembers open files, or how Firefox restores tabs. This per-application approach works for some use cases but falls apart when users want their entire workspace — window positions, virtual desktop assignments, running terminal sessions — brought back to life after a reboot.
The philosophical divide between GNOME and KDE on this issue mirrors a broader tension in Wayland’s development. KDE tends to preserve features from the X11 era and adapt them for Wayland. GNOME tends to question whether those features should exist at all, sometimes dropping functionality it considers outdated or better handled at the application level. Neither approach is wrong in the abstract, but the result is that session management has no champion with enough cross-project influence to drive a standard forward.
Why This Matters More Than It Sounds
To a casual user who shuts down their laptop and reopens apps manually, session management might seem like a niche concern. It isn’t. For developers who maintain complex workspace arrangements across multiple monitors, for sysadmins managing thin client deployments, and for anyone who relies on Linux as a daily-driver workstation, the inability to reliably restore a session is a genuine productivity drain.
It also matters for enterprise adoption. Windows and macOS both handle session restore at the OS level, and users expect it. Organizations evaluating Linux desktops for employee workstations notice when a reboot means manually reopening twelve applications and rearranging windows. These aren’t edge cases. They’re table stakes for a modern desktop operating system.
The problem extends beyond simple app relaunching. True session management encompasses window geometry, workspace placement, application-internal state, and the ordering of restoration. Getting all of this right requires cooperation between the compositor, the session manager, the application toolkit, and the application itself. Under X11, the XSMP protocol and the freedesktop.org autostart specification provided at least a common vocabulary. Under Wayland, developers are improvising.
Some workarounds exist. Tools like tmux and terminal multiplexers handle session persistence for command-line workflows. Certain Wayland compositors support window rules that can place specific applications on specific workspaces based on app-id matching. And the freedesktop.org XDG autostart specification still works for simply launching applications at login — but launching an app isn’t the same as restoring it to its previous state.
The wlroots project, which underpins compositors like Sway and Hyprland, has seen community discussions about session management, but nothing has solidified into a protocol extension. Sway’s maintainers have generally taken the position that session management is out of scope for the compositor and should be handled by external tooling or desktop environment-level infrastructure. That’s a defensible position architecturally, but it means someone else needs to build the infrastructure — and so far, no one has.
Meanwhile, the broader Wayland transition continues to accelerate. Fedora defaulted to Wayland years ago. Ubuntu followed. KDE Plasma 6 made Wayland its default session. Even NVIDIA’s proprietary drivers, long the biggest obstacle to Wayland adoption, now work reasonably well. The display server war is effectively over. Wayland won. But the victory is incomplete as long as fundamental desktop features like session management remain unresolved.
There are signs of movement. Discussions on the wayland-protocols GitLab repository occasionally touch on session-related topics, and some developers have floated ideas for a minimal session state protocol that would allow applications to register a restore token with the compositor. The concept borrows from how mobile operating systems handle app lifecycle management — saving a lightweight state blob that the system can use to relaunch the app in roughly the condition it was in before. But these remain ideas, not implementations.
The Freedesktop.org project, which coordinates cross-desktop standards for Linux, would be the natural home for such a protocol. But Freedesktop operates on consensus, and consensus requires interest from multiple stakeholders. With GNOME skeptical of traditional session management and KDE already solving the problem (partially) with its own tools, the incentive for a joint effort is weaker than it should be.
So the Linux desktop finds itself in a familiar position: the plumbing is modern, the paint is fresh, but a door is missing. Session management under Wayland isn’t a crisis — most users work around it without thinking too hard. But it’s an absence that keeps the Linux desktop from matching the polish and predictability of its proprietary competitors, and it’s the kind of missing feature that disproportionately affects the power users who are Linux’s most vocal advocates.
Someone will eventually write the protocol. Someone will implement it. The question is whether it happens through deliberate, cross-project coordination or through a patchwork of compositor-specific hacks that fragment the desktop further. The history of Linux desktop development suggests the latter is more likely. But the Wayland project has, in many other areas, proven that the community can converge on shared standards when the need is clear enough.
The need is clear. Now it requires the will.
WebProNews is an iEntry Publication