https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1419

The gamma curve remains valid even if the CRTC is turned off. As such,
there is no need to clear it and doing so breaks reading the gamma curve
while the screens are turned off using DPMS.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1419

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1392

When removing a device that has been just marked as the last in use, we may
try to notify that a NULL device is the last one.

This is not supported, as both update_last_device() and the clients of the
"::last-device-changed" signal are assuming that the last device is always
a valid ClutterInputDevice.

So let's avoid erroring, and stop the idle when clearing the current device.

Related to: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371

(cherry picked from commit 07568267)

When a device is removed we perform some actions such as stopping the
"::last-device-changed" signal emission and unsetting the current device.
And we want to be sure that these actions happen after all the
device-removed operations are sorted out.

Related to: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371

(cherry picked from commit 5730b998)

Add clutter device added and removed events to allow processing of them as
it happens in the backends, queuing them and performing actions in order.

This allows not to loose any event that is performed just before removing or
disabling a device, and still process the events in order in the event
queue.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371

(cherry picked from commit 928b32b1)

Clutter device events are special events coming from the backend when an
input device is added or removed.

When such events are processed, we should make the seat to handle them by
calling vfunc that can be implemented by each backend and eventually
emitting the appropriate signal.

If a device is removed, we can also safely dispose it, as it can be
considered stale at this point.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371

(cherry picked from commit cf67c54f)

When a device is removed from the seat the events that this device may have
emitted just before being removed might still be in the stage events queue,
this may lead a to a crash because:

Once the device is removed, we dispose it and the staling event is
kept in queue and sent for processing at next loop.
During event processing we ask the backend to update the last device
with the disposed device
The device is disposed once the events referencing it, are free'd
The actual last device emission happens in an idle, but at this point
the device may have been free'd, and in any case will be still disposed
and so not providing useful informations.

To avoid this, once a device has been added/removed from the seat, we queue
ClutterDeviceEvent events to inform the stack that the device state has
changed, preserving the order with the other actual generated device events.
In this way it can't happen that we emit another event before that the
device has been added or after that it has been removed.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345

(cherry picked from commit 9db289b4)

Delay the addition and removal of devices using ClutterDeviceEvent's so that
they are processed following the libinput event order, and that we don't
have to flush the events on removal.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371

(cherry picked from commit e44c42f2)

Like it's done for the pointer in other places. Without a stage assigned,
some bits (like IM handling) may end up with events ignored, and misbehave.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1413

(cherry-picked from commit 3a273028)

We only did this if we weren't currently doing an interactive resize,
but since the finish_move_resize() is not the actual interactive resize
but the acknowledgment of the configure event that was emitted as a
result, we shouldn't limit ourself to the same flags used during resize.

This fixes temporarly "stuck" position of attached modal dialogs while
they are being resized.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1163

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1446
(cherry picked from commit db796732)

We could call clutter_stage_schedule_update() and it wouldn't actually
schedule anything, as the master frame clock only tries to reschedule if
1) there is an active timeline, 2) there are pending relayouts, 3) there
are pending redraws, or 4) there are pending events. Thus, a call to
clutter_stage_schedule_update() didn't have any effect if it was called
at the wrong time.

Fix this by adding a boolean state "needs_update" to the stage, set on
clutter_stage_schedule_update() and cleared on
_clutter_stage_do_update(), that will make the master clock reschedule
an update if it is TRUE.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
(cherry picked from commit b8003807)

It's effectively used by mutter by abusing a ClutterTimeline to scedule
updates.  Timelines are not really suited in places that is done, as it
is really just about getting a single new update scheduled whenever
suitable, so expose the API so we can use it directly.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
(cherry picked from commit 99c9a14b)

On X11 we don't update the texture in certain circumstances, such as if
the surface is a fullscreen unredirect, or doesn't have a Pixmap. On
Wayland we only want to avoid updating the texture if there is no
texture, but as this is handled implicitly by MetashapedTexture, we
don't need to try to emulate the X11-y conditions in the generic layer
and instead just have the implementations handle update processing
themself.

