local_error in meta_egl_query_device_string() is using g_autoptr,
meaning that it was getting freed after g_propagate_error(). This then
would result in error->message becoming invalid, causing crashes when
logging the error message later on.
Fixes: 8234f5bc7 ("egl: Return success status from meta_egl_query_device_string")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3758>
Just shovel the data through our own stdin/stdout, which will end up at
the right place (e.g. /dev/null).
This should hopefully solve `mutter-dist` failing due to a D-Bus method
call timeout in CI.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3757>
An action can be performed both on a signal emitted by a window or by
a well-known signal name, so that one can do:
[window-id]::signal => command
And so these would work:
w/1::position-changed => resize w/2 20 30
::monitors-changed => move w/1 30 40
We only support "monitors-changed" global signal name or connecting to
window signals for now, but this can be easily expanded adding support
for more global signal values or parsing other kinds of object instances
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
Allows to use:
set_strut 0 0 MONITOR_WIDTH*0.5 MONITOR_HEIGHT/4 top [default]
We use the currently focused window as the reference monitor if any or
the primary one if no monitor is explicitly provided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We may need to compare monitor size to fractions and while it can be
done using inverse divisions, they were not supported as we didn't parse
floating point values.
So, just add support for both multiplications and divisions, so that we
can easily do stuff like `MONITOR_HEIGHT*3/4`.
Additions would be easy to support too if we don't care about operator
priorities, but that's out of scope for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We just made an half assed attempt to wait, but e.g. when clients were
waiting for a frame event, the attempt was not enough, as the clients
would not ack any configure until the time they were scheduled to paint
again.
Fix this by actually tracking newly pending configurations, and waiting
for them to return.
On X11, still be lazy and hope for the best, as there is no similar
configuration tracking there.
Some tests were updated to use just 'wait' when there was no actual need
for any extra waiting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
When a window with an input shape on its decoration window becomes
undecorated and meta_window_x11_update_input_region() gets called via
notify::decorated, the buffer_rect of the window has not been updated
yet while the decorated property has. This would lead to us comparing
the input shape of the client window to the buffer_rect which still
includes the decoration window. This would fail to detect the common
case when the client window has no input shape set, leading to the input
region being set to the size of the client window rather than NULL. If
the window is then resized later, the input shape would remain at the
previous size.
This was not a problem before 6bd920b35, because then we were (wrongly)
always comparing to the client_rect.
Fix this by choosing the correct rect for comparison depending on
whether the window is decorated.
Fixes: 6bd920b35 ("x11/window: Use correct bounding rect to determine NULL input region")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3451
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3720>
There is nothing to allocate for a 0-sized files, and indeed
posix_fallocate() will error out if the passed len isn't greater
than 0.
Now that anonymous files are used to back the memory selection
source, this fixes unsetting the selection when the screen is
locked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3752>
When a key binding is removed, and a trigger key sequence is dispatched
before the idle callback that resolves and updates the actual binding,
we should handle that gracefully.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3711>
Two new fields: ref_count and removed, are added to MetaKeyHandler, and
it would be freed only if the ref count has reached 0. When handler is
removed from key_handlers GHashTable, key_handler_destroy() would mark
removed as TRUE, and do an unref. handler->removed is checked in
get_keybinding, and binding with handler removed would not be used.
Also in MetaKeyBinding, it now has the ownership of the name field, to
avoid it being freed before logging. Create or copy a binding would
do a ref inc for handler, and free one would unref handler.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1870.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3711>
When a client resizes on its own, make sure the new size is passed
through the window constraints machinery directly, to trigger any
potential window management rule that might apply.
Fix a couple of tests to make use of this behavior by introducing a new
'wait_size' command that waits until a window has been resized to a
expected size.
This replaces the fix introduced in 0e736af301 ("window: Ensure
constraints after a Wayland client resize").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3700>
Starting the timeout to move from hidden to suspended before the window
is mapped means we don't have a previous window configufration which we
need to get the new window configuration with the suspended state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3731>
Sometimes the test runners are saturated with other work. Bump the test
timeouts by a multiplier of 5 with the hope that they now will be much
more likely to have time to finish in time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3735>
These functions are specific for X11 windows only so we should check
if the passed window is an X11 one, not just a MetaWindow since we're
casting to the actual type at later point.
Fixes changes part of commit e1e6534eb
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
If a window sends a configure stacking request, we were comparing the
active window with the event window even though they were different
client types (e.g. wayland and x11).
This was leading to a critical error, so let's handle this by ensuring
that the active window is of the same kind of the event window before
doing x11-specific checks. Behaving as different applications in case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
Because `meta_kms_impl_device_simple_initable_init` is called in the
middle of `meta_kms_device_new`, the crtcs list for `MetaKmsDevice`
has not been populated yet. And thus the loop to detect missing
cursor planes and create fake ones never iterated. But the crtcs list
does already exist in `MetaKmsImplDevice` so iterate over that instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3264
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3676>
Prior to commit 5dfed8a431, the MetaWaylandKeyboard would always remember
the last key press serial, and consider it valid after the key was released,
as long as no other key presses/releases happened in between.
That commit improved things so that MetaWaylandKeyboard can track multiple
keys being pressed simultaneously, but also changed so that the serial for
a key press is immediately forgotten after the key press event was received.
This may break in situations like testing or keyboard macros where key
press and release is handled in a quick sucession, so the client reaction
to the key press (e.g. popping up a menu) might arrive too late.
Add a sort of spiritual successor to this handling, and make keyboard
press serials corresponding to the last key up forgotten at the next
key press/release received.
Fixes: 5dfed8a431 ("wayland: Preserve serial for all pressed keys")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3458
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3721>
We did not track the current surface (i.e. the logical focus) too
thoroughly, so there might be chances that a stale surface pointer
here becomes the focus. Track its destruction (like it's done at e.g.
MetaWaylandPointer) and unset the current surface early, in order
to avoid possible invalid memory access.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3372
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3715>
