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>
When we use gbm together with the NVIDIA driver, we want the EGL/Vulkan
clients to do the same, instead of using the EGLStream paths. To achieve
that, make sure to only initialize the EGLStream controller when we
didn't end up using gbm as the renderer backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2052>
Quoting the spec for `wl_data_device::drop`:
> If the resulting action is "ask", the action will not be considered
> final. The drag-and-drop destination is expected to perform one last
> wl_data_offer.set_actions request, or wl_data_offer.destroy in order
> to cancel the operation.
We did not respect the action choosen by the drop destination when
it called `wl_data_offer::set_actions` after `wl_data_device::drop`
if a user override was still active. This eventually resulted in
a protocol error in `wl_data_offer::finish`, as the current action
could still be `ask`.
Fix this by only allowing a user override to `ask` before `drop` is
called, thus making sure the final `set_actions` preference is
honored.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1952
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2043>
With each wl_ouitput corresponding to a monitor, the logical monitor is
not part of the MetaWaylandOutput anymore.
Previously, send_xdg_output_events() would compare the old logical
monitor against the new one to determine whether the size and/or
position was changed and should be sent along with the xdg_output
events.
But that logic is now defeated as there is no old/new logical monitor
anymore, so the updated size or location would never be sent again.
Xwayland relies on this information to update its X11 clients and its
own internal root size, without this the X11 screen size and XRandR
information would never be updated.
To avoid that issue, always send the xdg_output size and location on
xdg_output events, Xwayland is smart enough to update its X11 clients
with XRandR only when the layout actually change.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1964
Fixes: bf7c3450 - Make each wl_output correspond to one monitor
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2050>
The extra stage update we schedule in `apply_state()` is mainly
needed in two situations:
- a partial update happened only in obscurred or off-screen parts
of a surface
- a surface requests frame callbacks without having done damage,
notably the (in)famous Firefox vsync implementation.
Commit 0330ce1f15 limited the update to cases when the actor
was mapped, breaking it for Firefox in the overview.
Remove the mapped check again and get the stage from the backend,
restoring previous behaviour.
Fixes 0330ce1f15
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1957
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2034>
A client request for maximizing itself should always be handled by mutter
by emitting a configure event with the native maximized resolution,
regardless of the client's own set limits. This also aligns the behavior by
allowing fixed-sized windows to go into fullscreen or maximized state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1997>
The way wl_seat capabilities work, by notifying clients of capabilities
changes, and clients consequently requesting the relevant interface
objects (pointer, keyboard, touch) is inherently racy.
On quick VT changes for example, capabilities on the seat will be added
and removed, and by the time the client receives the capability change
notification and requests the relevant keyboard, pointer or touch,
another VT switch might have occurred and the wl_pointer, wl_keyboard or
wl_touch already destroyed, leading to a protocol error which kills the
client.
To avoid this, create the objects when requested regardless of the
capabilities.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1797
Related: https://bugzilla.gnome.org/show_bug.cgi?id=790932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/77>
These are ClutterInputFocus subclasses, so this will trigger reset of
the input method. As the .done event is possibly deferred in the
zwp_text_input_v3 implementation, ensure the changes caused by the
reset are flushed immediately, before the button press is forwarded
to the client by MetaWaylandPointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940>
This is more in line with the protocol, and allows us to remove some
awkward code that tries to "combine" different metadata from different
monitors into one, which sometimes meant picking an arbitrary "main"
monitor, or "and" metadata together to find a common ground.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1712>
Before we first created the MetaWaylandCompositor instance, which would
repare Clutter/Cogl so they could initialize and turn on Wayland display
server features, then later to initialize the rest. Now that part is
done by the Wayland infrastructure itself, so we don't need the early
initialization. Simplify things a bit by centralizing it all into a
single meta_wayland_compositor_new() call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
As with the compositor type enum, also have the X11 display policy enum,
as it's also effectively part of the context configuration. But as with
the compositor type, move it to a header file for enums only, and since
this is a private one, create a private variant meta-enums.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
The DRM buffers aren't really tied to mode setting, so they shouldn't
need to have an associated mode setting device. Now that we have a
device file level object that can fill this role, port over
MetaDrmBuffer and friends away from MetaKmsDevice to MetaDeviceFile.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
When the MetaWindow resize machinery for toplevels ended up in the
Wayland window implementation, we tried to avoid configuring
not-yet-mapped windows that just had its zero sized dimension pass
through the constraint machinery, resulting in a 1x1 sized window.
If we'd properly set up the min size metadata earlier, that 1x1 would
likely be the minimum size set of a window, which makes things harder to
predict when peeking at side effects.
However, what the side effect peeking intends to do, as documented in
the comment, was to figure out when the client hadn't committed any
buffer yet, i.e. during the initial map, and in those cases avoid
sending that nasty 1x1 size, resulting in silly window sizes. A more
robust way to detect this is instead checking when we shouldn't really
try resize things our own way, and in those cases early out as was done
before.
This means that, for a yet to me mapped window, we only ever want to
send an initial non-zero configuration when 1) it's initially maximized,
2) initially fullscreen, or 3) initially tiled in any way, as those are
the situations where the compositor is the one deciding the size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1912>
The cancel phase for swipe gestures was not being handled, hence,
Wayland "end" events where not sent to clients when the gesture was
cancelled.
A swipe gesture is cancelled when extra finger(s) are put down on the
touchpad in the middle of the gesture or when some, but not all, of the
fingers are put up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1857>
Getting crossing events is necessary between client surfaces while
there is a popup grab in effect (e.g. allow press-drag-release in
menus), we should only stick with the focus surface while the pointer
is outside any client surface.
This partially undoes commit 79050004b0 (or, at least, mutter no
longer fixes the bug it claimed to fix). This will be addressed in
gtk4.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1885>
We first initialized the Wayland infrastructure, then the display, but
on shutdown, we first teared down the Wayland infrastructure, then the
display.
Make things a bit more symmetric and tear down the display before
Wayland. This however means we need to tear down some things Wayland a
bit earlier than the rest. For now this is a separate function, but
eventually, it can be replaced with a signal shared by the backend's
'prepare-shutdown' signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
This way we can initialize without having any way to retrieve it via
some global variable. This isn't needed now, but will be once Wayland
infrastructure initializiation is done in a single step.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
This is especially important as we might end up here when initializing
the Wayland infrastructure. Later that will be done in one step, meaning
the "get_default()" function will not work properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
It might not be there when shutting down, so get it from a more managed
place. Note that this isn't strictly needed right now, but eventually,
the MetaWaylandCompositor pointer will be cleared using a g_clear*()
helper, which clears the pointer before freeing the instance, which
wouldn't work here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
This will allow us less awkward startup, where previously we had to
pre-initialize Wayland very early so Cogl could bind the Wayland display
when it initialized. Move things around so we bind the Wayland EGL
display when initializing the rest of Wayland infrastructure.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
The callback on_displayfd_ready() would unconditionally set the return
value to TRUE, regardless of the condition.
Use the GIO condition to determine if there was data written and adjust
the return value accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1851>
We initialize, but might not start, e.g. when a test case just needs a
backend and doesn't start mutter. When cleaning up, we'll still try to
clean up Xwayland integration, and this commit handles cleaning up
without having made the mess.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1856>
We make objects inert when disabling the seat, but we requests may still
have effect. This is especially bad if disabling is followed by
destroying, but also means e.g. set_cursor() not doing an early out
after the pointer capability was disabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
MetaDisplay does a lot of things, and is a central part to anything
window management. To let Wayland units have an easier time tearing
down, make it so that the Wayland infrastructure is terminated before
MetaDisplay.
This also makes sure that X11 support is turned off, so that we don't
stumble upon Xwayland terminating due to the Wayland socket connection
being broken. Will mitigate that in a better way in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
We might not be the only entity holding on to the X11 GdkDisplay,
meaning the X11 connection will stay alive indefinitely, e.g. if the gjs
context has some reference to it.
Avoid running into issues due to X11 connection errors by setting the
libX11 handlers to no-ops, so when we are terminating; that means the
GDK X11 connection can stay "alive" until its too late, and we'll just
silently ignore any connection errors that may happen due to the
lingering GDK display reference.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
Compositor behaviour when calling `wl_data_device_manager_get_data_device`
for the same seat multiple times is not very clearly defined in
the spec and both Mutter and Weston currently don't handle
the DnD case properly.
While Weston handles DnD only for the last created data device,
Mutter, because of some internal reshuffling, ends up toggling
between two devices.
Properly handling this case requires some bigger changes. So
in order to behave predictable and in line with Weston,
only take the last created data device into account while
still keeping the previous created ones around.
The main affect client here is Firefox, which gets very
confused by the toggling behaviour and becomes more stable
with this patch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1841>
If a subsurface first gets reordered and afterwards detached from
the parent before the parent surface got commited, we currently
would end up reattaching the subsurface to its previous parent.
While clients should avoid this behaviour, it's legit according
to the spec.
We already prevent similar cases where the subsurface is destroyed -
extend that check to detaching, which includes the destroy case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1831>
Use the new API to make sure the shaped texture has a valid size
during the next layout phase.
This is needed here because, quoting the previous commit:
When the texture size is invalidated using `invalidate_size()`, the new
size will only get calculated the next time `update_size()` is
called. This happens e.g. in `meta_shaped_texture_get_preferred_size()`
via `ensure_size_valid()`.
`update_size()` can chain up to `clutter_content_invalidate_size()`
as well as emitting a `size-changed` signal. If this happens during
layout, the result is a 'change the layout conditions during layout'
issue, causing heavy breakage in e.g. the Shell overview.
To fix this, expose `ensure_size_valid()` as API so callers can make
sure the texture has a valid size without creating redundant size
invalidations calls.
Note that if a buffer with a new size is attached we already trigger
`update_size()` explicitely, avoiding such situations.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1718
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
If a client is naive enough to assume that it can set the selection while
it has got no surfaces, mutter will simply ignore the request and leave
the selection unchanged.
This is good and the expected behavior, however the poor client that did
this will enter in an inconsistent state where it "claimed" the selection,
but nobody told it that the wl_data_source is not current.
So, when the client is focused the next time, it will receive wl_data_offers
as usual, but it will still think all the time that it is owning the
selection. In the case of GTK, that takes client-side shortcuts, so any
attempted paste will still bring back the client-side aborted selection.
To fix this, cancel the selection right away if it happened while unfocused,
the client will be able to undo its own failed selection, and not assume
that future offers are its own.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1469
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1772>
It seems to be the preferred format of the Mesa V3D driver on
Raspberry Pi 4. If the compositor doesn't advertise it then Mesa will
fallback from `zwp_linux_dmabuf_v1` to `wl_drm`, incorrectly. Meaning
it will keep using a buffer with modifiers on an interface that does
not have modifiers.
Add support for `DRM_FORMAT_ABGR2101010`. It works, and prevents Mesa
from taking its broken fallback path.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1520
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1798>
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>
When deciding if `configure` event should be sent,
`meta_window_wayland_move_resize_internal` compares requested window size
with `window->rect` size. However, `window->rect` is only updated when `commit`
is received. So the following sequence produces incorrect result:
1. a window initially has size `size1`
2. `move_resize_internal` is called with `size2`. `configure` is sent
3. `move_resize_internal` is called with `size1` to restore original size,
but `commit` for `size2` haven't arrived yet. So `window->rect` still has size
`size1`, and thus new `configure` is not sent
4. `commit` for `size2` arrives, window changes size to `size2`
Expected window size in the end: `size1`
Actual: `size2`
To fix the issue, take size from pending `configure` events into account.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1627
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1755>
This commit assumes that cursor surfaces work in a "mailbox" fashion. If
they are painted multiple times before a successful flip, all commits
but the last get discarded, and the last commit gets presented after the
flip succeeds. This is more or less how it works in the atomic backend,
and also more or less how it works in other backends, with the exception
that the cursor painting might fail without any way of knowing. This
assumption is still better than unconditionally discarding all cursor
surface feedbacks as if the cursor painting always fails.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
Regarding the sequence = 0 fallback: in some cases (moving a cursor
plane on atomic amdgpu) we get sequence = 0 in the page flip callback.
This seems like an amdgpu bug, so work around it by assuming a sequence
delta of 1 (it is equal to 1 because of the sequence != 0 check above).
Sequence can also legitimately be 0 if we're lucky during the 32-bit
overflow, in which case assuming a delta of 1 will give more or less
reasonable values on this and next presentation, after which it'll be
back to normal.
Sequence is also 0 on mode set fallback and when running nested, in
which case assuming a delta of 1 every frame is the best we can do.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
The presentation-time protocol allows surfaces to get accurate
timestamps of when their contents were shown on screen.
This commit implements a stub version of the protocol which correctly
discards all presentation feedback objects (as if the surface contents
are never shown on screen). Subsequent commits will implement sending
the presented events to surfaces shown on screen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
If `meta_xwayland_start_xserver()` returned via an error path, some of
the socket FDs were leaked.
Fix that, and add `steal_fd()` calls to make it clearer that FDs passed
to `g_subprocess_launcher_take_fd()` are transferred to it. There were
no bugs with how `GSubprocessLauncher` was being used.
Spotted while working on
https://gitlab.gnome.org/GNOME/glib/-/issues/2332.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1738>
X11 clients can use different models of input handling, of which some
may not result focus being set synchronously.
For such clients, meta_focus_window() will not change the focus itself
but rely on the client itself to set the input focus on the desired
window.
Add a new MetaWindow API to check when dealing with such a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
In the case that DnD is performed and succeeds, we want to release
the grab early, and let the transfer IPC happen in the back. For
that to happen without a hitch, drag source and offer must be left
related to each other after undoing the grab, even though the default
ungrabbing code does that automatically (indirectly, by unsetting the
drag focus).
In these cases, we used to manually unset the current source, so
this decoupling was skipped. Notably, one missed case is X11 DnD,
so we might end up with the situation there that DnD did succeed,
transfer is ongoing, but the source and offer are already decoupled,
this confused the machinery and missed the finishing XdndFinished
to be emitted to the X11 drag source.
The prior commits prepared for this source/offer decoupling being
a manual operation, this commit avoids doing this automatically
when ungrabbing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
This object is just being detached, with no code unref'ing it. Do
this whenever the XDnD selection goes unowned, usually a good
indication that the drag source no longer is one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
When (un)maximizing, (un)fullscreening, the move/resize action is
flagged with 'ACTION_MOVE' and 'ACTION_RESIZE' , while e.g.
'appears-focus' does not.
When a client misbehaved and didn't immediately reply to a configure
request with a commit with the corresponding ack_configure, the
following commit would trigger a oddly timed move, making the window
appear to move back to a previous position.
Avoid this issue by only carrying over the target window position if the
configuration actually contained a new position.
We cannot only rely on the flags however, as e.g. a new position should
be respected during interactive resize, even though only 'ACTION_RESIZE'
is passed in such scenarios.
Do the same for the size, except if the window state dictates that the
size is fixed to a certain size, e.g. being fullscreen or maximized.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1445>
Previously the wl_resource and MetaWaylandGtkSurface corresponding to
any client gtk_surface have been kept around until the exit of the
client due to the client side destroy method not signaling the
destruction to the server. Ideally the protocol would have specified a
destroy request marked as destructor to handle this automatically,
however this is no longer possible due to the destroy method being
implicitly generated in the absence of an explicit request in the
protocol. Adding a destroy request marked as destructor now would
generate a new destroy method that unconditionally would send the
request to the server, which would break clients running on servers not
supporting that request.
So instead of modifying the destroy request add a new "release"
destructor, that indicates to the server that it can release the
resource. This can be optionally be used by clients depending on the
server protocol version.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1307>
The MetaWaylandSurface corresponding to a MetaWaylandGtkSurface can be
destroyed before the MetaWaylandGtkSurface is destroyed. In its destroy
function MetaWaylandSurface however was unsetting the destructor of the
correspnding resource along with the gtk_surface1 interface
implementation. This was done to prevent further gtk_surface1 requests
on a NULLed MetaWaylandSurface, if it has been destroyed before the
MetaWaylandGtkSurface.
It would be enough to just unset the resource implementation, while
keeping the destructor to fix this leak. However the following commit
will rely on the implementation being available after the
MetaWaylandSurface has been destroyed. So instead introduce NULL checks
for all functions that can be called on the gtk_surface1 interface and
do not unset the implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1307>
One for the public channel, and one for the private maintainance
channel. Use the public one for test clients, otherwise tests become
flaky, and the private one for MetaX11Display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1681>
This commit consolidates DRM buffer management to the MetaDrmBuffer
types, where the base type handles the common functionality (such as
managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types
their corresponding type specific behavior.
This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c
to meta-drm-buffer.c; dumb buffer allocation/management from
meta-renderer-native.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Current Xwayland has marked the command line option "-listen" as
deprecated in favor of "-listenfd".
Use the pkg-config variable "have_listenfd" (if available) from Xwayland
to determine if we should use that option, to avoid a deprecation
warning when spawning Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1682>
Mutter listens to two display connections, one for regular X11 clients
and another one for the so called "managed services".
Once an available display number is found for the regular X11 clients,
mutter would then redo the work to find another available display number
for the managed services.
Yet, it does so starting from the same initial display, which is a waste
of time since it just tried all displays to find the first available
one, so all these, including the regular display it just took, are now
in use.
So instead of starting over from the beginning when looking for a
display available for the managed services, continue from the next
display immediately after the one we found precedently.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1680>
Some X11 servers may not always create a lock file, yet mutter uses the
lock file to find a possible display number and then tries to bind to
the socket corresponding to that display number.
If it fails to bind, it will simply bail out. As a result, if an X11
server is already listening on that display but hadn't created a lock
file, mutter won't be able to start Xwayland.
To avoid that possible issue, make mutter retry with another display
for a given number of tries when binding fails even though the display
was supposed to be available based on the lock file presence.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1604
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
The function choose_xdisplay() calls open_display_sockets() which calls
ensure_x11_unix_dir().
We don't need to do that from within the loop though, as the directory
/tmp/.X11-unix is the same regardless of the display number.
Move the call to ensure_x11_unix_dir() from open_display_sockets() to
choose_xdisplay() prior to enter the display loop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
In case of failure to open the display sockets, we would not propagatre
the error which can cause a crash when trying to show the error message.
Properly propagate the error to avoid the crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
In the shutdown paths we check with the X11 display whether there's
remaining clients. However this happens in paths that happen after
the MetaX11Display vanished in the case of Xwayland crash.
Since in that situation the clients are forcibly vanishing too,
skip the client check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1677>
Closing automatically Xwayland once all relevant X11 clients are gone is
inherently racy, if a new client comes along right at the time we're
killing Xwayland.
Fixing the possible race conditions between mutter, Xwayland and the X11
clients may take some time.
Meanwhile, make that an experimental feature "autoclose-xwayland".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1673>
Currently, mutter checks for the presence of X11 windows to decide
whether or not Xwayland can be terminated, when Xwayland is started on
demand.
Unfortunately, not all X11 clients will map a window all the time, an
X11 client may keep the X11 connection opened after closing all its
windows. In that case, we may terminate Xwayland while there are some
X11 client connected still, and terminating Xwayland will also kill
those X11 clients.
To avoid that issue, check the X11 clients actually connected using the
XRes extension. The XRes extension provides the PID of the (local) X11
clients connected to the Xserver, so we need to match that against the
actual executable names, and compare with a list of known executables
that we can safely ignore, such as ibus-x11 or gsd-xsettings.
We also check against our own executable name, considering that the X11
window manager is also an X11 client connected to the Xserver.
Also, XRes returning the PID of local clients only is not a problem
considering that Xwayland does not listen to remote connections.
However, if the user spawns a client remotely on another system using
ssh tunneling (ssh -X), only clients which actually map a window will
be accounted for.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1537
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1671>
Changes in games between fullscreen and windowed modes may trigger
chaotic situations where the buffer and the frame size temporarily
disagree, producing rectangles with negative width/height. This is
usually followed by other updates that bring the pointer constraint
up to date.
This makes cairo panic and return an "error" empty region, which breaks
deeper down when using the region rectangles to apply the pointer
constraint.
If we hit this situation, ignore the frame rectangle, and just go with
the buffer rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1655>
Unfortunately there's situations where we can't fully rely on only
crossing events here. One such situation is pointer visibility changes
due to touch interaction, or e.g. after closing the lid.
In these situations the pointer position stays the same, picks the
same actor, yet we want to see the right surface as the pointer focus
again in the wayland side.
This used to happen on the first motion event after the pointer
visibility change before commit ad3f2b0b86, use motion events again
for picking so we don't break these usecases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
These events may be emitted for touchpoints (in which case they contain
an event sequence). Ignore those as they are not relevant for pointer
picking, and shouldn't influence its focus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
Just because of implementation details, this is only relevant to Wayland,
and is done via ::effects-completed handlers there. Ideally, Clutter should
notice by itself about effects starting, finishing, and affecting picking.
Doing this in generic code seems slightly cleaner in the interim.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
In the wayland code we are in synchronization with the events that
the ClutterStage is managing at the moment. Asking the ClutterSeat for
the pointer position gets ahead of the current events, and may result
in imprecise coordinates sent in wl_pointer.enter.
To be in consistence with the motion events that might be already
queued, we should ask the stage for the last known coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
As planned and prepared with the last commits, let ClutterStage take
care of tracking input devices and their respective actors. This means
we now can remove the old infrastructure for this from
ClutterInputDevice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
To find XWayland output that should be the primary one, iterate through all
XWayland outputs, and compare their geometry to the geometry of the primary
logical monitor.
To avoid possible race conditions (Mutter's monitor configuration already
updated, but Xrandr not yet), set the output both after Randr notifications and
after 'monitors-changed' signal.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1407
Signed-off-by: Aleksandr Mezin <mezin.alexander@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1558>
When we're running under a polyinstantiated SELinux environment, we'll
likely start with an isolated and empty /tmp, meannig no /tmp/.X11-unix
directory to add things to. To make it possible to still function in
this kind of setup, make sure said directory exists.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1626>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
The XIOErrorExitHandler expects (Display *, void *) whereas mutter uses
(Display *, MetaX11Display *).
That causes a warning at build time:
warning: passing argument 2 of ‘XSetIOErrorExitHandler’ from
incompatible pointer type [-Wincompatible-pointer-types]
813 | XSetIOErrorExitHandler (xdisplay, x_io_error_exit, display);
Actually, the MetaX11Display is not even used, so we can just use the
expected API and ignore the value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1621>
While browsing sysprof profiling reports, I saw surface-commit taking
significant times sometimes; trace attach too, to see whether such
things are due to e.g. texture uploads.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>
These use now more of a "pull" model, where they receive update
notifications and the relevant input position is queried, instead
of the coordinates being passed along.
This allows to treat cursor renderers all the same independently
of the device they track. This notifying of position changes should
ideally be more backend-y than core-y, a better location will be
figured out in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of letting the wayland bits maintain an always-software
cursor renderer, let the cursor renderer be managed by the backend,
and only hook to it (as we do for pointer cursor) in the wayland
bits.
ATM, make the cursor renderer still always-software, although
ideally we should allow moving the HW cursor management between
renderers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Since we schedule frames for each stage view seperately now, surfaces receive
frame callbacks for each stage view they are visible on.
Only emit frame callbacks for the primary stage view.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
For X11 grabs, the pattern matching mechanism would simply ignore
applications which have neither WM_CLASS nor WM_NAME set.
When dealing with an override redirect window however, it is not
uncommon that these window have neither value set as these window are
supposed to be ignored by the window manager.
When the WM_CLASS or the WM_NAME is not set by the client, assume the
value is empty so the pattern matching can allow for these.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1249
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1254>
Commit 8bdd2aa7 would offset the window position by the difference
between the configured window size and the committed size from the
client to prevent the window from drifting while resizing.
This, however, did not take into account the actual geometry scale, so
when using any scale greater than 1, the window would rapidly drift away
due to that offset.
In order to solve this, we need to make sure we store away the pending
window configuration in the stage coordinate space, in order to not
loose precision. When we then calculate the offset given the result from
the client, it'll use the right scalars, while before, one scalar was in
surface coordinates, while the other in stage coordinates.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1490
