Compositor shutdown sequencing

Currently the compositor shutdown sequence is "abrupt". If anything calls weston_compositor_exit(), that will stop the main event loop ASAP, and after the event loop has stopped, then shutdown begins. This makes things like waiting for the final page flips to complete really awkward to implement.

I propose to have a "shutting down" compositor state during which the main event loop is still running.

Add WESTON_COMPOSITOR_SHUTTING_DOWN to the anonymous enum (and name the enum properly, and use the enum type in struct weston_compositor::state).

Create a struct weston_compositor::state_change_signal to replace all existing shutdown, idle, etc. signals. The argument to the signal listeners is a pointer to

struct weston_compositor_state_change {
	struct weston_compositor *compositor;
	enum weston_compositor_state old_state;
	enum weston_compositor_state new_state;
};

Add new field struct weston_compositor::event_loop_ref which is a reference count for keeping the main event loop alive. As long as the reference count is greater than zero, the main event loop keeps on running. This should probably make use of a struct weston_refcount that should be introduced to share the refcount handling code with e.g. weston_surface.

Shutdown sequence would be as follows:

1. Something calls weston_compositor_exit(), which causes the compositor to switch to WESTON_COMPOSITOR_SHUTTING_DOWN state and emitting state_change_signal.

   • Plugins that respawn their helper clients handle the state change to SHUTTING_DOWN by marking their helper clients to not respawn anymore. They do not necessarily stop their helper clients yet.

   • DRM-backend can take a ref on event_loop_ref if it has any pending operations on-going: page flips to complete, or even a whole new KMS state to be programmed in before it is safe to drop DRM master and let the next KMS client continue. Or, preferably, take the ref during normal flip operations, so that the state transition does not need extra code.

2. New Wayland client connections will be rejected, or the Wayland listening sockets are removed.

3. Shutdown timeout timer is installed. This will force the main event loop to stop after a timeout if the shutdown does not complete.

4. The main event loop keeps on running until event_loop_ref drops to zero.

5. All remaining Wayland clients are destroyed.

6. Compositor shutdown signal is emitted, and so on.

The above has been described in terms of shutdown, but we may actually need to do the same sequencing on VT-switch away, in order to sanitize KMS state for smooth hand-over. This probably requires another new state "going to switch away".

The above also gives shell plugins a good way to install shutdown animations regardless of what triggers a shutdown (or switch-out).