Various code assumed PipeWire function calls would never fail. Some can
actually fail for real reasons, and some currently can only fail due to
OOM situations, but we should still not assume that will always be the
case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/102
(cherry picked from commit 0f9c6aef99)
The destroyed signal that was emitted if an imported surface was not
available when created, for example if the handle was invalid or
already unexported, was emitted on the wrong resource.
(cherry picked from commit 98d7024288)
The current implementation of the XdgSurface v6 protocol does not check
if the window changed before calling meta_window_wayland_move_resize().
The problem with this approach is that calling this function is a costly
operation since we enter the compositor side. In GNOME Shell case, it is
in JavaScript, which triggers a GJS trampoline. Calling this function on
every mouse movement is naturally as terrible as it could be - and is
exactly what happens now.
This commit adds the necessary checks to only call move_resize() when
the window actually changed, or when it needs to be updated.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
This will be used by the next commit to determine when a window
geometry change should be ignored or not. Normally, it would be
enough to just check if the position and sizes changed.
The position, in this case, is relative to the client buffer, not
the global position. But because it is not global, there is one,
admitedly unlikely, situation where the window state is updated
while the client size and relative positions don't change.
One can trigger this by e.g. tiling the window to the half-left of
the monitor, then immediately tile it to half-right. In this case,
the window didn't change, just it's state, but nonetheless we need
to notify the compositor and run the full move/resize routines.
When that case happens, though, the MetaWindowWayland is tracking
the pending state change or a move. And this is what we need to
expose.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
In the old, synchronous X.org world, we could assume that
a state change always meant a synchronizing the window
geometry right after. After firing an operation that
would change the window state, such as maximizing or
tiling the window,
With Wayland, however, this is not valid anymore, since
Wayland is asynchronous. In this scenario, we call
meta_window_move_resize_internal() twice: when the user
executes an state-changing operation, and when the server
ACKs this operation. This breaks the previous assumptions,
and as a consequence, it breaks the GNOME Shell animations
in Wayland.
The solution is giving the MetaWindow control over the time
when the window geometry is synchronized with the compositor.
That is done by introducing a new result flag. Wayland asks
for a compositor sync after receiving an ACK from the server,
while X11 asks for it right away.
Fixes#78
To check if a subsurface is effectively synchronized, we walk the
subsurface hierarchy to look for a non-subsurface parent or a subsurface
being synchronized.
However, when client is closing, the parent surface might already be
gone, in which case we end up with a surface being NULL which causes a
NULL pointer dereference and a crash.
Check if the parent surface is NULL to avoid the crash, and consider
it's already synchronized if it is NULL to avoid further updates.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/124
(cherry picked from commit 52fdd24467)
Before we just set it to "none", but this was not enough since various
calls will depend on not just the context being active, but the main
rendering surface.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/21
(cherry picked from commit ae26cd0774)
When deriving the global scale directly from the current hardware state
(as done when using the X11 backend) we are inspecting the logical
state they had prior to the most recent hot plug. That means that a
primary monitor might have been disabled, and a new primary monitor may
not have been assigned yet.
Stop assuming a primary monitor has an active mode before having
reconstructed the logical state by finding some active monitor if the
old primary monitor was disabled. This avoids a crash when trying to
derive the global scale from a disabled monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
(cherry picked from commit 0b3a1c9c31)
These paths implicitly relied on the forwarded IM key events having
a source_device backed by a real HW device. This assumption is no
longer held true since commit b5328c977.
Explicitly check the INPUT_METHOD flag so they are handled as they
should despite not being "real HW" events.
As a follow up to the patch from a95cbd0a, we need to make sure
that the pointer is out of the way as well when monitors changed,
since that's the event that will prevail in some cases. Besides,
this is also consistent with what the code before a95cbd0a was,
which initialized the pointer position in the same way both in
this case and in the real_post_init() function.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
Centering the pointer at startup causes undesired behaviour if
it ends up hovering over reactive elements, that might react
to that positioning, causing confusion. This is the case of
the login dialog when a list of different users is shown, as
centering the pointer at startup in that case will get the
user in the center of the screen pre-selected, which is not
the expected behaviour (i.e. pre-selecting the first one).
Fix this by simply moving the pointer out of the way, close
to the bottom-right corner, during initialization.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
Right now if Xwayland crashes, we crash, too.
On some level that makes sense, since we're supposed to control the
lifecycle of Xwayland, and by it crashing we've lost that control.
But practically speaking, the knock-on crash adds noise to the logs,
bug trackers, and retrace servers that only makes debugging harder.
And the crash isn't something mutter can "fix", since it's
ultimately from a bug in Xwayland anyway.
This commit makes mutter exit instead of crash if Xwayland goes away
unexpectedly.
(cherry picked from commit 2d80fd02e7)
Right now we explicitly g_clear_error any error we find, but that
makes it tricky to return early from the function, which a
subsequent commit will want to to do.
This commit switches GError to use g_autoptr so the error clearing
happens automatically.
(cherry picked from commit bb65854065)
Gtk now is caching the themed cairo surfaces, then as per
commit gtk@e36b629c the surface device scale is used to figure
out the current paint scaling.
Without this when using background-image's for window buttons
the -gtk-scaled icons isn't properly resized.
Fixes#99
(cherry picked from commit 4339b23dd0)
In the synchronized subsurface case, the destination list may
contain other elements from previous wl_surface.commit calls.
Resetting the list will leave those dangling frame callbacks
that will lead to invalid writes when those get to be destroyed
(eg. on client shutdown).
The ResetIdletime API can be used instead of an "XTest" binary to
programmatically reset the idle time, as if the user pressed a button on
a keyboard.
This is necessary since we stopped using the XSync extension to monitor
idletimes, as it didn't consider inhibitors as busy, and mutter's
clutter code ignores "Core Events" as generated by XTest.
This patch will require minimal changes to gnome-settings-daemon's power
test suite so that "key press" idletime resets are triggered through
this D-Bus interface rather than through XTest and a roundtrip through
the X server.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Take idle inhibitions into account for when to fire idle watches as
requested by OS components.
This should stop gnome-session and gnome-settings-daemon considering
the session idle when they have been inhibited for longer than their
timeout, for example to avoid the screensaver activating, or the
computer suspending after watching a film.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Now that we've removed the X11 specific backend of the idle monitor,
add back a cut-down version of it for the explicit purpose of being
told about idle time resets when XTest events are used.
XTest events are usually used by test suites and remote display software
to inject events into an X11 session. We should consider somebody moving
the mouse remotely to be just as "active" as somebody moving it locally.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
And use the old "native" backend for both X11 and Wayland. This will
allow us to share fixes between implementations without having to delve
into the XSync X11 extension code.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
When moving the pending state of an effectively synchronized subsurface
so it is applied together with the parent, perform a merge of the source
MetaWaylandPendingState into the destination one, instead of simply
overwriting the struct.
The other approach had 2 kind of leaks, one that would happen everytime
a wl_surface.commit happens on a sync subsurface (both surface/buffer
damage regions are leaked). The other more unlikely one would apply on
the rest of pending state data, happening whenever the compositor gets
>1 wl_surface.commit calls on the subsurface before the parent surface
gets its own.
The function has also been renamed to use the more descriptive "merge"
term.
Related: gnome-shell#64
Output ID is set equal to 'i' later in the loop. But 'i' was never
incremented, so all outputs were getting the same ID (equal to
the number of CRTCs, because 'i' was reused from the previous loop).
Make it re-enable:able by a hidden "experimental feature". To enable,
add "kms-modifiers" to the org.gnome.mutter.experimental-features
GSettings entry.
https://gitlab.gnome.org/GNOME/mutter/issues/81
The value is not scaled by default so it needs to be adjusted
depending on the window scaling, as it's done in other places.
Fixes: #87
(cherry picked from commit deda7a5235)
If we attempt GBM surface allocation with a set of modifiers but the
allocation fails, fall back to non-modifier allocations. This fixes
startup on Pineview-based Atom systems, where KMS provides us a set of
modifiers but the GBM implementation doesn't support modifier use.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/84
(cherry picked from commit e6109cfc22)
Rotating an output would show duplicate cursors when the pointer is
located over an area which would be within the output if not rotated.
Make sure to swap the width/height of the output when rotated.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/85
(cherry picked from commit ebff7fd7f4)
Rendering the next frame (which mostly happens as part of the flush done
in swap buffers) is a task that the GPU can complete independently of
the CPU having to wait for previous page flips. So reverse their order
to get the GPU started earlier, with the aim of greater GPU-CPU
parallelism.
(cherry picked from commit 6e415353e3)
Mutter recently gained the ability to deal with multiple GPUs
rendering at different displays. These GPUs would have a display
connected to them, and Mutter was adapted in order to be aware
of different GPUs and their outputs.
However, one specific edge case appeared: PRIME systems. PRIME
systems have two GPUs:
* The integrated GPU (iGPU), usually Intel, which has connectors
and deals with the routine load.
* The dedicated GPU (dGPU), usually AMD or NVidia, which has no
connectors at all and are there just to aid heavy loads.
On those systems, the dGPU is aggressively put to sleep by the
kernel to avoid energy waste. Waking it up is a costly operation.
With Mutter's adaptation to deal with multiple GPUs, Mutter began
wakening the dGPU every time some rendering had to be done. This
was causing stuttering every time the dGPU was put to sleep, and
Mutter asked it to wake up again.
To fix this situation, this commit ignores GPUs with no connectors
attached.
Issue: #77
This is a small mistake spotted while working on a solution
for #77. When a GPU fails to initialize, we're adding them
anyway, which might have pretty bad consequences when trying
to use these NULL GPUs.
Issue: #77
This state tracks hardware devices' state, thus shouldn't be triggered by
events that were emulated/forwarded by the IM. Those may include modifiers
and would result in xkb_state being doubly set, and possibly stuck.
https://gitlab.gnome.org/GNOME/mutter/issues/74Closes: #74
Commit d714a94d9 added support for stable xdg-shell surfaces while
preserving old unstable zxdg-shell v6 ones, but committed a mistake
in checking for both in the xdg_exporter.export error condition
paths. We want to check that the surface is neither of both.
https://gitlab.gnome.org/GNOME/mutter/issues/63Closes: #63
Raising and lowering windows in tandem without a proper grouping
mechanism ended up being more annoying than functional.
This reverts commit e76a0f564c.
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
When painting the titlebar, button icons that aren't available in the
desired size need to be scaled. However the current code inverses the
scale factor, with the result that the adjusted icons are much worse
than the original icons, whoops.
This went unnoticed for a long time given that most icons are availa-
ble in the desired 16x16 size, and the most likely exceptions - window
icons - are not shown by default.
https://gitlab.gnome.org/GNOME/mutter/issues/23
In order to let applications gracefully handle version mismatches, add
a version property to the APIs. Also add a warning on the APIs that
these are not meant for public consumption.
