The debug controller can optionally, when passing --debug-control,
enable manipulating debug state, so far enabling/disabling HDR, via
D-Bus.
It's always created, in order to have a place to store debug state and
emit signals etc when it changes, but so far, it doesn't have its own
state it tracks, it just mirrors that of the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3432>
Given destruction order, the display goes away before the stage, so
this lingering signal connection may trigger unintended crashes.
Fixes: 05eeb684d1 ("window: Postpone focusing until grab ended if uninteractable")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3422>
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>
Take a reference to the window to make sure the MetaFocusData->window
pointer is not pointing to a freed object.
Also make sure that the window that we want to focus is not currently
unmanaging.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
On X meta_window_handle_enter was called when the desktop window was
entered. On wayland the "desktop" is no window anymore. We still want to
inform the core that the desktop is focused, so it can unfocus windows
if focus-mode is mouse.
This commit prepares the core for handling a NULL windows to mean the
desktop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
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>
If we have an existing focused window that may have focus, default focus
will leave the focus there. An unmanaging window for example must not
have focus and default focus will continue to select another window in
this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
meta_display_ping_window() does nothing when check-alive-timeout is set
to 0, but meta_window_check_alive_on_event() was relying on it to reset
the events_during_ping. Without this events_during_ping was just
counting up until the threshold was reached and the window was marked as
not alive, preventing further pointer events from being sent to the
window.
Fix this by not doing anything in meta_window_check_alive_on_event() if
check-alive-timeout is 0, similar to meta_display_ping_window().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3142
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3367>
Locked modifiers should probably not have an effect on keybindings
while toggled. this is most relevant for modifiers that can be
either/both pressed or locked (e.g. Caps Lock key), if used in
keybindings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
The shell might raise and make windows recent for another workspace when
an app gets activated on another workspace. Making the windows only
recent on the current workspace thus results in inconsistent focus when
another window of the same app is closed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3315>
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>
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>
After an event has been handled such that it bypasses both Clutter and
Wayland, e.g. when handling a keybinding, bypass_clutter would get
unset in the presence of a wayland grab. This means that the event is
handled both as a keybinding and by Clutter.
In the case of switcher popups in gnome-shell in the presence of a gtk4
autohide popover this meant that instead of selecting the next element,
it would select the one after that. If there are only two elements, as
is common with input sources, this would mean going back to the current
one, preventing switching them with a single press of the keybinding.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6738
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3054>
