cogl_framebuffer_finish can result in a CPU-side stall because it waits for
the primary GPU to flush and execute all commands that were queued before
that. By using a GPU-side EGLSync we can let the primary GPU inform us when
it is done with the queued commands instead. We then create another EGLSync
on the secondary GPU using the same fd so the primary GPU effectively
signals the secondary GPU when it is done rendering, causing the latter
to wait for the former before copying part of the frames it needs for
monitors attached to it directly.
This solves the corruption that cogl_framebuffer_finish also solved, but
without needing a CPU-side stall.
(cherry picked from commit 3a40413f7cf036622da3c22c609b703c138c709c)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4015>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
This adds meta_egl_create_sync and meta_egl_destroy_sync to be able to
create and dispose EGLSync objects, respectively, as well as
meta_egl_wait_sync to be able to wait for an EGLSync on the GPU.
(cherry picked from commit d2e70c15ec1cf6b6f7cd8c8825a5d92a1f89b35b)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4015>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
e994fbf02 moved warping the pointer to before the destruction of the
resource to prevent dereferencing the constraint after destruction.
This however meant that the constraint was still active when the motion
event caused by the warp is handled, which would constrain the pointer
back again to its original position.
This moves the warping of the pointer back to after the destruction of
the resource and instead just retrieves the seat earlier while the
constraint is still valid.
Fixes: e994fbf02 ("wayland/pointer-constraints: Warp pointer before destroying resource")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3696
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4098>
(cherry picked from commit cb34fafd57)
Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:
Whenever you’re describing a function that takes a callback, you
should always annotate the callback argument with the argument that
contains the user data using the (closure argument) annotation
You should not annotate the data argument with a unary (closure).
The unary (closure) is meant to be used when annotating the callback
type
Recently gobject-introspection became a bit more strict with this and
that generated some warnings:
Warning: Cogl: invalid "closure" annotation: only valid on callback
parameters
This commit fix all the closure annotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4058>
(cherry picked from commit 077eb80a8d)
In some use cases there is a need to dynamically change the preferred
primary GPU, or get rid of the preference altogether. This is currently
not possible due to a change in udev introduced by systemd v247. This
version made the tags "sticky", meaning there is no way to remove them
once attached. When a tag gets removed, only the CURRENT_TAGS property
reflects that change, the removed tag will remain in the TAGS property.
This also bumps libgudev version to 238, since that version introduces
a function, which we need to get the current tags.
Related: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4055>
(cherry picked from commit 57812546b9)
MetaWaylandDrmLeaseDevice and MetaWaylandDrmLeaseConnector hold a
reference to each other.
In both cases, the reference count was increased. Do not increase the
reference count when lease_connector->lease_device is stored to break
the reference count cycle.
Fixes: fb08a597e1 ("wayland/drm-lease: Advertize initial connectors")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4031>
(cherry picked from commit 9c536939a1)
drmModeAddFB() doesn't take a format, but depth and bits per pixel.
These can be used to determine whether there should be an alpha channel
or not, and is roughly assumed to result in either XR24 or AR24 if one
passes 24 or 32 as depth, with 32 as bpp.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3926>
(cherry picked from commit 86c9d602cd)
During an onscreen swap, the cogl_onscreen_swap_buffers_with_damage()
function ensures that the Cogl renderer creates a sync object every
frame. This sync object is later shared with the Wayland clients that
utilize the explicit sync protocol.
However, in headless mode, the function mentioned above is not called.
As a result, the sync object the Cogl renderer stores seems to be not
created. This causes cogl_context_get_latest_sync_fd() function to
return an invalid sync fd, causing Mutter to not be able to materialize
the sync timeline point that the clients wait for when the explicit sync
protocol is in use.
This change simply adds a call to the cogl_framebuffer_flush() function
to the offscreen swap path to make sure that there is a sync object that
can be shared with the clients, which will be signalled when all the
queued operations before the swap are completed.
Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4056>
(cherry picked from commit 6a0cc1371c)
The meta_input_device_get_wacom_device function may return NULL, so
we should check it before use. I'm not 100% sure that the code as
currently written could reach here with a NULL wacom_device, but
that could change in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4070>
lease_disappeared() was calling meta_drm_lease_disappeared() and
set_connectors_as_available().
meta_drm_lease_disappeared() emits the "revoked" signal, connected to
on_lease_revoked(), which marks the leased connectors as available by
calling set_connectors_as_available().
Therefore, calling set_connectors_as_available() again from
lease_disappeared() is redundant.
Remove the redundant call to set_connectors_as_available() and drop two
unused functions.
Fixes: fc44437876 ("wayland/drm-lease: Withdrawn leased connectors")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3675
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4029>
(cherry picked from commit 3199d4bbb8)
In multi-GPU setups, when one of the GPUs is used to render the desktop
and the other one has all of their devices available for lease,
meta_kms_impl_device_list_lessees() can be called after the device fd
has been unhold.
Make sure to hold and unhold it in this function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4030>
(cherry picked from commit 45bf41bf94)
Because for `COGL_DRIVER_GL3`, `_cogl_context_get_gl_extensions` needs to
know that the GL version *really* is >= 3.0 before it calls `glGetStringi`
which didn't exist prior to GL 3.0 or ES 3.0.
This was causing crashes on Xilinx Mali implementations that only support
ES 2.0 (hence `glGetStringi` == NULL), but were being forced to call
that function before the GL version check which should tell you the
function isn't supported.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4019>
The NULL check was inverted, meaning we'd grab with no leader device.
That meant updates coming from the what-should-have-been leader device
getting lost because incorrectly being classified as non-leader of
the grab.
Fix this by only allowing to grab if we have a device, and always mark
the current tool device as the grab leader.
Fixes: e4004a7c4f ("wayland: Use the tool's current_tablet device instead of caching it")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4033>
GLES 2.0 does not have RGB8 and RGBA8 as sized internal formats. There
is OES_rgb8_rgba8 which adds RGB8 and RGBA8 but only for
RenderbufferStorageOES and not for TexImage2D which I wrongly assumed.
It seems like there is currently no GLES2 extension which adds RGB8 and
RGBA8 to TexImage2D so we have no choice but to fall back to unsized
internal formats in those cases as long as we don't want to drop GLES2
support.
This should be fine in practice and we should get our 8bpc textures.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3680
Fixes: 7f943613a8 ("cogl: Use sized internal renderable formats")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4036>
meta_wayland_color_management_dispose func is only called when the compositor
is shutting down, in that case the wl_globals are already automatically removed.
meta_wayland_color_management_dispose calls wl_global_remove again,
this makes a SIGSEGV when color_management is enabled and mutter is being
shut down.
Stop calling wl_global_remove to fix it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4032>
XPending() will do a recvmsg() syscall if there are no items in the queue.
In most cases, this is unnecessary because we know that there is data to be
read of the connection or there are items already read which simply need
to be processed.
Discovering both of those conditions can be done without recvmsg() in the
hot paths.
Before this path, every iteration of the main loop had the potential to
submit a recvmsg() syscall. This reduces that overhead drastically.
XFlush() on the other-hand knows if it needs to write data or not and will
do no IO in the case the buffer is empty.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3653
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4006>
We only need to wake up the other side of the GAsyncQueue if we transition
from 0 to 1 item in the queue. Otherwise, we can be certain that the other
side has received a wakeup and will eventually flush the queue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4007>
The wrong type resulted in a crash when returning from the function,
because g_slist_free was called instead of g_free for the old_struts
list data pointers.
Fixes: e005d035c0 ("boxes: Define cleanup function for MetaStrut and use auto-pointers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4028>
Track toplevels being saved, and save state some time after. This
will make session state somewhat remembered on shell crashes, as
long as there was time to snapshot the data in disk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
Allow saving the session gvdb file in the background, with as little
overhead in the main thread as possible. We still need to serialize
all created/deserialized MetaSessionState to a GVDB hashtable there,
in order to avoid these being poked from the async task thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
The xdg_session_manager_v1 global interface is the generator
of xdg_session_v1 objects for clients. These will notify of an
unique ID that can be used for future instantiations.
Once a xdg_session_v1 object is obtained, toplevels can be added
to be managed by it, and clients may get a hint about whether the
toplevel was restored to a saved state.
Changes by Carlos Garnacho: Integrate with MetaSessionManager core
object. Flesh out event emission of xdg_session_v1 and
xdg_toplevel_session_v1 objects, handle sessions being
replaced/deleted.
Changes by Sebastian Wick:
* make lifetimes of xdg_sessions entirely determined by the wayland and
handle its destruction via the signal
* fix session destruction vs deletion
* do not drop refcount of replaced session state temporarily to make
sure the replacing session keeps the state
* disconnect signals of destroyed and replaced sessions
* disconnect window-unmanaging signal handler for
MetaWaylandXdgToplevelSession
* call wl_resource_destroy in xdg_toplevel_session_remove to make it a
destructor
* handle session being destroyed before topevel-sessions
* handle the toplevel going away before the topevel-sessions
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
