The function focus_default_window() optionally takes a MetaWindow
argument denoting a window that should not be focused.

That function calls focus_ancestor_or_top_window() which in turn
calls meta_window_focus() to pass focus to another window.

However meta_window_focus() gives no guarantee that the given window
will end up being the one focused, and can fail in various and creative
ways.

If that fails, we could possibly end up with the focus window being the
one to avoid, while the caller assumes focus was changed, going as far
as asserting that fact like meta_window_unmanage() does.

As a result, mutter may abort simply because meta_window_focus() failed
to set focus on the expected window.

To avoid that issue, check that the focus did not end up on the window
that we explicitly did not want, and if that's the case, simply fallback
to the default focus window.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/862
(cherry picked from commit afa43154)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1653>

find_focusable_ancestor() may pick an ancestor window which is not
mapped or hidden, and setting focus on that window will fail.

Be a tad more selective when looking for a focusable ancestor, to reduce
the chance of meta_window_focus() not focusing the happy chosen one.

(cherry picked from commit 76d1a642)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1653>

Extract some boilerplate into new functions for next patch.

No functional change intended.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1561>

After last monitor gets unplugged from the system, hotplug detection may
no longer work on Intel GFX.

This is because we didn't trigger a modeset to disable CRTCs, and i915
requires it to make hotplug detection continue to work [1].

Ensure disabled CRTCs are unset and post a modeset to disable them.

[1] https://www.kernel.org/doc/html/latest/gpu/i915.html#hotplug

https://gitlab.freedesktop.org/drm/intel/-/issues/2602

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1561>

After last monitor gets unplugged from the system, hotplug detection may
no longer work on Intel GFX.

This is because we didn't trigger a modeset to disable CRTCs, and i915
requires it to make hotplug detection continue to work [1].

There's no guarantee that DPMS off in DDX also disables CRTCs, so
explicitly disable CRTCs to solve the issue.

[1] https://www.kernel.org/doc/html/latest/gpu/i915.html#hotplug

https://gitlab.freedesktop.org/drm/intel/-/issues/2602

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1561>

Carlos Garnacho authored Dec 23, 2020 and Robert Mader committed Jan 12, 2021

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>

(cherry picked from commit 98ef6d0d)

Update NEWS.

Once we are no longer managing a window, we have no business in
dealing with it anymore, and operations like focusing, raising or
pinging the window aren't expected to work, and can go horribly
wrong if we try.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676>
(cherry picked from commit e7b58c23)

We remove pending pings when unmanaging a window, but currently
don't prevent new pings to be scheduled after that.

The previous commit fixed a code path where this did indeed happen,
but as the result of gnome-shell trying to attach a Clutter actor
to a non-existent window actor is pretty bad, also guard can_ping()
against being called for an unmanaging window.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676>
(cherry picked from commit 81f36948)

Constantly manipulating the stack caused severe stalls (several seconds)
with many open windows when switching workspaces. The cause for this was
that each show/hide call dealt with the stack in isolation, meaning if
you hid N windows, we'd manipulate and synchronize the stack N times,
potentially doing synchronous calls to the X server while doing so.

Avoid the most severe stalls by freezing the stack while calculating
showing; this made the worst case go from several seconds to around
10-20 ms, which is still bad, but by far not as bad.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>


(cherry picked from commit d43c8cd8)

Analogous to MetaWindowActor. Also take it into account for positioning
when an anchor is set.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683>

(cherry picked from commit dfa659b5)

The removed parts are now all handled in MetaFeedbackActor.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683>

(cherry picked from commit 04eeeb78)

Technically this is still wrong if the source actor or dnd actor are
transformed in other ways. However geometry scale is the by far most
common case and we currently lack convenience API in Clutter to
easily compute the right values.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683>

(cherry picked from commit 7da34f15)

Carlos Garnacho authored Feb 08, 2021 and Robert Mader committed Feb 11, 2021

This currently happens by default whenever the grab is finished.
We want to eventually do this manually everywhere, so start here.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>

(cherry picked from 3799606f)

Carlos Garnacho authored Feb 08, 2021 and Robert Mader committed Feb 11, 2021

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>

(cherry-picked from 8e01ea1e)

Carlos Garnacho authored Feb 08, 2021 and Robert Mader committed Feb 11, 2021

Adapt more paths to manual detaching of source/offer. This is still
done automatically when the grab is finished.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>

(cherry picked from commit 0f9dc84d)

Carlos Garnacho authored Feb 08, 2021 and Robert Mader committed Feb 11, 2021

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>

(cherry picked from commit 698fe3f1)

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>
(cherry picked from commit 6438919a)

Commit afa43154 tried to make sure the focus was properly changed when
calling focus_default_window() by checking the focused window just after
trying to set the focus.

However, the X11 “Inter-Client Communication Conventions Manual” version
2.0 (ICCCM 2 for short) states that some X11 client may want to use a so
called “globally active input” model in which case the client expects
keyboard input and set input focus even when it's not one of its own
window.

To comply with this, when dealing with such clients, mutter will not
change the focus and send a WM_TAKE_FOCUS message instead.

That mechanism will defeat the logic introduced by commit afa43154
because the focused window is not changed in this case. As a result, the
input focus will fallback to the no-focus window.

To avoid this, only check that the focus change occurred for windows
using a synchronous focus model.

v2: Split specific test for "globally active input" model (Florian).
v3: Remove the check for window->unmanaging which is useless (Jonas).

Fixes: afa43154 - "core: Make sure focus_default_window() worked"
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/1620
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
(cherry picked from commit 2432508d)

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>

(cherry picked from commit ba8499f9)

Update NEWS.