There is a new merge on the Wayland GitLab repo. This new merge (of an old pull request) adds xdg-session-management protocol to Wayland. This is a big development and certainly a feature Linux users will enjoy.
As per the brief message in merge request:
For a variety of cases it’s desirable to have a method for negotiating the restoration of previously-used states for a client’s windows. This helps for e.g., a compositor/client crashing (definitely not due to bugs) or a backgrounded client deciding to temporarily destroy its surfaces in order to conserve resources.
This protocol adds a method for managing such negotiation and is loosely based on the Enlightenment “session recovery” protocol which has been implemented and functional for roughly two years.
In simpler words, session recovery is finally coming to Wayland.
Excuse my dumb, does this mean when I close a window/application in a particular location/size, when I launch it again, it returns to the last known size/location? Or does this only address crash/restore scenarios?
With all the crazy stuff going around in the world, “Wayland adds an actually useful feature that is basically core to a system tasked with managing windows” was not in my 2026 Bingo card. Kudos to them for finally doing it I guess.
Maybe by 2038 this thing will finally be usable, just in time to roll over the 32-bit grave.
I’ve been using Linux for 3-4 years now, and in that time I’ve only ever used Wayland.
I’ve never had any issues with it.
I’m curious what your use-case is, that prompts you to write that is not usable for you. I have used Wayland on KDE for years without any issues. Even multi monitor setups with weird adapters and HDR seem to just work.
My use case is pretty much having a normal, usable, standard desktop environment where I can do workflows supported by features such as:
- using a screen recording program to, ya know, record the screen;
- …without having to buy more into the so-called portals cartel (that is also adding age verification);
- opening programs with their windows being opened in the workspace, screen and at least approximate positioning where I last used then;
- being able to drag-and-drop or relocate windows across screens, workspaces or any such entities;
- launch graphical applications as a different user and have them interact natively with the rest of the desktop (eg.: fullscreen correctly);
- have a fucking clipboard!;
- with the Linux-classic middle-click alternate clipboard, too.
- assign a hotkey or keycombo for an application, that can be fired from anywhere else in the desktop;
- being able to manufacture input events for keyboard, mouse, joystick etc… for when there are issues;
- being able to launch the window of a program opened remotely;
- programs using the graphical theme I’ve assigned for window decoration, instead of inventing their own titlebars and min/maximize buttons;
- being able to drag-and-drop files from one window to another;
- and many others.
The last time I tried Wayland was in 2023-ish. The fucking thing could not even finish the startup for a desktop session in my machine. It’s honestly the worst vaporware I’ve ever seen, and I’ve been around since the '90s. I feel like these things will never ever be truly fixed, because from what I understand of the Wayland model, it is intrinsically about treating the user as an enemy:
“We’re treated like hostile threat actors on our own workstations” [1]
[1] https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
Which is, ultimately, worrying. Things like Pulseaudio, systemd, Wayland, …, feel like they are making Linux less for the user and more for corporations. It’s enshittification, and comes from a culture of enshittification (Potter-ing etc).
I’m using a tiling window manager, so the placement and window decoration stuff I’ve never tried, but these things worked out without any tinkering for me:
using a screen recording program to, ya know, record the screen;
with
wf-recorderor somethinglaunch graphical applications as a different user and have them interact natively with the rest of the desktop
clipboard
assign a hotkey or keycombo for an application, that can be fired from anywhere else in the desktop;
being able to manufacture input events for keyboard, mouse, joystick etc… for when there are issues;
all of these just came in with
hyprlandand appear to be common case. Hope all your requirements will be met soon!The last time I tried Wayland was in 2023-ish.
A lot has changed in 3 years.
And no clipboard? What? The things in your list that I’ve actually had to do just work. I can’t speak to the rest.
- using a screen recording program to, ya know, record the screen;
This will be interesting as well. Your Linux desktop will be able to remember window positions and sizes across restarts. So if you are meticulous about an organized layout where the terminal is on the left and the browser is on the right, it will be the same even after your system restarts. Note that session survives temporary app closures, too.
It’s about freaking time.
EDIT: I just realized that KWin has already had this for a year. Then again, maybe this means it’ll actually get used now?
But kwin can’t restore them to the correct workspace
Yeah I hacked it with window rules but forget positioning if you’re using more than one screen setup.
Yeah, it’s inconsistent. KDE / QT apps should reliably restore to the right desktop / activity and position. But non-KDE apps like GTK & Electron apps are not consistently restored depending on the app. Instead it depends on work arounds on Wayland and apps can still erroneously open on the current screen / desktop instead. This can be still be managed with Kwin with more workarounds - for example specific rules can be applied in Kwin for really problematic apps if users want - but its faffy.
So this is definitely a welcome change to wayland.
I am not sure this is true, or at least, if it is it wasn’t when I saved my session, because Konsole and Okular don’t restore to the correct workspaces.
I mean many Wayland compositors is kinda like old browsers at the moment. They all implement a common spec and then implement a bunch of their own extensions to get features the spec doesn’t allow for. And apps have to be aware of these custom extensions to make use of them. So in the KDE case, I imagine a lot of their apps are aware of KDEs own extensions to Wayland. But it doesn’t mean all of them are.
Surely it’d be absurd for each individual app to need to implement this spec - that defeats the whole point. I can believe it’d be down to Qt or some other library, but as I said, I’m sure that’d apply to those two apps.
I just fixed a long standing problem I had. My mouse would stop clicking.
I installed several USB distros just to try the mouse and they all failed.
Then I tried my mouse on other computers and it was fine.
It was the stupid keyboard! I swapped keyboards and its all good now. Apparently keyboards don’t like stuff like drinks falling in between the keys and such.
Combine that with multi virtual desktops and pain is much worse. TBH my top priority would be browsers.
Lately I’m having issues where I have some windows set to open full screen on the second monitor (not even full screen, just making it manually take all the space) via Kwin, but since I have a top toolbar panel on the main monitor, the fucker opens with an empty space above where the imaginary toolbar would be.
I’ve checked mostly everything and now it only happens in a game so I just set it to full screen and then windowed full screen again and I don’t need to worry until I reopen the game, so it’s mostly a non issue. In KDE’s defense, the game does open correctly, it just resized afterwards so it seems like a game issue.
Besides that game though, every other program (telegram, discord…) opens right where I told it to be, I use KDE, I created a window rule for every program I routinely open and I just recorded the position I like them in and they open exactly there. I do have 2 monitors, I can give you more info on my setup if you’d like.
This is great, yet I wish there was a way to send information to specific windows from outside. Yeah I know that that’s technically a security flaw and Wayland’s ethos is practically against it, but if I want to emulate a click in a specific window passively without focusing on it, there should be some way to allow it as long as I know the window ID.
I’m talking about that feature of xdotool that let’s you send click or key press events to specific windows that can’t be done by combining ydotool and kdotool, since neither has window specific interactions.
I know that it’s a very specific request, and it’s for a more stupid reason, I want to play bongo cat with my friends and I need a way to send k&m events to that window so it works on Wayland Linux 😭😭
Sounds like what I used to mess with using AutoIt. Great little scripting language!
Never noticed the issue.
Really? People will finally stop pushing it on users that don’t need it?
This is frickin YUGE
I thought for a moment they were talking about pip windows not remaining on top. Disappointed I am.
Sike omgawd I almost destroyed my system. I will never do that again. Wayland or like wayno… I don’t know what ya’ll talking about… When I “upgraded” it was only dog water
The ecosystem is slowly migrating to Wayland. It will probably take another decade but at some point your choice is going to be Wayland, or ancient unsupported systems.
What’s after Wayland?
Yutani?
Wayland 2: Electric Boogaloo
