For a description on the new libinput API see here:
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/139

For a description of the new protocol event see here:
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72/



The new events use 120 as baseline to represent a logical scroll unit (one
wheel detent). Windows has been using that value since Vista now, it's copied
from there.

The libinput events should be considered separate event streams, i.e for wheel
events we now get *both an AXIS and an AXIS_WHEEL event. This is for
technical reasons, the new and old events cannot always be lined up with the
data the hw provides.

In mutter we rely on libinput to always give us AXIS_WHEEL events even on
kernels where it's not supported (pre 5.0). All we have to do then  is treat
the new AXIS_WHEEL events as smooth scroll events and done.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Jonas Ådahl authored Apr 03, 2020 and Georges Basile Stavracas Neto committed Apr 03, 2020

This fixes an issue where a non-maximized screen casted window would be
stretched to fill the whole screen cast stream, instead of just the crop
that corresponds to the current window size.

GNOME/mutter!1174

It isn't immediately obvious that this is impossible, because there's some
"action at a distance" going on with framebuffers that have their size
set lazily, after their textures get allocated; so let's make this a
critical warning rather than crashing.

In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.

Workaround for <GNOME/gnome-shell#2538>.

GNOME/mutter!1172



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

A texture with no pixels isn't a useful thing to have, and breaks
assumptions elsewhere. For example, CoglFramebuffer assumes that after
a texture has been allocated, it will have width and height both greater
than 0.

In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.

Workaround for <GNOME/gnome-shell#2538>.

GNOME/mutter!1172



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

This is the same case of the layer node: a CoglPipeline field that
is not called 'pipeline' makes it harder to figure out what it
really is.

GNOME/mutter!1167

Use the non-deprecated cogl_texture_2d_new_with_size() function to create
the texture backing the FBO, and set it to pre-multiplied before allocating
it.

GNOME/mutter!1167

Both the valid and the error code paths end up unreffing
the texture. Move the unref to the shared code path.

GNOME/mutter!1167

It is not used anywhere beyond the initializer, and won't be
used later on.

GNOME/mutter!1167

So it clearly reads what it actually is.

GNOME/mutter!1167

Disabling a click action after a button-press but before a
button-release is captured makes ClutterClickAction connect to
captured-event and never disconnect.

This change fixes it by making sure the captured-event is only
processed if the action is still enabled, otherwise releasing
the action (reset state) and propagating the event.

GNOME/mutter!1170

Jonas Ådahl authored Mar 31, 2020 and Georges Basile Stavracas Neto committed Apr 01, 2020

If we would, we'd miss popping the framebuffer from the pant context
framebuffer stack.

GNOME/mutter!1166

Jonas Ådahl authored Mar 31, 2020 and Georges Basile Stavracas Neto committed Apr 01, 2020

Nothing should ever disable an actor modifier (e.g. effect) during the
paint sequence, nor should any actor be set or unset on it. If this
would happen, log warnings so that it can be tracked down.

GNOME/mutter!1166

GNOME/mutter!1168

Picking now only happens on allocated actors, but the
callback in the actor-pick test is not waiting for the
stage to run an allocation cycle. Ideally, we'd wait
for this cycle, but for now, forcing an allocation works
as well.

Allocate the overlay actor in the actor-pick test.

GNOME/mutter!1169

They're evil.

GNOME/mutter!1169

Andre Magalhaes authored Mar 31, 2020 and Georges Basile Stavracas Neto committed Mar 31, 2020

When selecting the pick regions for an actor we were not considering
whether the actor was allocated and that was causing issues where the
preferred width/height of the actor was used when deciding whether
the actor should be considered as a pick target.

Check if the actor has a valid allocation, in addition to being mapped
and being in pick mode, in clutter_actor_should_pick_paint().

GNOME/mutter!1169

Officially start the next development cycle \o/

This reverts commit 52e5d6fc.

Update NEWS.

Robert Mader authored Mar 30, 2020 and Georges Basile Stavracas Neto committed Mar 30, 2020

Normally we bail out in `sync_actor_geometry()`. The comment there
states:
```
Normally we want freezing a window to also freeze its position; this allows
windows to atomically move and resize together, either under app control,
or because the user is resizing from the left/top. But on initial placement
we need to assign a position, since immediately after the window
is shown, the map effect will go into effect and prevent further geometry
updates.
```

The signal for the initial sync originates in `MetaWindow` though and predates
`xdg_toplevel_set_maximized`, which again calls `meta_window_force_placement`,
triggering the signal too early. As a result, Wayland clients that start up
maximized have a wrong map animation, starting in the top-left corner.

In order to fix this without changing big parts of the geometry logic and risking
regressions, force the initial sync again before mapping.

Solution suggested by Jonas Ådahl.

GNOME/mutter!1164

The function can get called without valid surface role, e.g. from
`zwp_xwayland_keyboard_grab_manager_grab()`.

Debugged by @piegamesde

Fixes GNOME/mutter#1147

Christian Rauch authored Mar 29, 2020 and Christian Rauch committed Mar 29, 2020

GNOME/mutter!1163

Carlos Garnacho authored Mar 29, 2020 and Carlos Garnacho committed Mar 29, 2020

Like ed10aea4, but for color glyphs. Since they do use the alpha
component from the given color.

GNOME/mutter!1161

