As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
For Xwayland, mutter creates the sockets in the standard /tmp/.X11-unix
directory.
Yet, if that directory already exists, it may have been created by
another user with full control over the created socket.
To avoid that issue, if the directory /tmp/.X11-unix already exists,
check that the permissions are as we expect, i.e. the directory belongs
to either root or the user herself, is writable and has the sticky bit.
Thanks to fabian@ritter-vogt.de for reporting that issue.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1708
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1787>
Unlike other subsurface state, placement operations need to get
applied in order. As per spec:
```
Requests are handled in order and applied immediately to a pending
state. The final pending state is copied to the active state the
next time the state of the parent surface is applied.
```
Having placement operations being part of the subsurface state
makes it difficult to support arbitrary orderings. Make them
part of the parents surface pending state instead.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1691
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1768>
Some events such as the proximity one requires a device to be set before
we process them, so ensure we process the event details after we've
added the device to the seat.
This may lead to handle a device-removed signal before the clutter event
but it's anyways not different from what we did before commit 012c0a18
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1779>
The CallyStage objects lifetime is tied to the stage, so if we add a
weak pointer to it, we won't be able to remove it, as we would try to do
so not until the stage itself is being disposed, at which point removing
it fails. However, not removing it will make the stage try to clean up
the weak refs, and since it does this more or less directly after
freeing the cally stage, it ends up writing NULL to freed memory,
causing memory corruption.
Fix this by avoiding adding the weak pointer when that pointer is to the
stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
MetaInputSettings unref:ed the seat on destruction, but it never ref:ed
it on construction, meaning it "stole" the reference from the rightful
owner. Make MetaInputSettings less of a thief.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
XIQueryPointer allocates the button state mask that we were leaking in
some places. We need to manually free this, because there is no XI
function that would do this for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1728>
In case the shell ignores or can't accept the restart request we should
hide the message that has been just requested to be shown.
As per ::show-restart-message signal documentation, this has to be done by
emitting the signal with a NULL message.
So follow the API properly in such case
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1780>
