Jonas Ådahl authored Oct 09, 2019 and Robert Mader committed Nov 24, 2020

A frame callback without damage is still expected to be responded to.
Implement this by simply queuing damage if there are any frame callbacks
requested and there is no damage yet. If there already is damage,
we'll be queued already, but with more correct damage. Without we simply
need to make sure we flush the callbacks if any area of surface is not
occluded.

Fixes: #457

!839

(cherry picked from commit d49d10b1)

Part-of: <!1570>

Ray Strode authored Apr 30, 2020 and Jonas Ådahl committed Oct 15, 2020

cally_actor_action_do_action leaks a state set object in the
case where the actor is defunct, insensitive, or hidden.

This commit plugs the leak.

!1225


(cherry picked from commit 79e5ec57)

Jonas Ådahl authored Sep 11, 2020 and Georges Basile Stavracas Neto committed Sep 28, 2020

The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.

This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.

Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.

This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.

Jan Alexander Steffens authored Oct 20, 2019 and Marco Trevisan committed Sep 23, 2020

The eglext.h shipped by libglvnd does not include the Mesa extensions,
unlike the header shipped in Mesa.

Fixes #876

(cherry-picked from commit a444a4c5)

When closing the lid of a laptop, we reconfigure all the monitors in order
to update the CRTCs and (if enabled) the global UI scaling factor.

To do this, we try first to reuse the current configuration for the usable
monitors, but if we have only monitor enabled and this one is on the laptop
lid we just end up creating a new configuration where the primary monitor is
the laptop one (as per find_primary_monitor() in MetaMonitorConfigManager),
but ignoring the user parameters.

In case the user selected a different resolution / scaling compared to the
default one, while the laptop lid is closed we might change the monitors
layout, causing applications to rescale or reposition.

To avoid this, when creating the monitors configuration from the current
current state, in case we have only one monitor available and that one is
the laptop panel, let's just reuse this configuration.

!1200

(cherry-picked from commit e4851667)

Florian Müllner authored Mar 21, 2020 and Marco Trevisan committed May 05, 2020

Commit cda95790 fixed a corner case when setting the initial workspace
state of transient windows, but it still missed a case:

should_be_on_all_workspaces() returns whether the window should be on all
workspaces according to its properties/placement, but it doesn't take
transient relations into account.

That means in case of nested transients, we can still fail the assert:

 1. on-all-workspaces toplevel
 2. should_be_on_all_workspaces() is TRUE for the first transient's parent,
    as the window from (1) has on_all_workspaces_requested == TRUE
 3. should_be_on_all_workspaces() is FALSE for the second transient's
    parent, as the window from (2) is only on-all-workspace because
    of its parent

We can fix this by either using the state from the root ancestor
instead of the direct transient parent, or by using the parent's
on_all_workspaces_state.

The latter is simpler, so go with that.

#1083

Carlos Garnacho authored Aug 05, 2019 and Marco Trevisan committed May 05, 2020

Commit 09bab98b tried to avoid several workspace changes while in
window construction, but it missed a case:

If we have a window on a secondary monitor with no workspaces enabled
(so it implicitly gets on_all_workspaces = TRUE without requesting it)
and trigger the creation of a second window that has the first as
transient-for, it would first try to set the first workspace than the
transient-for window and then fallback to all/current workspace.

After that commit we only try to set the same workspace than the
transient-for window, but it gets none as neither is on a single workspace,
nor did really request to be on all workspaces.

Fixes crashes when opening transient X11 dialogs in the secondary monitor.

!714

Carlos Garnacho authored Jul 19, 2019 and Marco Trevisan committed May 05, 2020

We first set the workspace to the transient-for parent's, and then
try to set on the current workspace. If both happen, we double the
work on adding/removing it from the workspace, and everything that
happens in result.

Should reduce some activity while typing on the Epiphany address
bar, as the animation results in a number of xdg_popup being created
and destroyed to handle the animation.

#556