This doesn't have any functional changes, but removes a vfunc from
MetaSurfaceActorClass.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
(cherry picked from commit 510cbef1)

Move Wayland support (i.e. the MetaWaylandCompositor object) made to be
part of the backend. This is due to the fact that it is needed by the
backend initialization, e.g. the Wayland EGLDisplay server support.

The backend is changed to be more involved in Wayland and clutter
initialization, so that the parts needed for clutter initialization
happens before clutter itself initialization happens, and the rest
happens after. This simplifies the setup a bit, as clutter and Wayland
init now happens as part of the backend initialization.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
(cherry picked from commit 1571f807)

This is so that it can be retrieved later without going via the global
singleton.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
(cherry picked from commit e8b09df8)

Don't tie frame callbacks to actor painting, as it may end up in
situations where we miss sending frame callbacks when we should have. An
example of this is when a surface is partially off screen, and then
reports damage that is fully off screen. When this happen, we are likely
not to repaint anything, thus we won't send any frame callbacks even
though it's "suitable" for rendering again, as the surface is not on a
separate workspace or fully obscured.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/817
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1152

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
(cherry picked from commit 066bc598)

meta_barrier_destroy is responsible for removing the extra
reference added in meta_barrier_constructed.

Unfortunately, it fails to do this because of a misplaced early
return statement.

This commit removes the spurious return.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1449
(cherry picked from commit 97f10a0d)

When a MetaBarrier is first created it allocates a backend
impl object which does the actual heavy lifting.

Unfortunately, that backend object is never freed.

This commit ensures the implementation gets freed when
the barrier object is freed.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1451
(cherry picked from commit 1e78d90a)

When we resize a window we send it configure requests with size
suggestion. Some clients, e.g. gnome-terminal will limit its size to a
discrete set given the font size resulting in the size often not being
respected completely, but used as a hint to find a size as large as
possible but not larger than the configured size.

When doing an interactive resize dragging the right or top side of a
window, this caused issues with the configured window size not matching
the one used by the client, as the configured position wouldn't be
correct for the actual size. Fix this by offsetting the position given
the size mismatch offset, making the position again in sync with the
size.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1447

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1477


(cherry picked from commit 8bdd2aa7)

Use ClutterEvent* and clutter_event_new() to always allocate events.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1460
(cherry picked from commit 66640446)

Use ClutterEvent* and clutter_event_new() to always allocate events.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1460
(cherry picked from commit 16139efa)

We only update the last device from actual input interaction here,
avoid this pair of events. This is specially nasty with
CLUTTER_DEVICE_REMOVED, since the device we're notifying upon will be
disposed soon after emission.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1460
(cherry picked from commit 86fa8aff)

If the last updated device is removed, ensure that it does result in
a ::last-device-changed with a NULL device.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1460
(cherry picked from commit 089be8b7)

Wayland clients using buffers without alpha channel are not expected to
set an opaque region. However, we rely on the opaque region for the fast
painting path in `MetaShapedTexture`.

Thus, make sure to always set an opaque region internally in those cases.
For X11 clients, wo do so already.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1463

(cherry picked from commit 71f03a71)

This reverts the commits 372d73e2 and 1d200452 - the special
case for alpha-less textures could only happen on Wayland, but now
the opaque region is also set in those cases.

This commit saves us some allocations, simplifies the logic a bit and
makes sure culling uses the same opaque region as our painting paths.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1463

(cherry picked from commit 78592cbc)

Update NEWS.

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.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1360

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.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1225


(cherry picked from commit 79e5ec57)

Analogous to commit 8bdd2aa7, calculate the size missmatch offset
also when finishing a resize.

Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/396

(cherry picked from commit 554f7984)

Olivier Fourdan authored Oct 13, 2020 and Robert Mader committed Oct 19, 2020

On interactive resize, mutter calculates the difference in size based on
the pointer location and relies on window constraints to ensure the
minimum size is honored.

Wayland however does asynchronous window configuration, meaning that not
checking for size hints early enough may lead to the window moving as
the locations was initially computed on a size which will be invalidate
by the client eventually.

