Commit d48129f5ee broke the displaying of our own drag cursor during window
drags, as now the window cursor is always used, even during stage grabs
(window grabs are just a kind of stage grab).
To fix it, while not regressing on the intention of the other commit, unset
the MetaWaylandPointer surface in case a window drag is active (instead of
all kinds of grabs) by checking via meta_display_is_grab().
Fixes: d48129f5ee ("wayland: Fix pointer cursor during Wayland grabs")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3316
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3624>
Move the bulk of the implementation inside MetaWaylandPointer
files, like it happens in other places (e.g. MetaWaylandTabletSeat).
This avoids MetaWaylandPointer struct peeking from outside.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3627>
The _MUTTER_FRAME_EXTENTS need to have the correct size before the
window is shown, otherwise the client window size will effectively have
the headarbar height subtracted when initially syncing the frame/client
geometries.
This reverts commit f10b3eac62.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3628>
The min height reported by ClutterText when ellipsize and line-wrapping are
enabled was too small to fit the text.
The coordinates from `pango_layout_get_line_extents()` are baseline relative,
so the `y` coordinate means that the highest ascent would be `-y` above the
baseline and height gives the span between the ascent above the baseline and
the descent below it, so `logical_line_rect.y + logical_line_rect.height`
gives us the size of the descent. This is the wrong height to use for the
height of the actor.
The coordinates of the layout extents don't seems to be related to the baseline
and are just for offsets when rendering, that's probably how this bug got
initially introduced.
Therefore, the `y` coordinate from the layout is the correct offset to use,
even though, when looking at `pango_layout_get_extends_internal()`, it appears
that `y` is always set to 0.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3610>
Upstream the annotations used in Gala, make more Cogl methods available since
things got moved to a GObject base and thus works natively with the introspection.
Add all the public API to the introspection.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3619>
QueryDeviceString can successfully return NULL. The convention however
is that when NULL is returned, the error will be set.
This commit makes the returned string an output parameter which allows
us to return the success status and have the error set accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3614>
The convention is that when a function returns FALSE or NULL, the error
will be set. In this file we call set_egl_error but it might not set an
error. Code of the form
if (egl_do_thing (..., &error))
use_error (error);
will crash in those cases.
This commit makes sure we always set the error even if EGL doesn't give
us an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3614>
We depend on Gio for many introspection features (GSettings, GFile...)
without this we'd end up not having many symbols being exposed.
And errors such as
Warning: Meta: meta_display_add_keybinding: argument settings:
Unresolved type: 'GSettings*'
As per previous commit we now have this dependency implicitly, but still
it's better to make it clearer in case Clutter would drop it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3620>
This is added as a hint so that the caller can optionally use it, e.g.
in the case that a window drag is driven by the mouse. This will be used
to more accurately follow the drag position, other than starting at the
current pointer position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3546>
Pointer constraints obey to logical pointer focus changes, and looking
up the current surface in order to maybe enable them is getting ahead
of itself, since the pointer focus might differ from the current surface
due to other factors (e.g. grabs).
Change the code checking whether constraints should be enabled to again
check the pointer logical focus, this will be influenced by the
MetaWaylandEventInterface mechanism, and correctly reflect the logical
state accounting for those factors.
Fixes: 125ba92169 ("wayland: Port pointer constraints to using MetaWaylandEventInterface")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3303
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3618>
Currently, we don't handle too well the removal of a MetaWaylandEventInterface
during meta_wayland_event_interface_invalidate_all_focus(), since the
MetaWaylandEventInterface may be freed at an intermediate point in that function
while handling the focus change for all input devices.
Turn this invalidate_all_focus() function into a MetaWaylandInput method, and
always ensure to use the currently effective MetaWaylandEventInterface when
resetting the focus for each device.
This fixes the situation through handling reentrancy naturally, a focus
sync (say, triggered by a grab) would reset a device focus (say, pointer), which
would remove an event interface (say, a pointer constraint), which would
invalidate_all_focus() again underneath using the new effective
MetaWaylandEventInterface. When that is done, the initial invalidate_all_focus()
call would re-apply the same focus to the same currently effective
MetaWaylandEventInterface, resulting in a no-op for the remainder of the function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3618>
Even though the logical focus is typically business that only the
MetaWaylandEventInterface mechanism minds about, there are some pointer
subsystems that want to look this up, as opposed to the current surface.
Add a getter to make this easier, without struct peeking.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3618>
This also removes some g_return_if_fail's because the test suite expects
to be able to create arbitrary KmsUpdates even if they don't make sense
for the real state. We just get lucky that the test suite isn't
constructing updates with color space and hdr changes, yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
Currently querying support for some output features is done partially
through the OutputInfo and partially via KMS CRTC and Connector objects.
Let's be consistent and use OutputInfo always which works with all
backends and backend types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
We're currently pretending the gamma LUT has another size. This becomes
a problem when we try to reset the LUT to passthrough, create an
identity LUT for it and it has a size that the kernel doesn't accept.
We do track the size and have utility for creating the LUTs, so let's
just use them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
The kernel doesn't let us set gamma to passthrough with the legacy API
so we have to trick a bit and create an identity LUT, and also when we
read the KMS state, detect when an identity LUT is active.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
The frame size_allocate() will set it correctly once show() is called by
the window tracker.
This is less code and also help reduces the chance of a brief visual
glitch in fullscreen games during startup. If the window is initially
still decorated the gray area would still show up until the next redraw,
which due to loading times can take a while.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3608>
Relying on the content size_allocate() to determine the content position
can fail in situations where the position of the content has changed,
but not its size.
This happens for example when the window initially is sized fullscreen
height + headerbar height while not considered fullscreen yet. Then when
the window is resized to just the fullscreen height and marked as
fullscreen, the content size has not changed and size_allocate() is not
called on the content. Thus the previous position which assumes the
presence of a headerbar still applies. As a result the window is shifted
down, revealing a headerbar sized area showing the gtk window background
color.
This issue can be avoided by using the frame's size_allocate(), which
gets called in response to all relevant events, such as any headerbar
size changes, headerbar visibility changes, window resizes and
fullscreen status changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2937
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3608>
Allows to mark a wayland client window as a DOCK window. The reason for
this is that in Gala (elementary OS's window manager) we would like to
continue using GTK apps as panel and dock on wayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3612>
Assigning the corresponding stack layer of DOCK windows is currently X11
specific, because there is no way for wayland clients to set the DOCK
window type. This is about to change, so move the code to the generic
layer handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3612>