When a touch sequence was rejected, the emulated pointer events would be
replayed with old timestamps. This caused issues with grabs as they
would be ignored due to being too old. This was mitigated by making sure
device event timestamps never travelled back in time by tampering with
any event that had a timestamp seemingly in the past.

This failed when the most recent timestamp that had been received were
much older than the timestamp of the new event. This could for example
happen when a session was left not interacted with for 40+ days or so;
when interacted with again, as any new timestamp would according to
XSERVER_TIME_IS_BEFORE() still be in the past compared to the "most
recent" one. The effect is that we'd always use the `latest_evtime` for
all new device events without ever updating it.

The end result of this was that passive grabs would become active when
interacted with, but would then newer be released, as the timestamps to
XIAllowEvents() would out of date, resulting in the desktop effectively
freezing, as the Shell would have an active pointer grab.

To avoid the situation where we get stuck with an old `latest_evtime`
timestamp, limit the tampering with device event timestamp to 1) only
pointer events, and 2) only during the replay sequence. The second part
is implemented by sending an asynchronous message via the X server after
rejecting a touch sequence, only potentially tampering with the device
event timestamps until the reply. This should avoid the stuck timestamp
as in those situations, we'll always have a relatively up to date
`latest_evtime` meaning XSERVER_TIME_IS_BEFORE() will not get confused.

!886

We need to manipulate an X11 grab when a touch sequence ends; move that
logic to where it belongs - in the X11 backend.

!886

Starting with commit 2db94e2e we try to focus a fallback default focus window
if no take-focus window candidate gets the input focus when we request it and
we limit the focus candidates to the current window's workspace.

However, if the window is unmanaging, the workspace might be unset, and we could
end up in deferencing a NULL pointer causing a crash.

So, in case the window's workspace is unset, just use the currently active
workspace for the display.

Closes #687

!688

(cherry picked from commit 5ca0ef07)

Jonas Ådahl authored Oct 11, 2018 and Marco Trevisan committed Jul 08, 2019

Switch-configs are only to be used in certain circumstances (see
meta_monitor_manager_can_switch_config()) so when ensuring
configuration and attempting to create a linear configuration, use the
linear configuration constructor function directly without going via the
switch config method, otherwise we might incorrectly fall back to the
fallback configuration (only enable primary monitor).

This is a regression introduced by 6267732b.

Fixes: #342


(cherry picked from commit 149e4d69)

Daniel Drake authored Aug 30, 2018 and Marco Trevisan committed Jul 08, 2019

When constructing MetaMonitorsConfig objects, store which type
of switch_config they are for (or UNKNOWN if it is not such
type of config).

Stop unconditionally setting current_switch_config to UNKNOWN when
handling monitors changed events. Instead, set it to the switch_config
type stored in the MonitorsConfig in the codepath that updates logical
state. In addition to being called in the hotplug case along the same
code flow that generates monitors changed events, this is also called
in the coldplug case where a secondary monitor was connected before
mutter was started.

When creating the default linear display config, create it as a
switch_config so that internal state gets updated to represent
linear mode when this config is used.

The previous behaviour of unconditionally resetting current_switch_config
to UNKNOWN was breaking the internal state machine for display config
switching, causing misbehaviour in gnome-shell's switchMonitor UI when
using display switch hotkeys. The lack of internal tracking when the
displays are already in the default "Join Displays" linear mode was
then causing the first display switch hotkey press to do nothing
(it would attempt to select "Join Displays" mode, but that was already
active).

Fixes: #281
!213


(cherry picked from commit 6267732b)

Marco Trevisan authored Jun 25, 2019 and Marco Trevisan committed Jul 08, 2019

Related to #652

Marco Trevisan authored Jun 25, 2019 and Marco Trevisan committed Jul 08, 2019