Make sure to respect the client size hint on update_resize() so that we
don't end up with a window moving unexpectedly when the client
eventually acked the configuration.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1495

(cherry picked from commit 03c69ed8)

Olivier Fourdan authored Oct 15, 2020 and Robert Mader committed Oct 19, 2020

The XSizeHints set by X11 clients give a hint to the window manager
about size increment, aspect ratio, base, minimum and maximum size, etc.

When an X11 client changes those values, there is a good chance that it
will affect the actual window size in some way, and mutter rightfully
queue a window resize in that case.

However, mutter does not check if any of the hints have actually changed
and unconditionally queue a window resize whenever a client changes its
WM_NORMAL_HINTS property.

That can be a problem when a zealous client such as xterm decides to
update its WM_NORMAL_HINTS property on resize, because in return mutter
will queue a non-user driven resize in the middle of user-driven events,
hence defeating the purpose of the META_MOVE_RESIZE_USER_ACTION flag.

To avoid that issue, make mutter a bit smarter and avoid queuing a
window resize if the XSizeHints haven't actually changed.

https://gitlab.gnome.org/GNOME/mutter/-/issues/543

(cherry picked from commit deaa9480)

Olivier Fourdan authored Oct 14, 2020 and Robert Mader committed Oct 19, 2020

Bug 448183 fixed an issue with _NET_WM_MOVERESIZE_WINDOW not moving a
window by basing the resize on the current (new) rectangle instead of
the original rectangle.

While this fixes the issue with _NET_WM_MOVERESIZE_WINDOW, this also
causes windows with a size increment to move when the resize also
implies a move, such windows might drift while resizing.

Make sure to use the current rectangle for non-interactive resizes only.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/543

(cherry picked from commit 7ab3eac0)

Otherwise we might run into a use-after-free and crash on (virtual)
device removal:

 Invalid read of size 8
   at clutter_input_device_get_device_type (clutter-input-device.c:811)
   by update_last_device (meta-backend.c:1282)
   by g_main_dispatch (gmain.c:3325)
   by g_main_context_dispatch (gmain.c:4016)
   by g_main_context_iterate.constprop.0 (gmain.c:4092)
   by g_main_loop_run (gmain.c:4290)
   by meta_run_main_loop (main.c:708)
   by meta_run (main.c:723)
   by main (main.c:550)
 Address is 32 bytes inside a block of size 504 free'd
   at free (vg_replace_malloc.c:538)
   by g_type_free_instance (gtype.c:1939)
   by clutter_event_free (clutter-event.c:1420)
   by _clutter_stage_process_queued_events (clutter-stage.c:830)
   by handle_frame_clock_before_frame (clutter-stage-view.c:1064)
   by clutter_frame_clock_dispatch (clutter-frame-clock.c:405)
   by frame_clock_source_dispatch (clutter-frame-clock.c:456)
   by g_main_dispatch (gmain.c:3325)
   by g_main_context_dispatch (gmain.c:4016)
   by g_main_context_iterate.constprop.0 (gmain.c:4092)
   by g_main_loop_run (gmain.c:4290)
   by meta_run_main_loop (main.c:708)
   by meta_run (main.c:723)
 Block was alloc'd at
   at malloc (vg_replace_malloc.c:307)
   by g_malloc (gmem.c:106)
   by g_slice_alloc (gslice.c:1025)
   by g_slice_alloc0 (gslice.c:1051)
   by g_type_create_instance (gtype.c:1839)
   by g_object_new_internal (gobject.c:1939)
   by g_object_new_valist (gobject.c:2264)
   by g_object_new (gobject.c:1782)
   by meta_input_device_native_new_virtual (meta-input-device-native.c:1365)
   by meta_virtual_input_device_native_constructed (meta-virtual-input-device-native.c:705)
   by g_object_new_internal (gobject.c:1979)
   by g_object_new_valist (gobject.c:2264)

Suggested-by: Carlos Garnacho <carlosg@gnome.org>
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1529
(cherry picked from commit 8711d8d5)

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

At startup, libinput dispatch is called from the MetaSeatNative
constructed callback.

