libinput 1.27 added a new "sticky" mode to the tap-and-drag drag lock -
the previous mode is now called the "timeout" mode.
In sticky mode the drag lock is explicitly terminated with an extra tap,
i.e. a full sequence is:
tap, down, [:move, up, wait, down:], up, tap
where the middle part can repeat and/or wait as long as required.
In the previous "timeout" mode the drag lock would automatically release
after a timeout - for users with low dexterity this timeout may be too
short.
The sticky mode is also how macos does drag lock.
Related: https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2798
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4292>
Since we now cascade when center-new-windows is true, we need to update the
always-above window positions to account for where the new windows will end
up being placed.
Assertions are also added for the two test windows' positions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4202>
This commit introduces a new comparator, window_distance_cmp,
which uses either the top left or top right corner of a given window, based
on LTR, as reference for the squared distance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4202>
Both northwest_cmp and northeast_cmp didn't account for the work_area's
relative x and y coordinates which would lead to improper sorting on
multi-monitor setups.
To fix this, we pass the work_area when necessary and use it to offset the
absolute coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4202>
Remove unnecessary sqrt() calls in northwest_cmp and northeast_cmp.
The square root would have been necessary if we needed the actual distance,
but we only care about the relative order, so it isn't.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4202>
This is a preparatory commit, it refactors away of the
done_check_denied_focus label, simplifying the control flow.
The only functional difference is that now the auto-maximization when
windows don't fit the work_area is always applied.
The next commits will adapt find_next_cascade to properly handle this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4202>
This commit only reformats place.c, starting off uncrustify's output, no
functional change is intended.
It mostly aligns comments, as well as properly space out math,
follow current formatter enforced guidelines and fix alignment on a rogue
bracket.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4202>
By default, copy mode primary tries to use the GPU to perform the copy
and, in case of error, it fallbacks to CPU.
Add a flag (unused for the moment) to allow to use the CPU to perform
the copy.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4251>
_clutter_actor_get_animation_info() creates a new info when the actor
currently doesn't have one. That's unnecessary and wasteful in case
where we only need to check for transitions to remove, so switch to
_clutter_actor_get_animation_info_or_default() that falls back to
an empty static info.
Fixes: c250f602bd ("clutter/actor: Remove transitions when removing an effect")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4260>
More precisely, wait until no further udev hotplug events have arrived
in 2 seconds.
Keep a list of unique UpdateStatesData structs which have received
hotplug events, and call handle_hotplug_event for all of them once the
timeout expires.
This avoids problems due to some monitors generating hotplug events
when power saving is enabled on locking the session, and then
temporarily appearing disconnected.
v2:
* Make meta_test_disconnect_connect wait and run main context dispatch
before checking the number of logical monitors.
v3:
* Call g_source_unref immediately after g_source_attach, simplifies
source cleanup. (Sebastian Wick)
* Free hotplug devices list in meta_kms_finalize. (Sebastian Wick)
* Add KMS debug logging in on_udev_hotplug & hotplug_timeout.
* Bump timeout to 2 seconds. With my affected monitor, the second udev
hotplug event normally arrives almost a second after the first one,
occasionally more than 1.5 seconds though.
* Use UpdateStatesData with custom compare function for hotplug_devices
list data, since the GUdevDevice / device path string pointer values
are always different.
* Don't wait for timeout if meta_is_udev_test_device returns TRUE, to
hopefully fix VKMS CI tests. Drop meta_test_disconnect_connect changes
again.
v4:
* Use hash table instead of list for hotplug_events set. (Sebastian Wick)
* Add comment describing the keys & values in the hash table. (Sebastian Wick)
* Add KMS debug logging in handle_hotplug_event as well.
* Dropped Closes:, this might not suffice to fully address
https://gitlab.gnome.org/GNOME/mutter/-/issues/3831 after all.
v5:
* Simplify hash table annotation comment. (Sebastian Wick)
v6:
* Rename hotplug_timeout local string pointer to hotplug_event.
* Drop g_clear_pointer in favour of g_autofree in on_udev_hotplug.
(Sebastian Wick)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4209>
Handle NULL string pointer in meta_kms_update_states_in_impl.
Drop second parameter of meta_kms_update_states_sync, which wasn't used
by the external test caller anyway. Split out static update_states_sync
function which takes a hotplug event string pointer instead.
Preparation for next commit.
v2:
* Drop UpdteStatesData for encoded hotplug event strings.
v3:
* Put device path at the end of encoded string, allows simplifying
meta_kms_update_states_in_impl slightly further.
v4: (Sebastian Wick)
* Use g_autofree for hotplug_event string in on_udev_hotplug, fixes
leak.
* Store pointer to hotplug event device path string in local variable in
meta_kms_update_states_in_impl.
v5:
* Initialize `path` local variable to `NULL` and test it instead of the
`hotplug_event` parameter. Avoids (false-positive) compiler warning
about `path` possibly being used uninitialized.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4209>
It forced the power save mode to META_POWER_SAVE_ON when reading the
current KMS state.
This was problematic when a hotplug event is emitted while the session
is locked, which can be triggered by monitors polling all their inputs
for a signal: There's no mechanism to restore the previous power save
mode in this case, so the monitors would fail to actually enter power
saving mode but stayed on with a blank screen. This was at least one
cause of the symptoms described in
https://gitlab.freedesktop.org/drm/amd/-/issues/662 .
Moreover, I suspect it hasn't had any effect for the actual reading of
KMS state since 5f6aee341959 ("kms/update: Make power saving an update
wide change"), as changing the power save mode to META_POWER_SAVE_ON no
longer results in any immediate KMS state change, it's now only taken
into account for the next mode set.
It's not clear what the intended effect was in the first place, it was
originally added as part of 65db8efbe8b1 ("MonitorManager: add a KMS
backend") without rationale. It might have been cargo-culted from
somewhere else. It shouldn't be necessary from a KMS API PoV though.
Also adjust the KMS hotplug test to assert that a hotplug event doesn't
implicitly change the power save mode.
v2: (Sebastian Wick)
* Fix shortlog of commit which added
meta_monitor_manager_native_read_current_state.
v3:
* Adjust KMS hotplug test for the change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4209>
Unused since f27ca241f9a2 ("renderer/native: Move per frame KMS update
to MetaFrameNative") / a6baa77eab89 ("kms: Split out impl/non-impl
separation into MetaThread(Impl)").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4209>
As a follow-up to 87cc6633a5, embed a partial copy of the Adwaita cursor theme
and point to it with XCURSOR_PATH to make the test completely independent
from the installed cursor themes.
Indeed, adwaita-icon-theme changed ever so slightly in version 48 so the
ref tests started failing when the new version was installed.
This is a copy of adwaita-icon-theme 47, which is what was used to generate
the ref images.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4252>
This requires reverting the previous changes intended for adapting to
triple buffering.
Fixes these tests randomly failing, also in CI pipelines of MRs not
directly related to any of this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4290>
As per previous commit we're figuring out the bash location on shebang
using env, let's do it everywhere for coherency, even if in CI fedora
may not yet have issues about this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4288>
Bash can be in both /usr/bin/bash or /bin/bash (or elsewhere!) depending on
the distro, so let's be generic using env to figure it out.
This comes from a packaging lintian error we get:
E: mutter-16-tests: wrong-path-for-interpreter /usr/bin/bash != /bin/bash
[usr/share/mutter-16/tests/socket-launch.sh]
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4288>
Avoids the following warning in the logs
mutter-x11-frame[4003]: Using
GtkSettings:gtk-application-prefer-dark-theme with libadwaita is
unsupported. Please use AdwStyleManager:color-scheme instead.
When initializing libadwaita, the AdwStyleManager default instance is
initialized taking care of loading the appropriate stylesheet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4276>
It tests that the cursor renderer can successfully initialize with the
environment variable MUTTER_DEBUG_DISABLE_HW_CURSORS=1.
It would have caught the crash fixed by the previous commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4272>
Don't try to realize the cursor sprite for the HW cursor when it's set.
v2:
* Refactor is_hw_cursor_supported helper out of
realize_cursor_sprite_from_wl_buffer_for_crtc. (Jonas Ådahl)
v3:
* Keep meta_crtc_native_is_hw_cursor_supported check in
meta_cursor_renderer_native_update_cursor, to try and avoid
mysterious CI failure.
v4:
* Rename is_hw_cursor_supported → is_hw_cursor_available_for_gpu
and take a MetaGpuKms * parameter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4272>
We want to ensure that also the stderr is matching our golden files
and at the same time we should be able to see it in logs (especially
when there's a python error to catch).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4277>
