• Changing the configuration option and reconfiguring does not change the behavior, because the wlroots xwayland object is still the same as was created at launch. Changing the behavior requires a compositor restart. Do we care?

No, I think that limitation is fine. I don't expect users wanting to keep changing this during runtime. We should add that limitation to the man page though (Changing this setting requires a restart of labwc to take effect. or something like that).

Updated the docs, and added support for running an xinitrc script whenever Xwayland is started.

LGTM, not tested.

Personally, I am fine with having this bypass the release cooldown. Thoughts @johanmalm ?

I did some more investigation with the xinitrc addition:

1. When Xwayland is not running, running xrdb -query locally will print no content (even when I have an .Xresources) the first time. Likewise, running something like gimp when Xwayland is not currently running will cause the application to behave as if no resources were set.
2. Once Xwayland has launched, running the client (xrdb -query or gimp) will behave as expected, because the xinitrc will have loaded the resource database.
3. Connecting to a remote host with SSH forwarding when Xwayland is NOT running, and running a client like xrdb -query seems to show the right behavior immediately.

The problem is that we aren't notified that Xwayland is ready until it is already responding to clients, so the local application that triggers its launch has already queried the resource database before we've had a chance to (asynchronously) populate it. The X11 proxy built into SSH seems to delay things long enough that the local xinitrc can populate the database before the remote client accesses it.

This is a race we seem destined to lose for local clients, and I don't believe there is anything that we can do about it. I don't even know if wlroots can do anything about it. I also don't know if my observation of "correct" behavior on remote, SSH-tunneled clients is a necessary consequence of the implementation, or just a race we are less likely to lose.

While there might be some value in supporting xinitrc (and, by reusing the session machinery, it doesn't really cost us anything to do so), I think the only reliable way to solve the configuration issue in #1958 is to configure Xwayland for persistence.

So if making Xwayland persistent is the only way to reliably solve the issue,

I'm sure we can solve the race (which might require changes to wlroots), but I agree that it'd be better to commit just the persistence change now, and delay committing the xinitrc support until we've solved the race.

I moved "persists" to "persistence" in the first commit, and decided to move the xinitrc support to #1963 for separate consideration. As described in that PR, I believe there is still merit in supporting an xinitrc script.

Thanks!

I've just moved to 0.7.3, and this solves my issue quite nicely. Thanks.