We'll never scan out, which is why ADDFB2 is required otherwise, and we
won't enable the DMA buffer extension if
'EGL_EXT_image_dma_buf_import_modifiers' is missing, so send modifiers
in this case.
This also happens to avoid crashing when the GPU is null, since we'd
otherwise attempt to dereference it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2578>
This is what the protocol says we should do, and even though normally
an out of focus client should not have any reason to create IM requests,
there is a bit of a grey area around focus changes, as both the client
losing focus and the client gaining focus may respectively try to
disable/enable in an undetermined order.
Anyways, since in that situation the client losing focus is not aware
of the requests being ignored, the serial should always be incremented
in order not to break accounting of .done/.commit for that specific
client.
Fixes the IM focus being possibly "lost" after changing focus between
clients, if the race condition turned the odds in that direction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2585>
Same applies to MetaOutput. The reason for this is to make it possible
to more reliably know when there was EDID telling us about these
details. This will be used for colord integration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
In the timespan between an activation token being created and the
token being used by the activated application, the surface that started
the activation request may end up destroyed/disposed.
In that case, the token would be left with a stale surface pointer,
maybe causing crashes later on. Set up a destroy notification listener
so that we do know to unset the token surface if that situation arises,
this will result in Mutter not considering the token activatable, thus
maybe issuing the "Application needs attention" notification if the
activated surface did not immediately get focus. In any case this is
better than a compositor crash.
A typical situation where this may happen is "Open With..." dialogs,
since those don't live long after launching the application.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2390
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2592>
There is some surface tracking going on here, and all notify handlers
are possibly leaving the linked wl_listener behind. Ensure it is unlinked
in all destroy notification functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2588>
This condition is inverted of how it should be. Since pad focus relies
on grouped devices lookups (e.g. pads not grouped with a tablet do not
focus surfaces), this fixes issues in pad focus and event propagation to
wayland clients.
Fixes: fff3654941 - wayland: Check input device capabilities in tablet seats
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2573>
If the window didn't have a size, it would still have a monitor, and
when we are asked to update, we must update, as the old monitor might
not be kept around, leaving us vulnerable to use after free.
Avoid not updating the monitor by using the stored IDs (preferred, or
previous) to find suitable logical monitors, with the primary monitor
being the last fallback unless we're completely headless.
This fixes the assert
!window->monitor ||
g_list_find (meta_monitor_manager_get_logical_monitors (monitor_manager),
window->monitor)
in meta_window_update_for_monitors_changed() being hit when a Wayland
window has been created, but not mapped, when a hotplug happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
The function finds a suitable logical monitor given the window
rectangle; this wasn't all that clear from the name
"calculate_main_logical_monitor".
This is in preparation for finding a new logical monitor using things
other than the geometry of the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
Now that we support Wayland buffer transforms in all cases, we can
properly report them to outputs.
Also make sure we resend the output geomerty on transform changes.
This partly reverts commit bda9c359
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/344>
The "single pixel buffer" Wayland protocol extension provides a way for
clients to create 1x1 buffers with a single color, specified by
providing the color channels (red, green and blue) as well as the
alpha channel as a 32 bit unsigned integer.
For now, this is turned into a 1x1 texture. Future potential
improvements is to hook things up to the scanout candidate logic and
turn it into a scanout capable DMA buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
To Wayland clients, it doesn't matter how we configure our onscreen
buffers, since they don't necessarily have the same bandwidth issues
related to mode setting, whichis the primary reason why we disable
modifiers using the udev rule, so simply check whether importing with
modifiers will work at all and advertise modifiers if so is the case.
This might help avoid issues using legacy non-modifiers path in drivers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2546>
As testing of direct scanout revealed, `META_MONITOR_TRANSFORM`
does actually match `WL_OUTPUT_TRANSFORM` enums. The fact that
things rendered correctly with 90/270 degree values swapped
was because other parts of the stack got the interpretation
wrong, most notably `meta_rectangle_transform()`.
Thus lets revert this change and fix the stack accordingly.
This reverts commit 8d9bbe109b.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
Fixes memory leak:
==995170== 936 (40 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 15,090 of 15,641
==995170== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==995170== by 0x4B211D0: g_malloc0 (gmem.c:155)
==995170== by 0x4A56693: meta_wayland_tablet_manager_new (meta-wayland-tablet-manager.c:109)
==995170== by 0x4A56693: meta_wayland_tablet_manager_init (meta-wayland-tablet-manager.c:126)
==995170== by 0x4A3FA95: meta_wayland_compositor_new (meta-wayland.c:626)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: 745cb67988 ("wayland: Initialize the MetaWaylandTabletManager")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 383 (96 direct, 287 indirect) bytes in 1 blocks are definitely lost in loss record 14,733 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A4A8B4: meta_wayland_compositor_update_outputs (meta-wayland-outputs.c:483)
==995170== by 0x4A4ABAB: meta_wayland_outputs_init (meta-wayland-outputs.c:716)
==995170== by 0x4A3FA65: meta_wayland_compositor_new (meta-wayland.c:620)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
v2:
* Use meta_backend_get_monitor_manager. (Jonas Ådahl)
Fixes: 9a4783e364 ("Integrate the monitor manager with wayland")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 288 (96 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 14,607 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A4F973: meta_wayland_init_presentation_time (meta-wayland-presentation-time.c:222)
==995170== by 0x4A3FB04: meta_wayland_compositor_new (meta-wayland.c:635)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: dccc60ec3e ("wayland: Implement stub presentation-time")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 240 (48 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 14,428 of 15,641
==995170== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==995170== by 0x4B211D0: g_malloc0 (gmem.c:155)
==995170== by 0x4A3CDB3: meta_wayland_activation_init (meta-wayland-activation.c:383)
==995170== by 0x4A3FB0C: meta_wayland_compositor_new (meta-wayland.c:636)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: ec390b68c5 ("wayland: Implement the xdg-activation protocol")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 192 (96 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 14,260 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A3F3A4: meta_wayland_compositor_init (meta-wayland.c:477)
==995170== by 0x4E1F509: g_type_create_instance (gtype.c:1929)
==995170== by 0x4E03DFC: g_object_new_internal (gobject.c:2011)
==995170== by 0x4E0538C: g_object_new_with_properties (gobject.c:2181)
==995170== by 0x4E05D40: g_object_new (gobject.c:1821)
==995170== by 0x4A3F8C4: meta_wayland_compositor_new (meta-wayland.c:590)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: 8df2a1452c ("wayland: Notify actively of xwayland window/surface associations")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes potential use-after-free during mutter shutdown, e.g.:
==993876== Invalid read of size 8
==993876== at 0x4A4FCA3: meta_wayland_presentation_time_ensure_feedbacks (meta-wayland-presentation-time.c:373)
==993876== by 0x4A3F07F: on_presented (meta-wayland.c:282)
==993876== by 0x661B7E9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==993876== by 0x661A922: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==993876== by 0x4DFF4BC: g_cclosure_marshal_generic_va (gclosure.c:1648)
==993876== by 0x4DFE948: _g_closure_invoke_va (gclosure.c:893)
==993876== by 0x4E17498: g_signal_emit_valist (gsignal.c:3406)
==993876== by 0x4E176BE: g_signal_emit (gsignal.c:3553)
==993876== by 0x51D9DB5: clutter_stage_view_notify_presented (clutter-stage-view.c:1226)
==993876== by 0x499ACD2: frame_cb (meta-stage-view.c:83)
==993876== by 0x499ACD2: frame_cb (meta-stage-view.c:43)
==993876== by 0x50CAA41: notify_event (cogl-onscreen.c:175)
==993876== by 0x50CAA41: _cogl_onscreen_notify_complete (cogl-onscreen.c:545)
==993876== by 0x4A877F5: meta_onscreen_native_notify_frame_complete (meta-onscreen-native.c:211)
==993876== Address 0x24b7be58 is 296 bytes inside a block of size 344 free'd
==993876== at 0x484217B: free (vg_replace_malloc.c:872)
==993876== by 0x4E1F88B: g_type_free_instance (gtype.c:2001)
==993876== by 0x49C793C: meta_context_dispose (meta-context.c:675)
==993876== by 0x4E037E0: g_object_unref (gobject.c:3636)
==993876== by 0x4E037E0: g_object_unref (gobject.c:3553)
==993876== by 0x10F145: glib_autoptr_clear_GObject (gobject-autocleanups.h:27)
==993876== by 0x10F145: glib_autoptr_clear_MetaContext (meta-context.h:32)
==993876== by 0x10F145: glib_autoptr_cleanup_MetaContext (meta-context.h:32)
==993876== by 0x10F145: main (mutter.c:126)
==993876== Block was alloc'd at
==993876== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==993876== by 0x4B21178: g_malloc (gmem.c:125)
==993876== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==993876== by 0x4B39C29: g_slice_alloc0 (gslice.c:1098)
==993876== by 0x4E1F544: g_type_create_instance (gtype.c:1901)
==993876== by 0x4E03DFC: g_object_new_internal (gobject.c:2011)
==993876== by 0x4E0538C: g_object_new_with_properties (gobject.c:2181)
==993876== by 0x4E05D40: g_object_new (gobject.c:1821)
==993876== by 0x4A3F864: meta_wayland_compositor_new (meta-wayland.c:585)
==993876== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==993876== by 0x10F065: main (mutter.c:148)
Fixes: 2ce3a050f0 ("wayland: Wire up presentation-time machinery")
Fixes: 8cff3b84f7 ("wayland/compositor: Process frame callbacks on 'after-update'")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
When building the list of formats to be sent as part of the scanout
tranche, avoid requiring modifier support by the DRM driver for
formats relying on implicit modifiers (DRM_FORMAT_MOD_INVALID).
Specifically, the previous check required the DRM driver to have
advertised some modifier support for the given format in its
IN_FORMATS KMS plane property, regardless of modifier it was. If it
hadn't, the format was left out of the list of formats to be sent
in the scanout tranche.
When no formats remained to be sent in the scanout tranche, the
tranche simply wasn't sent.
This resulted in the scanout tranche never being sent for GPUs where
modifiers aren't supported. In those cases, no formats are advertised
using the IN_FORMATS property, and thus the list of formats to be sent
in the scanout tranche remained empty.
Since Mesa doesn't use scanout-compatible buffers for native Wayland
clients unless specifically requested to do so using the "scanout"
tranche flag, it effectively means that direct scanout of native
Wayland clients wasn't supported for GPUs without modifiers support.
Sending a tranche with formats paired with the implicit modifier
(DRM_FORMAT_MOD_INVALID) is both allowed by the protocol and is
already done by default for GPUs with modifiers support, unless the
experimental support for explicit modifiers is enabled in Mutter.
So instead of requiring modifiers to be supported for each format
being evaluated for the scanout tranche, when processing formats
which rely on implicit modifiers, only check if the format in
question is supported by the DRM driver for scanout on the primary
plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2510>
While the check for `clutter_actor_has_mapped_clones` clearly indicates
an intention to take clones into account, the following code
does not do so, likely because it predates the introduction of
`clutter_actor_is_effectively_on_stage_view()`.
Switch to that newer API in order to take clones into account. This
avoids unnecessary `wl_surface_send_enter()` and `wl_surface_send_leave()`
events when entering the overview, reducing client work.
This also avoids unnecessarily allocating a `cairo_region_t`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2502>
Unparenting the surface actor when the subsurface object is destroyed
has several issues:
- subsurface actors can be unparented while a close animation is
still ongoing, breaking the animation for e.g. Firefox.
- adding and removing the actor to/from the parent is not handled in
one place, making the code harder to follow.
- if the destroyed subsurface had children of its own, they potentially
stick around until a surface-tree rebuild. This makes the Firefox
hamburger menu not close with the "compositor" backend.
Move the unparenting back to
`meta_window_actor_wayland_rebuild_surface_tree()` and instead just
notify the parent of a state change, if it still exist. This will ensure
a correct mapping between the subsurface node tree and the flat surface
actor list. In case of the closing animation the parent will already be
removed and the call is skipped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
Fixes leak:
==14889== 2,168 (16 direct, 2,152 indirect) bytes in 1 blocks are definitely lost in loss record 15,308 of 15,584
==14889== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==14889== by 0x4BAC1D0: g_malloc0 (gmem.c:155)
==14889== by 0x4AAFF60: meta_wayland_dma_buf_feedback_new (meta-wayland-dma-buf.c:298)
==14889== by 0x4AAFFE0: meta_wayland_dma_buf_feedback_copy (meta-wayland-dma-buf.c:317)
==14889== by 0x4AB16B6: ensure_surface_feedback (meta-wayland-dma-buf.c:1121)
==14889== by 0x4AB1848: dma_buf_handle_get_surface_feedback (meta-wayland-dma-buf.c:1169)
==14889== by 0x66F77E9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x66F6922: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x5318750: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5313B99: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5316649: wl_event_loop_dispatch (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x4AA7C19: wayland_event_source_dispatch (meta-wayland.c:110)
Fixes: 64e6bedb6b ("wayland/dma-buf: Add support for scanout surface feedback")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2469>
The min distance to the right/bottom edge depends on Wayland concepts
(wl_fixed_t) and eventually geometry scale. Move the logic the Wayland
side of the pointer constraints machinery to avoid the backend trying to
figure this out without the proper data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
Add `sync_effects_completed()` and `verify_view()` in
order to allow Wayland test clients to trigger verifications
and add convenience functions to use them to client-utils.
Notes:
- `sync_effects_completed()` works in two stages in order
to ensure it doesn't race with window effects. By the time
`sync_effects_completed()` is processed, an effect could
already have ended or not yet been scheduled. Thus we
defer a check for pending effects to the next paint cycle,
assuming that by then they should have been scheduled.
- `meta_ref_test_verify_view()` internally triggers the
`paint` signal for the stage which is why it can not be run
in the after-paint signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Our internal interpretation of output transforms is not in line with
the Wayland spec. Wayland describes them as the transform that a
compositor will apply to a surface to compensate for the rotation
or mirroring of an output device - counter-clockwise.
Mutter in turn interprets it the other way around. One could
argue it does the same but clock-wise - or it interprets the transform
from the viewpoint of the content, not the device.
In either way, the difference is that 90 and 270 degree values are
switched. Thus swap these accordingly when we translate from
`WL_OUTPUT_TRANSFORM` to `META_MONITOR_TRANSFORM`.
See: https://gitlab.freedesktop.org/wayland/weston/issues/99
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Since the new ClutterGrab API replaced the old plugin-modal hook,
the event-route is never set to COMPOSITOR_GRAB.
The code in question already checks whether the stage has a grab,
so we can just remove old checks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
It's not allowed to call eglQueryWaylandBuffer() if the call to
eglBindWaylandDisplay() failed, and will result in an assert being hit
in mesa if called.
Avoid that by keeping track whether we succeeded to bind, and only
attempt to realize a legacy EGL wl_buffer if binding succeeded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
Simply signal preedit string changes from/to NULL once, in order
to avoid unwanted activity in the client side. We do still need to
send the preedit once each .done event, if there is one, in order
to behave according to the protocol when it matters the most.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2395>
Unfortunately we cannot do this generically since the target of the
button/touch press does matter, e.g. tapping on the OSK, or clicking
the IBus candidates window. These situations should not trigger a
reset.
So be more selective about the situations where button/touch presses
trigger an IM reset, in the case of ClutterText these are still clicks
inside the actor, for Wayland's text-input it is when clicking the
surface that has text_input focus.
For all other situations where clicking anywhere else might make
sense to trigger an IM reset are covered by the focus changing paths,
that also ensure a reset before changing focus between surfaces/actors.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1961
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Focus changes should trigger an IM reset, as some engines do want
to maybe commit the preedit string before changing focus. In addition,
we do not want the preedit string to be able to move between
windows/applications.
Ensure that the commit string is committed when the IM deems so, and
ensure we send a .done event disntinct to the .leave event, so that
the client doesn't miss the commit.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2030
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
As of currently, we only emit .done() on actual changes coming from the
ClutterInputMethod/ClutterInputFocus. With the recent changes in the
interpretation of serials, it becomes more important now that the
compositor acknowledges every .commit done by the client, in order to
keep them feeding future IM state updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
Compensate the protocol statelessness with our ClutterInputFocus
statefulness. This becomes more necessary now, since sending
consecutive .done() events is now considered acceptable behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
Currently, meta_xwayland_shutdown_dnd() is called from the handler
on_x11_display_closing() triggered from the signal "x11-display-closing"
hooked up from meta_xwayland_init_display().
Once the signal has been triggered, on_x11_display_closing() removes the
signal handler, disconnecting from the signal.
As meta_xwayland_init_display() is called from meta_display_new() which
is issued only once, the signal handler is not restored again.
As a result, meta_xwayland_shutdown_dnd() is not called anymore after
Xwayland has been restarted, but meta_xwayland_init_dnd() will check and
assert that the manager's DND object is NULL.
Basically, restarting Xwayland more that once will trigger an assertion
failure in mutter. That's even more of a problem with autoclose-xwayland
where Xwayland is expected to terminate when there is no meaningful X11
client remaining, which can happen multiple times during the lifetime
of a user session.
To make sure that meta_xwayland_init_display() is called for every new
instance of Xwayland, simply keep the signal hooked in place by not
disconnecting it when triggered.
This reverts commit 9a10b8ff94.
Even though, originally, this issue was first introduced with commit
b4fe1fdd95 ("xwayland: Make setup/teardown
a bit more symmetrical") which didn't actually kept 'x11-display-setup'
and 'x11-display-closing' connected.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2168
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2339>
Before scanning out the surface of a native client we have
to check the following attributes that influence the
relationship between buffer and the defined result on screen:
- buffer scale
- buffer transform
- viewport
In the future we can loose these checks again in cases where the
display hardware supports the required operations (scaling, cropping
and rotating).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2276>
Prior to 67033b0a mutter was accidentally including sizes for
configurations that were just focus state changes. This was not leading
to any known problems on the client side, but it was causing issues in
mutter itself when detecting whether a resize originated from the client
or the server.
Not including sizes in focus change configurations anymore however
revealed a bug in gtk. It was storing the window size when in a fixed
size mode (tiled/maximized/fullscreen), but not on any other server side
resizes. It was then restoring this stored size whenever there was a new
configuration without a size while in floating mode, i.e. the focus
change configurations generated by mutter after 67033b0a.
This change now addresses the issue 67033b0a was fixing in a way that
restores the previous behavior of always including the size whenever
sending a configuration.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2238>
In some configurations (e.g. NVIDIA driver 470) Xwayland may use DMA
buffer for passing buffers around. When this is done, we might attempt
to scanout these buffers when they are fullscreen, and to do so we
import them using gbm.
However, for the mentioned configuration, there is no gbm device
available for importing. This was not handled, and resulted in a crash;
avoid this crash by checking whether we have a gbm device and fail
gracefully if we don't.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2098
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2318>
This aims to replace the x,y arguments in wl_surface.attach(); meaning
it can be used more sanely together with EGL, and at all when using
Vulkan.
The most common use case for the offset is setting the hotspot of DND
surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1905>
This implements the new 'bounds' event that is part of the xdg_toplevel
interface in the xdg-shell protocol. It aims to let clients create
"good" default window sizes that depends on e.g. the resolution of the
monitor the window will be mapped on, whether there are panels taking up
space, and things like that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
We'd guess the initial monitor before it was actually calculated by
looking at the initial geometry. For Wayland windows, this geometry was
always 0x0+0+0, thus the selected monitor was always the primary one.
This is problematic if we want to provide initial more likely
configurations to Wayland clients. While we're not doing that yet, it'll
be added later, and this is in preparation for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
Since the introduction of ClutterGrabs, MetaDnd now no longer gets
notified about input events on the stage during grabs (for example while
the alt-tab popup is shown) and thus can't move the grab feedback actor
anymore.
To fix this, forward events to MetaDnD directly from
meta_display_handle_event() when a ClutterGrab is in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
The XDG activation support was missing interoperability with other
startup sequences, notably those coming from other means than XDG
activation.
In order to play nice with X11 startup sequence IDs, we not just
have to check for the startup ID being in the general pool, but
we also need to fallback into X11-style timestamp comparison so the
window ends up properly focused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2314>
When a drag and drop occurs from an X11 client to a Wayland native
client, mutter uses an internal X11 window as a peer for the DnD drop
site.
That internal X11 window is moved and resized to match the Wayland
native windows as the drag destination moves.
When moving from one Wayland native window to another Wayland native
window, the same X11 window is used, and as a result no DND enter/leave
events is emitted.
In that case, the drop may occur on the wrong Wayland native window,
because no new XdndEnter/XdndLeave event were emitted.
To avoid that issue, use a pair of X11 windows instead of just one and
alternate between the two when repicking a new drop surface, so that
moving from a Wayland surface to another will always generate the
expected enter/leave events that we rely on.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2136
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2305>
If we happen to handle a CLUTTER_TOUCH_BEGIN without a corresponding
CLUTTER_TOUCH_END at MetaWaylandTouch, we would still attempt to
reuse the older MetaWaylandTouchInfo, resulting in an assert triggered
as there is a stale touch reference on the previous surface.
Warn in place and create a new touch info struct to still fix the
broken surface accounting, instead of finding out the hard
way after the surface is destroyed. The assert is preserved to ensure
the accounting does not sneakily break anymore/further.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/584
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2251>
The `ensure_x11_unix_perms` function tries to detect systems on which
/tmp/.X11-unix is owned by neither root nor ourselves because in that
case the owner can take over the socket we create (symlink races are
fixed in linux 800179c9b8a1e796e441674776d11cd4c05d61d7). This should
not be possible in the first place and systems should come with some way
to ensure that's the case (systemd-tmpfiles, polyinstantiationm …). That
check however only works if we see the root user namespace which might
not be the case when running in e.g. toolbx.
This change relaxes the requirements such that in the root user
namespace we detect and abort if a vulnerable system is detected but
unconditionally run in toolbx.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2261>
Wayland event processing and WM operations are themselves outside the
ClutterGrab loop so far. Until this is sorted out, these pieces of
event handling have got to learn to stay aside while there is a
ClutterGrab going on.
So, synchronize foci and other state when grabs come in or out, and
make it sure that Wayland event processing does not happen while
grabs happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
The experimental feature "autoclose-xwayland" requires a couple of
prerequisites:
1. Be able to (re)start Xwayland on demand, i.e. with systemd
2. Xwayland must support the terminate delay
Add a warning message if "autoclose-xwayland" was requested but any of
those prerequisites is not met.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
Since commit 226afa24a - "Use Xwayland auto-terminate feature", the
callback function shutdown_xwayland_cb() does not check for the
autoclose-xwayland experimental feature anymore.
As a result, when running nested or outside of systemd,
gnome-shell/mutter would quit after 10 seconds unless some X11 window
was mapped.
But now that we rely on Xwayland's own terminate feature, there really is
no need to use any xserver timeout function anymore.
We do not need to keep track of X11 windows being created or unmapped, as
again, Xwayland does all that for us at the client level.
Remove all this code that we do not need anymore.
fixes: 226afa24a - Use Xwayland auto-terminate feature
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
When using Xwayland-on-demand (default), if the (experimental) autoclose
features is enabled, we can rely on Xwayland's auto-terminate feature
instead of explicitly killing the Xwayland process.
With it, gone is the mechanism that was added to check the X11 clients
connected and their executable to check whether we can (safely) kill
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
The connection to the Xserver for the X11 window manager part of mutter
even on Wayland may prevent the Xserver from shutting down.
Currently, what mutter does is to check the X11 clients still connected
to Xwayland using the XRes extension, with a list of X11 clients that
can be safely ignored (typically the GNOME XSettings daemon, the IBus
daemon, pulseaudio and even mutter window manager itself).
When there is just those known clients remaining, mutter would kill
Xwayland automatically.
But that's racy, because between the time mutter checks with Xwayland
the remaining clients and the time it actually kills the process, a new
X11 client might have come along and won't be able to connect to
Xwayland that mutter is just about to kill.
Because of that, the feature “autoclose-xwayland” is marked as an
experimental feature in mutter and not enabled by default.
Thankfully, the Xserver has all it takes to manage that already, and
is even capable of terminating itself once all X11 clients are gone (the
-terminate option on the command line).
With XFixes version 6, the X11 clients can declare themselves
"terminatable", so that the Xserver could simply ignore those X11
clients when checking the remaining clients and terminate itself
automatically.
Use that mechanism to declare mutter's own connection to the Xserver as
"terminatable" when Xwayland is started on demand so that it won't hold
Xwayland alive for the sole purpose of mutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
It is possible that we never create a cached state for a surface
even if it is synced. That is the case if `commit()` is never called.
We still need to call `apply_state()` in this case in order to run
e.g. `role_post_apply_state()` or `parent_state_applied` on subsurfaces.
So just ensure to initialize the cached state instead of bailing out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
Subsurfaces can be effectively synced indirectly via their ancestors.
Right now such indirectly synced surfaces don't apply their cached
state when their ancestor effectively becomes desync as by the time
we call `parent_state_applied()` on them, they are considered as
desync.
Thus sligthly reoder things so when the ancestors becomes desync
and applies its state, those surfaces still count as synced and
will thus apply their cached state as well.
While on it, add a check to prevent `set_desync()` to have side
effects when the target surface is not currently synced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
When running in KVM, the EGL driver supports querying the render node
path, but it returns NULL. Handle that better by falling back to
querying the device main device file, instead of falling back on v3 of
the protocol and logging a warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
If the EGL header is not new enough, it will not contain that relatively
new macro definition, so to avoid breaking compilation, define it
ourselves for now. Should be possible to remove after some time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2214>
This significantly increases the chance of a fullscreen surface buffer
being scanned out instead of being painted via composition. This is
assuming the client supports the DMA buffer feedback Wayland protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
Whenever a surface is promoted as a scanout candidate by
MetaCompositorNative, it'll get a CRTC set as the candidate CRTC.
When a client asks for DMA buffer surface feedback, use this property to
determine whether we should send a scanout feedback tranche.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1959>
We're in the destructor, it's pointless to unset the userdata as we'll
never ever see a request being invoked with it ever again, since the
resource itself will be destroyed or marked as destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2202>
Most clients nowadays switched to buffer damage, most notably Mesa
and Xwayland. Thus lets avoid the extra cost of allocating three
`cairo_region_t`s and doing some calculations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
If no viewport is set, the neutral viewport is the surface size
without viewport destination size applied - i.e. transform and
scale applied to the buffer size. Change it accordingly, giving
us the same values we'd return in `get_width` in this case.
As result, this only changes cases where a viewport destination
size but no viewport source rectangle is set.
The change fixes exactly such cases, e.g. the Gstreamer Wayland
sink. Can be tested with: `gst-play-1.0 --videosink=waylandsink`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
When Xwayland was not initalized, we'd still clean things up. What this
accidentally meant was that the uninitialized display number 0 was
cleanud up, which very likely was main display of the host session.
What this meant in practice was that /tmp/.X11-unix/X0 was often
removed, causing every Flatpak X11 application to fail to start until
Xwayland was restarted nad the X0 socket file was restored.
Fix this in two ways: firstly only shutdown Xwayland if we ever started
it, i.e. if the X11 display policy was not 'disabled'. This should fix
the issue most of the times. Secondly only clean up the socket if it was
ever initialized. This should fix things if the socket creation failed,
as if it did, the name would be set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2162>
A popup surface can be remapped multiple times using the same
wl_surface, if a new xdg_popup object is created. To properly handle
this, we need to reset the 'dismissed_by_client' boolean to false, as
otherwise we won't allow new buffer commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
We are using internal API that has the benefit of checking that the
focus surface still matches, but has the drawback that it does not
check the MetaWaylandKeyboard state.
In order to fix this, look for keyboard focus and serial matches
specifically when triggering activation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2148>
Since this signal is in a hot path during input handling, it makes sense
not to have this be a signal at all, currently most of the time spent in
it is in GLib signal machinery itself.
Replace it with a function/user data pair that are set on the sprite
itself. Only the places that create an sprite are interested in hooking
one ::prepare-at behavior per sprite, so we can do with a single pair.
This makes meta_cursor_sprite_prepare_at() inexpensive enough.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Let the meta_cursor_sprite_realize() function return a boolean value
telling whether there was an actual change in the sprite cursor. E.g.
the surface/icon for it changed in between.
This is used in the native backend to avoid converting/uploading again
the cursor surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Listen to changes in MetaWindow::is-alive, so that the pointer
can logically leave the surface as soon as that happens. This
helps prevent flooding the client socket while it is stalled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
If we were cancelled, it could mean we teared down, meaning fetching
manager instances will attempt to fetch past freed instances. Handle
this by waiting with the fetching until we know we weren't cancelled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2140>
This avoids the following crash, that could happen in certain rare race
conditions, e.g. in tests:
0) wl_closure_invoke (closure=0x2fbf9e0, target=0x2e5b3d0, opcode=0)
at ../src/connection.c:1014
1) wl_client_connection_data () at ../src/wayland-server.c:432
2) wl_event_loop_dispatch () at ../src/event-loop.c:1027
3) wayland_event_source_dispatch () at ../src/wayland/meta-wayland.c:104
4) g_main_dispatch () at ../glib/gmain.c:3381
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2127>
A client can create a token without any seat, serial, or surface. In
this case, we'd still try to grab, which would run into some unforseen
code paths, potentially resulting in the following crash:
0) meta_wayland_tablet_seat_device_added (tablet_seat=0x55dff4271c90,
device=0x7f87b80655b0) at
../src/wayland/meta-wayland-tablet-seat.c:200
1) meta_wayland_tablet_seat_new (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-tablet-seat.c:283
2) meta_wayland_tablet_manager_ensure_seat (manager=manager@entry=0x55dff3ec7b40,
seat=seat@entry=0x0) at
../src/wayland/meta-wayland-tablet-manager.c:239
3) meta_wayland_tablet_manager_ensure_seat (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-touch.c:595
4) meta_wayland_seat_get_grab_info (seat=0x0, surface=0x55dff43ff5b0,
serial=0, require_pressed=0, x=0x0, y=0x0) at
../src/wayland/meta-wayland-seat.c:479
5) activation_activate (...) at
../src/wayland/meta-wayland-activation.c:261
Fix this by not trying to grab if not enough parameters was passed when
creating the token. Also add a test case that reproduces the above
crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
When an activation times out, we'll be signalled two signals on the
startup sequence object: "timeout", and "complete".
Normally, the "complete" signal is emitted when a startup sequence is
completed succesfully by it being used for activation, and in this case,
the xdg_activation implementation should remove the sequence from the
startup notification machinery.
However, in the timeout case, we should not remove it, as the startup
notification machinery itself will deal with this. If we would, we'd end
up with use-after-free issues, as the sequence would be finalized when
removed the first time.
To avoid this, just clean up the Wayland side in the "timeout" signal
handler, leaving the "complete" signal handler early out if it was
already handled by it.
This avoids crashes like:
0) g_type_check_instance (type_instance=type_instance@entry=0xdd6740)
1) g_signal_handlers_disconnect_matched (instance=0xdd6740, ...)
2) meta_startup_notification_remove_sequence (sn=0x4cc890,
seq=0xdd6740) at
../src/core/startup-notification.c:544
3) startup_sequence_timeout (data=0x4cc890, ...) at
../src/core/startup-notification.c:504
4) g_timeout_dispatch (...) at ../glib/gmain.c:4933
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
The previous code was trying to detect client resizes by only
considering resizes without any pending configurations as client
resizes. There can however be pending configurations that do not involve
resizing, such as ones triggered by state changes. These may also stay
unacknowledged by the client until the next size change. This was
causing client resizes after showing the window (and therefore changing
its status to focused) to not be detected as client resize.
Fix this by checking whether the queue has any configuration with size
changes rather than just whether it is empty.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2023
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
meta_window_wayland_finish_move_resize() is called for both, finishing
a resize that has been requested through/by mutter and for resizes
directly done by the client. This introduces a CLIENT_RESIZE flag to
differentiate the former from the latter. Having this distinction is
required to know what the last requested size by either the client or
mutter is while ignoring older requests that might only have been
applied now.
This excludes client resizes when there are still pending
configurations, because the resize is known to be only temporary.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
This will make clients immediately aware of the output disappearing,
while still allowing for a grace period of 10 seconds for attempting to
bind to it before it turning into a protocol error. This API added as
part of wayland 1.18.
This requires us to not add the output resource to the output resource
list, if the output was made inert. This effectively makes the resource
useless, but that is harmless, since shortly after, the client will
clean it up anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This will be crucial when we start to remove the global directly when an
output is removed, as that means Xwayland might have removed the output
before we managed to get our queries in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
We setup Xwayland in an early phase of the X11 display, before we had a
MetaX11Display, and teared down in a couple of places happening when
tearing down the Xwayland integration if the X server died or
terminated. It was a bit hard to follow what happened and when it
happened. Attempt to clean this up a bit, with things being structured
as follows:
* Early during X11 display connection setup, only setup the rudimentary
X11 hooks, being the libX11 error callbacks, and adding the local
user to XHost.
* Move "initialize Xwayland component" code to a new
'x11-display-setup' signal handler. Things setup here are cleaned up
in the 'x11-display-closing' handler.
* Connect to 'x11-display-setup' and 'x11-display-closing' up front,
and stay connected to these two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