That means that we may get libinput events even before the default seat
is set.

In turn, processing those events may trigger the use the default seat
while it's still not set yet, and cause a crash of gnome-shell/mutter
at startup.

A simple reproducer for this is to start gnome-shell/mutter with a
tablet connected and the stylus in proximity, the proximity event will
cause gnome-shell/mutter to crash at startup.

To avoid that issue, avoid dispatching libinput events early from the
MetaSeatNative constructed callback, those events will eventually get
processed when the seat and the backend are all setup.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1501
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
(cherry picked from commit c618b8a0)

Not calling libinput dispatch in the backend constructor defeats the
logic in post init as the device added events have not been processed
yet.

So instead of trying to guess the cursor initial visibility, simply
update it along when devices get added.

Additional benefit, we do not need to walk the all device list looking
for touchscreens anymore, we just need to check the device being added
since the current logic is to hide the cursor as soon as a touchscreen
is found.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
(cherry picked from commit 9b881729)

If a subsurface is equal to or an ancestor of the parent surface
we currently crash. Check for that case and terminate the client.

Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1521

(cherry picked from commit 4e9a67ac)

These devices in x11 are "disabled", that doesn't mean we should refrain
from notifying about them.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1476
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1496

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1553

(cherry-picked from commit 34710eab)

This is similar to commit b9e5a2d6, but for the X11 backend.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1466
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1495

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1553

(cherry-picked from commit b6211bb6)

Jonas Ådahl authored Nov 16, 2020 and Robert Mader committed Nov 16, 2020

Instead of aborting with an error, display a half transparent gray
square instead of cursors and log a warning in the journal, allowing the
user to fix their system withotu having to rely on switching to a TTY.

It will be immediately obvious the cursor is silly looking, which will
be a better hint than just aborting.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1428
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1563>

(cherry picked from commit 83360a4a)

Fixes 8f5ea43c

Commit e28c1ab4 added a hints_have_changed() function to only
recalculate windows features when the WM_NORMAL_HINTS change.

That function hints_have_changed() however was merely checking whether
the various XSizeHints flags where flipped, which is not sufficient
because the hints may remain the same while the actual values are
changed.

Not checking for the actual value differences would prevent some windows
from being able to switch fullscreen.

Improve the helper function hints_have_changed() to check not only for
flags being flipped, but also for the values being changed for each
relevant XSizeHints flags being set currently.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1534
(cherry picked from commit 06e604cf)

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

This applies the optimizations from 0c55e87d to serveral
similar places in region-utils.

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

(cherry picked from commit 91c94162)

As you should always do. Using the `float` variant even if `scale` is
a `double` as values passed in are potentially computed at `float`
precission.

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

(cherry picked from commit 09b1bbb1)

Daniel van Vugt authored Nov 18, 2020 and Robert Mader committed Nov 19, 2020

Because it gets destroyed (unreferenced) immediately after that.
This avoids a deep copy of potentially kilobytes of data.

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

(cherry picked from commit 32b68478)

Christian Rauch authored Jan 04, 2020 and Robert Mader committed Nov 23, 2020

https://gitlab.gnome.org/GNOME/mutter/merge_requests/801#note_676932
(cherry picked from commit 3faea853)

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

Olivier Fourdan authored Nov 23, 2020 and Robert Mader committed Nov 23, 2020

Commit 03c69ed8 ("Do not go past size hints on resize") was meant to
ensure the size hints set by the client would be honored during resize,
as going past those values could cause the window to move on resize.

However, it did so by calling ensure_size_hints_satisfied() which works
with the frame rect rather than the client rect. As a result, the
minimum size enforced would end up being larger than expected with
client-side decorations.

Use meta_window_maybe_apply_size_hints() instead which automatically
adjusts for client size.

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

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

Update to upstream version '3.36.7'
with Debian dir 6385813546f4047a8e8ea9a1e774eac1a879103c

Update to upstream version '3.36.7+git20201123'
with Debian dir 3f3fcee7615bb8f209cf81fbad7ef01d23877d3a

No symbol is a public one