When using Xwayland-on-demand (default), if the (experimental) autoclose
features is enabled, we can rely on Xwayland's auto-terminate feature
instead of explicitly killing the Xwayland process.
With it, gone is the mechanism that was added to check the X11 clients
connected and their executable to check whether we can (safely) kill
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
The connection to the Xserver for the X11 window manager part of mutter
even on Wayland may prevent the Xserver from shutting down.
Currently, what mutter does is to check the X11 clients still connected
to Xwayland using the XRes extension, with a list of X11 clients that
can be safely ignored (typically the GNOME XSettings daemon, the IBus
daemon, pulseaudio and even mutter window manager itself).
When there is just those known clients remaining, mutter would kill
Xwayland automatically.
But that's racy, because between the time mutter checks with Xwayland
the remaining clients and the time it actually kills the process, a new
X11 client might have come along and won't be able to connect to
Xwayland that mutter is just about to kill.
Because of that, the feature “autoclose-xwayland” is marked as an
experimental feature in mutter and not enabled by default.
Thankfully, the Xserver has all it takes to manage that already, and
is even capable of terminating itself once all X11 clients are gone (the
-terminate option on the command line).
With XFixes version 6, the X11 clients can declare themselves
"terminatable", so that the Xserver could simply ignore those X11
clients when checking the remaining clients and terminate itself
automatically.
Use that mechanism to declare mutter's own connection to the Xserver as
"terminatable" when Xwayland is started on demand so that it won't hold
Xwayland alive for the sole purpose of mutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
Adding a <dbus/> element containing a boolean (yes/no) determines
whether org.gnome.Mutter.DisplayConfig ApplyMonitorsConfig will be
callable. The state is also introspectable via the
ApplyMonitorsConfigAllowed property on the same interface.
For example
<monitors version="2">
<policy>
<dbus>no</dbus>
</policy>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The test aims to verify that setting the following policy
<policy>
<stores>
<store>system</store>
</stores>
</policy>
only applies monitor configurations from the system level.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
This adds a way to define a way, at the system level, to define a policy
of how monitor configuration files are loaded.
The intended use case is to e.g. either prefer system level monitor
configurations before user levels, or only allow system level
configurations.
Examples:
Prefer system over user level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
<store>user</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Only allow system level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
strncmp() always return 0 if the passed length is 0. What this means is
that whatever the first string check happens to be, if the parsed XML
cdata was empty (e.g. if we got <element></element>), the first
condition would evaluate to true, which is rather unexpected.
Fix this by making sure the string length is correct first. Also move it
into a helper so we don't need to repeat the same strlen() check every
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The way device backends implement power saving differ, and power saving
needs to contain nothing incompatible in the same update. Make it
impossible to e.g. mode set, page flip, etc while entering power save by
not using MetaKmsUpdate's at all for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
When we're predicting state, i.e. when having posted an update while
avoiding reading KMS state, copy the predicted state, update the actual
state, and check that the predicted state matches the newly updated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
It was a bit scattered, with it being split between MetaKms and
MetaKmsImpl, dealing with MetaKmsDevice and MetaKmsImplDevice
differentation. Replace this by, for now, single entry point on
MetaKmsDevice: meta_kms_device_process_update_sync() that does the right
thing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
As other KMS tests, depends on being DRM master and vkms being loaded.
Currently consists of a sanity check that checks for the expected set of
connectors, CRTCs, planes, etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
Right now gamma is set only via the D-Bus API (from gsd-color), but the
actual gamma isn't right after SetCrtcGamma(), meaning if one would call
GetCrtcGamma() right after setting it, one would get the old result.
Avoid this by getting the "current" CRTC gamma from the cache we manage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
In order to support dynamic imports, gjs added an implicit mainloop
that can drive the main context independently from other mainloops
like the one from GApplication or MetaContext.
That means that sources can now get dispatched to the main context
from the moment the plugin is started, resulting in a crash as the
association between compositor and plugin manager doesn't exist until
meta_plugin_manager_new() returns.
Make sure this doesn't happen by only starting the plugin after
meta_plugin_manager_new() has returned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2242>
When privacy screen is changed and this happens on explicit user request
(that is not a setting change) we should notify about this via an OSD.
To perform this, we keep track of the reason that lead to a privacy
screen change, and when we record it we try to notify the user about.
When the hardware has not an explicit hotkey signal but we record a
change we must still fallback to this case.
Fixes: #2105
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Privacy screen events on connector are handled as notification events
that won't cause any monitors reconfiguration but will emit monitors
changed on DBus, so that the new value can be fetched.
We monitor the hardware state so that we can also handle the case of
devices with hw-switchers only.
In case a software state is available it means we can also support
changing the state, and if so expose the state as unlocked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
When both a setting change and a monitor change happens we need to
ensure that the monitor settings are applied.
This is currently only related to privacy settings, but will in future
also handle other monitor parameters such as brightness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Some monitors support hardware features to enable the privacy screen
mode that allows users to toggle (via software or hardware button) a
state in which the display may be harder to see to people not sitting
in front of it.
Expose then this capability to the monitor level so that we can get its
state and set it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
In some cases mutter is started in the user scope from a TTY (for
example using toolbox). Using sd_pid_get_session fails because it's not
in the session scope so it falls back to the primary session
(sd_uid_get_display). We want to start mutter on the TTY we started
mutter on however. Instead of relying on the scope to figure out the
correct session we first look at $XDG_SESSION_ID which is set by
systemd_pam.so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2254>
It is possible that we never create a cached state for a surface
even if it is synced. That is the case if `commit()` is never called.
We still need to call `apply_state()` in this case in order to run
e.g. `role_post_apply_state()` or `parent_state_applied` on subsurfaces.
So just ensure to initialize the cached state instead of bailing out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
Subsurfaces can be effectively synced indirectly via their ancestors.
Right now such indirectly synced surfaces don't apply their cached
state when their ancestor effectively becomes desync as by the time
we call `parent_state_applied()` on them, they are considered as
desync.
Thus sligthly reoder things so when the ancestors becomes desync
and applies its state, those surfaces still count as synced and
will thus apply their cached state as well.
While on it, add a check to prevent `set_desync()` to have side
effects when the target surface is not currently synced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
At first glance the `goto` looks like a loop, or potentially an infinite
loop. It's not a loop because the mode has changed at that point to
`META_SHARED_FRAMEBUFFER_COPY_MODE_PRIMARY`. But we can make it more
obvious and avoid the need for a goto.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2240>
The stage window is an interface, that added properties, that were only
then actually managed by MetaStageImpl. Shuffle things slightly, and let
the MetaStageImpl object deal with these things itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
What the keymap eventually is after, are things handled by the actual
backend (MetaBackendX11), so let it keep a pointer to that. This
eliminates some usages of globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
It tests that if we go from (x is the pointer cursor)
+--------+
| |
| X |
+--------+
to
+----------------+
| |
| |
+--------+ |
| | |
| X | |
+--------+----------------+
i.e. making sure that X ends up somewhere within the logical monitor
region.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2237>
These will be skipped by default, but can be run from a TTY for easier
debugging by doing:
dbus-run-session -- meson test -C build --suite mutter/native/tty --setup plain
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This commit makes it possible to run test executables in a test
environment constructed of a virtual machine running the Linux kernel
with the virtual KMS driver enabled, and a mocked system environment
using meta-dbus-runner.py/python-dbusmock.
The qemu machine is configured to use 256M of memory, as the default
128M was not enough for the tests to pass.
Using qemu is also only made possible on x86_64; more changes are needed
for it to be runnable on aarch64, so add a warning if it was enabled on
any other architecture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This is needed if one wants to run the test suite parts that need KMS or
evdev access in a virtual machine.
However, only initiate these methods if the meta-dbus-runner.py program
was launched with --kvm, as it's only suitable for using while running
as root in a virtual machine.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When we test, we might not have a systemd session to rely on, and this
may cause some API we depend on to get various session related data to
not work properly. Avoid this issue by passing fallback values for these
when we're running in test mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
There will be another mode added later, 'test'; prepare for this by
changing the existing "mode" boolean ('headless') to a mode, which is
either 'default' or 'headless'. Checking the is_headless variable is
changed to using the function is_headless(), except for one place, being
VT switching, which in preparation is only allowed on the 'default'
mode. Other places where it makes sense, the conditions are changed to
switch statements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When running in KVM, the EGL driver supports querying the render node
path, but it returns NULL. Handle that better by falling back to
querying the device main device file, instead of falling back on v3 of
the protocol and logging a warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
Some API will return NULL or the equivalent; sometimes it's an error,
and sometimes it's not, and the way to check that is by looking at the
return value of eglGetError(). When we check this, don't set the GError
if it returned EGL_SUCCESS, as that indicates that the return value is
expected behavior, and not an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
There was a sanity check that complained if there was still a "next
framebuffer" when disposing an onscreen. This is correct to complain
about under normal operation, as we always wait until receiving the page
flip callback before cleaning up the onscreen and their state.
However, when there are many hotplugs occurring, we might end up with
race conditions when the above sanity check is not valid: when we have
more than one monitor active, paint 1 one of them, but receive a hotplug
event before we paint the other(s), we will discard the already painted
onscreen before really issuing a page flip.
In this situation, we will have the "next framebuffer", but having that
is not a bug, it's a race condition, thus to not leak in this situation,
make sure to clean up the next framebuffer here too.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2081
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2225>
If there are any pending updates, for example if we painted one of
multiple monitors but without having posted the update due to waiting
for another monitor to be painted, but before we paint all of them and
post the update, another hotplug event happens, we'd have stale pending
KMS update. When that update eventually would be processed, we'd try to
apply out-of-date updates which may contain freed memory.
Fix this by discarding any update when we're rebuilding the views. We
can be sure not to need any of the old updates since we're rebuilding
the whole content anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1928
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2216>
Following the EGL_KHR_swap_buffers_with_damage specification, the
surface damage used by eglSwapBuffersWithDamage does not need to
contain the damage history.
Rework that to reduce the amount of rectangles that get passed to
the backend.
Also rework some of the regions that were using fb_clip_region and
missing the last scaling to support fractional scaling.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2089>
When the before-paint function is executed, it's only purpose
is to check if there's any scanout queue, and immediately
record it if any.
However, since [1], we regressed in this specific case with the
introduction of an idle callback in the before-paint function.
The regression only happens when the PipeWire stream is using
DMA-BUF buffers, and it would operate as follows:
1. In before-paint, when there's a scanout available, we queue
an idle callback to capture the monitor. The idle callback
(almost always) executes after the scanout is pulled from
the stage view
2. meta_screen_cast_stream_src_maybe_record_frame() is called
by the idle callback. In the DMA-BUF case, it then runs
meta_screen_cast_monitor_stream_src_record_to_framebuffer()
3. In meta_screen_cast_monitor_stream_src_record_to_framebuffer(),
because the stage view doesn't have a scanout anymore, it
ends up calling cogl_blit_framebuffer() with the stage view
framebuffer. This is the regression bug.
This regression presents itself in the form of the screencast
stream showing the desktop when there's an unredirected fullscreen
application window running.
Revert before-paint - and only that - back to immediately capturing
any available scanout. Only record these frames when the target
buffer is a DMA-BUF handle. Nothing is captured on before-paint if
the stream is not using DMA-BUF, since the regular paint routine
will handle these frames regularly post-paint.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1914
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
Next commits will reintroduce a certain behavior of stage
capturing that can only happen with DMA-BUF buffers. To
control this, add a new flag tp MetaScreenCastRecordFlags
for this behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
If a Wayland subsurface is the topmost actor, consider in for
scanout as well. This will extend our scanout capabilities to apps
like Firefox
While on it, correct a unnessary type check to a NULL check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
On Wayland a window actor may have more than one surface actor,
most importantly when subsurfaces are used.
Add a new function to request the one which is at the top -
it will be used in the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
If the EGL header is not new enough, it will not contain that relatively
new macro definition, so to avoid breaking compilation, define it
ourselves for now. Should be possible to remove after some time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2214>
We save the window rect before going fullscreen to a dedicated variable,
so we can go back to the correct dimension. We also have a dedicated
variable for returning from other window states, e.g. maximized, and
this one we initialized when creating the MetaWindow. This meant that we
could always rely on this being up to date on X11 windows that were
mapped maximized or fullscreen.
What the commit that introduced the saved rect dedicated for going
unfullscreen missed was to initialize the new saved rectangle too when
creating the MetaWindow. This resulted in windows mapped as fullscreen
often ending up misbehaving when unfullscreening, as mutter would tell
them to unfullscreen to 0x0.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1786
Fixes: a51ad8f932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2210>
Since every input stream now uses its own window, the X property used to
transfer the data no longer has to be unique, so we can stop generating
those unique names. This avoids creating a new atom for every transfer
since those are never freed, neither on the shell nor on the server
side. Also don't unnecessarily duplicate other strings that are
(almost) never used and get them from the atom in the rare case when
they are needed.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1328
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
When there are two (or more) concurrent XConvertSelection requests with
the same target, selection and window and the data is large enough for
SelectionNotify events to overlap. This can result in the affected streams
being considered completed without any data being transferred.
While regular mutter/shell code does not make use of concurrent
XConvertSelection requests with the same targets, some extensions might.
Such as for example a clipboard manager that like the built-in clipboard
manager tries to read the selection on owner-changed.
One potential solution would be to make sure the event is for the correct
property, but not all clients seem to support concurrent requests for the
same targets but different properties on the same window.
This commit instead changes the streams to use their own window which
seems to be more widely supported.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4034
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
This is a preparation for each input stream creating its own window. It
moves deleting the property from meta_x11_selection_input_stream_xevent
where it can run after the stream has been finalized to a spot where
the stream still exists. Use an error trap in case the property was not
set by the client, such as when the conversion failed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
This significantly increases the chance of a fullscreen surface buffer
being scanned out instead of being painted via composition. This is
assuming the client supports the DMA buffer feedback Wayland protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
This API can be used to construct a MetaKmsUpdate with plane assignments
that in isolation will be tested against the current KMS state. How it
is tested depends on the KMS implementation; in the simple / legacy KMS
backend, the tests are identical to the current scanout requirements
(dimension, stride, format, modifiers, all must match), and with atomic
KMS, it uses the TEST_ONLY on a real constructed atomic mode setting
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
Whenever a surface is promoted as a scanout candidate by
MetaCompositorNative, it'll get a CRTC set as the candidate CRTC.
When a client asks for DMA buffer surface feedback, use this property to
determine whether we should send a scanout feedback tranche.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1959>
The final tick of a timeline is >= its duration, but when using ticks that
are slightly in the future ("next presentation time") this means the final
tick will execute and complete the timeline up to one frame interval before
the timestamp of that final tick.
For the single clock test we now just check if the overall duration is
within one frame of the expected timeline duration.
The dual clock (switching) test needs a threshold of two frames because
starting each new clock creates a phase shift (error) of up to one frame.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2161>
We're in the destructor, it's pointless to unset the userdata as we'll
never ever see a request being invoked with it ever again, since the
resource itself will be destroyed or marked as destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2202>
When rendering to a buffer that is not the stage view buffer, we can not
know where the buffer will be displayed on the screen. As a result we
also can not know what translation would need to be applied to culling.
This was causing glitches when the gnome-shell magnifier was applying
offscreen effects. ClutterOffscreenEffect causes MetaWindowGroup to be
rendered to an offscreen buffer at an offset, because it draws to a
slightly larger texture with an accordingly translated origin. This
translation then later is canceled out again when the offscreen buffer
is drawn. To meta_actor_painting_untransformed() however which only sees
the translation used when drawing to the buffer this looked like the
window group was being rendered at the offset. This then lead to
redraw_clip getting translated accordingly, resulting in wrong
coordinates used for culling.
Similarly this was leading to issues when taking area screenshots while
at 1x zoom.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1678
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4876
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2080>
Refresh rates >60Hz become ever more common. In order to allow users
to keep hight refresh rates when not running at a natively advertized
resolution, add common refresh rates to our fallback modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
Right now we often add a duplicate fallback mode that's almost
identical to the native mode. This adds unnecessary clutter to
UIs, thus filter out such modes.
In order to keep the code small, use `MetaCrtcModeInfo` directly
instead of recalculating the values. And to keep consistency, do
the same in the loop above.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
This is so that it can unregister from it on tear down. The tracker owns
references to cursors too, but this cycle is already broken as the
backend calls 'g_object_run_dispose()' when tearing the cursor tracker
down.
Fixes a crash on shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2181>
An incorrect assumption that after mode set there would be no pending
page flips was made. This meant that if there was a mode set, followed
by a page flip, if that page flip was for a CRTC on a now unused GPU,
we'd crash due to the renderer GPU data having already been freed. This
commit avoids that by keeping it alive as long as the page flips are
still in the air. It fixes crashes with backtraces such as
0) meta_render_device_get_egl_display (render_device=0x0)
at ../src/backends/native/meta-render-device.c:320
1) secondary_gpu_state_free (secondary_gpu_state=0x1c8cc30)
at ../src/backends/native/meta-onscreen-native.c:560
2) meta_onscreen_native_dispose (object=0x1cb65e0)
at ../src/backends/native/meta-onscreen-native.c:2168
3) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3540
4) g_object_unref (_object=0x1cb65e0)
at ../gobject/gobject.c:3470
5) clutter_stage_view_finalize (object=0x1cbb450)
at ../clutter/clutter/clutter-stage-view.c:1412
6) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3578
7) g_object_unref (_object=0x1cbb450)
at ../gobject/gobject.c:3470
8) meta_kms_page_flip_closure_free (closure=0x1d47e60)
at ../src/backends/native/meta-kms-page-flip.c:76
9) g_list_foreach (list=<optimized out>, func=0x7fb3ada67111 <meta_kms_page_flip_closure_free>, user_data=0x0)
at ../glib/glist.c:1090
10) g_list_free_full (list=0x1cb4d20 = {...}, free_func=<optimized out>)
at ../glib/glist.c:244
11) meta_kms_page_flip_data_unref (page_flip_data=0x1c65510)
at ../src/backends/native/meta-kms-page-flip.c:109
12) meta_kms_callback_data_free (callback_data=0x227ebf0)
at ../src/backends/native/meta-kms.c:372
13) flush_callbacks (kms=0x18e2630)
at ../src/backends/native/meta-kms.c:391
14) callback_idle (user_data=0x18e2630)
at ../src/backends/native/meta-kms.c
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
This ensures we don't have any left over cursor GPU buffers (via
gbm_bo's) after destroying the corresponding gbm_device (owned by
MetaRenderDevice).
Fixes crashes with backtraces such as
1) meta_drm_buffer_gbm_finalize at ../src/backends/native/meta-drm-buffer-gbm.c:450
4) invalidate_cursor_gpu_state at ../src/backends/native/meta-cursor-renderer-native.c:1167
9) update_cursor_sprite_texture at ../src/wayland/meta-wayland-cursor-surface.c:70
10) meta_wayland_surface_role_apply_state at ../src/wayland/meta-wayland-surface.c:1869
11) meta_wayland_surface_apply_state at ../src/wayland/meta-wayland-surface.c:832
12) meta_wayland_surface_commit at ../src/wayland/meta-wayland-surface.c:993
13) wl_surface_commit at ../src/wayland/meta-wayland-surface.c:1158
14) ffi_call_unix64 at ../src/x86/unix64.S:76
15) ffi_call at ../src/x86/ffi64.c:525
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
During tear down, if anything teared down after the seat tries to get
the cursor renderer, we'd crash trying to get it as the seat would
already be gone. Avoid this by returning NULL when there is no seat.
It's assumed that any path that will happen during tear down that relies
on getting the cursor renderer will gracefully handle it not being
present, e.g. by relying on the cursor rendering cleaning up itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
Most clients nowadays switched to buffer damage, most notably Mesa
and Xwayland. Thus lets avoid the extra cost of allocating three
`cairo_region_t`s and doing some calculations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
If no viewport is set, the neutral viewport is the surface size
without viewport destination size applied - i.e. transform and
scale applied to the buffer size. Change it accordingly, giving
us the same values we'd return in `get_width` in this case.
As result, this only changes cases where a viewport destination
size but no viewport source rectangle is set.
The change fixes exactly such cases, e.g. the Gstreamer Wayland
sink. Can be tested with: `gst-play-1.0 --videosink=waylandsink`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
When checking panel orientation on logical monitors we should take
panel orientation transform to check it's properly applied, so ensure
that we're checking the right one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
Commit 2289f56112 ("monitor-manager: Don't apply unneeded orientation
changes") added an early return to handle_orientation_change () in case
the transform is unchanged.
But this did not take the correction of the transform for devices
with 90° mounted panels into account causing a desired orientation
change to get skipped if the new orientation matches the corrected
logical orientation from the previous transform setting.
Fix this by calling meta_monitor_crtc_to_logical_transform () on the
transform before comparing it, matching the
meta_monitor_crtc_to_logical_transform () call in
create_for_builtin_display_rotation ().
Related: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
When Xwayland was not initalized, we'd still clean things up. What this
accidentally meant was that the uninitialized display number 0 was
cleanud up, which very likely was main display of the host session.
What this meant in practice was that /tmp/.X11-unix/X0 was often
removed, causing every Flatpak X11 application to fail to start until
Xwayland was restarted nad the X0 socket file was restored.
Fix this in two ways: firstly only shutdown Xwayland if we ever started
it, i.e. if the X11 display policy was not 'disabled'. This should fix
the issue most of the times. Secondly only clean up the socket if it was
ever initialized. This should fix things if the socket creation failed,
as if it did, the name would be set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2162>
A popup surface can be remapped multiple times using the same
wl_surface, if a new xdg_popup object is created. To properly handle
this, we need to reset the 'dismissed_by_client' boolean to false, as
otherwise we won't allow new buffer commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
Change to use the headless backend with a virtual monitor, instead of
the nested backend. This means tests can create and use virtual input
devices, which isn't possible with the nested backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
The roundtrip in the handle-configure function could in theory (and in
practice in the future) happen to receive another configure event. If we
send yet another invalid geometry the second time, we log one time too
many in the server, which fails the test. Avoid this by ignoring the
second configure event; it's enough to pass through the error handling
path once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
We are using internal API that has the benefit of checking that the
focus surface still matches, but has the drawback that it does not
check the MetaWaylandKeyboard state.
In order to fix this, look for keyboard focus and serial matches
specifically when triggering activation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2148>
The GBM support in the NVIDIA driver is fairly new, and to make it
easier to identify whether a problem encountered is related to using GBM
instead of EGLStreams, add a debug environment variable to force using
EGLStream instead of GBM.
To force using EGLStream instead of GBM, use
MUTTER_DEBUG_FORCE_EGL_STREAM=1
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2045
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2132>
We created pipes for the stdout of the spawned mock services. This
resulted in the pipe being filled if enough things were logged, as
nothing was reading from it. Change this to allow for two modes:
verbose - where output is logged to the parent stderr, as well as non-verbose
(default) - where things are logged directly to /dev/null.
This fixes frozen tests when running with --repeat and a high enough
repeat count.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2139>
Since this signal is in a hot path during input handling, it makes sense
not to have this be a signal at all, currently most of the time spent in
it is in GLib signal machinery itself.
Replace it with a function/user data pair that are set on the sprite
itself. Only the places that create an sprite are interested in hooking
one ::prepare-at behavior per sprite, so we can do with a single pair.
This makes meta_cursor_sprite_prepare_at() inexpensive enough.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Let the meta_cursor_sprite_realize() function return a boolean value
telling whether there was an actual change in the sprite cursor. E.g.
the surface/icon for it changed in between.
This is used in the native backend to avoid converting/uploading again
the cursor surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
This test is injecting input events without checking the correct stage/
device state. Wait for the pointer to enter the stage, so the event gets
correctly forwarded across.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Listen to changes in MetaWindow::is-alive, so that the pointer
can logically leave the surface as soon as that happens. This
helps prevent flooding the client socket while it is stalled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
Change some things in these "app is alive" checks:
- The dialog timeout is separated from the ping timeout, in order
to show it again at a constant rate after dismissing, despite in
flight pings. It still shows immediately after the first failed
ping.
- As we want to tap further into is-alive logic, MetaWindow now
made it a property, that other places in code can fetch and
subscribe.
- Motion events trigger ping (as long as there was none other in
flight for the same window), and are counted between ping and
pong, in order to preemptively declare the window as not alive
before there is trouble with event queues being overflown.
This results in a separate logic between "the application does
not respond" and "we are showing the close dialog" so that the
former may get triggered independently.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
If we were cancelled, it could mean we teared down, meaning fetching
manager instances will attempt to fetch past freed instances. Handle
this by waiting with the fetching until we know we weren't cancelled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2140>
MetaBackend can now show whether it is in headless mode or not
using a vfunc is_headless.
Fallback of is_headless returns FALSE.
MetaBackendNative implements is_headless returning its
is_headless property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2130>
This is a strange thing to do since MetaInputMapper also does take care of
devices with an output configured through settings, since we might have
devices that were configure through settings exclude other devices that
belong together with an output (e.g. a display-integrated tablet).
This was essentially here as a last resort to avoid matching two very
similar looking tablets to one of two very similar looking outputs. There
was a 50% chance already that the choice was wrong, and now these devices
can all be configured specifically through settings, so this shouldn't
be missed either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
Non-display-attached tablets (e.g. Intuos) may find no match, which
should mean "use the span of all monitors", not "pick one for me".
Reserve this fallback to touchscreen devices, since these might
still benefit from it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
The matrix and aspect ratio of the tablet is irrelevant on pads, and
it actually triggers warnings when trying change that on those devices:
gnome-shell:42536): mutter-CRITICAL **: 17:22:41.994: meta_input_device_native_get_mapping_mode_in_impl: assertion 'device_type == CLUTTER_TABLET_DEVICE || device_type == CLUTTER_PEN_DEVICE || device_type == CLUTTER_ERASER_DEVICE' failed
This is unnecessary to do on pad devices, these just need to be moved
together with their respective stylus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
Since the completion callback (on_switch_workspace_effect_complete) sets
priv->tml_switch_workspace1 to NULL, the unref was trying to unref NULL,
and the reffed ClutterTimeline was not getting unreffed.
This could be triggered by rapidly switching workspaces, switching again
before the animation of the initial switch was done.
Found while working on #2038.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2120>
This avoids the following crash, that could happen in certain rare race
conditions, e.g. in tests:
0) wl_closure_invoke (closure=0x2fbf9e0, target=0x2e5b3d0, opcode=0)
at ../src/connection.c:1014
1) wl_client_connection_data () at ../src/wayland-server.c:432
2) wl_event_loop_dispatch () at ../src/event-loop.c:1027
3) wayland_event_source_dispatch () at ../src/wayland/meta-wayland.c:104
4) g_main_dispatch () at ../glib/gmain.c:3381
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2127>
Passing a NULL workspace does not make sense, since it silently
returns no windows. Mandate that a workspace is explicitly requested,
and while at it check the other arguments as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2124>
The cursor renderer shouldn't assume all the CRTCs of a logical are KMS
CRTC's, as we'll end up checking hardware capabilities for CRTC's of
virtual monitors as well, when they were created to not embed the cursor
image directly in the framebuffer.
Instead, use the newly introduced API for checking CRTC cursor
capabilities. This fixes a crash with the following backtrace:
0) get_plane_with_type_for at ../src/backends/native/meta-kms-device.c:150
1) meta_kms_device_get_cursor_plane_for at ../src/backends/native/meta-kms-device.c:173
2) has_cursor_plane at ../src/backends/native/meta-cursor-renderer-native.c:678
3) foreach_crtc at ../src/backends/meta-logical-monitor.c:247
4) meta_monitor_mode_foreach_crtc at ../src/backends/meta-monitor.c:1920
5) meta_logical_monitor_foreach_crtc at ../src/backends/meta-logical-monitor.c:274
6) crtcs_has_cursor_planes at ../src/backends/native/meta-cursor-renderer-native.c:718
7) should_have_hw_cursor at ../src/backends/native/meta-cursor-renderer-native.c:881
8) meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1085
9) meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:411
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2000183
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1991>
On a KMS backed CRTC, hardware cursor are supported when there are
cursor planes to assign them to. Note that when using legacy mode
setting, fake cursor planes are added when adequate.
On virtual CRTCs, used with virtual monitors, the equivalent of hardware
cursor are always supported, as they are sent using embedded PipeWire
stream metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1991>
This can happen if a texture was newly assigned to the actor, but the
unobscured region hasn't been updated yet. Without bailing here, the
actor would display correctly via direct scanout, but other parts of
mutter would continue considering it obscured, which would e.g. result
in no frame callbacks getting sent for its surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1636
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2112>
Previously we chose to only anti-alias texels inside the boundary
(`clip_radius - 1.0`) but zoomed in you could see it was slightly smaller
than the correct curve (#2024).
Similarly if you choose to only anti-alias texels outside that edge
(`clip_radius + 1.0`) then you'd get an overly convex curve that doesn't
match up with the straight line sections.
So now we anti-alias texels that intersect the circle boundary, regardless
of which side they are mostly on. For efficiency we define "intersect" to
mean any texel whose center is within 0.5 of the theoretical edge.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2102>
It was dropping to zero after the first frame because it hadn't been
incremented high enough. So the second frame would crash with:
```
#0 g_type_check_instance_cast
#1 META_DRM_BUFFER
#2 copy_shared_framebuffer_cpu
```
That's the CPU-copy path (fallback-fallback) that probably no one is using
but it does work after this fix. Exactly the same issue as was fixed
in `copy_shared_framebuffer_primary_gpu` by 36352f44f9.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2104>
A client can create a token without any seat, serial, or surface. In
this case, we'd still try to grab, which would run into some unforseen
code paths, potentially resulting in the following crash:
0) meta_wayland_tablet_seat_device_added (tablet_seat=0x55dff4271c90,
device=0x7f87b80655b0) at
../src/wayland/meta-wayland-tablet-seat.c:200
1) meta_wayland_tablet_seat_new (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-tablet-seat.c:283
2) meta_wayland_tablet_manager_ensure_seat (manager=manager@entry=0x55dff3ec7b40,
seat=seat@entry=0x0) at
../src/wayland/meta-wayland-tablet-manager.c:239
3) meta_wayland_tablet_manager_ensure_seat (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-touch.c:595
4) meta_wayland_seat_get_grab_info (seat=0x0, surface=0x55dff43ff5b0,
serial=0, require_pressed=0, x=0x0, y=0x0) at
../src/wayland/meta-wayland-seat.c:479
5) activation_activate (...) at
../src/wayland/meta-wayland-activation.c:261
Fix this by not trying to grab if not enough parameters was passed when
creating the token. Also add a test case that reproduces the above
crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
When an activation times out, we'll be signalled two signals on the
startup sequence object: "timeout", and "complete".
Normally, the "complete" signal is emitted when a startup sequence is
completed succesfully by it being used for activation, and in this case,
the xdg_activation implementation should remove the sequence from the
startup notification machinery.
However, in the timeout case, we should not remove it, as the startup
notification machinery itself will deal with this. If we would, we'd end
up with use-after-free issues, as the sequence would be finalized when
removed the first time.
To avoid this, just clean up the Wayland side in the "timeout" signal
handler, leaving the "complete" signal handler early out if it was
already handled by it.
This avoids crashes like:
0) g_type_check_instance (type_instance=type_instance@entry=0xdd6740)
1) g_signal_handlers_disconnect_matched (instance=0xdd6740, ...)
2) meta_startup_notification_remove_sequence (sn=0x4cc890,
seq=0xdd6740) at
../src/core/startup-notification.c:544
3) startup_sequence_timeout (data=0x4cc890, ...) at
../src/core/startup-notification.c:504
4) g_timeout_dispatch (...) at ../glib/gmain.c:4933
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
We set it via setenv(), and might not have the MetaX11Display at hand.
This fixes a crash when the stuck-client dialog (using zenity) appears
without any X1 client having appeared.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
This test ensures that windows that were resized such that they extend
beyond the screen will be moved to be fully on the screen (if possible).
This has been working on X11 since forever, but on Wayland only since
the last commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
The previous code was trying to detect client resizes by only
considering resizes without any pending configurations as client
resizes. There can however be pending configurations that do not involve
resizing, such as ones triggered by state changes. These may also stay
unacknowledged by the client until the next size change. This was
causing client resizes after showing the window (and therefore changing
its status to focused) to not be detected as client resize.
Fix this by checking whether the queue has any configuration with size
changes rather than just whether it is empty.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2023
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
Used to log multiple line entries. Just make continue prefix things, no
need to mess with maybe-prefixing; it'll just complicate using some less
custom logging functionality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2094>
If some connectors disappeared, but the rest didn't change, we missed
actually removing the ones that disappeared, as we incorrectly assumed
nothing changed. Fix this by only assuming nothing changed if 1) we
didn't add any connector, and 2) we have the same amount of connectors
as before the hotplug event. The connector comparison checking makes
sure we report changes if anything of the still available connectors
changed.
Fixes: a8d11161b6
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
When a docking station is disconnected, a few previously existing DRM
connectors may now be gone. When this happens, getting them via the
libdrm API results in NULL pointers returning, and we need to handle
this gracefully by making sure the connector state is properly updated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
The 'stop_after_next' will execeute one command, then not return to the main
loop until a 'continue' command is passed. Commands will still be
processed between 'stop_after_next' and 'continue'.
This is intended to be used to induce race conditions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
Currently the stored unconstrained_rect is only ever updated if there
was a move, resize or state change according to the move_resize_internal
implementation. For Wayland windows however resizes or state changes
are done in two steps, first the new configuration is sent to the client
and then once client acknowledges it, it is set on the mutter side in
another move_resize_internal call. Only the second call would result in
the unconstrained_rect being updated.
This started causing problems when unfullscreening windows was
immediately followed by a strut change. These strut changes started
happening in gnome-shell due to the visibility of the panel now being
considered for the struts and the presence of a fullscreen causing it to
be hidden until unfullscreen. In this situation first the unfullscreen
would resize the window to its pre-fullscreen size as expected, but then
the strut change triggers another window resize. This window resize is
based on the stored unconstrained_rect, which is still at the fullscreen
size because the unfullscreen resize only has sent its configuration,
but it has not been acknowledged yet. As a result the strut change
causes a resize to the fullscreen size which due to the constraints now
looks like a maximized window.
To fix this always update the unconstrained_rect when the requested size
has changed, but not when a previous request has been acknowledged
unless it is originating from the client itself.
If this included the move_resize_internal call from acknowledging the
size as well, it would be possible for this to be delayed long enough on
the client side to overwrite an intermediate resize originating from
mutter. And if this did not include resizes originating from the client,
clients would not be able to set an initial window size.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1973
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
meta_window_wayland_finish_move_resize() is called for both, finishing
a resize that has been requested through/by mutter and for resizes
directly done by the client. This introduces a CLIENT_RESIZE flag to
differentiate the former from the latter. Having this distinction is
required to know what the last requested size by either the client or
mutter is while ignoring older requests that might only have been
applied now.
This excludes client resizes when there are still pending
configurations, because the resize is known to be only temporary.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
Because POSIX sh was, with hindsight, not a particularly well-designed
programming language, if we don't 'set -e', then we'll respond to failure
of a setup command such as cd by carrying on regardless.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2009>
The assumption here seems to be that it's an overlay onto the
current environment which would make sense; but the implementation in
gnome-desktop-testing currently removes all other environment variables
(see GNOME/gnome-desktop-testing#1). This causes test failure when the
tests are run in Debian's autopkgtest framework, possibly because PATH
is cleared.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2009>
Systems with AMD GPUs do not take advantage of Mutter's zero-copy path
when driving DisplayLink screens. This is due to a very slow CPU access
to the zero-copy texture. Instead they fall back on primary GPU doing a
copy of the texture for fast CPU access. This commit accelerates texture
copy by working through damage regions only.
Tests on a 4K screen with windowed applications show significant
reduction of GPU utilisation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2033>
If one would end up with an actor attached to mapped actor, where the
attached actor doesn't itself have an up to date stage view list while
listening on the stage for updating, when clearing the stage views of
the list, anything that would query the stage views list at this time
would end up accessing freed memory.
This could happen if
1) An actor was added to a newly created container actor attached to
the stage
2) The actor got a timeline attached to it
3) The actor was moved to a container that already was mapped
4) A hotplug happened
After (1) both the container and actor would not have any stage views.
After (2) the timeline would listen on the stage for stage views
updates. After (3) the actor would still listen on the stage for stage
views updates. When (4) happened, the actor would be signalled when the
stage got its stage view cleared, at which point it would traverse up
its actor's tree finding an appropriate stage view to base its animation
on. The problem here would be that it'd query the already mapped
container and its yet-to-be-cleared stage view list, resulting in
use-after free, resulting in for example the following backtrace:
0) g_type_check_instance_cast ()
1) CLUTTER_STAGE_VIEW ()
2) clutter_actor_pick_frame_clock ()
3) clutter_actor_pick_frame_clock ()
4) update_frame_clock ()
5) on_frame_clock_actor_stage_views_changed ()
6) g_closure_invoke ()
7) signal_emit_unlocked_R ()
8) g_signal_emit_valist ()
9) g_signal_emit ()
10) clear_stage_views_cb ()
11) _clutter_actor_traverse_depth ()
12) _clutter_actor_traverse ()
13) clutter_actor_clear_stage_views_recursive ()
14) clutter_stage_clear_stage_views ()
...
Avoid this issue by making sure that we don't emit 'stage-views-changed'
signals while the actor tree is in an invalid state. While we now end up
traversing tree twice, it doesn't change the Big-O notation. It has not
been measured whether this has any noticible performance impact.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1950
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2025>
Certains keys (such as ~ and |) are in the keyboard map behind the
second shift level. This means in order for them to be input, the
shift key needs to be held down by the user.
The GNOME Shell on-screen keyboard presents these keys separately on
a page of keys that has no shift key. Instead, it relies on mutter
to set a shift latch before the key event is emitted. A shift latch
is a virtual press of the shift key that automatically gets released
after the next key press (in our case the ~ or | key).
The problem is using a shift latch doesn't work very well in the face
of key repeat. The latch is automatically released after the first
press, and subsequent repeats of that press no longer have shift
latched to them.
This commit fixes the problem by using a shift lock instead of a shift
latch. A shift lock is never implicitly released, so it remains
in place for the duration of key repeat.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2045>
The `guess_candidates()` function scores each display that an input
device could be mapped to and then uses the `sort_by_score()` comparator
to find the best option. The function expects the list to be sorted from
best to worst, but the comparator currently sorts them in the opposite
order. This causes the function to end up returning the _worst_ match
rather than the the best. This commit reverses the sort order of the
comparator so that the best display can be returned as intended.
Closes: #1889
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1934>
Mutter already calculates and tracks the damage rectangles to redraw
only areas of the screen that change since the last time a buffer was
used.
This patch extends this by using the EGL_KHR_partial_update extension to
inform the GPU in advance that only those areas will be changed, which
may allow for further optimization.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2023>
This will make clients immediately aware of the output disappearing,
while still allowing for a grace period of 10 seconds for attempting to
bind to it before it turning into a protocol error. This API added as
part of wayland 1.18.
This requires us to not add the output resource to the output resource
list, if the output was made inert. This effectively makes the resource
useless, but that is harmless, since shortly after, the client will
clean it up anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This will be crucial when we start to remove the global directly when an
output is removed, as that means Xwayland might have removed the output
before we managed to get our queries in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
We setup Xwayland in an early phase of the X11 display, before we had a
MetaX11Display, and teared down in a couple of places happening when
tearing down the Xwayland integration if the X server died or
terminated. It was a bit hard to follow what happened and when it
happened. Attempt to clean this up a bit, with things being structured
as follows:
* Early during X11 display connection setup, only setup the rudimentary
X11 hooks, being the libX11 error callbacks, and adding the local
user to XHost.
* Move "initialize Xwayland component" code to a new
'x11-display-setup' signal handler. Things setup here are cleaned up
in the 'x11-display-closing' handler.
* Connect to 'x11-display-setup' and 'x11-display-closing' up front,
and stay connected to these two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This old handling of session files looked on ~/.mutter, which has
been unused and unsupported for a long time. It also had paths were
the GError was leaked. Fix both by dropping the legacy code, and
falling back to the common error paths.
CID: #1502682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
When grabbing the devices, there's no error paths that would quit
late enough that both pointer and keyboard would need ungrabbing,
so the keyboard checks were dead code.
Fix this by dropping the boolean variable checks, and adding goto
labels to unroll the operation properly at every stage.
CID: #1418254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
The monitor orientation tests do a lot of things in sequence. Replace
some of the comments with g_test_message() so that the log from a failed
test gives us a better idea of how far we got.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
Previously, we were waiting up to 300ms for the signal, then proceeding
anyway. However, 300ms is not necessarily long enough to wait on an
autobuilder that might be heavily loaded, particularly if it's a non-x86
with different performance characteristics.
Conversely, if mutter responds to the D-Bus signal from the mock sensor
before we have connected to the signal, then we cannot expect to receive
the signal - it was already emitted, but we missed it. In this case, we
need to avoid waiting.
One remaining use of wait_for_orientation_changes() that would previously
always have timed out was in
meta_test_orientation_manager_has_accelerometer(), which does not
actually expect to see an orientation-changed signal. Make this wait
for the accelerometer to be detected instead.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1967
Bug-Debian: https://bugs.debian.org/995929
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
When we use gbm together with the NVIDIA driver, we want the EGL/Vulkan
clients to do the same, instead of using the EGLStream paths. To achieve
that, make sure to only initialize the EGLStream controller when we
didn't end up using gbm as the renderer backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2052>
This switches the order of what renderer mode is tried first, so that
the gbm renderer mode is preferred on an NVIDIA driver where it is
supported.
We fall back to still try the EGLDevice renderer mode if the created gbm
renderer is not hardware accelerated.
The last fallback is still to use the gbm renderer, even if it is not
hardware accelerated, as this is needed when hardware acceleration isn't
available at all. The original reason for the old order was due to the
fact that a gbm renderer without hardware acceleration would succeed
even on NVIDIA driver that didn't support gbm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2051>
This replaces functionality that MetaRenderDevice and friends has
learned, e.g. buffer allocation, EGLDisplay creation, with the usage of
those helper objects. The main objective is to shrink
meta-renderer-native.c and by extension meta-onscreen-native.c, moving
its functionality into more isolated objects.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
All render devices that have a device file backing them might be able to
allocate dumb buffers, so add a helper for doing that. Will indirectly
result in an error up front on a surfaceless render device due to lack
of a device file.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It might not be needed by the user of the buffer, so don't always
require it up front. Instead make sure that any user that needs it first
calls "meta_drm_buffer_ensure_fb_id()" to create the ID.
Only the plain gbm implementation creates the ID lazilly, the other
still does it on construction due to the objects used to create them
only existing during construction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Mostly calls into gbm_bo_* API, or something somewhat similar when on
dumb buffers. Added API are:
* get offset for plane
* get bpp (bits per pixel)
* get modifier
This will allow users of MetaDrmBuffer to avoid having to "extract" the
gbm_bo to get these metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
The purpose of MetaRenderDevice is to contain the logics related to a
render device; i.e. e.g. a gbm_device, or an EGLDevice. It's meant to
help abstract away unrelated details from where it's eventually used,
which will be by MetaRendererNative and the MetaOnscreenNative
instances.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Meant for MetaRenderer and everything related that deals with turning
composited frames, or client buffers, into mode set updates. This is
slightly related to the debug topic 'kms' is meant for the KMS details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It was a feature relevant for when Clutter was an application toolkit
that wanted the application window to communicate a minimum size to the
windowing system.
Now, clutter is part of the windowing system component, so this feature
doesn't make any sense, so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
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>
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>
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>
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>
When the native backend is paused we still process the udev events
even though this isn't needed and may just cause unneeded events to be
triggered afterwards.
Since we'll resume with full changes on such event, we can just block
the signal hander when paused and restore it afterwards.
As per this we can cleanup also a bit the device adding signal handling
given that now we don't have to disconnect/reconnect it again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Resume happens after we may have received various events that we've
ignored, so at this point we need to just emit an hotplug event like if
everything changed so that user settings may be re-applied.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may get informations about what CRTC or connector
changed a property (and the property itself), so in such case let's just
ignore the changes to the non-affected CRTCs/connectors, and let's read
only the affected one
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may receive a "CRTC" or "CONNECTOR" property that
indicates which crtc/connector property ID has changed.
In such case, instead of update data for all the devices, only update the
device containing the relative connector.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Hotplug events may contain CRTC or CONNECTOR ids to notify a property
change to just one owner, so we need to find its parent device.
Also we may want to update properties directly without having to go through
all the devices, so expose a simple way to find them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
In case we have no devices, after a KMS update (both because they've
all have been removed or because there were none), we may need to behave
differently compared to the case in which nothing changed, so add a more
specific KMS update change type
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
If only gamma changed on drm CRTC's we don't have to rebuild the whole
monitors, nor to inform the backed about, the only consumer could be the
DBus API, and so we still emit a signal, but nothing else is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Since we cache already all the KMS parameters we care about let's check at
each device update if anything has really changed and only in such case
emit a resources-changed signal.
In this way we can also filter out the DRM parameters that when changed
don't require a full monitors rebuild.
Examples are the gamma settings or the privacy screen parameters, that
emits an udev "hotplug" event when changed, but we want to register those
only when we handle the changed property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
A client request for maximizing itself should always be handled by mutter
by emitting a configure event with the native maximized resolution,
regardless of the client's own set limits. This also aligns the behavior by
allowing fixed-sized windows to go into fullscreen or maximized state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1997>
It works correctly with scanouts, in contrast to
clutter_stage_capture_into. Inspired by
meta_screen_cast_area_stream_src_record_to_buffer.
maybe_paint_cursor_sprite is now unused and thus removed.
v2:
* clutter_stage_paint_to_buffer requires switching to recording from an
idle callback as well. (Jonas Ådahl)
v3:
* Set human readable name for idle source. (Ivan Molodetskikh)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1940
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1914>
