X11 server side focus changes, such as when a focus change was requested
by mutter for a globally active window, did not go through
meta_display_set_input_focus(), which is responsible for emitting the
`focus-window` signal. Since this signal is what triggers the display
server specific code to handle focus changes, this was leading to a
problem on Wayland where the focus remained on the last active Wayland
window when the focus got changed to a globally active XWayland window.
This commit now changes handling X11 server side focus changes to also
go through the code path that emits the signal while making sure to not
trigger another focus change and keeping the same serials as the
previous code to not interfere with future focus changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3328
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3651>
Assigning the corresponding stack layer of DOCK windows is currently X11
specific, because there is no way for wayland clients to set the DOCK
window type. This is about to change, so move the code to the generic
layer handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3612>
Except meta_window_x11_get_group, which is still used by GNOME Shell
and we can't make it a private API for now.
Will need further investigation and could be done as a future
step
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
If we happen to be changing focus to a window *while* taking focus
away from Clutter widgetry, we would unintendedly trigger reentrance
in a way that the old focused window remained in focus, by asking
to focus the default focus window in an untimely manner.
To handle this reentrancy, delay dropping the Clutter key focus
until the window focus changed, so that the focus change will look
up the default focused window in the workspace, and find the up to
date one.
Fixes: ae102ee3011 ("x11: Refactor ClutterStage key focus management")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3467>
Trying to get the xwindow of a wayland only window would fail when
casting to a x11 window. Which happens as
meta_x11_display_set_input_focus is called whenever the focused
window changes, whether it is a wayland or x11 one
Fixes: bc9cd123e ("window: Move xwindow to WindowX11")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3506>
Integrate it into the code, instead of depending on MetaDisplay
notify::focus-window for it. Now, instead of focusing explicitly the
stage window, we focus a NULL window, and let the MetaX11Display
determine whether focus should go to the stage window if there's
a focused actor, or the no_focus_window if nothing has focus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
We currently offer the mechanism for GNOME Shell to implement, and
while this is not exercised often (our entries are typically surrounded
by a ClutterGrab ensuring key events, so this is reserved to grab-less
entries, probably there are some in extensions), this is arguably
something Mutter should cover by itself without GNOME Shell guidance.
This is only necessary on the X11 backend, although it is conceptually
more tied to the MetaX11Display connection, so perform the focus
tracking there only if not running as a Wayland compositor (i.e. --x11).
This avoids the only case where the low-level
meta_x11_display_set_input_focus_xwindow() function is used, or rather
makes it completely a MetaX11Display implementation detail, leaving
only the MetaDisplay API as the high-level entry points to handle
window key focus.
The public API that allowed GNOME Shell to implement these mechanisms
is also gone in this commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
Scoped traces are less error prone, and they can still be ended
prematurely if needed (this commit makes that work). The only case this
doesn't support is starting a trace inside a scope but ending outside,
but this is pretty unusual, plus we have anchored traces for a limited
variation of that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3396>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
The following commits will make it possible to pass a NULL window to
display_handle_window_enter/leave to represent the cursor entering the
desktop. This means it can't be a method of the window class anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
Assigning the corresponding stack layer of DESKTOP windows is
currently X11 specific, because there is no way for wayland
clients to set the DESKTOP window type.
This is about to change, so move the code to the generic layer
handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
This is similar, but reserved for the crossing events induced by the
input shape changes on our overlay window. The mechanism in the previous
commit does again protect against this, so this mechanism may go away.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
Focus follows mouse is meant to avoid focusing windows that happened
to pop up under the pointer, e.g. due to mapping, workspace changes,
etc... On X11, this has been done since ancient times through a
moderately complex synchronization mechanism, so mutter would know
to ignore crossing events caused on those situations.
This mechanism is much prior to XInput 2 though, where we may know
this in a more straightforward way: If the sourceid of the crossing
event is a logical pointer (i.e. equals deviceid), the crossing event
was triggered logically, and not through user input.
Perform this simpler check, and drop the existing mechanism to
ignore logically induced crossing events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
Commit 9c3b130f67 changed slightly destruction order to handle use-after-free
situations, but missed a small new one introduced by the order change: The
MetaX11Display may schedule callbacks through MetaLaters, which depend on the
MetaCompositor, which is now freed before the MetaX11Display.
Since there is no winning move here, make the MetaX11Display aware of this
by avoiding to remove the callback if the MetaCompositor is already gone.
The MetaLaters infrastructure is already fully freed at this point (incl. the
data it contained), so this shouldn't be a leak.
Fixes: 9c3b130f67 ("display: Fix destruction order")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3247>