After commit 2e64457f we destroy window actors as part of compositor
destruction, however this might emit 'actor-removed' signals on window groups
that the shell could use to access to resources that are already free'd at this
point (like the destroyed screen, in gnome-shell's Panel._updateSolidStyle()).

So, move the actor destructions under in a new function and destroy the window
actors as part of compositor unmanage step, just after that all the windows are
unmanaged (as they need to have an actor around).

Fixes #652

As per commit f71151a5 we focus an input window if no take-focus-window accepts
it. This might lead to an infinite loop if there are various focusable but
non-input windows in the stack.

When the current focus window is unmanaging and we're trying to focus a
WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input
window in the stack.

However, if an application (such as the Java ones) only uses non-input
WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This
might lead to a state where no window is focused, or a wrong one is.

So, instead of only focus the first eventually input window available, try to
request to all the take-focus windows that are in the stack between the
destroyed one and the first input one to acquire the input focus.
Use a queue to keep track of those windows, that is passed around stealing
ownership, while we protect for unmanaged queued windows.

Also, reduce the default timeout value, as the previous one might lead to an
excessive long wait.

Added metatests verifying these situations.

Closes: #660
!669

(cherry picked from commit 6d8293a4)

Use a static function if a window can be the default focus window, and use such
function to return a filtered list of the stack.

!669

(cherry picked from commit 2439255f)

As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus
targets, however this might end-up in an infinite loop if there are multiple
non-input windows stacked.

So, accept any focusable window as fallback focus target even if it's a
take-focus one (that might not reply to the request).

Added a stacking test to verify this.

Closes: #660
!669

(cherry picked from commit c327b2df)

When looking for the best fallback focus window, we ignore it if it is in the
unmanaging state, but meta_stack_get_default_focus_window() does this is check
for us already.

So, ignore the redundant test.

!669


(cherry picked from commit 9aee47da)

Marco Trevisan authored May 03, 2019 and Marco Trevisan committed Jun 28, 2019

If something (i.e. gnome-shell or an extension) tries to activate an unmanaged
window, we should warn about this and avoid to perform further actions as this
could lead to a crash of mutter, since the window has not valid flags (like
workspace) set anymore at this stage.

Fixes #580

!564


(cherry picked from commit a6fc656e)

When requesting to a take-focus window to acquire the input, the client may or
may not respond with a SetInputFocus (this doesn't happen for no-input gtk
windows in fact [to be fixed there too]), in such case we were unsetting the
focus while waiting the reply.

In case the client won't respond, we wait for a small delay (set to 250 ms) for
the take-focus window to grab the input focus before setting it to the default
window.

Added a test for this behavior and for the case in which a window takes the
focus meanwhile we're waiting to focus the default window.

!307
(cherry picked from commit f71151a5)

This will only wait for events to be dispatched and processed by the server
without waiting for client processing.

Reuse the code for the wait command too.

!307
(cherry picked from commit 6022b239)

This allows to sleep for a given timeout in milliseconds.

Rename test_case_before_redraw to test_case_loop_quit since it's a generic
function and use it for the timeout too.

!307
(cherry picked from commit d08763c1)

Ensure that we have a focused window when closing transient windows with
no-focus or no-take-focus atoms

!307
(cherry picked from commit fcb408ad)

This allows to verify which window should have the focus, which might not
be the same as the top of the stack.

It's possible to assert the case where there's no focused window using
"NONE" as parameter.

!307
(cherry picked from commit 51f9e04e)

When a window with no frame, that doesn't accept focus and that has no
take-focus atom set is destroyed, we ended up in not changing the current_focus
window, causing a crash.

Added test cases that verify this situation.

Related to #308
!307
(cherry picked from commit 2fc7760c)

Allow to set/unset WM_TAKE_FOCUS from client window.
This is added by default by gtk, but this might not happen in other toolkits,
so add an ability to (un)set this.

So fetch the protocols with XGetWMProtocols and unset the atom.

test-client now needs to depend on Xlib directly in meson build.

!307
(cherry picked from commit f2d2d473)

Under the hood, calls gtk_window_set_accept_focus in the client

!307
(cherry picked from commit e1f839f4)

When destroying a window that has a parent, we initially try to focus one of
its ancestors. However if no ancestor can be focused, then we should instead
focus the default focus window instead of trying to request focus for a window
that can't get focus anyways.

Fixes #308
(cherry picked from commit eccc791f)

Marco Trevisan authored May 17, 2019 and Marco Trevisan committed May 27, 2019

When free'ing a pipeline we destroy the BigState first and then the fragment and
vertex snippets lists using the big state pointer which is now invalid.
This causes a crash  when G_SLICE=always-malloc is set and using MALLOC_CHECK_.

So, invert the operations by free'ing the snippet lists first, and the big state
afterwards.

!581


(cherry picked from commit 7e0d1851)

Marco Trevisan authored May 17, 2019 and Marco Trevisan committed May 27, 2019

MetaWaylandSeat is allocated using g_new0(), and thus we should use g_free() to
destroy it.

!581


(cherry picked from commit 04057865)

Marco Trevisan authored May 17, 2019 and Marco Trevisan committed May 27, 2019

Fix a small leak in native renderer.

!581


(cherry picked from commit b016ff29)

Update NEWS.

Marco Trevisan authored Apr 29, 2019 and Marco Trevisan committed May 03, 2019

From this point there's not any need for the compositor to listen to signals
so we can disconnect from the stage ones we are connected to.

!556


(cherry picked from commit 3ba79961)

Marco Trevisan authored Apr 29, 2019 and Marco Trevisan committed May 03, 2019

When the compositor is destroyed we should cleanup the list of window actors we
created and destroy them.
Since all the actors are added to the window_group or top_window_group we can
just destroy these containers (together with the feedback_group), and simply
free the windows list.

This is particularly needed under X11 because before we destroy the display, we
might do some cleanups as detaching the surface pixmaps and freeing the damages
and if this happens at later point (for example when triggered by garbage
collector in gnome-shell), we might crash because the x11 dpy reference is
already gone.

Destroying the window actors instead, ensures we avoid any further call to X11
related functions and that we release the actors XServer resources.

Fixes #576


(cherry picked from commit 7718e67f)

Daniel van Vugt authored Jul 31, 2018 and Marco Trevisan committed May 03, 2019

(cherry picked from commit db5abbb2)

Andrea Azzarone authored Jul 13, 2018 and Marco Trevisan committed May 03, 2019

Keycode lookup can fail for serveral reasons, e.g. if there is no combination of
modifiers and keycodes that can produce the target keysym with the current
keyboard layout.

In case the keycode lookup fails, remap temporarily the keysym to an unused
keycodes.

Fixes: gnome-shell#109

(cherry-picked from commit e3e933c4)

Andrea Azzarone authored Jan 22, 2019 and Marco Trevisan committed Apr 30, 2019

Since e3e933c4 a keyval can be temporarily remapped to an unused keycode. Due to
some limitations in XTestFakeKeyEvent, the remapping has to be done in the first
xkb group/layout. In case there are two or more keyboard layouts enabled and the
selected keyboard layout is not the first, clutter_keymap_x11_keycode_for_keyval
will fail to retrieve the correct keycode for a remapped keyval. Let's use the
reserved_keycodes map in order to retrieve the correct keycode if needed.

Fixes: #443


(cherry picked from commit e0811ce1)

Carlos Garnacho authored May 07, 2017 and Marco Trevisan committed Jan 24, 2019

Avoids some context invalidations in cogl.

https://bugzilla.gnome.org/show_bug.cgi?id=782344


(cherry picked from commit 3c6a518d)

Carlos Garnacho authored Dec 18, 2018 and Marco Trevisan committed Jan 24, 2019

The actor-shader-effect test actors are 50px wide, but we check the 51st
pixel. This went along undetected until "clutter: Avoid rounding
compensation when invalidating 2D actors" because the paint volumes were
made slightly bigger and the shaders paint all over them (I guess nobody
noticed those actors being actually ~52px wide).

Update the test to check the middle of the opposite edge, so we keep neatly
rounded numbers.


(cherry picked from commit 1d73533f)