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>
As ClutterGrab is a stack, the backend only cares about some grab
existing currently or not. Make it sure that we grab whenever we
go to >=1 grabs, and ungrab whenever we go to <1.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
Dissociate clutter_stage_set_key_focus() from the actors focused
state, so that it obeys stage grabs. The key focus actor state may
also change due to grab changes, add the code to notify about this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
Emit crossing events whenever a grab coming or going would cause a
pointer/touchpoint to become inactive on their position. Depending
on whether the pointer lies inside the old or new grab widgets,
enter or leave events would be generated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
We will want to be more specific about the portions of the actor
hierarchy that receive this event, separate creation and emission
so each place does what is relevant.
However, this commit brings no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
These events are not meant to be ever silenced away, every actor
that is meant to receive one should do so. Make it sure that those
events cannot be stopped, despite the event signal handlers return
values.
This opens the debate about whether crossing events should be
ClutterEvents, since they are more and more uncommon at being one,
maybe this notification mechanism should be taken away from the
event machinery, but that's something for future refactors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
Hopefully, the one to make them all converge. This new ClutterGrab
represents a handle on a created grab. These are stacked, so grabs
can be overridden and remain inactive until there is a time that
they become active again, although undoing these early is optional.
These grabs are global, they do apply to all pointer, touchpoint
and keyboard foci.
At the moment, only the API to create and stack those is added,
the actual functionality is added in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
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>
