GitLab

To make the double buffered shadow buffer damaged tiles detection
feasable, a new EGL extension is needed for creating FBO's backed by
a custom CPU memory buffer, instead of DMA buffers, as DMA buffers can
be very slow to read, much slower than just painting the shadow buffer
directly.

Leave the code there, since such an EGL extension is intended to be
added, but hide it behind an env var so that it isn't enabled by
accident.

(cherry picked from commit ad5b5f2c)

!1724

Part-of: <!1743>

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: #1620
Part-of: <!1716>
(cherry picked from commit 2432508d)

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

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: <!1720>

(cherry picked from commit 698fe3f1)

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

Part-of: <!1720>

(cherry picked from commit 0f9dc84d)

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: <!1720>

(cherry-picked from 8e01ea1e)

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

Part-of: <!1720>

(cherry picked from 3799606f)

We might have a stage view listener attached to the stage itself if the
actor didn't have a suitable frame clock when the actor was associated
with the timeline. We'd then listen to stage-views-changed signals on
the stage itself to be able to attach to a frame clock when one
appeared.

What went wrong is that if an actor that didn't have a frameclock was
associated with a timeline, but then destroyed, the timeline would
disassociate itself from the actor, but it'd still listen on the
stage-views-changed signal on the stage. This would be in itself
harmless, until the timeline itself is destroyed, as at this point, it
wouldn't clean up the stage-views-changed listener on the stage, as it's
assumed to only be valid when there is an actor attached.

Fix this issue by cleaning up the stage's stage-views-changed listener
when the actor is destroyed, as we wouldn't be able to make use of it by
then anyway.

Closes: gnome-shell#3323
Part-of: <!1719>


(cherry picked from commit 4145fbba)

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: <!1683>

(cherry picked from commit 7da34f15)

The removed parts are now all handled in MetaFeedbackActor.

Part-of: <!1683>

(cherry picked from commit 04eeeb78)

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

Part-of: <!1683>

(cherry picked from commit dfa659b5)

Now that we have a window actor API that can hint whether or not the
window actor would support freezing commits, use it to avoid freezing
Xwayland commit on actors that will not be thawed after paint.

Closes: #1615
Part-of: <!1678>

(cherry picked from commit a2e2cfe4)

Mutter freezes Xwayland commits when resizing windows, and thaw them in
the window actors' after_paint() for X11.

Yet, after_paint() could be never called, as when a new window is mapped
while the overview is active in gnome-shell.

As a result, the content of the X11 window will remain invisible to the
overview.

Add a new window actor API to tell whether commits can be frozen. For
Wayland window actors, this always return FALSE, whereas for X11 window
actors, it checks whether the Clutter actor is mapped.

Part-of: <!1678>

(cherry picked from commit df5a5d27)

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: <!1616>


(cherry picked from commit d43c8cd8)

Like with the monitor source, we need to reattach to the new views after
monitor changes, otherwise the screen cast will get stuck.

(cherry picked from commit 893c0cd2)

Part-of: <!1694>

If the monitor configuration changed, even though the streamed monitor
didn't change, we'd still fail to continue streaming, as we failed to
update the stage watchers, meaning we wouldn't be notified about when
the stage views were painted.

Fix this by reattaching the stage watches, i.e. update the painted
signalling listeners to listen to the right views, when monitor changes
happens.

(cherry picked from commit e877b06f)

Part-of: <!1694>

(cherry picked from commit 9f6a4416)

Part-of: <!1694>

An extension can by accident cause us to end up in a state where we try
to add the same window to a workspace twice. When this happens we
shouldn't crash, but instead complain loudly.

Closes: #992
Related: gnome-shell-extensions!157
(cherry picked from commit b55b2666)

Part-of: <!1694>

Make it easier to find out what went wrong with `migrated_data` by
having it included in the debug logs.

Closes: <#1011>
(cherry picked from commit 180e6251)

Part-of: <!1694>

`g_free()` alone can't help if the value it gets is `NULL` + the offset
of the struct members.

This prevents gnome-shell from segfaulting if `monitors.xml` contains
invalid XML.

Closes: <#1011>
(cherry picked from commit 88647ae2)

Part-of: <!1694>

Makes sure that monitor specs which may be read from EDID data do not
contain characters that are invalid in XML. Makes it possible to restore
monitor configs of monitor models with characters such as '&' in them.

To make this change not break any tests, the sample monitor configs need
to be adjusted as well. Apostrophes don't strictly have to be escaped in
XML text elements. However, we now do escape the elements in
`<monitorspec>` specifically.

Closes: <#1011>
(cherry picked from commit 70cdd720)

Part-of: <!1694>

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.

gnome-shell#2467

Part-of: <!1676>
(cherry picked from commit 81f36948)

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.

gnome-shell#2467

Part-of: <!1676>
(cherry picked from commit e7b58c23)

Update NEWS.

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: <!1655>

(cherry picked from commit 98ef6d0d)

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Part-of: <!1668>

(cherry picked from commit d439501f)

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: <!1561>

(cherry-picked from commit ed87937f)

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: <!1561>

(cherry-picked from commit e5b07138)

Extract some boilerplate into new functions for next patch.

No functional change intended.

Part-of: <!1561>

(cherry-picked from commit 45a9c386)

This adds a test case for
#862 that checks that
hiding a dialog where its parent is not yet shown doesn't trigger any
asserts or crashes.

(cherry picked from commit c94d9293)

Part-of: <!1650>

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: <!1650>

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: #862
(cherry picked from commit afa43154)

Part-of: <!1650>

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.

#1407Signed-off-by: Aleksandr Mezin <mezin.alexander@gmail.com>


(cherry picked from commit 4f544b63)

Part-of: <!1638>

Update NEWS.

The API allows for invalid barriers to be created; in an X11 session,
this could result in involutary early exit, so guard against those with
soft asserts. These will be logged in the journal as warnings, but will
avoid the crash unless compiled out.

Note that this doesn't fix the bug, it just makes it more detectable.

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1901610


(cherry picked from commit f5949af0)

Part-of: <!1613>

Unconditionally setting has_touchscreen to check_touch_mode
when a new device gets added leads to has_touchscreen becoming
false when during runtime e.g. an USB keyboard gets plugged in.

Fix this by setting has_touchscreen to TRUE when check_touch_mode
is TRUE and leaving it alone otherwise.

!1506
(cherry picked from commit 6c240dc8)

Part-of: <!1610>

xkb recently gained support for user-specified keymaps, which means we
can no longer assume that the configuration data is necessarily fully
complete or correct; and the configuration language is quite a labyrinth,
so it's easy to get wrong. If setting the keymap fails, leave it in
whatever state it previously had, since that seems preferable to crashing
with a NULL pointer dereference.

Resolves: #1555Signed-off-by: Simon McVittie <smcv@debian.org>


(cherry picked from commit 60f647df)

Part-of: <!1609>