Writing tests' output to a log file makes them difficult to debug when
the test might be running on an autobuilder or CI system where only
stdout/stderr are recorded. This is particularly troublesome if a
failure is only reproducible on a particular autobuilder.
Recent Automake versions have the convention that detailed output from
failing tests is written to stdout/stderr, not just to log files, when
the VERBOSE environment variable is set; borrow that convention as a
trigger for producing detailed test output.
This was originally cogl!14, but applies equally to mutter's fork of cogl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1273
Signed-off-by: Simon McVittie <smcv@debian.org>
When a MetaBarrier is first created it allocates a backend
impl object which does the actual heavy lifting.
Unfortunately, that backend object is never freed.
This commit ensures the implementation gets freed when
the barrier object is freed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1451
meta_barrier_destroy is responsible for removing the extra
reference added in meta_barrier_constructed.
Unfortunately, it fails to do this because of a misplaced early
return statement.
This commit removes the spurious return.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1449
This is already taken care of in meta_backend_monitors_changed(), called
from the same code paths that emit ::monitors-changed-internal. It is
better to leave this up to backend internals.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1448
This resolves a couple of FIXMEs. The FIXME comments were right in
stating that not *all* journals needed flushing, only the one we
are trying to put on screen needs flushing.
However we can't eliminate all flushes because the winsys swap calls
that follow go directly into OpenGL which knows nothing about cogl
journalling. So the journal *must* be flushed before the swap, to give
OpenGL the correct state.
P.S. If this turns out to cause any bugs then the next best answer is
to just remove the FIXME comments. Because flushing is still the right
thing to do.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1362
We only did this if we weren't currently doing an interactive resize,
but since the finish_move_resize() is not the actual interactive resize
but the acknowledgment of the configure event that was emitted as a
result, we shouldn't limit ourself to the same flags used during resize.
This fixes temporarly "stuck" position of attached modal dialogs while
they are being resized.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1163https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1446
In X, buttons 1, 2, 3 are left, middle, right. In evdev, the order is
BTN_LEFT, BTN_RIGHT, BTN_MIDDLE. So setting a scroll button to 2 gave us a
middle button in the X session and a right button in a wayland session.
Fix that by hard-coding the LMR buttons handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1433
Even when a direct client buffer has a compatible format, stride and
modifier for direct scanout, drmModePageFlip() may still fail sometimes.
From testing, it has been observed that it may seemingly randomly fail
with ENOSPC, where all subsequent attempts later on the same CRTC
failing with EBUSY.
Handle this by falling back to flipping after having composited a full
frame again.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1410
We already correctly set the font-dpi based on user settings in
MetaSettings at each user change and as part of backend initialization,
so there's no point to set it also during x11 backend post-parsing and
using X11 values, as this may happen at later point and lead to a wrong
clutter font DPI value.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1444
If there is no laptop panel (for example on a desktop PC or a virtual
machine), attempting to put a NULL monitor in the list of matches
will just make mapping_helper_apply() crash.
Mitigates: https://gitlab.gnome.org/GNOME/mutter/-/issues/1414
Signed-off-by: Simon McVittie <smcv@debian.org>
It's enabled by default when using the i915 driver, but disabled
everywhere else until it can be made reliably an improvement. Until
then, for anyone want to force-enable it, add the string
'dma-buf-screen-sharing' to the experimental features list in GSettings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
Seems DMA buffer based interprocess buffer sharing is more broken than
not, so for now only enable it when using the i915 driver.
For example vmwgfx, qxl and radeon, it results in mmap() failing to mmap the
memory region. Other drivers, e.g. amdgpu will function, but may hit
very slow memory download paths, resulting in worse performance.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
When the CoglRenderer didn't set the DMA buffer constructor vfunc, we
return NULL. What we didn't do was set the error, meaning the caller
would crash if it tried to look up why DMA buffer construction failed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1430
We only want the panel autorotation to happen if the laptop has an
accelerometer, and is in tablet mode. Regular laptop mode should
lock the orientation, and let it be configured manually.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
So far, we've expected this signal to not happen whenever autorotation
shouldn't apply (no accelerometer is a strong reason). In future commits
we'll add further checks to this policy, so prevent autorotation to
change the display configuration if the MetaOrientationManager signal
happens but it should be ignored.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
Instead of having everyone check net.hadess.SensorProxy themselves, have
this all controlled by the MetaOrientationManager, and proxied everywhere
else via a readonly property in org.gnome.Mutter.DisplayConfig.
We want to attach more complex policies here, and it seems better to
centralize the handling of the autorotation feature rather than
implementing policy changes all over the place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
We used to pick the "best" output for each builtin/size/edid categories,
and then pick the "best" (in that order) of those for each input device.
This is most often enough, but is prone to wrong results in some corner
cases (eg. 2 outputs with the exact same dimensions).
Change this to a score mechanism that doesn't leave outputs out. The
weights are the same, but the score is accumulated if an output matches
multiple categories. All outputs are evaluated and sorted by score, and
input devices with the best matches are applied first (as they already
did).
This should break the tie if eg. there's 2 outputs with similar dimensions,
but one of them has some EDID match in addition. The output with multiple
matches will score higher up, while it might have been entirely discarded
with the previous implementation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1175https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1202
The work at https://gitlab.gnome.org/GNOME/gnome-control-center/issues/239
intended to make integrated devices optionally mappable to other outputs
(in order to allow fix mishandling from our heuristics, or to quickly reach
things in other monitor without changing devices).
This was missed in that plan, we do allow cycling outputs, but we still did
prevent it from doing anything for integrated devices. Fix that, and change
output cycling so we don't allow a "NULL" EDID for integrated devices, this
makes those go through the MetaInputMapper (resulting in one output listed
twice), instead of mapping to the full stage.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1186https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1201
