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>
If we have a window that match the size (i.e. will pass the "fits
framebuffer" low level check), that doesn't mean it matches the
position. For example, if we have two monitors 2K monitors, with two 2K
sized windows, one on monitor A, and one on monitor both monitor A and
B, overlapping both, if the latter window is above the former, it'll end
up bing scanned out on both if it ends up fitting all the other
requirements.
Fix this by checking that the paint box matches the stage view layout,
as that makes sure the actor we're painting isn't just partially on the
right view.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2387
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624>
Painting the swap region with CLUTTER_DEBUG_PAINT_DAMAGE_REGION happens
on the view framebuffer, so don't transform the region we paint to the
onscreen.
Fixes the swap region painting on rotated monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2590>
Gnome-shell uses meta_display_focus_default_window() when shell elements
loose focus which is the case with Alt+Tab window switching. Globally
active input clients don't immediately gain focus though so if
meta_display_focus_default_window focuses a wrong window stacking and
focus don't behave as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
New commands to set the number of workspaces, activate a workspace, with
and without focus, move windows to specific workspaces, and check the
stacking on a specific workspace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
When switching workspaces we previously focused on whatever window is on
top of the stack. If a window is marked as "always on top" then it would
always receive focus when switching workspaces.
Fixes#2240
Fixes gnome-shell#5162
Fixes#178Fixes#678
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
We want to use the workspace MRU list to decide the default focus but
Globally Active Input clients don't call
meta_window_set_focused_internal and therefore don't update the MRU
list. Move the update to meta_window_focus instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
The completed signal is only emitted if the timeline actually completed
but when an actor is destroyed or removed from its parent the timeline
is stopped and not completed.
The workspace switch effect removes window actors from the window group
which destroys the timeline so on_$EFFECT_effect_stopped is never
called and the pointer to the timeline is dangling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
The workspace switch animation moves the WindowActors out of the
WindowGroup so if we shut down while the animation is playing the
WindowActors will have queued a destroy but will be disposed only after
the compositor is destroyed, leaving the WindowActor with a dangling
pointer.
Fix the issue by killing the workspace switch animation on shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
This is an old relic from when ClutterStageView was being added, and
tests were somewhat prepared to be able to test the "X11 style" of
things, with the nested backend some how managing to emulate that.
Lets drop that stuff, it isn't used by the test suite, and isn't useful
anyway; if we want to test X11 configurations, we should use the actual
X11 backend, which didn't make use of this anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2619>
