We want to run those tests in VKMS later with the same reference image.
To make the tests as close to each other as possible we use the same
resolution for the VKMS and the virtual output which is 640x480.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
This test currently only works because the monitor has the same width
and height. Generalize it to arbitrary monitor sizes by taking into
account that width and hight are swapped for some rotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
Most tests use the draw_surface function to draw a solid color to a
surface. This moves it from the shm-only path to WaylandBuffer which
makes all of those tests usable via dma-buf.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
The custom drawing requires adjusting the test. Instead of poking at
memory directly, we can just draw a color at certain coordinates which
makes it independent of the pixel format used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
It abstracts away the kind of buffer so clients can be tested with both
shm and dma-buf paths. We'll make use of it in the future by adding the
wayland tests to the TTY and KVM test suits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
When capturing the view we have to make sure the stage is actually
updated. In direct scanout mode the stage is unmodified and we can't
find the content we want to test.
Currently the ref-tests are all running on non-native setups where
direct scanout is impossible but we will change that soon!
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
Transfer none was achieved using a stack GArray in the stage which
would get resized to 0 at the end of every frame to "free" it.
In the case of direct scanout however, painting the next frame only
happens after leaving fullscreen again. Until then the array just kept
growing and because GArrays don't reallocate when shrunk, this memory
remained allocated even after leaving fullscreen.
There is no cache benefit from storing paint volumes this way, because
nothing accesses them after their immediate use in the calling code.
Also the reduced overhead from avoiding malloc calls seems negligible as
according to heaptrack this only makes up about 2-3% of the temporary
allocations.
Changing this to transfer full and removing the stack array simplifies
the code and fixes the "leak".
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3191
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3442>
This is a step in cleaning up the Clutter context management. By making
it a GObject it's easier to add e.g. properties and features that helps
with introspection.
For now, this means the context creation is changed to go via a
"constructor" (clutter_create_context()). This is so that the global
context singleton can be mantained outsid of ClutterContext, until it
can be removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
The original purpose of being able to report errors is no longer
relevant, since the Clutter backend is now practically a thin wrapper
around the actual backend, which has already dealt with error reporting.
Thus move this to the regular constructor path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
The current usage of MetaWindow::unmanaging may result in confused
focus window lookups while undoing the MetaWindowDrag grab (i.e.
still pointing to the window that is now being unmanaged).
The meta_window_unmanage() function itself takes care of changing
focus outside of the window being unmanaged, so postpone the
MetaWindowDrag undoing to a point after that is done.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3073
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3376>
Since meta_kms_impl_device_get_sync_file always returns the same
file descriptor referencing the same sync_file, this means the atomic
ioctl doesn't need to wait for any fences to signal. This is fine
because we already waited for the buffer to become idle before applying
the Wayland surface state.
Fixes the atomic commit ioctl spuriously synchronizing to the screen
cast paint (at least with the amdgpu driver), which could result in
the page flip missing its target scanout cycle.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3148
v2:
* Rename local variable to signaled_sync_file for consistency with new
function name
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
It returns a file descriptor which references a signaled sync_file.
v2:
* Change function name and add Doxygen comment to hopefully make its
purpose a bit clearer (Ivan Molodetskikh)
v3: (Jonas Ådahl)
* Create sync_file from scratch via a syncobj, no buffer needed anymore
* Initialize priv->sync_file = 1 and use g_clear_fd in finalize
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
The debug controller can optionally, when passing --debug-control,
enable manipulating debug state, so far enabling/disabling HDR, via
D-Bus.
It's always created, in order to have a place to store debug state and
emit signals etc when it changes, but so far, it doesn't have its own
state it tracks, it just mirrors that of the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3432>
While we should ideally have a sensible cursor theme, handle the
case of cursor themes that lack certain cursor names, and fallback
to the 'default' cursor in those cases.
The 'grey rectangle' fallback is still left, in case we even fail
to load a 'default' cursor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3295>
When a stream is destroyed by a consumer, mutter won't be able to
recognize that.
For mutter, the stream just paused, but did not disconnect, because the
connection state of a PipeWire stream only represents, whether the
respective PipeWire context is connected to PipeWire.
In addition to that, it may be the case, that the stream consumer just
recreates the stream.
So even if mutter would be able to know, when the stream consumer
destroyed a stream, but not the whole screencast or remote-desktop
session, then mutter would not know, whether the stream will be resumed
eventually or not.
So, add an explicit API call to the screencast interface to stop a
stream.
For virtual streams, this also means, that the respective virtual
monitor is destroyed.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2889
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
When a virtual stream is destroyed, its respective virtual monitor is
destroyed too. When the virtual monitor is destroyed, mutter reloads
the monitor manager.
However, at this point, the virtual stream is not completely destroyed
yet. The viewport of the virtual monitor still exists at this point and
when the monitor manager reloads, it will try to fetch the logical
monitor of the now destroyed virtual monitor, which will fail and thus
gnome-shell will run into a segfault.
Fix this situation by reloading the monitor manager in an idle callback.
When the monitor manager reloads, the virtual monitor is completely
gone, since the viewport of the virtual monitor is destroyed after the
virtual monitor itself.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2864
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
There is no way to set any gamma luts, or do anything other color
management related. Eventually we'll probably want to, but that requires
bringing color management plumbing to PipeWire.
Doing this is also needed when running a headless session, as when
headless, polkit doesn't let us create colord devices without explicit
user permission, meaning we'll spam the session with useless dialogs
each time a session is started.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3423>
Given destruction order, the display goes away before the stage, so
this lingering signal connection may trigger unintended crashes.
Fixes: 05eeb684d1 ("window: Postpone focusing until grab ended if uninteractable")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3422>
`count_mode_setting_devices` was incorrect in both name and in function.
What it was actually doing was counting GPUs that had been registered with
the backend so far (during the `init_gpus` loop). What it was intended to
do was to count the number of `MetaRenderDeviceEglStream` instances, which
is the thing we're limited to only one of. So `count_mode_setting_devices`
would return zero whenever the first GPU initialized happened to be a
`MetaRenderDeviceEglStream`, which would in turn prevent
`MetaRenderDeviceEglStream` from successfully initializing. Seems it only
ever worked in the case of a hybrid system where the first GPU initialized
was GBM-based.
Now we count `MetaRenderDeviceEglStream` instances (zero or one) externally.
This allows initialization to succeed when it happens to be the first (or
only) GPU. And so `MUTTER_DEBUG_FORCE_EGL_STREAM=1` now works.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2905>
For scanout on a secondary GPU, for the time being try only formats
which are guaranteed to be renderable with GLES3, which notably excludes
10 bpc formats without alpha channel.
v2:
* Use separate format array for 10 bpc formats without alpha.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
If the EGL_KHR_no_config_context extension is supported, use it to
choose a format per onscreen which is compatible with the scanout CRTC
and the GL rendering API used.
Suggested by Jonas Ådahl.
v2:
* Drop code which checked for GLES3 renderability. Makes no sense for
various reasons, in particular that EGLconfigs are about EGLSurfaces,
whereas secondary GPU contexts use an FBO for blitting.
* Use error parameter directly for meta_renderer_native_choose_gbm_format
call (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
Preparation for the following commits, no functional change intended.
v2:
* Pass through MetaEgl pointer
v3:
* Make it return gboolean (Robert Mader)
v4:
* Add debug logging and corresponding purpose parameter
v5:
* Fix excessive function parameter indentation (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
Split the struct into mutable and immutable parts. Access the mutable
parts via getters and the immutable parts via a single struct. This
avoids copying around the immutable parts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3280>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
Now that the monitor screencast records to DMA-BUF buffers immediately
(since bc2f1145d8), and we know which phase of the paint rountines we
are (since last commit), we have the opportunity to bring back the
blitting technique.
Bring back blitting. This time, instead of simply failing if the blit
fails, add a fallback path that does a stage paint if something goes
wrong. Unlike the previous implementation of blitting, this one only
blits the current view - it does not blit all views that intersect
with the screencasted monitor.
Embedded cursors should still be fine because hardware cursor is
inhibited while embedded cursor screencasts are running.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3406>
Track where we are in terms of the paint cycle. Do this through an
enumeration that is passed through the paint vfuncs of screencast
sources.
Right now, this information is not used by any one of the sources,
but next patch will use it to prevent blitting when detached from
the paint cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3406>
With the existing ClutterInputMode terminology (inherited from XI2),
hardware devices may be "physical" (i.e. attached to a logical device),
or "floating" (i.e. detached from all logical devices).
In the native backend, tablet devices are closer to "floating" than
"physical", since they do not emit events relative to the ClutterSeat
pointer logical device, nor drive the MetaCursorTracker sprite. This
is in contrast to X11 where all tablet devices drive the Virtual
Core Pointer by default, along with every other pointing device.
Change this mode in the Wayland backend to be more coherent. The
existing checks on the ClutterInputMode along Mutter seem appropriate
for handling these as floating devices, since they mainly care about
logical vs non-logical.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3393>
The window actor can be mapped every frame, e.g. when it is dragged in
the overview. This commit keeps track when the geometry changed and we
didn't managed to sync the geometry yet and need to sync it at a later
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3404>
At the end of the sync_actor_geometry function the window buffer_rect
and the WindowActor position and size are the same and consistent.
Call the virtual method at the end and let the implementations look at
either the buffer_rect or the actor position/size itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3404>
In some cases the window is not mapped when the geometry changes.
Without the mapped window the surfaces are not mapped either and don't
have a sensible allocation.
This patch makes sure we abort syncing the geometry if the window is not
mapped and also make sure we sync geometry when the actor eventually
does get mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3152
Fixes: 8f4ab53bd ("window-actor/wayland: Ensure to use allocation for black background check")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3401>
Scoped traces are less error prone, and they can still be ended
prematurely if needed (this commit makes that work). The only case this
doesn't support is starting a trace inside a scope but ending outside,
but this is pretty unusual, plus we have anchored traces for a limited
variation of that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3396>
Allow only specific files to use those deprecated APIs making
it easier to find where deprecated APIs are still in use
and avoid introducing new usages without being noticed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3400>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
Currently, json-glib is used for two things:
- For loading scripts, nothing seems to use that in real life other
than some tests
- For debugging paint nodes
For now, the PR drops the first use case and only require json-glib
if it is a debug build
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3354>
We don't actually need the host to be a container, so simply work on
actors saving us a few casts.
This'll simplify dropping ClutterContainer entirely later, and
StViewport/ShellWindowPreviewLayout will also need to be updated for the
new signatures
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3384>
Sticky keys configuration changes reset the pressed modifier state mask,
even though the XKB state might already match with the expected new
state. In those cases we can avoid the XKB state mask update completely.
This also fixes a crash at initialization with sticky keys toggled on,
since configuring the device a11y settings will trigger a XKB state
mask merely reassuring the initial state with no modifiers pressed,
while the connection between the ClutterSeat and the impl object has
not been set up yet. This crash was introduced by commit 00bb4190b
("backends/native: Drop device_native->seat_impl field").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3392>
Tests that
* the window under the cursor has focus
* focus_default_window won't move the focus away from a previously
focused window even if the cursor is somewhere else
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
When the desktop is focused instead of a window we want to tell the core
about this to handle focus-mode mouse. This is handled by looking for
CLUTTER_LEAVE events where the newly focused window is NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
Take a reference to the window to make sure the MetaFocusData->window
pointer is not pointing to a freed object.
Also make sure that the window that we want to focus is not currently
unmanaging.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
On X meta_window_handle_enter was called when the desktop window was
entered. On wayland the "desktop" is no window anymore. We still want to
inform the core that the desktop is focused, so it can unfocus windows
if focus-mode is mouse.
This commit prepares the core for handling a NULL windows to mean the
desktop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The following commits will make it possible to pass a NULL window to
display_handle_window_enter/leave to represent the cursor entering the
desktop. This means it can't be a method of the window class anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
If we have an existing focused window that may have focus, default focus
will leave the focus there. An unmanaging window for example must not
have focus and default focus will continue to select another window in
this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The layout manager takes the generic ClutterActor expand/align
properties into account. Everyone should already use those instead
of the custom layout/child properties, so removing them should have
little fallout, while making for a nice cleanup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3382>
It tests various sub-surface corner cases. It would fail without the
previous fixes.
v2:
* Fix draw_descendant parameter formatting
* Make toplevel window fullscreen (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
To make sure a new wl_subsurface created for the same wl_surface won't
inherit the position from the wl_subsurface being destroyed.
v2:
* Move into permanently_unmap_subsurface
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
Instead of duplicating the code in both.
v2:
* Rename helper to make it clear(er) that it permanently unmaps the
sub-surface
* Move transaction allocation & commit into the helper
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
wl_subsurface_place_above/below need to hook it up to the parent
surface's pending state, so that it gets picked up next time the parent
is committed.
v2:
* Adapt to wl_subsurface_destructor not resetting sub-surface position
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is simpler, and makes sure it's called only once for each surface
in the transaction as committed.
v2:
* Use array for surface states with placement ops (Jonas Ådahl)
v3:
* Use GPtrArray instead of GArray (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is necessary to make sure the unmapped sub-surface is no longer
visible.
v2:
* Use META_IS_WAYLAND_SUBSURFACE (Jonas Ådahl)
* Use same sequence of assignments in both cases
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
meta_display_ping_window() does nothing when check-alive-timeout is set
to 0, but meta_window_check_alive_on_event() was relying on it to reset
the events_during_ping. Without this events_during_ping was just
counting up until the threshold was reached and the window was marked as
not alive, preventing further pointer events from being sent to the
window.
Fix this by not doing anything in meta_window_check_alive_on_event() if
check-alive-timeout is 0, similar to meta_display_ping_window().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3142
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3367>
Locked modifiers should probably not have an effect on keybindings
while toggled. this is most relevant for modifiers that can be
either/both pressed or locked (e.g. Caps Lock key), if used in
keybindings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
This struct contains the pressed/latched/locked set of modifiers applying
to the event, and may be filled in by backends generating those events.
Other places where we forward modified key events, state may be normally
obtained from the original event.
Since this constructor is used in a variety of places, this commit
updates them all in one go.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
If multiple sync events are send in the same dispatch, a further call to
wait_for_sync_event will get stuck. Fix this by keeping track of the
latest sync event serial in the display and always compare against that.
This also means sync event sequences must start at 0 and increase by 1.
The wayland-x11 interop test is the only one where that wasn't already
the case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3358>
Currently, we use cairo_region_t despite it being a thing wrapper around pixman_region_32
In order to push for a cairo-less and wayland only build in the future, replace
cairo_region_t with a thin wrapper that is almost a copy of the upstream cairo implementation
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3292>
