We'd set the capabilities to 'none', meaning all previously enabled
device classes would be disabled. That means we shouldn't re-disable
them directly after.
This ensures '..disable()' is only called once for every '..enable()'.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2657>
We traverse the whole screnegraph anyway these days in finish_layout(),
so no need for the whole "set the flag on parents even though we don't
need it" dance anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2667>
With high frequency mouse devices, we would send very many configure
events per each update cycle, which had the end result that some clients
constantly re-allocating and redrawing their buffers far too often, if
they did this in direct response to xdg_toplevel configure events.
Lets throttle the interactive resize updates to stage updates, to avoid
having these clients doing the excessive buffer reallocation.
This also removes some old legacy X11 client resize throttling, that
throttled a bit arbitrarily on 25 resizes a second; it is probably
enough to throttle on stage updates for these clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2652>
Some mice send a value slightly lower than 120 for some detents. The
current approach waits until a value of 120 is reached before sending a
low-resolution scroll event.
For example, the MX Master 3 sends a value of 112 in some detents:
detent detent
| | |
^ ^ ^
112 REL_WHEEL 224
As illustrated, only one event was sent but two were expected. However,
sending the low-resolution scroll event in the middle plus the existing
heuristics to reset the accumulator solve this issue:
detent detent
| | |
^ ^ ^ ^
REL_WHEEL 112 REL_WHEEL 224
Send low-resolution scroll events in the middle of the detent to solve
this problem.
Fix https://gitlab.gnome.org/GNOME/mutter/-/issues/2469
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2668>
There do indeed seem to be places in our own code that trigger grabs on
actors before they are realized. It was not the intention to change the
practical preconditions for GNOME 43, so make it an even lower minimum
that every caller ought to match: That the actor is attached to the stage.
Further constraining of these preconditions will have to wait until
branching for new development.
Fixes: 9c79c7234 (clutter: Only allow grabs to be created on realized actors)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2670>
The bare minimum that we can ask to an actor before creating a grab
on it is that it is realized (and thus, attached to the stage). Bail
out if that is not the case when creating a grab.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2669>
If an actor is being unrealized or otherwise unparented, it's a good
indication that its grabs are now stale and possibly harmful. Ensure
these are dropped when the actor is unparented.
This is now an unlikely event, since there is code to also dismiss
grabs when a visible grabbed actor goes unmapped. But that may be
prevented from happening, or the ordering of circumstances allow a
grab to be created and an actor destroyed without going unmapped
first. This grab dismission on unmap stays as it matches the UI-level
expectatives that an actor must be visible to be grabbed.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2475
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2669>
Previously, when scroll was received in a remote session, it was handled
as continuous scroll.
This generated issues with clients without high-resolution scroll
support as the code path in charge of accumulating scroll until 120 is
reached was not used and therefore discrete scroll events were not being
generated.
Handle scroll generated in a remote session as discrete scroll when the
source is CLUTTER_SCROLL_SOURCE_WHEEL to fix this issue.
Fix https://gitlab.gnome.org/GNOME/mutter/-/issues/2473
Fixes: 9dd6268d13 ("wayland/pointer: Send high-resolution scroll data")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2664>
In fcfe90aa, multiple for loops were replaced with
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE.
However, this substitution was not side-effect free, and introduced a
null-pointer dereference risk as shown in the example below:
Old:
for (n = g_node_first_child (surface->subsurface_branch_node);
n;
n = g_node_next_sibling (n))
{
if (G_NODE_IS_LEAF (n))
continue;
meta_wayland_surface_update_outputs_recursively (n->data);
}
n is checked for NULL during each loop in the condition expression.
Therefore, when `G_NODE_IS_LEAF (n)` is called, `n` is guaranteed not to
be NULL. Note also that g_node_first_child is also NULL-safe since it
performs a NULL check internally.
New:
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE (surface, subsurface_surface)
meta_wayland_surface_update_outputs_recursively (subsurface_surface);
=
for (GNode *G_PASTE(__n, __LINE__) = meta_get_first_subsurface_node ((surface)); \
(subsurface = (G_PASTE (__n, __LINE__) ? G_PASTE (__n, __LINE__)->data : NULL)); \
G_PASTE (__n, __LINE__) = meta_get_next_subsurface_sibling (G_PASTE (__n, __LINE__)))
In the new logic `subsurface` is still checked for NULL in the loop
condition. However, in the new loop init:
...
meta_get_first_subsurface_node (MetaWaylandSurface *surface)
...
n = g_node_first_child (surface->subsurface_branch_node);
if (!G_NODE_IS_LEAF (n))
...
The above implementation performs a `G_NODE_IS_LEAF` call, which
performs a dereference on `n`, without first checking for NULLs.
This NULL dereference triggers the following gnome-shell crash:
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 meta_get_first_subsurface_node (surface=0x55d589623450) at ../src/wayland/meta-wayland-surface.h:399
#1 pointer_can_grab_surface (pointer=0x7f6dc4012700, surface=0x55d589623450) at ../src/wayland/meta-wayland-pointer.c:1306
#2 0x00007f6ddb94d509 in meta_wayland_pointer_can_grab_surface (pointer=<optimized out>, surface=surface@entry=0x55d589623450, serial=serial@entry=996) at ../src/wayland/meta-wayland-pointer.c:1321
#3 0x00007f6ddb950d05 in meta_wayland_seat_get_grab_info (seat=seat@entry=0x55d586c24f20, surface=0x55d589623450, serial=996, require_pressed=require_pressed@entry=0, x=x@entry=0x0, y=y@entry=0x0)
at ../src/wayland/meta-wayland-seat.c:467
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2655>
Unlike the multi-view path, the optimized/single-view one doesn't check
if the surface-actor is really present on the view. That is the case
whenever it's hidden - e.g. when the window is minimized.
Fixes 3b7137cb35
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2662>
The stage view list does not get updated when an actor gets hidden in
order to avoid unnecessary work, such as scale changes. However, we
still want `is_effectively_on_stage_view` to report `FALSE` in this
case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2662>
The :input-purpose and :input-hints properties were added without
actually handling the get/set operations, whoops.
All code uses the (working) methods, so this only fixes expectations,
not an actual bug :-)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2659>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case the window content get centered on a black
background which covers the whole monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case it should be shown centered on the monitor
with a black background. The black background becomes part of the window
geometry.
The surface container is responsible for correctly culling the surfaces
and making sure the surface actors are removed from the actor tree to
avoid destroying them.
The window actor culling implementation assumes all surfaces to be direct
children of said actor. The introduction of the surface_container actor
broke that assumption. This implements the culling interface in
MetaWindowActorWayland which is aware of the actor surface_container and
fullscreen state.
v2: Fix forwarding culling to surface even if there is a background.
v2: Don't alter passed geometry.
v2: Update window geometry code documentation to reflect these changes.
v2: Only use constrained rect if we're acked fullscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
Prepare for adding Wayland specific culling logic to the
MetaWindowActorWayland class by moving all the logic to the non-abstract
classes, since there will be no reason to keep the logic in
MetaWindowActor around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
This is helpful to know what current state a window actually have, in
contrast to the state in MetaWindow (e.g. MetaWindow::fullscreen) which
is the intended state, be it current or not yet so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
First make sure we call 'move_resize()' in all cases where the size or
position can change, then move the updating of the buffer rect to the
same place as we update the frame rect. This means keeping track of
surface size changes, in addition to geometry changes, and calling
finish_move_resize() whenever any of those changes, in addition to
acknowledged configurations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
A "window rect" in most places refers to the rectangle the window
corresponds to when it comes to window management. MetaWindow::rect also
refers to this window management related rectangle. However in the
geometry sync functions, it instead called what was to be the rectangle
the actor should have as "window rect", which is arguably a bit
confusing. Fix this by renaming it "actor_rect" so that it becomes clear
that it's the rectangle the actor should get on the stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
MetaWindowActor previously peeked at the number of child Actors to
determine the number of surfaces. The following commit rearranged the
tree such that MetaWindowActorWayland always has two Actors. This change
lets the subclass determine if the main surface describes the whole
window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
When a window configuration is constructed for a Wayland surface it
contains a position, size and a scale. The scale is the geometry scale
for the configuration, i.e. before the size is sent the passed dimension
is divided with the passed scale.
When moving between monitors with different scales, if we use the
existing geometry scale, this means we will send a configure event with
incorrect dimensions. Fix this by calculating the scale used in the
configuration given the rect we're configuring with as this will mean
the correct size will be sent to the client.
v2: Removed the fullscreen condition. Don't know why it was added to
begin with.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
There were some magic conditions that decided when
meta_window_constrain() was to be called or not. Reasoning about and
changing these conditions were complicated, and in practice the caller
knows when constraining should be done. Lets change things by adding a
'constrain' flag to the move-resize flags that makes this clearer. This
way we can, if needed, have better control of when a window is
constrained or not without leaking that logic into the generic
to-constrain-or-not expression.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
We have no way to sanely add safe modes if there are no modes we can
compare with, thus don't try.
Fixes the following crash:
#0 are_all_modes_equally_sized at ../src/backends/native/meta-output-kms.c:284
#1 maybe_add_fallback_modes at ../src/backends/native/meta-output-kms.c:310
#2 init_output_modes at ../src/backends/native/meta-output-kms.c:347
#3 meta_output_kms_new at ../src/backends/native/meta-output-kms.c:414
#4 init_outputs at ../src/backends/native/meta-gpu-kms.c:332
#5 meta_gpu_kms_read_current at ../src/backends/native/meta-gpu-kms.c:368
#6 meta_gpu_kms_new at ../src/backends/native/meta-gpu-kms.c:403
#7 create_gpu_from_udev_device at ../src/backends/native/meta-backend-native.c:461
#8 init_gpus at ../src/backends/native/meta-backend-native.c:551
#9 meta_backend_native_initable_init at ../src/backends/native/meta-backend-native.c:632
Fixes: 877cc3eb7d44e2886395151f763ec09bea350444
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2127801
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2646>
This just checks for any chromaticity being zero and gamma being in
range but we could do a better job at detecting bad data in the future.
Also check the return value of cmsCreateRGBProfileTHR which can be NULL.
Fixes gnome-shell#5875
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2627>
ATM sending modifiers to clients prevents direct scanout for DRI3
clients via Xwayland. Xwayland using the dma-buf feedback v4 Wayland
protocol will solve that, but that might take a while yet to appear in
the wild. Once that happens, this can be reverted.
Direct scanout still works for native Wayland clients as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2637>
Make sure that if we wiggle a scan-out capable surface a bit, it won't
scan out if it's not exactly in the right position. Do this by first
making the window not fullscreen, then moving it back and forth,
verifying the correct scanout state for each presented frame.
This test addition reproduces the issue described in
https://gitlab.gnome.org/GNOME/mutter/-/issues/2387.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624>
