141373f0ba
The Xwayland manager now has 4 distinct phases: - Init and shutdown (Happening together with the compositor itself) - Start and stop In these last 2 phases, handle orderly initialization and shutdown of Xwayland. On initialization We will simply find out what is a proper display name, and set up the envvar and socket so that clients think there is a X server. Whenever we detect data on this socket, we enter the start phase that will launch Xwayland, and plunge the socket directly to it. In this phase we now also set up the MetaX11Display. The stop phase is pretty much the opposite, we will shutdown the MetaX11Display and all related data, terminate the Xwayland process, and restore the listening sockets. This phase happens on a timeout whenever the last known X11 MetaWindow is gone. If no new X clients come back in this timeout, the X server will be eventually terminated. The shutdown phase happens on compositor shutdown and is completely uninteresting. Some bits there moved into the stop phase as might happen over and over. This is all controlled by META_DISPLAY_POLICY_ON_DEMAND and the "autostart-xwayland" experimental setting. https://gitlab.gnome.org/GNOME/mutter/merge_requests/709 |
||
---|---|---|
.. | ||
backends | ||
compositor | ||
core | ||
meta | ||
tests | ||
ui | ||
wayland | ||
x11 | ||
libmutter.pc.in | ||
meson.build | ||
meta-marshal.list | ||
org.freedesktop.login1.xml | ||
org.gnome.Mutter.DisplayConfig.xml | ||
org.gnome.Mutter.IdleMonitor.xml | ||
org.gnome.Mutter.RemoteDesktop.xml | ||
org.gnome.Mutter.ScreenCast.xml |