If weston-desktop-shell dies soon after launch, or maybe cannot be
executed at all, let weston exit rather than letting the user stare at a
black screen.
But, do not exit weston, if weston-desktop-shell dies later, as the user
may already have apps open, and those apps would likely still function
correctly. This gives the user the opportunity to save his work and
close the apps properly.
This should make one class of "I see only black screen" failures obvious.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
The desktop shell plugin registers both a wl_client destroy signal
listener, and a sigchld handler, when launching weston-desktop-shell.
However, nothing guarantees in which order do the wl_client destructor
and the sigchld handler run.
Luckily, the sigchld handler cannot interrupt any code, because we
handle the signal via signalfd, which means it is handled like any event
in the compositor's main event loop.
Still, shell.c has a race, that when lost, can cause a crash, as
described in bug #82957.
If the sigchld handler happens to run first, it will try to launch a new
weston-desktop-shell without removing the destroy listener from the old
wl_client first. This leads to list corruption, that may cause a crash
when the old wl_client gets destroyed.
Simply removing the destroy listener in the sigchld handler is not
enough, because respawning sets shell->child.client pointer, and if
the wl_client destructor runs after, it will reset it to NULL.
OTOH, the wl_client destroy handler cannot reset shell->child.process,
because that would cause the sigchld handler in weston core to not find
the process tracker anymore, and report that an unknown process exited.
Turns out, that to make everything work, we would need to wait for both
the wl_client destructor and the sigchld handler to have run, before
respawn. This gets tricky.
Instead, solve the problem by removing shell->child.process. Use the new
weston_client_start() which automatically creates and manages the struct
weston_process. The shell does not need to know about the process exit,
it only needs to know about the client disconnect. Weston-desktop-shell
will never attempt to reconnect, and it would not work even if it did,
so disconnect is equivalent to weston-desktop-shell exiting.
This should permanently solve the race for weston-desktop-shell.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82957
Cc: Boyan Ding <stu_dby@126.com>
Cc: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Panels are always assumed to be on the top edge of the output. If this
is not the case views will be placed under the panel, wherever it is,
and maximize doesn't use the correct space allocated for views.
By telling the server on which edge the panel is located, it can
correctly calculate where to put new views and how big maximized views
should be.
[Pekka Paalanen: the user of this protocol so far is Maynard.]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
At the moment when surfaces are destroyed they are faded out but let's
make it configurable!
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Previously, desktop-shell would only create its internal shell_seat object
for each seat available when the desktop-shell module is loaded. This is a
problem any time seats are created dynamically. In particular, the Wayland
and RDP backends create seats on an as-needed basis and they weren't
getting picked up proprely by desktop-shell.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=77649
lower_fullscreen_surface() was removing fullscreen surfaces from
the fullscreen layer and inserting them in the normal workspace
layer. However, those fullscreen surfaces were never put back in
the fullscreen layer, causing bugs such as unrelated surfaces
being drawn between a fullscreen surface and its black view.
Change the lower_fullscreen_surface() logic so that it lowers
fullscreen surfaces to the workspace layer *and* hides the
black views. Make this reversible by re-configuring the lowered
fullscreen surface: when it is re-configured, the black view
will be shown again and the surface will be restacked in the
fullscreen layer.
https://bugs.freedesktop.org/show_bug.cgi?id=73575https://bugs.freedesktop.org/show_bug.cgi?id=74221https://bugs.freedesktop.org/show_bug.cgi?id=74222
Previously, the repositioning logic would iterate the compositor's list
of layers and move the views on those layers. However, that failed in
two different ways: it didn't cover hidden workspaces and crashed when
the display was locked.
This patch changes the logic to explicit iterate over all the layers
owned by the shell. The iteration is done through a helper function,
shell_for_each_layer().
https://bugs.freedesktop.org/show_bug.cgi?id=76859https://bugs.freedesktop.org/show_bug.cgi?id=77290
We now handle the client-side xdg_surface_set_minimized()
call, and eventually hide the target surface by moving it
to a dedicated layer.
Signed-off-by: Manuel Bachmann <manuel.bachmann@open.eurogiciel.org>
Since that signal is per output, it is necessary to track in which
output a view is in so that the signal is handled properly.
Instead, add a compositor wide output moved signal, that is handled by
the shell. The shell iterates over the layers it owns to move views
appropriately.
Add a config file option to enable it, but leave it off by default. Exposay
still triggers too many lock-ups or stuck grabs and triggers under X even
when the Wayland window doesn't have keyboard focus.
Set the internal pointer for the client to NULL. This fixes a
segmentation fault at shutdown, where the shell would hang up before
and cause libwayland to call wl_client_destroy(). When the shell was
destroyed later, another call to wl_client_destroy() would cause the
crash.
https://bugs.freedesktop.org/show_bug.cgi?id=72550
