There is an increasing number of cases where we want the frame callback
logic to run for a stage-view and the complexity needed to avoid these,
combined with the likelyhood of bugs, arguably does not justify the
benefit any more.
Thus unconditionally schedule updates for all stage-views when frame
callbacks are requested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
Screen-casted windows need to be considered visible in various situations
but existing APIs such as `clutter_actor_is_effectively_on_stage_view()`
don't do so. Add new API that allows checking if a surface belongs to a
screen-casted window for the respective cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
The introduction of the META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED
flag threw off some checks around keyboard-driven resize. This
was partly because there were some == checks that did not account
for that flag maybe being enabled, but also the handling
of META_GRAB_OP_KEYBOARD_RESIZING_UNKNOWN into a definite
resize direction was maybe unsetting that flag. Fix both things
at the same time.
Fixes: 2d8fa26c8e ("core: Pass "frame action" grab operations as an "unconstrained" grab op")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2629
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2871>
From the scale factors available to it, Mutter will now try to select
the scale factor that makes the UI's size as close as possible to the
size it would be, w/o scaling, on a display at 135 PPI (for mobile
displays) or at 110 PPI (for stationary displays)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2653>
After !2489, the active workspace's MRU list is now used to pick
the next focus window instead of the stack order.
This list is currently only updated on focus, which can lead to
surprising behavior when closing a window after activating its
ShellApp in the shell.
That is because raising a window (as part of shell_app_activate())
will only change the stacking order, so when closing the active
app window, the focus will switch to whatever had focus before the
app was activated, not the app's next window.
In order to allow gnome-shell to address this, add a new
raise_and_make_recent() method that also adjust the MRU order.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2540
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2866>
The pointer to the manager, the peer name and the ID are things that are
always metadata related to a session, so make them properties on the
interface instead of duplicating them. The implementations still need to
keep track of them, but their existance is shared.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This class is intended to be used as a base class for D-bus interface
implementations that deal with "session" objects, i.e. a D-Bus object
representing a certain session of some kind, e.g. a screen cast session.
It handles things such as hooking up to the D-Bus client watcher,
generates IDs, handles shutdown procedures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
It's currently not set by anything, and will only be used by
non-abstract implementations of a future D-Bus interface session
manager. When interface implementations gets ported to this new type,
their MetaDbusSession implementations will set this vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This means the MetaDbusSession interface takes a more active role
instead of being something that more or less sends signals to the
interface implementor. This will allow better control when using
MetaDbusSession to manage these sessions, instead of their non-abstract
variants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
Allows for creating LUTs at some fixed size which maintains enough
precision for concatenating or otherwise manipulating the LUT without
having to care about the precision of the hardware.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
If the device supports the atomic API the property based API is used to
write gamma updates and the legacy API is used in the non-atomic case.
The current state is read from the legacy API always though which can be
different from the property API. This commit always uses the correct API
to update the state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
This API will be used by GNOME Shell to handle X11 events
in the relevant places, as a substitute to gdk_window_add_filter().
It is ATM still a bit ironic, since the Mutter X11 event handler
is itself a GdkFilterFunc, but it may move away from that eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2779>
With detach meaning having the onscreen stop listening on configuration
changes on the corresponding backing mode setting objects. We need to do
this as there is a time between rebuilding the views, and that the new
mode sets are called, where the old onscreen is kept alive, but the
stage view is gone. At this point in time, if privacy screen or gamma
configuration changes, e.g. by the night light temperature changing, the
onscreen would attempt to schedule an update on the now gone stage view.
This commit also renames the "keep onscreen alive" to "detached
onscreens" to more clearly communicate that it's detached onscreens from
their corresponding mode setting objects.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2621
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2863>
For the coordinates of pointers or stylii, we translate the ones we store
using the viewport matrix already. For touch events otoh, we store coords
untranslated and translate them later only for event emission.
Let's be consistent here and store the coordinates of touch events
translated, just like we do for pointer events.
This fixes touch window dragging on rotated monitors. MetaWindowDrag calls
clutter_seat_query_state(), which uses those stored coordinates. So in case
of a touch sequence the coords returned by query_state() would be
untranslated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2859>
In the case where we early-out from meta_window_drag_begin(), the
effective_drag_window might not be set yet. In this case, we might finalize
the object before effective_drag_window is set, leading to a NULL pointer
when accessing window->display in hide_tile_preview().
To avoid that crash, add a check whether the window is set already. If no
window is set, we can just skip hiding the preview anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2858>
This fixes an issue when GLFW tries to change the display resolution
while fullscreen where the application window size doesn't get updated
according to the emulated resolution.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2725>
Streams are generally recoverable by the client and errors may happen
e.g. on negotiation failures. Right now we close the stream and
corresponding session, which is neither necessary nor expected by
clients.
Just disable the stream instead and let clients handle things as they
seem fit. This allows clients to e.g. try several Gstreamer pipelines
with limited caps on a single stream.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2850>
Doing it in dispose means the backend is actively tearing down itself,
meaning various components might or might not be there, depending on how
the tearing down is implemented. Make things a bit more robust by doing
any work that might rely on the backend being there before shutdown is
done in response to the 'prepare-shutdown' signal being emitted by the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2853>
Reading upon the history of this code branch (commits 6891ce95dc
and 7a4c808e43 are most relevant), it seems this code is meant to
synchronize Mutter focus state taking the Xserver state as true.
That is, if Mutter tried to change the focus but something truncated
that action, Mutter focus will be changed to be in sync with the
Xserver again.
This sounds backwards in a Wayland session. Mutter focus should be
the canonical source, and not second-guessed from the current Xserver
focus window. These race conditions might still apply between X11
clients, so make these paths only apply in that case.
An example of this breaking can be reproduced with a Spotify and
Firefox window, moving the focus from the first to the second by
going to the GNOME Shell overview in between, and clicking the
Firefox window from there. The Firefox window will be raised, but
refuse to take focus.
It's unclear what made this an issue recently, perhaps commit
0e6395d932 since the now possibly ignored XI_FocusIn/Out events
affect this accounting of the Xserver focused window. Anyhow it
sounds better to ignore these paths for Wayland/native altogether.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2841>
The intention when the offset request was added to protocol was
that the attach request in a new enough protocol version should
require dx/dy to be zero, but ignore them otherwise.
The current code checks for 0, but then overwrites the existing
dx/dy with it, which renders an earlier wl_surface_offset() call
ineffective.
Fixes: #2622
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2843>
This protocol is intended to let special clients create transient-for
relationships between X11 and Wayland windows. The client that needs
this is xdg-desktop-portal-gnome, which will create e.g. file chooser
Wayland dialogs that should be mapped on top of X11 windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
When modal dialogs are attached, and we set the parent/transient-for
after setting the modal type, the attachedness isn't updated. This is
(apparently) not the case for X11 windows, as they go through a
unmanage/manage dance avoiding the issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The script is a list of newline separated command lines that are sent to
the client one by one as if one would have used e.g.
meta_test_client_do().
It doesn't have error handling as it's expected to be used from tests,
and handling errors in tests that never expects to handle errors is
cumbersome.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The service channel D-Bus interface aims to be a "back door" for
services that needs special casing in Mutter, e.g. have custom private
protocols only meant to be used by that particular service.
There are currently no special casing implemented; only the basic
service channel infrastructure is added. There is a single method on the
interface, that is meant to eventually be used by
xdg-desktop-portal-gnome to open a Wayland connection with a private
protocol needed for the portal backend's rather special window
management needs.
The service channel Wayland client works by allowing one instance of
each "type", where each time needs to be defined to work in parallel. If
a new service client connects, the old one will be disconnected.
MetaWaylandClient's are used to manage the service clients, and are
assigned the service client type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
One can add a wl_global filter to a wl_display instance, which can be
used to decide what clients should see what globals. This has so far
been used to limit a Xwayland specific protocol extension to only
Xwayland. In order to expand the logic about what globals are filtered
to what clients, introduce a filter manager and port the Xwayland
specific protocol filter to this new manager.
Tests are added, using a new dummy protocol, to ensure that filtering is
working as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
It only tests indirect clients, i.e. not the subprocess part, so far,
but tests explicitly terminating by destroying the MetaWaylandClient
object, as well as the client self terminating and the signal being
emitted.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
This API creates a "client" then later sets up a wl_client and returns a
file descriptor some Wayland client can connect to. It's meant to be
used as a method other than WAYLAND_SOCKET and process launching, e.g.
passing a file descriptor via a D-Bus API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
There will be two kind of client instances, lets move fields that are
only relevant to the current way of operation in an anonymous struct to
keep things a bit separate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
On X11, the stage itself is backed by an XWindow, and moving the
input focus elsewhere will bypass any Clutter-level grabs.
This effectively allows newly opened windows to steal the focus
from gnome-shell itself, which is clearly undesirable. To prevent
that, only allow moving the X11 focus to a Window when no grab is
in place, just like commit 50e89e376 did for the stage focus.
But particularly the updating of x11_display->focus_xwindow is not
prevented. Since it's more consistent to the MetaDisplay/MetaX11Display
dual focus tracking and across Wayland/X11 backends, ensure the X11
input focus is actually set on the last focus Window after the
grabs are gone and windows became interactable again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
This patch unfortunately results in situations where it is intended
that the focus change happens while a grab is present (e.g. Alt+tab
popup), resulting in confused focus state.
This commit is reverted in order to try a similar approach at a
different level.
This reverts commit 7531669b4f.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
We used it to retrieve a Display, and convert between Atoms and
strings. We can just use the MetaX11Display's Display (It's the
same than GDK's anyways) and use XInternAtom/XGetAtomName for
these conversions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2836>
We didn't always set an implementation, when the foreign toplevel wasn't
found, and when the importer tried to set the parent-child relationship,
the implementation was missing and we'd crash in wl_closure_invoke() in
libwayland-server.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2834>
Windows that are decorated may get configure requests before
the frames client created a corresponding frame window and Mutter
reparented the window.
Since the configure request results in the buffer size being
used to update the window size and the window does not have a
buffer yet, these requests could mistakenly result in the client
window being given a minimal size.
In these situations, do not use the buffer size but the given
size. The window still has to undergo frame creation and
reparenting before being shown for the first time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2588
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2605
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2808>
This used to be implicitly done by popups using a META_GRAB_OP_WAYLAND_POPUP
MetaDisplay grab. Since commit a8cd488c6f Wayland popups no longer do that,
so the keyboard focus was simply unset if a popup was destroyed while having
the keyboard focus.
Trigger a full input focus sync, so the correct MetaWaylandKeyboard focus
surface is looked up from the focused MetaWindow.
Fixes: a8cd488c6f - wayland: Drop redundant MetaDisplay grab op
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2833>
On one hand, this used to be handled generically in all the paths that
changed the MetaWaylandPointer focus surface, induced by user interaction
or not.
On the other hand, just listening for crossing events is not sufficient
since those also do happen programmatically. We must only listen to
crossing events that have a physical source device, meaning this was
created through user interaction.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/888
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
On Wayland sessions, this handling is unnecessary and even prone
to confusion (e.g. crossing serials are only ignored in X11-exclusive
paths, so this handling competes directly with that in MetaWaylandPointer).
Avoid it entirely there, so MetaWaylandPointer can figure out
sloppy/mouse mode focus for all Wayland/Xwayland surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
In GTK this is only used for GTK clipboard/DnD selections, and
finding out whether there is a compositing manager in charge.
In Mutter, we manage our own clipboard/DnD selections, and don't
perform any rendering through GTK in the Mutter process.
So there's no special reason to let these events go through GTK,
and (related to xwayland-on-demand?) there may be race conditions
in the handling of the second feature.
There's a chance this race condition may be in Mutter, but it
does not sound worth to chase this race condition when we can
let GTK ignore these events. And it does not make sense to "fix"
gtk3 for this Mutter-only condition, when we intend to eventually
avoid it.
So, take the easy path and ignore these events.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2617
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2831>
The first monitor in stacking tests is the primary monitor but that
doesn't have to stay this way forever. Instead of special casing the
name "primary" to refer to whatever monitor happens to be the primary
monitor, we add an `assert_primary_monitor` command to verify that the
monitor that should be the primary monitor actually is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
New add_monitor command for adding secondary monitors. Support setting
the workspaces-only-on-primary preference.
The stacking test tests the focus and stacking for multiple monitors
with workspaces-only-on-primary=true. The default_focus changes
previously broke this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
bind_output() creates output interface resource, but does not
set implementation for it when wayland_output->monitor is NULL.
However, when the wayland library is running wl_closure_invoke(),
it expects the implementation to be non-NULL, and if not, it just
segfaults mutter by NULL pointer dereference.
This commit tries to address this issue by setting an implementation
when wayland_output->monitor is NULL. This could help prevent crash
when resuming from suspend or hotplugging displays.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2570
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2827>
The order of dependencies influences the order of -L arguments to gcc/ld,
we should put our private library first, so that introspection prefers
looking up libraries in private paths than public ones.
This could bring problems in API updates of the libmutter-test library,
since introspection would still prefer the old installed one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2826>
ClutterActions now no longer receive their events via
clutter_actor_event(), instead they get special treatment by the stage
now. Make the MetaGestureTracker work with this and stop emitting events
directly to Clutter via clutter_actor_event(), but instead let them get
through to Clutter (but still not to Wayland).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
The previous logic tried to keep the position of the top left corner of
the window relative to the top left corner of the monitor. This allowed
the window to move out of the target monitor. This change keeps the
proportions of the distance between the window and the monitor borders
instead if possible. Otherwise it keeps the relative position of the
center of the window clamped to [0,1] to make sure the window lands on
the right output.
This also slightly changes what monitor is considered to be on: the
monitor which contains the center of the window and, if the center is on
no monitor, the monitor wich overlaps the most with the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2591>
This partly reverts f9857cb8 but leaves an exception for cursor
surfaces in place, as some apps/toolkits will likely not get updated
anytime soon to ensure cursor themes comply with the Wayland spec.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2815>
So we can remove the additional `next_fb` and `current_fb` pointers from
`MetaOnscreenNativeSecondaryGpuState`.
Some non-scanout buffers also need to be held in the case of GL blitting
which completes in the background. Those are referenced from the scanout
buffers themselves to ensure the source buffers live just as long.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2087>
As with GAMMA_LUT, track whether privacy screen state has been pushed to
KMS in the onscreen. This leaves MetaOutput and MetaCrtc to be about
configuration, and not application.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
As with CRTC GAMMA_LUT, we're moving towards making the entity managing
KMS updates aware if there are any changes to be made, and whether KMS
updates are actually needed or not, and for privacy screen changes, this
means we need to communicate whether the privacy screen state is valid
or not. This allows the caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We're moving towards making the entity managing KMS updates aware if
there are any changes to be made, and whether KMS updates are actually
needed or not, and for GAMMA_LUT changes, this means we need to
communicate whether the GAMMA_LUT state is valid or not. This allows the
caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We may fall through these paths on --nested too, resulting in us poking the
wrong internals from the wrong MetaRenderer subclass. Fixes launching of
clients using wl_drm in --nested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2818>
Running each stacking test as a separate installed-test is analogous to
what was done for build-time tests in c6d1cf4a (!442) and should make it
easier to track regressions, by being able to see whether a regression
is specific to one .metatest script or applies to more than one.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2773>
While completely untested, at least this makes it work "in theory"
again. Before it'd listen to signals on the stage, but have an incorrect
type signature to handle the test paint procedures, meaning it'd
probably crash or cause memory corruptions.
What was needed was a signal which in the callback the test could call
some cogl functions to paint on the framebuffer. While there is no such
signal on the stage, and the ClutterActor::paint signal (which they
probably used in the past) is long gone, lets add a "test actor" that is
just a wrapper that adds that paint signal with a paint context.
The tests that need it are changed to add this actor to the stage, and
to listen to the paint signal on the actor instead of incorrectly
listening on stage signals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2807>
At least indirectly, this is set as object qdata while the
window drag is ongoing, and reset/reconstructed if needed.
Consequently, this edge data does not need to be stored in
the MetaDisplay struct anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Even though the data is still stored in the display, add a "high
level" meta_window_drag_update_edges() call, so that the cached
edges may be updated while a window drag operation is ongoing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since MetaWindowDrag took a lot of this code to handle window drags
internally with less interactions with the rest of the stack, this
code in display/window/keybindings is unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This helper object (and the whole window drag operation) will be
requested to the compositor instead of created directly, and only
one of those can exist at a time, so the compositor will also
safeguard that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since SSD X11 windows require synchronization between frame and client
windows on resizes, updates do not always happen immediately but in
control of external factors (i.e. when both windows become to have
a coherent size).
This method will be used to update the window position between
resize/sync operations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
