The signal handler must return TRUE as the invocation is already handled
by returning an error. Also update the error message a bit to clarify
that the API exists only for testing purposes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/457
We should not only take the old CRTC for an output whenever
possible, but we should also assign one that is 'free', i.e.
one that another monitor (to be processed after this one)
isn't using, so that that monitor can use the same CRTC.
https://gitlab.gnome.org/GNOME/mutter/issues/373
We shouldn't change an output's CRTC if we don't have to, as
that causes the output to go black.
This patch depends on
"monitor-unit-tests: initial crtcs in custom_lid_switch".
https://gitlab.gnome.org/GNOME/mutter/issues/373
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
The external grab handler is shared across all external bindings and external
bindings have now different binding flags. For this reason, when rebuilding the
binding table there could be loss of information if we assign the bindings flags
of the external handler to all external bindings. Let's store the bindings flags
in MetaKeyGrab too and use this when rebuilding the binding table to avoid the
above issue.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/169
The "force restore shortcuts" being triggered by a key-combo, there is
no guarantee that the currently focused window is actually non-NULL in
which case we would crash.
Make sure there is a window currently focused before trying to restore
the shortcuts on that window.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/464
This basically reverts commit 54735dec, which tried to avoid the
GLib-defined types in favor the standard C ones. One exception to this
is the bool type, for which the commit introduces a new type CoglBool.
Let's just get rid of this type in favor of having consistency with the
GLib types. Note by the way that neither CoglBool nor gboolean (which
has a size of `int`) are completely compatible with bool (size `char`).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
On X11, if a window cannot be maximized because its minimum size is
already larger than the output size, a request to maximize will be
ignored.
On Wayland, however, we would still honor the maximize request and
switch the window state to maximized, without actually moving the window
which leads to weird visual effects, as the window end up being
maximized in-place.
To avoid this, make sure the window has the maximize functionality
available prior to change its state in xdg-shell `set_maximized`
request.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/463
This adds a pipeline stage for merge requests that checks that the
commit message contains an URL to either a issue or a merge request.
This means that for merge requests without corresponding issues will
always fail initially, as the merge request URL is not known until after
it is created. This is still arguably better than accidentally merging
merge requests without URLs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/440
As per commit 43633d6b, we mark an unmanaging window as not focusable, while
this is true, it might cause not resetting the current focused window when
unmanaging it causing a crash.
Also this wouldn't allow to check if a window can be focused when unmanaging it,
so let's revert the previous behavior.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/462
This was wrongly done just before enable, which is not right as
per the protocol. A side effect was that input purpose/hints were
eagerly reset before being applied, thus not properly honored,
noticed in the doing of emoji/numeric OSK panels.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/410
This means we need to make sure we don't accidentally free the provided
source GError (which automatically happens with `g_autoptr`), so use
`g_steal_pointer()`.
This fixes an issue where, when launched in a bubblewrap environment
(such as the one provided by Buildstream), mutter would give the
following warning message:
```
mutter-WARNING **: 8:31:35:069: Can't initialize KMS backend: (null)
```
... which isn't that useful when trying to debug the actual issue.
Iterate over all the monitor product words to check for a partial matching on
EDID, otherwise we would hang inside an infinite while loop.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/459
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
It is based on and very similar in nature to buffer transforms.
From the specification:
> The global interface exposing surface cropping and scaling
> capabilities is used to instantiate an interface extension for a
> wl_surface object. This extended interface will then allow cropping
> and scaling the surface contents, effectively disconnecting the
> direct relationship between the buffer and the surface size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
