Architecture / Modularization

Posted Jan 28, 2026 17:17 UTC (Wed) by rgmoore (✭ supporter ✭, #75)
In reply to: Architecture / Modularization by farnz
Parent article: Xfwl4: the roadmap for a Xfce Wayland compositor

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?

to post comments

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.