Architecture / Modularization

Posted Jan 28, 2026 5:37 UTC (Wed) by dilinger (subscriber, #2867)
In reply to: Architecture / Modularization by raven667
Parent article: Xfwl4: the roadmap for a Xfce Wayland compositor

It's not just crashing, though. I gave Gnome/Wayland a good solid try two years ago, with both me and my wife using it. She lasted about a month (there were some missing features that she needed), and I lasted about 9 months before switching back to Cinnamon. One thing that drove me nuts was the memory leakage. It's not as bad as it used to be, but some extension or something was slowly leaking memory, and after 2-3 months of uptime I was finding the machine out of ram. With Cinnamon and Gnome/X, I just restart the window manager without having to restart my various in-progress things, but not with Wayland.

to post comments

Architecture / Modularization

Posted Jan 28, 2026 8:22 UTC (Wed) by taladar (subscriber, #68407) [Link] (15 responses)

This might also be a concern for xmonad-style library-like window managers if restarting is not easily possible.

Architecture / Modularization

Posted Jan 28, 2026 10:55 UTC (Wed) by farnz (subscriber, #17727) [Link] (14 responses)

If you look at how Arcan has solved it, and how KDE is gradually improving in this area, the tricks are the same: have a state store component that's highly reliable, because all it does is accept state from the compositor and send state back to the compositor. The compositor sends over the bare minimum state to the state store to allow it to recover (client FDs so that they don't need to reconnect, DMABUFs for client buffer contents so that the client doesn't need to re-render to be visible again, locations and other renderer parameters), and on startup, pulls that state back out of the state store.

The result is that it can recover from a crash, because the state store doesn't crash (it doesn't communicate with clients, nor does it access hardware) when the compositor crashes. The hard part (and the bit KDE is working on now) is making sure that there's just enough state in the state store to let you recover, without getting tempted to make it do too much.

Architecture / Modularization

Posted Jan 28, 2026 12:50 UTC (Wed) by Wol (subscriber, #4433) [Link] (13 responses)

> The hard part (and the bit KDE is working on now) is making sure that there's just enough state in the state store to let you recover, without getting tempted to make it do too much.

And fix it so when you log back in (after logging out) your apps etc all appear back on screen in the same place? I currently have two instances of xosview every time I log in (I only want one :-), and all my apps seem to be centred on screen one on top of the other, so I have to re-arrange my screen before I can start anything.

Cheers,
Wol

Architecture / Modularization

Posted Jan 28, 2026 14:30 UTC (Wed) by farnz (subscriber, #17727) [Link] (11 responses)

That would be an example of making the state store do too much - it's supposed to be a runtime state store, not persistent between sessions.

Persistence between sessions is something the compositor needs to handle separately - the state store is for the things that need to persist between two instances of a compositor in a single session.

Architecture / Modularization

Posted Jan 28, 2026 17:17 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (10 responses)

Could you please expand on this? Maybe I don't know enough to understand the problem, but it seems really duplicative to have separate mechanisms to save state between compositors in the same session and between sessions. What is so different about starting another compositor in an existing session versus starting a new session that demands a different mechanism?

Architecture / Modularization

Posted Jan 28, 2026 17:28 UTC (Wed) by Wol (subscriber, #4433) [Link] (5 responses)

Eggsackerly.

The spec is to persist state from one instance of the compositor to the next. WHY the old compositor died is irrelevant to the requirement.

Cheers,
Wol

Architecture / Modularization

Posted Jan 28, 2026 18:25 UTC (Wed) by pizza (subscriber, #46) [Link] (4 responses)

> The spec is to persist state from one instance of the compositor to the next. WHY the old compositor died is irrelevant to the requirement.

Except for the minor detail where the the sets of state needed for both situations are different.

* "restoring after a new startup" requires a list of applications (including command line used to launch things) and the state consists of application X instance Y window Z ==> position/size" (and almost nothing else). And of course the applications themselves need to be able to pick up where they left off, which may or may not be technically feasible or desireable. [1]

* "compositor crashed" requires is "existing connection/socket/etc ==> [a large amount of runtime compositor state]" which will necessarily require a lot more than position/size because the already-running application itself has to seamlessly recover. Notably absent is any need to know how to re-launch these applications [2]

[1] I don't need dozens of empty xterms started up for me, for example.
[2] Worth noting that the compositor probably does not even know how the application was launched (ie executable name/path/cmdline), as its first interaction with the application was when said application initiates a connection to the compositor.

Architecture / Modularization

Posted Jan 28, 2026 19:40 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

So it sounds like the state required to recover from a crashed compositor is a SUPERSET of that required to restore state after a fresh start.

So why not implement the state required to recover, and get a fresh start FOR FREE? If you have to do all that work anyway, why not take advantage of it?

Cheers,
Wol

Architecture / Modularization

Posted Jan 28, 2026 20:09 UTC (Wed) by pizza (subscriber, #46) [Link]

> So it sounds like the state required to recover from a crashed compositor is a SUPERSET of that required to restore state after a fresh start.

Uh, A+B and B+C means they share B, not that one's a superset of another.

Architecture / Modularization

Posted Jan 29, 2026 9:06 UTC (Thu) by farnz (subscriber, #17727) [Link]

No - they have very little in common (see my other comment for details). Your position is like saying that because motorbikes and planes can both get you from point A to point B, but a plane carries more people, a pilot's licence is clearly a superset of a motorbike licence.

Both have window positions. But that's all that they have in common; one has details of how to start applications and get them to create the windows you need them to create to restore state after a fresh start. The other has details of how to pretend to already-running applications that the compositor never crashed, and thus they don't have to create new windows at all.

Architecture / Modularization

Posted Jan 29, 2026 9:57 UTC (Thu) by geert (subscriber, #98403) [Link]

> [1] I don't need dozens of empty xterms started up for me, for example.

I have a script to start them for me ;-)
But as long as --geometry is a no-op on Wayland...

Different state between sessions and within sessions

Posted Jan 28, 2026 18:57 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

It's completely different state, and there's very little overlap.

The in-session restart state wants to start from a connected client socket FD that you can duplicate and pass back to the restarted compositor, and then send it a serialized lump of state (including DMABUF FDs) that allows the compositor to "fast-forward" to exactly the place the communications were in before the client crashed, as-if all the previous communications with the client had happened with this instance of the compositor. If it all works, the client is completely unaware of the crash - and if the client quit or crashed between the compositor restarting, and you sending this state to it, you just drop the client (that is, after all, what you'd have done if the compositor hadn't crashed).

The between-session restart state wants to know how to launch the client, and what to send the client to get it to issue appropriate protocol requests to (e.g.) reopen windows that you can then position where they were before. But that's completely different metadata, with the overlap basically being that both include positions and sizes in them.

For example, the in-session restart state might say "there is a monitor attached to DP-3, which is at 0x0 and size 3840x2160, scale factor 125/100", or "FD 123 has surface ID 0x12345678 open, contents provided by the DMABUF on FD 2155 using DMABUF, and attached as a sub-surface of 0x7714 at location 120x340. Surface 0x7714 is a top-level surface, at 10x10 from the top-left of DP-3". The compositor follows all of this metadata to restore state to where it was when it crashed, then does things like "DP-3 is disconnected, rearrange windows".

The between-session metadata might say "start browser-binary, and ask it to open https://lwn.net/ attaching metadata token browser-restart-lwn-net. When a top-level surface is created with attached metadata token browser-restart-lwn-net, move it to 10x10 from the top-left of the Dell U3216Q and make it 2000 pixels wide by 2000 pixels high, resizing and moving as appropriate if that monitor is not connected any more".

Different state between sessions and within sessions

Posted Jan 28, 2026 21:16 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Thank you for the detailed response. It makes total sense now.

I also want to thank LWN for producing the kind of place where my question was treated as a serious request for information. I feel like if I asked the same kind of question in a lot of places, people would treat it as a challenge to their competence, resulting in a lot of unproductive bickering. It's so refreshing to have a place where that rarely happens and the moderators are quick to step in if it does.

Different state between sessions and within sessions

Posted Jan 29, 2026 9:13 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

What is probably closely related to the crash recovery state is the state required to restart for the purposes of upgrading the compositor without restarting all the applications too. That one might need a bit more information on the exact data types in use though so it can detect when something changed and needs migration between versions of the same data.

Different state between sessions and within sessions

Posted Jan 29, 2026 10:23 UTC (Thu) by farnz (subscriber, #17727) [Link]

It is - it's also a subset of the state that wprs has to maintain, since it knows whether the compositor can recover state implicitly, or has to have explicit protocol to recover a given piece of state.

Architecture / Modularization

Posted Feb 2, 2026 22:13 UTC (Mon) by piterpunk (subscriber, #52618) [Link]

After the InputCapture Portal implementation and being able to use input-leap/deskflow with Plasma 6 on Wayland, the session restore is one of the few big annoyances that I still have with Wayland. By now I still miss:

- That my apps remembers their size and position. It's very annoying to have all windows to show up stacked at the center of screen and always need to distribute them around my monitors and workspaces;
- Being able to Shade/Unshade windows. Reduce the windows to only its title bars is a very quick and convenient way to put an window "out of way" to see what is under it and then back to its place;
- Something to remember permissions that I gave for an application to do something (snapshot screen, read my keyboard, etc), I don't want to re-authorize things at every startup.

I am happy that it's a very small list.