Graphene uses C99 and includes stdbool.h, which adds a
new 'bool' type. Clutter has an a11y test that names a
variable as 'bool' too, and they do not play well together.
Rename this variable to boolean.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Clutter had support for internal children in its early revisions, but they
were deprecated for long time (commit f41061b8df, more than 7 years ago) and
no one is using them in both clutter and in gnome-shell.
So remove any alternative code path that uses internal children.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/816
This is for all intents and purposes the same as
`cogl_object_ref/unref`, but still refers to handles rather than
objects (while we're trying to get rid of the former) so it's a bit of
unnecessary redundant API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/451
Clutter actors might emit property changes in dispose, while unparenting.
However we assume that the ::destroy signal is the last one we emit for an
actor, and that starting from this moment the object is not valid anymore,
and so we don't expect any signal emission from it.
To avoid this, freeze the object notifications on an actor during its
disposition, just before the ::destroy signal emission.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Clutter actors unset their parent on dispose, after emitting the ::destroy
signal, however this could cause ::parent-set signal emission. Since we
assume that after the destruction has been completed the actor isn't valid
anymore, and that during the destroy phase we do all the signal / source
disconnections, this might create unwanted behaviors, as in the signal
callbacks we always assume that the actor isn't in disposed yet.
To avoid this, don't emit ::parent-set signal if the actor is being
destroyed.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
Add a function to check whether a point is inside a quadrilateral
by checking the cross product of vectors with the quadrilateral
points, and the point being checked.
If the passed quadrilateral is zero-sized, no point is ever reported
to be inside it.
This will be used by the next commit when comparing the transformed
actor vertices.
[feaneron: add a commit message and remove unecessary code]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
And add the necessary glue so those initialize a X11 clutter backend.
This should get Clutter tests that are dependent on windowing to work
again, thus they were enabled back again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
As per commit f71151a5 we focus an input window if no take-focus-window accepts
it. This might lead to an infinite loop if there are various focusable but
non-input windows in the stack.
When the current focus window is unmanaging and we're trying to focus a
WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input
window in the stack.
However, if an application (such as the Java ones) only uses non-input
WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This
might lead to a state where no window is focused, or a wrong one is.
So, instead of only focus the first eventually input window available, try to
request to all the take-focus windows that are in the stack between the
destroyed one and the first input one to acquire the input focus.
Use a queue to keep track of those windows, that is passed around stealing
ownership, while we protect for unmanaged queued windows.
Also, reduce the default timeout value, as the previous one might lead to an
excessive long wait.
Added metatests verifying these situations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When used it setups an X11 event monitor that replies to WM_TAKE_FOCUS
ClientMessage's with a XSetInputFocus request.
It can only be used by x11 clients on windows that have WM_TAKE_FOCUS atom set
and that does not accept input.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When using gtk under X11 some WM related events are always filtered and not
delivered when using the gdk Window filters.
So, add a new one with higher priority than the GTK events one so that we can
pick those events before than Gtk itself.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus
targets, however this might end-up in an infinite loop if there are multiple
non-input windows stacked.
So, accept any focusable window as fallback focus target even if it's a
take-focus one (that might not reply to the request).
Added a stacking test to verify this.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When requesting to a take-focus window to acquire the input, the client may or
may not respond with a SetInputFocus (this doesn't happen for no-input gtk
windows in fact [to be fixed there too]), in such case we were unsetting the
focus while waiting the reply.
In case the client won't respond, we wait for a small delay (set to 250 ms) for
the take-focus window to grab the input focus before setting it to the default
window.
Added a test for this behavior and for the case in which a window takes the
focus meanwhile we're waiting to focus the default window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
This allows to sleep for a given timeout in milliseconds.
Rename test_case_before_redraw to test_case_loop_quit since it's a generic
function and use it for the timeout too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
This allows to verify which window should have the focus, which might not
be the same as the top of the stack.
It's possible to assert the case where there's no focused window using
"NONE" as parameter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
Allow to set/unset WM_TAKE_FOCUS from client window.
This is added by default by gtk, but this might not happen in other toolkits,
so add an ability to (un)set this.
So fetch the protocols with XGetWMProtocols and unset the atom.
test-client now needs to depend on Xlib directly in meson build.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
This fixes the following compiler warning:
In file included from /usr/include/glib-2.0/glib.h:114,
from ../src/tests/test-utils.h:23,
from ../src/tests/test-utils.c:22:
../src/tests/test-utils.c: In function ‘test_init’:
/usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: warning: ‘basename’ may be used uninitialized in this function [-Wmaybe-uninitialized]
28 | g_free (*pp);
| ^~~~~~~~~~~~
../src/tests/test-utils.c:73:24: note: ‘basename’ was declared here
73 | g_autofree char *basename;
| ^~~~~~~~
https://gitlab.gnome.org/GNOME/mutter/merge_requests/627
When running in slow or busy machines (hey CI!) or under valgrind headless
tests could fail because of a non fatal warning during initialization.
So define a fatal handler that ignores the frame counter warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
Creating a window could take some time, causing false-positive failures when
running in slower or busy hardware like:
window 1/2 isn't known to Mutter
So before we proceed in doing any operation on it, wait for the client.
Do this in the test runner instead of repeating the same in every .metatest.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
Don't launch the stacking tests in one single shot, to allow better debugging
and being able to launch just one single test using meson test.
Those tests can now be all launched with:
meson test --suite stacking [single-test-name]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
This test forgot to specify the existing CRTC routings in the setup. For the
first output the default 0 was ok, now it is -1 to ensure that the code will
assign it correctly. For the second output the default 0 was incorrect, because
possible_crtcs does not include 0. Now that CRTC is initialized to off
instead, because the second output is hotplugged later and running a CRTC
without an output does not make sense.
This fix will keep this test passing when a future patch attempts to preserve
existing CRTC routings. Assuming that any existing routing is valid, such
routing will be kept. In this test case the existing routing was illegal, it
should have been impossible, which then causes that future patch to fail the
test by assigning the wrong CRTC.
https://gitlab.gnome.org/GNOME/mutter/issues/373
This is the last remaining feature necessary to achieve
parity with the Autotools build.
A few changes were made to the install locations of the
tests, in order to better acomodate them in Meson:
* Tests are now installed under a versioned folder (e.g.
/usr/share/installed-tests/mutter-4)
* The mutter-cogl.test file is now generated from an .in
file, instead of a series of $(echo)s from within Makefile.
Notice that those tests need very controlled environments
to run correctly. Mutter installed tests, for example, will
failed when running under a regular session due to D-Bus
failing to acquire the ScreenCast and/or RemoteScreen names.
We already ran a Wayland client to test various Wayland paths. What was
missing to also run a X11 client was to hook in the X11 async waiter
wires, so do that and run both types of clients.
https://bugzilla.gnome.org/show_bug.cgi?id=790207
As with the Wayland display name, to avoid clashes with already an
running Xwayland or Xorg instance, override the X11 display name to
something less likely to cause a clash.
https://gitlab.gnome.org/GNOME/mutter/issues/193
Meson uses the 'dependencies' field to determine and
parallelize build steps, but that isn't entirely true
with 'link_with'; this might cause a race condition
when generating header files while trying to build
them.
Fix that by only using 'dependencies' instead of 'link_with'.
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
This is the filename convention you get when you define a shared module
in meson, and since there is no particular reason to not include the
"lib" prefix, lets make it easier to port it over. While at it,
de-duplicate the retrieval of the plugin name.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
testboxes was a binary that did unit testing, but it wasn't integrated
to the test system, so in effect, it was never run. Instead integrate it
into the other mutter unit tests. This includes changing a few of
meta_warning()s into g_warning()s so that the GTest framework can handle
them.
When a transient window is destroyed, the expected behavior is that
focus is passed to the ancestor if possible. This was broken for
quite a while until the previous commit, so add a test case to make
sure it doesn't happen again.
https://gitlab.gnome.org/GNOME/mutter/issues/15
This test aims at checking that the transient relationship set using the
xdg-foreign API is respected by mutter and that no crash occurs, such as
the one in issue !174.
Note: the crash from issue !174 occurs only if "attach_modal_dialogs" is
set, so one has to change that default value to "true" to be able to
trigger the crash:
gsettings set org.gnome.mutter attach-modal-dialogs true
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Add a "set_parent_exported" command to test the xdg-foreign support, so
that we can add a test which uses the GDK API for exported window:
`gdk_wayland_window_set_transient_for_exported()`
That will allow to detect if transient is applied correctly between
foreign windows and detect possible crashes such as issue !174.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Rather than handle UpClient in both MetaBackend (to reset the idletime
when the lid is opened), and in MetaMonitorManager and
MetaMonitorConfigManager (to turn the screen under the lid on/off
depending on its status), move the ability to get the lid status from
UPower or mock it in one place, in MetaBackend.
Previously we relied on the test-client to make sure that a window was
shown. For X11, we did not need to do anything, but for Wayland we had
to make sure we had drawn the first frame, otherwise mutter wouldn't
have a buffer making the window not showable.
Doing it this way doesn't work anymore however, since the 'after-paint'
event will be emitted even if we didn't actually paint anything. This is
the case with current Gtk under Wayland, where we won't draw until the
compositor has configured the surface. In effect, this mean we'll get a
dummy after-paint emission before the first frame is actually painted.
Instead, move the verification that a "show" command has completed by
having the test-runner wait for a "shown" signal on the window, which is
emitted in the end of meta_window_show(). This requires an additional
call to gdk_display_sync() in the test-client after creating the window,
to make sure that the window creation vents has been received in the
compositor.
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Changing the test monitor managers ability to rotate CRTCs in one test
affected the next test. Avoid leaking such state by resetting it before
each test. To continue passing, some tests needed to be updated
regarding to still pass.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
Add a test case that checks that we don't try to revert to a
laptop-panel-only configuration after closing the lid after an external
monitor is connected.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
Check that if there are multiple modes with the same ID (resolution,
refresh rate and handled flags) we correctly add the preferred mode to
the list of monitor modes.
https://bugzilla.gnome.org/show_bug.cgi?id=789153
In order to eventually support multilpe GPUs with their own connectors,
split out related meta data management (i.e. outputs, CRTCs and CRTC
modes) into a new MetaGpu GObject.
The Xrandr backend always assumes there is always only a single "GPU" as
the GPU is abstracted by the X server; only the native backend (aside
from the test backend) will eventually see more than one GPU.
The Xrandr backend still moves some management to MetaGpuXrandr, in
order to behave more similarly to the KMS counterparts.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Move finding, opening and managment of the KMS file descriptor to
MetaMonitorManagerKms. This means that the monitor manager creation can
now fail, both if more than one GPU with connectors is discovered, or
if finding or opening the primary GPU fails.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Instead of passing it around or fetching the singleton, keep a pointer
to the monitor manager that owns the CRTC. This will eventually be
replaced with a per GPU/graphics card object.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Instead of passing it around or fetching the singleton, keep a pointer
to the monitor manager that owns the output. This will eventually be
replaced with a per GPU/graphics card object.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Convert MetaCrtcMode from a plain struct to a GObject. This changes the
storage format, and also the API, as the API was dependent on the
storage format.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Turn MetaCrtc into a GObject and move it to a separate file. This
changes the storage format, resulting in changing the API for accessing
MetaCrtcs from using an array, to using a GList.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Turn MetaOutput into a GObject and move it to a separate file. This
changes the storage format, resulting in changing the API for accessing
MetaOutputs from using an array, to using a GList.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Check that configurations where monitors are disabled are properly
used. Also test that old configurations with explicitly disabled
outputs are migrated properly.
https://bugzilla.gnome.org/show_bug.cgi?id=787629
