Real time scheduling is needed for better control of when we commit
updates to the kernel, so add a property to MetaThread that, if the
thread implementation uses a kernel thread and not a user thread, RTKit
is asked to make the thread real time scheduled using the maximum
priority allowed.
Currently RTKit doesn't support the GetAll() D-Bus properties method, so
some fall back code is added, as GDBusProxy depends on GetAll() working
to make the cached properties up to date. Once
https://github.com/heftig/rtkit/pull/30 lands and becomes widely
available in distributions, the work around can be dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Also add an API to inhibit the kernel thread from being used, and make
MetaRenderDeviceEglStream inhibit the kernel thread from being used if
it's active.
The reason for this is that the MetaRenderDeviceEGlStream is used when
using EGLStreams instead of KMS for page flipping. This means the actual
page flipping happens as a side effect of using EGL/OpenGL, which can't
easily be done off thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This will be necessary in order to default to 'kernel' and then switch
to 'user' if the thread instance can no longer be properly multi
threaded.
To avoid having the same thread impl creating and destroying
GMainContext's, this also means always creating a GMainContext for the
thread-impl. When running in user-thread mode, the GMainContext is
wrapped in a wrapper source and dispatched as part of the real main
thread GMainContext, and when in kernel-thread mode, it runs
independently in the dedicated thread.
This has the consequence that the wrapper source will always have the
priority of the highest impl context GSource, but only after it has
dispatched once. Would we need it earlier than that, we either need a
way to introspect existing sources in a GMainContext and their
priorities, or manually track known sources in MetaThreadImpl.
The wrapper source will never be below 0, as that'd mean it could reach
INT_MAX priority if it had no more sources attached to it, meaning it'd
never be dispatched again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While the default when passing NULL will be the main context of the main
thread, make it possible to specify another main context, so that
result handlers can be invoked on the right thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Callbacks could be queued to be invoked either on the impl side or the
main thread side of the thread; change this to take a GMainContext,
which effectively means a callback can be queued to be invoked on any
thread that has a GMainLoop running on its own GMainContext.
Flushing is made to handle flushing callbacks synchronously on all
threads. This works by keeping a hash table of queued callbacks per
thread (GMainContext); when flushing (from the main thread), callbacks
on the main thread context is flushed, followed by synchronization with
all the other threads.
meta_thread_flush_callbacks() is changed to no longer return the number
of dispatched callbacks; it becomes much harder when there are N queues
spread across multiple threads. Since it wasn't used for anything, just
drop the counting, making life slightly easier.
Feedback to thread tasks are however always queued on the callers
thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means each test is run 4 times:
* with atomic mode setting using a kernel thread,
* with atomic mode setting using a user thread,
* with legacy mode setting using a kernel thread, and
* with legacy mode setting using a user thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This isn't a problem for user space threads, as there are no race
conditions, but when kernel thread support is introduced, we must make
sure that e.g. the main loop is actually running before quitting it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This uses the queue that was introduced when migrating impl task
management from MetaThread to MetaThreadImpl, with the exception that
it's now fully used as an actual queue. It now has a GSource that sits
on the right GMainContext that is dispatched whenever there are tasks to
execute.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It's the impl side that wants to add impl side idle sources, or fd
sources, etc, so make it part of MetaThreadImpl.
This changes things to be GAsyncQueue based. While things are still
technically single threaded, the GAsyncQueue type is used as later we'll
introduce queuing tasks asynchronously, then eventually queuing across
thread barriers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Accessibility should be handled on the receiving end, if needed. Make
sure this is the case by listening on some signals, verifying they are
only triggered if we're not capturing input.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
An input only grab is a ClutterGrab on the stage that doesn't have an
explicit actor associated with it. This is useful for cases where event
should be captured as if focus was stolen to some mysterious place that
doesn't have anything in the scene graph that represents it.
Internally, it's implemented using a 0x0 sized actor attached directly
to the stage, and a clutter action that consumes the events. An
input-only grab takes a handler, user data and a destroy function for
the user data. These are handed to the ClutterAction, which handles the
actual event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Adding a barrier and later enabling the input capture session will
create MetaBarrier instances for each added input capture barrier.
The barriers are created as "sticky" which means that when a pointer
hits the barrier, it'll stick to the point of entry, until it's
released.
The input capture session is also turned into a state machine with
explicit state, to more easily track things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This API aims to provide a way for users to capture input devices under
certain conditions, for example when a pointer crosses a specified
barrier.
So far only part of the API is implemented, specifially the session
management as well as zone advertisement, where a zone refers to a
region in the compositor which edges will eventually be made available
for barrier placement.
So far the remote access handle is created while the session is enable,
despite the input capturing isn't actually active yet. This will change
in the future once it can actually become active.
v2: Remove absolute/relative pointer, keep only pointer (ofourdan)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
We'd get a re-entry like scenario when destroying the PipeWire stream
object, where PipeWire would call the stream process vfunc. When this
happened, we had already destroyed the stream, so don't try to dequeue
or anything, just do an early exit. Fixes the following crash in the
test case client:
#0 pw_stream_dequeue_buffer() in /usr/lib64/libpipewire-0.3.so.0.367.0
#1 on_stream_process() at ../src/tests/screen-cast-client.c:348
#2 do_call_process() in /usr/lib64/libpipewire-0.3.so.0.367.0
#3 flush_items() in /usr/lib64/spa-0.2/support/libspa-support.so
#4 loop_invoke() in /usr/lib64/spa-0.2/support/libspa-support.so
#5 impl_send_command.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#6 suspend_node.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#7 pw_impl_node_set_state() in /usr/lib64/libpipewire-0.3.so.0.367.0
#8 client_node_removed() in /usr/lib64/pipewire-0.3/libpipewire-module-client-node.so
#9 pw_proxy_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#10 pw_stream_disconnect() in /usr/lib64/libpipewire-0.3.so.0.367.0
#11 pw_stream_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#12 stream_free() at ../src/tests/screen-cast-client.c:530
#13 main() at ../src/tests/screen-cast-client.c:803
#14 __libc_start_call_main() at ../sysdeps/nptl/libc_start_call_main.h:58
#15 __libc_start_main() at ../csu/libc-start.c:360
#16 _start() in /home/jonas/Dev/gnome/mutter/build/src/tests/mutter-screen-cast-client
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3095>
If the timelines don't get destroyed they keep references to frame
clocks. Later tests check for the destruction of those frame clocks and
then can fail if the frame clock is implemented slightly differenty.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3084>
The stage already maintains its own list of stage-views via
clutter_stage_peek_stage_views(), it's a bit superfluous to copy that list
around all the time into priv->stage_views of ClutterActor. Let's deal with
that by returning clutter_stage_peek_stage_views() when
clutter_actor_peek_stage_views() gets called for the stage.
In order to make sure ClutterActor::stage-views-changed still gets emitted
correctly for the stage, always emit that signal on the ClutterStage when
the stage views get invalidated. This now depends on the backend only
actually invalidating the views and calling
clutter_stage_clear_stage_views() when things have actually changed, but
that should be the case.
This needs a change in one of the stage-views tests, namely the one which
tests stage-view-changed emission on the stage: Here we now see an emission
of stage-views-changed, but that signal emission actually seems correct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
Under X11 hiding the backend implies also unmapping the stage window, if
we do that after that we've closed the display we may end up in a
BadWindow error because such window seems to be destroyed together with
the compositor output parent (even though we are not notified about), so
to prevent this, reparent the backend window during compositor unmanage,
setting it back as a root window child.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2835
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3020>
Hides libdisplay-info under a build time default-off flag,
provides provision to parse essential edid parameters with
APIs provided by libdisplay-info. This implementaion increases
readibility, avoids code duplication and decreases complexity
of edid parsing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2642>
This ATM triggers missed .commit events for the window in question,
to be addressed in Xwayland. Since the test does not seem to specifically
rely on this window being CSD, make it a regular window instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
This will be used to extract the resolution and refresh rate from
strings like "1920x1080@60.0" or "1280x720". This aims to replace the
use of the locale dependent sscanf() function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
Otherwise we'll have a cursor sprite backed by a surface that no longer
exist. This usually doesn't happen, but can happen in rare situations
related to pointer capability changes Wayland client cursor changes and
hotplugs.
Fixes the following crash:
#0 meta_wayland_buffer_get_resource() at ../src/wayland/meta-wayland-buffer.c:128
#1 realize_cursor_sprite_from_wl_buffer_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1649
#2 realize_cursor_sprite_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1869
#3 realize_cursor_sprite() at ../src/backends/native/meta-cursor-renderer-native.c:1887
#4 meta_cursor_renderer_native_update_cursor() at ../src/backends/native/meta-cursor-renderer-native.c:1100
#5 meta_cursor_renderer_update_cursor() at ../src/backends/meta-cursor-renderer.c:414
#6 meta_cursor_renderer_force_update() at ../src/backends/meta-cursor-renderer.c:449
#7 update_cursors() at ../src/backends/meta-backend.c:328
#8 meta_backend_monitors_changed() at ../src/backends/meta-backend.c:338
#9 meta_monitor_manager_notify_monitors_changed() at ../src/backends/meta-monitor-manager.c:3590
#10 meta_monitor_manager_rebuild() at ../src/backends/meta-monitor-manager.c:3678
#11 meta_monitor_manager_native_apply_monitors_config() at ../src/backends/native/meta-monitor-manager-native.c:343
#12 meta_monitor_manager_apply_monitors_config() at ../src/backends/meta-monitor-manager.c:706
#13 meta_monitor_manager_ensure_configured() at ../src/backends/meta-monitor-manager.c:779
#14 meta_monitor_manager_reconfigure() at ../src/backends/meta-monitor-manager.c:3738
#15 meta_monitor_manager_reload() at ../src/backends/meta-monitor-manager.c:3745
or the following on gnome-43:
#0 meta_wayland_surface_get_buffer at ../src/wayland/meta-wayland-surface.c:441
#1 meta_cursor_sprite_wayland_get_buffer at ../src/wayland/meta-cursor-sprite-wayland.c:83
#2 realize_cursor_sprite_from_wl_buffer_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1612
#3 realize_cursor_sprite_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1836
#4 realize_cursor_sprite at ../src/backends/native/meta-cursor-renderer-native.c:1854
#5 meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1087
#6 meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:413
#7 meta_cursor_renderer_force_update at ../src/backends/meta-cursor-renderer.c:448
#8 update_cursors at ../src/backends/meta-backend.c:344
#9 meta_backend_monitors_changed at ../src/backends/meta-backend.c:354
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2185113
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2968>
We have the drm/InfoFrame encoding and our MetaOutputHdrMetadata
encoding. Check that we can correctly convert between each other by
doing a encode/decode and decode/encode roundtrip and then checking for
equality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
We relied on them being valid longer to keep track of used GPUs. If we
don't have the CRTC (or output) we don't have a way to fetch the pointer
to the MetaGpu that drives the associated monitor.
This avoids a crash when trying to fetch said pointer from what would be
the NULL MetaCrtc pointer.
Fixes: 08593ea872 ("onscreen/native: Hold ref to the output and CRTC until detached")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2667
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2887>
We want to avoid using too high scales too easily, which started to
happen 2f1dd049bf ("monitor-manager: Rework default scale factor
selection"). Instead of using the closest non-fractional scale, which
effectively is what we'd do, only round upwards if we're closer than
0.25 (25%).
Since there are some wiggle room for scales to make the logical
resolution on the integer pixel grid, make sure to compensate. This
compensation is done by adding an extra 0.2 to scale difference.
For example the following fractional scales will get these corresponding
integer scales:
* 1.25 -> 1.0
* 1.5 -> 1.0
* 1.75 -> 2.0
* 2.0 -> 2.0
* 2.50 -> 2.0
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2880>
Instead of testing headless start using the dummy backend, do so with
the real native backend, and use the drm-mock library instead to emulate
monitors being disconnected at startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
This new filter allows test cases to manipulate what the kernel reports,
e.g. mark connected connectors as disconnected to emulate monitors
connecting and disconnecting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
In order to make things more and more asynchronus and to each time we
paint be an isolated event, that can be potentially be applied
individually or together with other updates, make it so that each time
we draw, we use the transient MetaFrameNative (ClutterFrame) instance to
carry a KMS update for us.
For this to work, we also need to restructure how we apply mode sets.
Previously we'd amend the same KMS update each frame during mode set,
then after the last CRTC was composited, we'd apply the update that
contained updates for all CRTC.
Now each CRTC has its own KMS update, and instead we put them in a per
device table, and whenever we finished painting, we'll merge the new
update into any existing one, and then finally once all CRTCs have been
composited, we'll apply an update that contains all the mode sets for all
relevant CRTCs on a device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
Add a tiny library that sabotages errors in drmMode*() API calls. This
will be used to artificially trigger arbitrary errors, e.g. cause the
next commit to fail with EBUSY.
The three mocked methods are added as they will be used in a future
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
At first it was called seal(), but then updates could be amended after
being posted, given a flag. That flag has been removed, so we can go
back to sealing, since it's once again acts more as a seal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we call schedule(), which will schedule an update some time in the
future, and then schedule_now(), we should reschedule the frame clock to
update immediately, and not some time in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This is intended to be used only for plane assignment, and CRTC like
changes, so that one can e.g. change a cursor plane on a pending update
that changes the primary plane, before it has been committed to KMS.
The kms-updates test overrides the get-state function MetaKmsCrtc. This
is needd to not have the update mechanism not clamp the gamma size to 0,
as vkms reports the gamma length 0. By pretending it's 3, we can test a
simple and small gamma lut is merged correctly when merging updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This protocol is intended to let special clients create transient-for
relationships between X11 and Wayland windows. The client that needs
this is xdg-desktop-portal-gnome, which will create e.g. file chooser
Wayland dialogs that should be mapped on top of X11 windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The script is a list of newline separated command lines that are sent to
the client one by one as if one would have used e.g.
meta_test_client_do().
It doesn't have error handling as it's expected to be used from tests,
and handling errors in tests that never expects to handle errors is
cumbersome.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
One can add a wl_global filter to a wl_display instance, which can be
used to decide what clients should see what globals. This has so far
been used to limit a Xwayland specific protocol extension to only
Xwayland. In order to expand the logic about what globals are filtered
to what clients, introduce a filter manager and port the Xwayland
specific protocol filter to this new manager.
Tests are added, using a new dummy protocol, to ensure that filtering is
working as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
It only tests indirect clients, i.e. not the subprocess part, so far,
but tests explicitly terminating by destroying the MetaWaylandClient
object, as well as the client self terminating and the signal being
emitted.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The first monitor in stacking tests is the primary monitor but that
doesn't have to stay this way forever. Instead of special casing the
name "primary" to refer to whatever monitor happens to be the primary
monitor, we add an `assert_primary_monitor` command to verify that the
monitor that should be the primary monitor actually is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
New add_monitor command for adding secondary monitors. Support setting
the workspaces-only-on-primary preference.
The stacking test tests the focus and stacking for multiple monitors
with workspaces-only-on-primary=true. The default_focus changes
previously broke this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
The order of dependencies influences the order of -L arguments to gcc/ld,
we should put our private library first, so that introspection prefers
looking up libraries in private paths than public ones.
This could bring problems in API updates of the libmutter-test library,
since introspection would still prefer the old installed one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2826>
Running each stacking test as a separate installed-test is analogous to
what was done for build-time tests in c6d1cf4a (!442) and should make it
easier to track regressions, by being able to see whether a regression
is specific to one .metatest script or applies to more than one.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2773>
While completely untested, at least this makes it work "in theory"
again. Before it'd listen to signals on the stage, but have an incorrect
type signature to handle the test paint procedures, meaning it'd
probably crash or cause memory corruptions.
What was needed was a signal which in the callback the test could call
some cogl functions to paint on the framebuffer. While there is no such
signal on the stage, and the ClutterActor::paint signal (which they
probably used in the past) is long gone, lets add a "test actor" that is
just a wrapper that adds that paint signal with a paint context.
The tests that need it are changed to add this actor to the stage, and
to listen to the paint signal on the actor instead of incorrectly
listening on stage signals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2807>
That means before-update, prepare-paint, before-paint, paint-view, after-paint,
after-update. While yet to be used, it will be used as a transient frame
book keeping object, to maintain object and state that is only valid
during a frame dispatch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
It was missing a cairo_region_t. This also needs adapting the test case,
since prior to this, we didn't actually bump the paint counter when
painting.
When a scanout test isn't waiting to go from compositing to scanout, but
from scanout to compositing, we should not early out when we actually
composited, since that's what we're expecting to see.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
Flushing the input thread might implicitly iterate the mainloop, and thus
update the stage while still inside the clutter_test_flush_input() call.
This means the stage update has already happened when we call
wait_stage_updated(), and that's why we call clutter_stage_schedule_update()
there currently.
This clutter_stage_schedule_update() call is not necessary though, instead
we can flush the input thread from inside wait_stage_updated() after
setting was_updated to FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2792>
Quoting Carlos:
The META_PRIORITY_EVENTS ± 1 happening below are in order to set these idles
and timeouts in a priority that is relative to the literal GDK event priority,
making those diverge is a likely way to sneakily break things.
But that's unlikely to happen, and decoupling mutter from GTK further
should make it moot, so perhaps it's alright after all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
There are two tests; one checks that clearing with a color that cannot
be represented using 8 bits per channel doesn't loose precision when
painted, then read back using glReadPixels(). Would the texture backing
store have 8 bits per channel instead of 10, we'd get a different value
back.
The other test checks that painting from one fbo to another also doesn't
loose that precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
The "later" API is used to queue actions in relation to compositing,
thus is owned by the MetaCompositor instance. Make users of this
functionality get MetaLaters instance from the compositor, and stop
using the global meta_later() API.
display: Use non-singleton MetaLater API
tests: Use non-singleton MetaLater API
meta/common: Make docs refer to context aware MetaLater API
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This means we can eliminate the use of scattered singletons that isn't
added by the tests or the test framework itself.
tests: Don't get backend from old singleton getter
Either use the ownership chain, or the explicit test context instance
pointer.
tests/wayland: Pass context to test client constructor
So that we can get the Wayland compositor directly from the context.
tests: Don't get display from singleton
tests/client: Make test client carry a context pointer
tests/runner: Have test cases carry a context pointer
tests/wayland/test-driver: Get backend from context
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This means objects have an owner, where the chain eventually always
leads to a MetaContext. This also means that all objects can find their
way to other object instances via the chain, instead of scattered global
singletons.
This is a squashed commit originally containing the following:
cursor-tracker: Don't get backend from singleton
idle-manager: Don't get backend from singleton
input-device: Pass pointer to backend during construction
The backend is needed during construction to get the wacom database.
input-mapper: Pass backend when constructing
monitor: Don't get backend from singleton
monitor-manager: Get backend directly from monitor manager
remote: Get backend from manager class
For the remote desktop and screen cast implementations, replace getting
the backend from singletons with getting it via the manager classes.
launcher: Pass backend during construction
device-pool: Pass backend during construction
Instead of passing the (maybe null) launcher, pass the backend, and get
the launcher from there. That way we always have a way to some known
context from the device pool.
drm-buffer/gbm: Get backend via device pool
cursor-renderer: Get backend directly from renderer
input-device: Get backend getter
input-settings: Add backend construct property and getter
input-settings/x11: Don't get backend from singleton
renderer: Get backend from renderer itself
seat-impl: Add backend getter
seat/native: Get backend from instance struct
stage-impl: Get backend from stage impl itself
x11/xkb-a11y: Don't get backend from singleton
backend/x11/nested: Don't get Wayland compositor from singleton
crtc: Add backend property
Adding a link to the GPU isn't enough; the virtual CRTCs of virtual
monitors doesn't have one.
cursor-tracker: Don't get display from singleton
remote: Don't get display from singleton
seat: Don't get display from singleton
backend/x11: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Add a helper function that ensures any queued virtual input events have
been flushed from the input thread. This works by posting a task to the
input thread, which will itself queue another callback back to the main
thread. Once the main thread callback is invoked, the flush call is
unblocked and the function returns. Upon this, any previously emitted
virtual input event should have already passed through the input thread
back into the main thread, however not necessarily fully processed.
For making sure it has been processed, one also have to make sure the
stage has been updated, e.g. via `meta_wait_for_paint()`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2727>
The test does simply "wait" which apparently is not enough to ensure the
client window did resize to the expected dimensions. Use "wait_reconfigure"
and assert that the size after resize is the expected, before going further
at testing its behavior after maximize/unmaximize; it might end up with the
unexpected size after the whole operation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
We put a DEVICE_ADDED or DEVICE_REMOVED event into Clutters event queue
here, so we should also wait for Clutter to process events once.
Just putting an event into the queue doesn't mean it gets processed
immediately (especially when the commit after this one is applied), so
wait for a stage update here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2697>
If two X11 windows were the last two, we'd remove them from the stack
while unmanaging them. That'd hit an assert in
meta_stack_tracker_restack_managed(), resulting in the following crash
when Xwayland exited unexpectedly with two or more X11 windows being the
only windows on the stack:
#1 g_assertion_message() at ../glib/gtestutils.c:3256
#2 g_assertion_message_expr() at ../glib/gtestutils.c:3282
#3 meta_stack_tracker_restack_managed() at ../src/core/stack-tracker.c:1210
#4 on_stack_changed() at ../src/core/stack.c:142
#5 _g_closure_invoke_va() at ../gobject/gclosure.c:895
#6 g_signal_emit_valist() at ../gobject/gsignal.c:3456
#7 g_signal_emit() at ../gobject/gsignal.c:3606
#8 meta_stack_changed() at ../src/core/stack.c:265
#9 meta_stack_remove() at ../src/core/stack.c:324
#10 meta_window_unmanage() at ../src/core/window.c:1542
#11 meta_x11_display_unmanage_windows() at ../src/x11/meta-x11-display.c:111
#12 meta_x11_display_dispose() at ../src/x11/meta-x11-display.c:141
#13 g_object_run_dispose() at ../gobject/gobject.c:1448
#14 meta_display_shutdown_x11() at ../src/core/display.c:831
The added test specifically checks that this scenario is handled
gracefully.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2143637
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2704>
Instead of having users of the test client manually deal with alarm
filters, let the test client automatically add itself as filters. This
changes the MetaX11Display a bit, to handle an array of filters instead
of a single filter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2704>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case the window content get centered on a black
background which covers the whole monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
Make sure that if we wiggle a scan-out capable surface a bit, it won't
scan out if it's not exactly in the right position. Do this by first
making the window not fullscreen, then moving it back and forth,
verifying the correct scanout state for each presented frame.
This test addition reproduces the issue described in
https://gitlab.gnome.org/GNOME/mutter/-/issues/2387.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624>
Gnome-shell uses meta_display_focus_default_window() when shell elements
loose focus which is the case with Alt+Tab window switching. Globally
active input clients don't immediately gain focus though so if
meta_display_focus_default_window focuses a wrong window stacking and
focus don't behave as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
New commands to set the number of workspaces, activate a workspace, with
and without focus, move windows to specific workspaces, and check the
stacking on a specific workspace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
This is an old relic from when ClutterStageView was being added, and
tests were somewhat prepared to be able to test the "X11 style" of
things, with the nested backend some how managing to emulate that.
Lets drop that stuff, it isn't used by the test suite, and isn't useful
anyway; if we want to test X11 configurations, we should use the actual
X11 backend, which didn't make use of this anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2619>
This adds a copy of the calibration test profile and sets up a test to
first add it as a system profile, then setting up the XDG_DATA_HOME
directory so that the duplicate profile is detected, added, and later
discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
The D-Bus runner used by tests, including installed tests, is made to be
reusable from GNOME Shell. To do this, install it and the templates in
the pkgdatadir (e.g. /usr/share/mutter-APIVERSION/tests/), generate a
custom runner for the installed tests that uses the installed script and
templates, and change the non-installed original runner to use the
non-installed templates.
The end goal is to reuse the D-Bus session runner and templates used for
mutter when test running GNOME Shell.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1354>
This allows using two separate ICC profiles for one "color profile",
which is necessary to properly support color transform
calibration profiles from an EFI variable.
These types of profiles are intended to be applied using the color
transformation matrix (CTM) property on the output, which makes the
presented output match sRGB. In order to avoid color profile aware
clients making the wrong assumption, we must set the profile exposed
externally to be what is the expected perceived result, i.e. sRGB, while
still applying CTM from the real ICC profile.
The separation is done by introducing a MetaColorCalibration struct,
that is filled with relevant data. For profiles coming from EFI, a
created profile is practically an sRGB one, but the calibration data
comes from EFI, while for other profiles, the calibration data and the
ICC profile itself come from the same source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2568>
This mocks gsd-colord to enable night ligth at a given temperature. The
test then verifies that the result exactly matches that of the gamma
ramps gsd-color generated for the same temperature and ICC profile.
There are two types of profiles tested; ones with VCGT, i.e. calibrated
profiles, and ones without. These are tested as the VCGT affects how the
gamma curve looks, while the non-VCGT profiles all only rely on
the blackbody temperature to generate a gamma ramp.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
We created device profiles, that we manage the lifetime of in colord,
but color devices can be assigned profiles other than the ones it was
created for. For example, this can include the standard sRGB profile
provided by colord.
To achieve this, keep track of the default profile of the CdDevice as
the "assigned" color profile of the device. Given this profile
(CdProfile), construct a MetaColorProfile that can then be interacted
with as if it was generated by ourself.
The assigned profile (default profile in colord terms) does nothing
special so far, but will later be used to determine how to apply CRTC
gamma ramps etc.
The sRGB.icc file used in the tests was copied from colord. It was
stated in the repository that it has no known copyright restrictions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Just as gsd-color does, generate color profiles. This can either be done
from EFI, if available and the color device is associated with a built
in panel, or from the EDID. If no source for a profile is found, none is
created.
The ICC profiles are also stored on disk so that they can be read by
e.g. colord. The on disk stored profiles will only be used for storing,
not reading the profiles, as the autogenerated ones will no matter what
always be loaded to verify the on disk profiles are up to date. If a on
disk profile is not, it will be replaced. This is so that fixes or
improvements to the profile generation will be made available despite
having run an older version earlier.
After generating, add some metadata about the generated file itself
needed by colord, i.e. file MD5 checksum and the file path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Tests that test case EDID is setup correctly, and that color devices for
monitors are created.
tests/color: Add hotplugging tests
Checks that changing the number of connected monitors reflects the
number of current color devices, and that we end up with the correct end
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
This will be needed for adding colord integration without breaking
testing.
The test context is altered to make sure any left over color devices are
cleaned up before starting. This means it becomes possible to run a test
case multiple times without having to restart meta-dbus-runner.py.
Note: Don't use os.getlogin() to get the current username; as that
requires a controlling terminal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
We fairly consistently had multiple monitors with the whole
vendor,product,serial tuple identical. If we start relying on making
monitors a bit more unique, e.g. for colord integration, we need to make
two monitors connected distinguishable in order for tests to properly
reflect reality and excercise the correct colord integration paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Client connections may linger after the test driver is teared down;
handle this gracefully by unsetting the user data on the wl_resource,
and make the resource destructor a no-op, instead of where it would
otherwise remove itself from the resource list. This fixes this crash
seen in CI:
Received signal 11 (SIGSEGV)
#0 g_list_remove() at ../glib/glist.c:596
#1 test_driver_destructor() at ../src/tests/meta-wayland-test-driver.c:219
#2 destroy_resource() at ../src/wayland-server.c:730
#3 for_each_helper() at ../src/wayland-util.c:416
#4 wl_map_for_each() at ../src/wayland-util.c:430
#5 wl_client_destroy() at ../src/wayland-server.c:889
#6 wl_display_destroy_clients() at ../src/wayland-server.c:1482
#7 meta_wayland_compositor_prepare_shutdown() at ../src/wayland/meta-wayland.c:441
#8 meta_context_dispose() at ../src/core/meta-context.c:667
#9 g_object_unref() at ../gobject/gobject.c:3863
#9 g_object_unref() at ../gobject/gobject.c:3780
#10 glib_autoptr_clear_GObject() at /usr/include/glib-2.0/gobject/gobject-autocleanups.h:29
#10 glib_autoptr_clear_MetaContext() at ../src/meta/meta-context.h:32
#10 glib_autoptr_cleanup_MetaContext() at ../src/meta/meta-context.h:32
#10 main() at ../src/tests/wayland-unit-tests.c:707
#11 __libc_start_call_main() in /usr/lib64/libc.so.6
#12 __libc_start_main() in /usr/lib64/libc.so.6
#13 _start() in /builds/GNOME/mutter/build/src/tests/mutter-wayland-unit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2601>
The catch option makes test run via 'catch'[1], which will log
backtraces whenever an abort or segmentation fault happens in any of the
subprocesses. The aim is to enable this when running in CI to help
debugging crashes that only tend to happen in CI.
While it's possible to wrap the whole meson command in 'catch', doing so
doesn't cover the KVM tests, so this option is added instead that covers
both cases.
[1] https://gitlab.gnome.org/jadahl/catch/
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2561>
