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>
In this case wl_client_add_destroy_listener() was called with a NULL
client, which is invalid.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
desktop shell and weston keyboard both refer to themselves prefixed by
LIBEXECDIR, however this is only valid once installed. make check will
currently either fail or run pre-existing versions.
This patch adds a way to override that location by setting the env var
WESTON_BUILD_DIR - which is then set by the test env script so make check
will test the versions in the build directory regardless of whether they're
installed or not.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The experimental versioning has not been updated when it was supposed
to. Let's try to be better at it now, as xdg-shell is close to have its
first stable version.
Bump the version now to bring the world into the same exact version.
There may be some protocol changes still coming, but we try to land them
before 1.6 gets out. Those changes will bump the experimental version
again as needed.
When 1.6.0 is released, the experimental version will no longer be
bumped, and no incompatible protocol changes will be made. Xdg-shell.xml
file will move to Wayland in 1.7.0, drop the experimental versioning,
and become stable.
Cc: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Now the client can let us know where the panel is using
desktop_shell.set_panel_position, we can correctly calculate where to
put new views and how big maximized views should be.
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
The commit 'input: Send leave and enter pair when the surface moves
under the cursor' introduced focused surface local pointer coordinates
to keep track of if a surface had been moved or transformed in a way
that the pointer posititon relative to that surface would change.
Update these coordinates also for the popup grab as otherwise every
pointer motion during a popup grab results in leave and then enter
events.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Tested-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>
An error makes the client exit, which cleans up the resources anyway.
Note (Jason Ekstrand):
This is safe for two reasons. First, we should be handling object
destruction nicely anyway. Second, in each of these cases, the resources
don't have any implementation or destruction set so it has absolutely no
effect on the rest of weston whether we destroy it now or later.
This introduces a new struct, weston_layer_entry, which is now used
in place of wl_list to keep the link for the layer list in weston_view
and the head of the list in weston_layer.
weston_layer_entry also has a weston_layer*, which points to the layer
the view is in or, in the case the entry it's the head of the list, to
the layer itself.
Currently, there is a fun flicker when toggling maximization or
fullscreen on a window in mutter or more sophisicated compositors
and WMs.
What happens is that the client want so go maximized, so we
calculate the size that we want the window to resize to (640x480),
and then add on its margins to find the buffer size (+10 = 660x500),
and then send out a configure event for that size. The client
renders to that size, realizes that it's maximized, and then
says "oh hey, my margins are actually 0 now!", and so the compositor
has to send out another configure event.
In order to fix this, make the the configure request correspond to
the window geometry we'd like the window to be at. At the same time,
replace set_margin with set_window_geometry, where we specify a rect
rather than a border around the window.
Commit 9aa8ce69 forgot to set shsurf->fullscreen_output in
fullscreen_binding(), causing segfault when fullscreening using key
bindings. This patch fixes that.
https://bugs.freedesktop.org/show_bug.cgi?id=79828
Signed-off-by: Boyan Ding <stu_dby@126.com>
Fixes a crash on touch devices without a pointer, when touching
the window frame of a client.
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
With most of the code in send_configure_for_surface, the helper
methods don't give us that much benefit, so stop using them. We
can't kill them off, as they're part of the shell interface and
used by the WM.
Currently, there's a giant bug in how xdg-shell state management
is done. If a client calls set_fullscreen and then set_maximized,
it will get two configure events:
=> set_fullscreen
<= configure(800, 600, [STATE_FULLSCREEN])
=> set_maximized
<= configure(800, 560, [STATE_FULLSCREEN, STATE_MAXIMIZED])
Since fullscreen takes precedence over maximized, the client will
render full-screen at 800x600 first, and then 800x560 next. As
a result, the surface gets the wrong size.
This is because the code that sends out configure requests is
"immediate" -- when an app calls set_maximized, we immediately
send out the configure event that would have happened if we
transitioned immediately into maximized mode.
In wl_shell, this is correct behavior. However, in xdg-shell,
this is wrong. State needs to be more carefully managed in
xdg-shell, as states aren't exclusive.
Pull all the code that sends out configure events out and send
them centrally, based on Weston's on surface state management.
This should work with both wl_shell and xdg_shell's strategies.
Currently, there's a race condition. When resizing from the left, and
a client attaches a buffer after the resize ends, you suddenly see the
buffer jump to the right, because the resize ended while multiple
attaches were in-flight. Making resize a state can fix this, as the
server can now know exactly when the resize ended, and whether a commit
was before or after that place.
We don't implement the correct tracking in this commit; that's left as
an exercise to the reader.
Additionally, clients like terminals might want to display resize popups
to display the number of cells when in a resize. They can use the hint
here to figure out whether they are resizing.
The states system, so far, has been a complicated mix of weird APIs
that solved a real race condition, but have been particularly ugly
for both compositors and clients to implement.
It's a confusing name that comes from the ICCCM. The ICCCM is best
forgotten about.
With the addition of the potential new "transient" role meaning a
parent-relative toplevel like a long-lived popup, used for e.g.
tooltips, the set_transient_for name will become even more confusing.
The check to avoid calling weston_keyboard_set_focus() for a seat that
didn't have a keyboard in restore_focus_state() was cheking the wrong
seat (the one from the previous loop). That caused a crash when
switching workspaces if there was an extra seat that didn't have a
keyboard.
https://bugs.freedesktop.org/show_bug.cgi?id=78349
Views that extend past the bottom of the output are still visible after
the workspace animation ends but before its layer is hidden. When the
layer was hidden, nothing would cause those regions to be repainted,
leading to artifacts.
https://bugs.freedesktop.org/show_bug.cgi?id=78363
With xdg_shell wl_shell starting to diverge in how they work, there's
less shared code in set_fullscreen(). The problem is that the xwayland
window manager calls into set_fulscreen() which now doesn't complete
the fullscreen transition. Add shell_interface_set_fullscreen() for
the shell interface set_fullscreen hook to use.
https://bugs.freedesktop.org/show_bug.cgi?id=78230
send_configure was originally modelled after
wl_shell_surface::send_configure, which takes these arguments. However,
the X WM and xdg_surface::configure variants don't use these arguments.
We already store the resize edges for a surface while it's being
resized, so just use the saved state in the wl_shell_surface variant.
This moves the check for shsurf->grabbed into surface_move() and
surface_resize(), which are shared with the xwayland code. This prevents
trying to resize or move an xwayland window with multiple pointers.
9c376b54ea fixed the crash when a client goes
away during a resize grab. The shsurf->resource is set to NULL in that
case and we were trying to send out events to a NULL resource. However,
xwayland shell surfaces are created by the xwayland module and don't have a
resource. We use a different function pointer for sending the configure
events that handle the events inside xwayland instead of sending protocol
events.
To fix all this, we just move the check for a NULL resource into the
functions that we use for sending configure events for wl_shell and
xdg_shell.
The geometry for visible views will keep unchanged,
weston_view_set_position() doesn't mark these views
as dirty. So there is no chance for them to reassign output, then
these views will disappear.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72946
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
When commit 07926d90 factored out the code that chooses in which layer
a surface is added to, it changed the behavior for surfaces with no
type. Instead of not adding it to any layer, the surface is added to
the current workspace.
This patch restores the old behavior.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=77527
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
If a client exists during a resize grab, the resource for the shell
surface being resized is destroyed. The shell surface is not destroyed
immediately, however, because of the window close animation. In that
case, the compositor would crash trying to send configure events to
the surface being resized, since it would pass a NULL pointer to
wl_resource_post_event().
The code for the resize grab was already able to handle the surface
going away, so expand it to also handle the resource going away and
fix the crash.
https://bugs.freedesktop.org/show_bug.cgi?id=77344
In order to do the window close animation, a reference for a destroyed
surface is kept. However, the reference count was also increased for
unmapped surfaces, in which case the animation wouldn't run. Since the
reference count was decremented in the animation done function, it would
never be decreased for unmapped surfaces, causing them to not be
released.
The close animation also changed how shell surfaces are released. The
destroy function for its resource was changed to not deallocate the
surface, and instead keep it around until the animation finishes and
the weston surface is destroyed. The destruction should happen in the
destroy listener for the weston surface, but it wouldn't destroy the
shell surface in the case the resource was still valid, assuming that
it would be freed in the resource destroy function.
We now carry the shell_client around with each shell_surface. This is much
more reliable than tacitly assuming that there is only one wl_shell or
xdg_shell instance bound to a particular wl_client. In particular, weston
would crash when a client bound to both wl_shell and xdg_shell even if it
only ever used one of them.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Pekka Paalanen
Arnaud Vrac
Ondřej Majerech
Derek Foreman
Jonny Lamb
Jonas Ådahl
Jasper St. Pierre
Giulio Camuffo
Boyan Ding
Emilio Pozuelo Monfort
Kristian Høgsberg
Ander Conselvan de Oliveira
Xiong Zhang
Jason Ekstrand