This is unnecessary as we are unsetting the DnD selection owner,
and will result in the related data source being cancelled already.
https://gitlab.gnome.org/GNOME/mutter/issues/591
(cherry picked from commit e7b2f9603e90d87092c9e755c176f1244a8b3e36)
Those were used to signal clipboard ownership around, but that got
replaced by MetaSelection and friends. These signals are no longer
listened on, so can be safely removed.
https://gitlab.gnome.org/GNOME/mutter/issues/591
(cherry picked from commit 46b3811e22b3b898342141b1575c888285e51caf)
Properly take the panel_orientation_transform into account in
update_monitor_crtc_cursor. This fixes us sometimes drawing the cursor
on two monitors at the same time as we did not properly swap the crtc
width/height when a panel_orientation_transform is active.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/927
(cherry picked from commit 8907a299127be21169aba05ab1751c66c6d36754)
Actually store the panel_orientation_transform in the meta_output, so
that it gets honored by the core code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/927
(cherry picked from commit a5f986259f8e68dbad2f7835d1481840b446408f)
The MetaBackgroundActor uses a region to find out the areas that need
repainting, but forgot to free it, oops.
(cherry-picked from 40e6aa7d94e64d80fe07f020d75d540200004ea9)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/873
If the page flip is postponed, keep a ref to it, but still unref it
on the page flip callback anyways. Fix suggested by Jonas Ådahl.
(cherry-picked from 668be1f4bd309fedc846a0022180aef5a9e44869)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/873
Add missing clutter_x11_[un]trap_x_errors around the XIGetProperty call
in meta-input-settings-x11.c's get_property helper function.
This fixes mutter crashing with the following error if the XInput device
goes away at an unconvenient time:
X Error of failed request: XI_BadDevice (invalid Device parameter)
Major opcode of failed request: 131 (XInputExtension)
Minor opcode of failed request: 59 ()
Device id in failed request: 0x200011
Serial number of failed request: 454
Current serial number in output stream: 454
https://gitlab.gnome.org/GNOME/mutter/merge_requests/928
We currently assume that the actor_animate() helper function returns
a timeline. However Clutter may skip implicit animations and simple
set properties directly, for example when the actor is hidden.
The returned timeline will be NULL in that case, and we abort when
using it as instance parameter to g_signal_connect().
Fix this by only setting up a completed handler when we are actually
animating, and complete the effect directly otherwise.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/925
The actor is already in surface coordinate space, so we should not scale
with the buffer scale to transform surface coordinates to stage
coordinates.
This bug causes input method using wayland text-input protocol to
receive wrong cursor location. Reproduced in ibus (when candidate
window is open) with scaling factor other than 1.
This commit also fixes pointer confinement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/915
Java applications might use override-redirect windows as parent windows for
top-level windows, although this is not following the standard [1].
In such case, the first non-override-redirect child window that is created
was marked as being on_all_workspaces since the call to
should_be_on_all_workspaces() returns TRUE for its parent, and this even
though the on_all_workspaces_requested bit is unset.
When a further child of this window was added, it was set as not having a
workspace and not being on_all_workspaces, since the call to
should_be_on_all_workspaces() for its parent would return FALSE (unless if
it is in a different monitor, and the multiple-monitors workspaces are
disabled).
Since per commit 09bab98b we don't recompute the workspace if the
on_all_workspaces bit is unset, we could end up in a case where a window can
be nor in all the workspaces or in a specific workspace.
So let's just ignore the transient_for bit for a window if that points to an
override-redirect, using the x11 root window instead.
Add a stacking test to verify this scenario (was failing before of this
commit).
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128
(cherry picked from commit bacbbbd628fd68618f14bdf07ba3f9e6ccd1c038)
Once we set the transient_for, we look for parent MetaWindow, so instead
of overwriting this value for loops check, just use another function
and avoid to look for the xwindow again when setting the MetaWindow parent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
(cherry picked from commit c85fb107c0556283062f2bf9b8d990f1e2c0acae)
There might be cases in which a window might be marked as both not in all
workspaces and with NULL workspace.
So to avoid this to happen, let's just assert early instead of doing this at
later point where the context might not be clear.
Related to https://gitlab.gnome.org/GNOME/mutter/issues/885https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
(cherry picked from commit 13f10e36e4ac162f0b54fa57de24120e0e5a5453)
Override-redirect windows have no workspace by default, and can't be parent
of a top-level window, so we must check that the parent window is not an
O-R one when setting the workspace state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
(cherry picked from commit 2644e54c514377009a9d4d747874a55b387c6beb)
We're expected by MetaWaylandSurface to always pick the frame callbacks
out from the pending state when committing (applying) so that no frame
callbacks are unaccounted for. We failed to do this if our actor for
some reason (e.g. associated window was unmanaged) was destroyed. To
handle this situation better, store away the frame callbacks until we
some later point in time need to pass them on forward.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/893
(cherry picked from commit 0e5a5df5fe4d147197d85d4191d8a5c2eefb1561)
For stable branches, we currently only check out the correct shell
branch for merge requests. For the regular pipeline, our code to
determine the current mutter branch fails because CI runs on a
temporary "pipeline/12345" branch that doesn't exist for gnome-shell.
Switching to the correct gitlab environment variable fixes that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/811
When using DesktopIcons extension and clicking in an icon, gnome-shell
starts an infinite loop caused by the first focus change that may trigger
on X11 a focus in/out event that leads to stage activation/deactivation
which never ends.
This happens because as part of meta_x11_display_set_input_focus_xwindow()
to focus the X11 stage window, we unset the display focus, but this also
causes to request the X11 display to unset the focus since we convolute by
calling meta_x11_display_set_input_focus() with no window, that leads to
focusing the no_focus_window and then a focus-in / focus-out dance that the
shell amplifies in order to give back the focus to the stage.
In order to fix this, mimic what meta_display_set_input_focus() does, but
without updating the X11 display, and so without implicitly calling
meta_x11_display_set_input_focus(), stopping the said convolution and
properly focusing the requested xwindow.
Also ensure that we're not doing this when using an older timestamp, since
this check isn't performed anymore.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/896
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/899https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
(cherry picked from commit efe5bed5b4a8706fc796dfd7dc07562a866c12ed)
Otherwise we'll end up trying to access the out of date state later.
Fixes the following test failure backtrace:
#0 _g_log_abort ()
#1 g_logv ()
#2 g_log ()
#3 meta_monitor_manager_get_logical_monitor_from_number ()
#4 meta_window_get_work_area_for_monitor ()
#5 meta_window_get_tile_area ()
#6 constrain_maximization ()
#7 do_all_constraints ()
#8 meta_window_constrain ()
#9 meta_window_move_resize_internal ()
#10 meta_window_tile ()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/912
Create the intermediate shadow framebuffer for use exclusively when a
shadowfb is required.
Keep the previous offscreen framebuffer is as an intermediate
framebuffer for transformations only.
This way, we can apply transformations between in-memory framebuffers
prior to blit the result to screen, and achieve acceptable performance
even with software rendering on discrete GPU.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/917
(cherry picked from commit 551641c74822ca2e3c685e49603836ebf5397df2)
Previously, we would use a single offscreen framebuffer for both
transformations and when a shadow framebuffer should be used, but that
can be dreadfully slow when using software rendering with a discrete GPU
due to bandwidth limitations.
Keep the offscreen framebuffer for transformations only and add another
intermediate shadow framebuffer used as a copy of the onscreen
framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/917
(cherry picked from commit 2b8b450fe16c21f0f37a1779560c0e5da61a9b89)
This allows xdg_popup.grab() to work with styli. Without this check
we would bail out and emit xdg_popup.popup_done, leaving stylus users
unable to interact with popup menus, comboboxes, etc...
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/886
When a touch sequence was rejected, the emulated pointer events would be
replayed with old timestamps. This caused issues with grabs as they
would be ignored due to being too old. This was mitigated by making sure
device event timestamps never travelled back in time by tampering with
any event that had a timestamp seemingly in the past.
This failed when the most recent timestamp that had been received were
much older than the timestamp of the new event. This could for example
happen when a session was left not interacted with for 40+ days or so;
when interacted with again, as any new timestamp would according to
XSERVER_TIME_IS_BEFORE() still be in the past compared to the "most
recent" one. The effect is that we'd always use the `latest_evtime` for
all new device events without ever updating it.
The end result of this was that passive grabs would become active when
interacted with, but would then newer be released, as the timestamps to
XIAllowEvents() would out of date, resulting in the desktop effectively
freezing, as the Shell would have an active pointer grab.
To avoid the situation where we get stuck with an old `latest_evtime`
timestamp, limit the tampering with device event timestamp to 1) only
pointer events, and 2) only during the replay sequence. The second part
is implemented by sending an asynchronous message via the X server after
rejecting a touch sequence, only potentially tampering with the device
event timestamps until the reply. This should avoid the stuck timestamp
as in those situations, we'll always have a relatively up to date
`latest_evtime` meaning XSERVER_TIME_IS_BEFORE() will not get confused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/886
In a similar vein to commit 8fd55fef853. This notably failed when setting
the focus on the stage (eg. to redirect key events to Clutter actors).
Deeper in MetaDisplay focus updating machinery, it would check
meta_stage_is_focused() which would still return FALSE at the time it's
called.
This would not typically have side effects, but our "App does not respond"
dialogs see the focus change under their feet, so they try to bring
themselves to focus again. This results in a feedback loop.
Changing the order results in later checks on the X11 POV of the focus
being correct, so focus is not mistakenly stolen from the close dialog,
and it actually succeeds in keeping the key focus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607https://gitlab.gnome.org/GNOME/mutter/merge_requests/876
(cherry picked from commit 71c3f4af3196b77fb52f395238f0704e7fa4d273)
Syncronized subsurfaces that call into `merge_pending_state` might
otherwise not create new destroy handlers, ending up with a invalid
handler ids, throwing errors and leaking.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/868
(cherry picked from commit 98892391d764d1cf4b32e57367e45f39b10880e4)
Instead of doing a roundtrip to the X server before setting it, rely on
the previous value fetched before the configuration was sent over DBus.
This matches the argument check we already do elsewhere, and will allow
us to more easily add an additional condition to determine if underscan
is supported.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/673
(cherry picked from commit 8665084df15190adc0d18cc77b7fcb738d3e4fa6)
As per commit c2d03bf73 we're using a private method to set the actors key
focus and emit key-focus-in signal, but we're using inverted logic here.
So flip the parameter to match the expected result.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/860
(cherry picked from commit 553211dd81a849f33f0aca447c8683f031fff868)
When clutter actors with key focus are destroyed we emit ::key-focus-out on
them just after their destruction. This is against our assumption that no
signal should be emitted after "::destroy" (see GNOME/mutter!769 [1]), and
in fact could cause the shell to do actions that we won't ever stop on
destroy callback.
To avoid this to happen, use a private function to set its key-state (so we
can avoid looking for the stage) and emit ::key-focus-in/out events and use
this value in both clutter_actor_has_key_focus(),
clutter_actor_grab_key_focus() and on unmap and destruction to unset the
stage key focus before we emit the ::destroy signal.
As result of this, we can now avoid to unset the key focus on actor
destruction in the stage.
[1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1704
(cherry picked from commit c2d03bf73e5a945296d22c4d95709eeebf2eb57c)
We were just looking at DnD actions which might still be unset at that
point. Instead of doing these heuristics, store the selection type on
the data offer.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/845
Requesting a selection with a NULL data source means "unset the clipboard",
but internally we use an unset clipboard as the indication that the
clipboard manager should take over.
Moreover, this unset request may go unheard if the current owner is someone
else than the MetaWaylandDataDevice.
Instead, set a dummy data source with no mimetypes nor data, this both
prevents the clipboard manager from taking over and ensures the selection
is replaced with it.
The MetaSelectionSourceMemory was also added some checks to allow for this
dummy mode.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/793
Instead of taking resource and send/cancel funcs, take a
MetaWaylandDataSource, which exposes all the vfuncs to do the same on the
internal resource.
This has the added side effect that only MetaWaylandDataSource has a
pointer to the wl_resource, which may be unset untimely.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
If a data source is destroyed we first unset the resource, and then try to
unref the related selection source. At this point the only event that might
be emitted by the internal selection machinery is .cancelled, so make sure
we avoid it on destroyed sources.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
We are still poking the mimetypes from the previous selection when creating
the new offer. This may come out wrong between changes of the copied
mimetypes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/789
The default value of the ClutterShaderEffect:shader-type
property is CLUTTER_FRAGMENT_SHADER. However, because the
struct field is not actually initialized to it, it ends
up assuming the value 0, which is CLUTTER_VERTEX_SHADER.
Properly initialize ClutterShaderEffect's shader_type to
CLUTTER_FRAGMENT_SHADER.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/846
There are two common ways of building mutter: With both the native
backend and Wayland support (most common, used by most Linux distributions), and
without the native backend and Wayland support (as is done by some
BSD*s).
To catch compilation errors in both these common build configurations,
change the no-native-backend build phase to also not build with Wayland
support.
This also disables building mutter tests, as tests depend on Wayland to
run.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
Otherwise we'll get the warning
../src/core/main.c: In function 'meta_test_init':
../src/core/main.c:755:1: error: function might be candidate for attribute 'noreturn' [-Werror=suggest-attribute=noreturn]
755 | meta_test_init (void)
| ^~~~~~~~~~~~~~
when building without Wayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