Florian Müllner authored Mar 28, 2020 and Jonas Ådahl committed Mar 29, 2020

cogl_object_[get|set]_value_object() are annotated as [get|set]-value-func
for objects and primitives, so they must be visible for any derived types
to be usable from introspection.

GNOME/mutter#1146

Florian Müllner authored Mar 28, 2020 and Jonas Ådahl committed Mar 29, 2020

Obsolete since commit 6885c377.

GNOME/mutter#1146

Carlos Garnacho authored Mar 27, 2020 and Carlos Garnacho committed Mar 29, 2020

IBusInputContext/ClutterInputFocus/GtkIMContext all go for offset+len
for their ::delete-surrounding signals, with offset being a signed int
(neg. to delete towards left of selection, pos. to delete towards right
of selection) and len being an unsigned int from the offset (and
presumably, skipping the current selection).

The text-input protocols however pass in this event two unsigned integers,
one being the length of text to delete towards the left of the selection,
and another the length of text to delete towards the right of the selection.

To translate properly these semantics, positive offsets shouldn't account
for before_length, and negative offset+len shouldn't account for after_length.
The offset/length approach may of course represent deletions that are
detached from the current cursor/selection, we simply delete the whole range
from the cursor/selection positions then.

GNOME/mutter!517

Takao Fujiwara authored Aug 15, 2019 and Carlos Garnacho committed Mar 29, 2020

The input method can assign a negative value to
clutter_input_method_delete_surrounding() to move the cursor to the left.
But Wayland protocol accepts positive values in delete_surrounding() and
GTK converts the values to the negative ones in
text_input_delete_surrounding_text_apply().

GNOME/mutter#539

Jonas Dreßler authored Mar 28, 2020 and Jonas Dreßler committed Mar 28, 2020

GObject recommends to break references to other objects on dispose
instead of finalize, also we want to release the pressed virtual buttons
as early as possible if we know the object is getting destroyed.

So release the pressed buttons and unref our virtual
MetaInputDeviceNative when the dispose vfunc is called, which also
allows us to release the buttons immediately from javascript instead of
waiting for the garbage collector by calling run_dispose() on the
object.

GNOME/mutter!1157

In commit d846fabd we moved to using the override color alpha, however
it was missed that the actor opacity is transferred to the PangoRenderer
through the default color alpha, and the reason it was used there.

We actually want to factor in both alpha values, in order to respect
both foreground color alpha and actor opacity. This is done on the
unpremultiplied color, so we just need to change the alpha value.

Fixes effects on text actors that involve actor opacity.

GNOME/mutter!1158

pango_renderer_get_alpha() returns 0 to indicate that the alpha value
should be inherited from the environment, but we are passing it on
(and therefore making the text fully translucent).

Instead, make the text fully opaque as expected.

GNOME/mutter!1156

This allows us to screencast any window continuously, even
without it being visible. Because it's still being painted,
clients continue to receive frame callbacks, and people
are happy again.

GNOME/mutter!1129

This will allow us to continue painting actors that are
outside the visible boundaries of the stage view.

GNOME/mutter!1129

Just like what's done for monitor screencasting. Unfortunately, there's
no mechanism to share fences with PipeWire clients yet, which forces
us to guarantee that a frame is completed after blitting.

GNOME/mutter!1129

A regression compared to the old code, we're not drawing the cursor
when on EMBEDDED mode.

Blit the cursor to the screencast framebuffer when on EMBEDDED mode.

GNOME/mutter!1129

MetaScreenCastWindowStreamSrc connects to the "damaged" signal of
MetaWindowActor. This signal is not exactly tied to the paint cycle
of the stage, and a damage may take quite a while to arrive when
a client doesn't want to draw anything. For that reason, the window
screencast can start empty, waiting for a damage to arrive.

Ensure at least one frame is recorded when enabling the window stream.

Fixes: GNOME/mutter#1097

GNOME/mutter!1129

cogl_framebuffer_push_rectangle_clip() acts on the current modelview
matrix. That means the result of clipping then translating will be
different of the result of translating then clipping.

What we want for window screencasting is the former, not the latter.
Move the translation code (and associated) to after clipping.

Fixes: GNOME/mutter#1097

GNOME/mutter!1129

Move the CoglColor assignment right above the cogl_framebuffer_clear() call,
and let these wonderful partners together to delight us with an easier to
read code.

GNOME/mutter!1129

Use the override color alpha, if set.

GNOME/mutter!1155

Instead of hardcoding 0xff as alpha, forward this attribute.

GNOME/mutter!1155

Jonas Dreßler authored Mar 19, 2020 and Jonas Ådahl committed Mar 27, 2020

Fix a regression that got introduced with
c483b52d where we started passing the
redraw_clip to paint_stage() instead of creating a temporary view_region
for unclipped redraws: In case we detect an invalid buffer age, we fall
back to doing an unclipped redraw after we passed the first check
setting up may_use_clipped_redraw. That means we didn't reset the
redraw_clip to the view_rect, and we're now going to redraw the stage
using the original redraw clip even though we're swapping the full
framebuffer without damage.

To fix that, check for the buffer age before setting up the
fb_clip_region and the redraw_clip and set may_use_clipped_redraw to
FALSE if the buffer age is invalid, too. This ensures the redraw_clip is
always going to be correctly set to the view rect when we want to force
a full redraw.

Fixes GNOME/mutter#1128