The device ID is kind of pointless on Wayland, so it might be better to
stick to something that works for both backends. Passing the device here
allows the higher layers to pick.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/676
As per commit f71151a5 we focus an input window if no take-focus-window accepts
it. This might lead to an infinite loop if there are various focusable but
non-input windows in the stack.
When the current focus window is unmanaging and we're trying to focus a
WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input
window in the stack.
However, if an application (such as the Java ones) only uses non-input
WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This
might lead to a state where no window is focused, or a wrong one is.
So, instead of only focus the first eventually input window available, try to
request to all the take-focus windows that are in the stack between the
destroyed one and the first input one to acquire the input focus.
Use a queue to keep track of those windows, that is passed around stealing
ownership, while we protect for unmanaged queued windows.
Also, reduce the default timeout value, as the previous one might lead to an
excessive long wait.
Added metatests verifying these situations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When used it setups an X11 event monitor that replies to WM_TAKE_FOCUS
ClientMessage's with a XSetInputFocus request.
It can only be used by x11 clients on windows that have WM_TAKE_FOCUS atom set
and that does not accept input.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When using gtk under X11 some WM related events are always filtered and not
delivered when using the gdk Window filters.
So, add a new one with higher priority than the GTK events one so that we can
pick those events before than Gtk itself.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus
targets, however this might end-up in an infinite loop if there are multiple
non-input windows stacked.
So, accept any focusable window as fallback focus target even if it's a
take-focus one (that might not reply to the request).
Added a stacking test to verify this.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When looking for the best fallback focus window, we ignore it if it is in the
unmanaging state, but meta_stack_get_default_focus_window() does this is check
for us already.
So, ignore the redundant test.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
Since 4cae9b5b11, and indirectly before that as well, the
MetaMonitorManager::power-save-mode-changed is emitted even
when the power save mode didn't actually change.
On Wayland, this causes a mode set and therefore a stuttering.
It became more proeminent with the transactional KMS code.
Only emit 'power-save-mode-changed' when the power save mode
actually changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/674
We need to set XdndAware and XdndProxy on the stage window if running
a X11 compositor, this is not necessary on wayland.
Takes over gnome-shell code doing this initialization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/667
As per commit 040de396b, we don't try to grab when shortcuts are inhibited,
However, this uses the focus window assuming that it is always set, while this
might not be the case in some scenarios (like when unsetting the focus before
requesting take-focus-window to acquire the input).
So allow the button grab even if the focus window is not set for the display
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/663https://gitlab.gnome.org/GNOME/mutter/merge_requests/668
On Wayland, if a client issues a inhibit-shortcut request, the Wayland
compositor will disable its own shortcuts.
We should also disable the default handler for the button grab modifier
so that button events with the window grab modifiers pressed are not
caught by the compositor but are forwarded to the client surface.
That also fixes the same issue with Xwayland applications issuing grabs,
as those end up being emulated like shortcut inhibition.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/642
gnome-shell hardcodes a vertical one-column workspace layout, and
while not supporting arbitrary grids is very much by design, it
currently doesn't have a choice: We simply don't expose the workspace
layout we use.
Change that to allow gnome-shell to be a bit more flexible with the
workspace layouts it supports.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/618
Waking up gnome-shell and triggering JavaScript listeners of
`size-changed` every time a window was only moved was wasting a lot
of CPU.
This cuts the CPU requirement for dragging windows by around 22%.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/568
Clutter has two motion event toggles: one in the global context, and
one per stage. The global one is deprecated, and currently unused.
Remove the global motion event handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/666
We currently don't handle the lack of DRM_CLIENT_CAP_UNIVERSAL_PLANES
KMS capability. Fail constructing a device that can't handle this up
front, so later made assumptions, such as presence of a primary plane,
are actually valid.
If we want to support lack of said capability, the required planes need
to be emulated by a dummy MetaKmsPlane object.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/665
The way code was structured made it easy to misunderstand things as the
surface actor of a window actor could change over time. So is not the
case, however, the intention of the corresponding "update" function was
so that a surface actor could be assigned to a window actor as soon as
the X11 window was associated with its corresponding wl_surface, if the
window in question came from Xwayland.
Restructure the code and internal API a bit to make it clear that a
window actor only once gets a surface actor assigned to it, and that it
after that point never changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/659
X11 actors need to release the server data (pixmap and damage) before the
display is closed.
During the close phase all the windows are unmanaged and this causes the window
actors to be removed from the compositor, unsetting their actor surface.
However, in case a window is animating the surface might not be destroyed until
the animation is completed and a reference to it kept around by gjs in the shell
case. By the way, per commit 7718e67f all window actors (even the animating
ones) are destroyed before the display is closed, but this is not true for the
child surface, because the parent window will just unref it, leaving it around
if reffed somewhere else. This is fine for wayland surfaces, but not for X11
ones which are bound to server-side pixmaps.
So, connect to the parent MetaWindowActor "destroy" signal, releasing the x11
resources that implies detaching the pixmap (unsetting the texture) and removing
the damages.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/629https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
free_damage and detach_pixmap functions are called inside dispose and an object
can be disposed multiple times, even when the display is already closed.
So, don't try to deference a possibly null-pointer, assigning the xdisplay too
early, as if the X11 related resources have been unset, the server might not be
open anymore. In fact, we assume that if we have a damage or a pixmap set,
the display is still open.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
In MetaWindowActor creation we're setting the compositor private (i.e. the
window actor itself) of a window before creating the surface actor, and so
passing to the it a window without its compositor side set.
Since the surface actor might use the parent actor, set this before updating
the surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
As per commit 80e3c1d set_surface_actor has been added, meant to do different
things depending on the backend, like connecting to signals under X11.
However, the vfunc isn't ever used, making the X11 surfaces not to react to
repaint-scheduled signal.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
Everytime the top window changes we connect/disconnect to the actor's destroy
signal, although as explained in commit ba8f5a11 this might be slower in case
the window actor has many other signal connections.
So, just track this using an ID.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
There were fallbacks in place in case IN_FORMATS didn't yield any usable
formats: the formats in the drmModePlane struct, and a hard coded array.
The lack of these fallbacks in place could result in a segfault as code
using the supported plane formats assumed there were at least something
in there.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/662
The display name is being used by the monitor manager to expose to name
to the DBUS API.
It is being rebuilt each time, so instead build the displa yname once
for the monitor and keep it around, with an API to retrieve it, so that
we can reuse it in preparation of xdg-output v2 support.
https://gitlab.gnome.org/GNOME/mutter/issues/645
