This feature was configured depending on whether the Cogl backend
reported COGL_WINSYS_FEATURE_MULTIPLE_ONSCREEN or not. All cogl backends
do report this, so any code handled the 'static' case were never used.
While we only ever use one stage, it's arguable more correct to
consilidate on the single stage case, but multiple stages is something
that might be desirable for e.g. a remote lock screen, so lets keep this
logic intact.
This has the side effect of completely removing backend features, as
this was the only left-over feature detection that they handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This changes the setup phase of clutter to not be result of calling an
init function that sets up a few global singletons, via global singleton
setup vfuncs.
The way it worked was that mutter first did some initial setup
(connecting to the X11 server), then set a "custom backend" setup vfunc
global, before calling clutter_init().
During the clutter_init() call, the context and backend was setup by
calling the global singleton getters, which implicitly created the
backend and context on-demand.
This has now changed to mutter explicitly creating a `ClutterContext`
(which is actually a `ClutterMainContext`, but with the name shortened to
be consistent with `CoglContext` and `MetaContext`), calling it with a
backend constructor vfunc and user data pointer.
This function now explicitly creates the backend, without having to go
via the previously set global vfunc.
This changes the behavior of some "get_default()" like functions, which
will now fail if called after mutter has shut down, as when it does so,
it now destroys the backends and contexts, not only its own, but the
clutter ones too.
The "ownership" of the clutter backend is also moved to
`ClutterContext`, and MetaBackend is changed to fetch it via the clutter
context.
This also removed the unused option parsing that existed in clutter.
In some places, NULL checks for fetching the clutter context, or
backend, and fetching the cogl context from the clutter backend, had to
be added.
The reason for this is that some code that handles EGL contexts attempts
to restore the cogl EGL context tracking so that the right EGL context
is used by cogl the next time. This makes no sense to do before Cogl and
Clutter are even initialized, which was the case. It wasn't noticed
because the relevant singletons were initialized on demand via their
"getters".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
In various places we retrieved the default seat from the ClutterBackend.
All the clutter backends implement this by calling
meta_backend_get_default_seat() which will then return
MetaBackendPrivate::default_seat.
Lets avoid this by fetching the default seat directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
Rename all instances of `MetaClutterBackendX11` so they are called
`clutter_backend_x11`. This is because `MetaBackendX11` will start to be
used for some things, and having both be named `backend_x11` would be
confusing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This one is a trivial wrapper around clutter_actor_get_children(), so just
use that in the two places where clutter_container_get_children() is used,
and remove clutter_container_get_children().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2057>
Right now we damage the stage even if an actor is not mapped, for
example in the overview.
Stop doing so, reducing over-paint significantly in some situations.
Clones will still do stage damage on their own.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2035>
Quoting the spec for `wl_data_device::drop`:
> If the resulting action is "ask", the action will not be considered
> final. The drag-and-drop destination is expected to perform one last
> wl_data_offer.set_actions request, or wl_data_offer.destroy in order
> to cancel the operation.
We did not respect the action choosen by the drop destination when
it called `wl_data_offer::set_actions` after `wl_data_device::drop`
if a user override was still active. This eventually resulted in
a protocol error in `wl_data_offer::finish`, as the current action
could still be `ask`.
Fix this by only allowing a user override to `ask` before `drop` is
called, thus making sure the final `set_actions` preference is
honored.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1952
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2043>
Since the CI pipeline now runs `meson dist` which includes a test
for an up-to-date NEWS entry, post-branch/release version bumps
have become unwieldy.
It's still useful to increase the API version right after branching
though, so return to bumping it manually and do so now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2053>
With each wl_ouitput corresponding to a monitor, the logical monitor is
not part of the MetaWaylandOutput anymore.
Previously, send_xdg_output_events() would compare the old logical
monitor against the new one to determine whether the size and/or
position was changed and should be sent along with the xdg_output
events.
But that logic is now defeated as there is no old/new logical monitor
anymore, so the updated size or location would never be sent again.
Xwayland relies on this information to update its X11 clients and its
own internal root size, without this the X11 screen size and XRandR
information would never be updated.
To avoid that issue, always send the xdg_output size and location on
xdg_output events, Xwayland is smart enough to update its X11 clients
with XRandR only when the layout actually change.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1964
Fixes: bf7c3450 - Make each wl_output correspond to one monitor
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2050>
ClutterText implements its own get_paint_volume() with its own cache,
but was not invalidating the actor paint volume when when it has
changed. This sometimes could result in labels, especially quickly
changing ones, using the old paint volume which either would cut off the
label or leave parts of the old label on screen.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1943
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2006>
Easily seeing the buildtype and debug status can be quite useful.
Gnome-Shell already has it.
And while on it, add a 'Directories' section for already existing
entries.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2044>
meta_keymap_x11_replace_keycode currently reports to the X server
that the key types data is changed when adding a key to the keymap.
It's not changed. The number of key types is the same, and none of
them are modified.
This has two bad side effects:
1) It sends all of the key types data into the request
2) It hits a bug in the X server leading to the request getting
rejected entirely. See:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/761
Furthmore, the changed structure used to report to the X server
that the key types data is changed doesn't actually need to modified
at all in the function. It's already prepped by libX11 with the
correct state for the changes mutter is doing when
XkbChangeTypesOfKey is called.
This commit addresses the above two problems by just removing the
lines causing the issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2039>
Keys in the reserved keycode list are always added for the first group.
Before the previous commit such keycodes were not found unless that was
the current group. But now that we can also find matching keycodes that
are not directly in the current group, this is not necessary anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
Some keys, such as enter or backspace are only bound to a single group,
even if multiple groups are configured. Because the code was previously
only looking for keysyms in the same group as the current one, no
matching keycodes for these would be found if the current group is not
the first group. This was causing those keys to not work on the X11 OSK.
To fix this use the correct action to convert an out of range group for
that key according to its group_info field.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
This effectively changes meta_keymap_x11_get_entries_for_keyval() to
meta_keymap_x11_get_entry_for_keyval() and moves the check if the
keycode maps to the keyval in the current group there. This simplifies
the code a bit and will allow a followup fix.
As a side effect this now also causes the reserved kecodes to be
searched, if no keycodes were found, rather than just when only ones
matching the wrong groups.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
The extra stage update we schedule in `apply_state()` is mainly
needed in two situations:
- a partial update happened only in obscurred or off-screen parts
of a surface
- a surface requests frame callbacks without having done damage,
notably the (in)famous Firefox vsync implementation.
Commit 0330ce1f15 limited the update to cases when the actor
was mapped, breaking it for Firefox in the overview.
Remove the mapped check again and get the stage from the backend,
restoring previous behaviour.
Fixes 0330ce1f15
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1957
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2034>
Avoid having laptops suspend or lock as soon as the power cable is
unplugged as the timeout for those actions when on battery are smaller
than the timeouts when on AC.
- laptop is plugged in, and hasn't been used for X minutes
- laptop is unplugged
- the gnome-settings-daemon power plugin sets up its timeouts for
inactivity for the "on battery" case
- those X minutes of inactivity are still counting, and are above
the level of one of the timeouts (say, suspend or lock screen),
mutter fires the timeouts
- gsd-power activates the action associated with the timeout
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1953
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2029>
If the ancestor a window is transient for has already been unmanaged
when the window is activated via meta_window_activate_full while its
transient_for property still points to that ancestor, this will cause
the already unmanaged ancestor to get added to the windows workspace.
This is after the ancestor had its workspace set to NULL when it was
unmanaged, causing this to look like an actual workspace change. Once
the window has been added to the workspace, it will never be removed
again, because the it has already been unmanaged. This confuses things
like the shell window tracker and leads to phantom windows being
considered present for apps that are not even running anymore.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4184
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2003>
When a test failed, an exception would be raised. This meant that the
mocked service would stay alive, and the test case being run eventually
failing due to a timeout, not the failure itself.
Fix this by catching the exception during the test, ensuring that we
tear down properly, then re-raise the same exception again after having
teared down.
This avoids the dead lock, while still printing the appropriate error
message.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2008>
With the introduction of MetaContext, the responsibility for handling
signals was changed to the application (e.g. GNOME Shell) using
libmutter. What wasn't fixed was making the stand-alone mutter do the
equivalent as well. This commit fixes this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2007>
