This has been causing troubles for some of our users and only been there
for legacy reasons, we trust Xwayland just as much as your next program
and weston doesn't take any such care when starting it.
Makes the xwayland startup process two phased.
The first phase just initialises the X11 sockets.
The second phase starts the Xwayland server itself.
When starting xwayland lazily the second phase will be postponed until
a client has connected to the X11 socket.
Changes in behaviour:
The DISPLAY environment is now set immediately after the X11 sockets
are created.
When the Xwayland server is killed or crashes, the sockets will not be
recreated, but reused.
Fixes#849: Start up Xwayland lazily
xwm.h was meant to be private, so move it to include/xwayland/xwm.h
We had an ifdef WLR_HAS_XCB_ICCCM in xwayland.h which was easy to move
to xwm, it is not safe to use the WLR_HAS_* in the public headers.
I checked a few of our current users and none rely on xwm.h being
public as expected (rootston, sway, hsroots)
This adds `wlr_xwayland_surface_is_unamanged`, to allow compositors more
fine grained control over XWayland focus.
A surface that is unmanaged should not receive focus, while other
windows that are just override redirect may want it (dmenu).
The way unamanged is determined is taken from wlc.
This is more robust than trying to recopy a few fields.
Note: wlr_xwayland->events.ready now resets after each trigger, so one can
hook on it again and be called when restart is ready
The intermediate fork needs to wait for SIGUSR1 for when Xserver is
ready, or SIGCHLD if the exec didn't work out.
Also change the exit() to _exit() as that is apparently more appropriate
for forks (and waitpid's status was wrong without it for some reason)
Fixes#122.
emersion
Dominique Martinet
nyorain
random human
Scott Anderson
Vincent Vanlaer
n3rdopolis
Markus Ongyerth
Drew DeVault
Scott Anderson
Tony Crisci
Greg V
Calvin Lee