We currently offer the mechanism for GNOME Shell to implement, and
while this is not exercised often (our entries are typically surrounded
by a ClutterGrab ensuring key events, so this is reserved to grab-less
entries, probably there are some in extensions), this is arguably
something Mutter should cover by itself without GNOME Shell guidance.
This is only necessary on the X11 backend, although it is conceptually
more tied to the MetaX11Display connection, so perform the focus
tracking there only if not running as a Wayland compositor (i.e. --x11).
This avoids the only case where the low-level
meta_x11_display_set_input_focus_xwindow() function is used, or rather
makes it completely a MetaX11Display implementation detail, leaving
only the MetaDisplay API as the high-level entry points to handle
window key focus.
The public API that allowed GNOME Shell to implement these mechanisms
is also gone in this commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
There might not be a single plane that is "for" a CRTC, so remove the
API that made it appear as if it did. The existing users only cared if
there was some plane for said CRTC, so replace the getters with API that
just checks the existance at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When there are a set of primary planes, and a set of CRTCs, where each
plane can be used on multiple CRTCs, we need to make sure that when we
mode set and page flip, each CRTC gets assigned an individual plane that
isn't used with any other CRTC.
Do this during the monitor resource assignments that sets up later to be
applied configurations of the mode setting objects, but with the new
hooks into the backend, so that we don't need to teach the monitor
config manager about planes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2398
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
This means that it doesn't necessarily mean what transform / rotation
the hardware resource gets, e.g. it instead represents the logical
transform related to the configured mode. This allows us to postpone
checking the plane capabilities until later (as rotation capabilities
depends is a plane property), when a plane has been assigned.
This was in practice already handled when configuring the
transform-via-offscreen case, handled when creating the view, and the
mode setting configuration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When we're configuring monitors, allow backends to add backend specific
assignments during resource assignment (mapping connectors and CRTCs
etc).
This will later allow the native backend's KMS monitor resources to
assign a primary plane and optionally a cursor plane during
configuration. This will then dictate what plane will be used for
primary plane updates, as well as cursor updates, until reconfigured
again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
A set of primary planes can be usable with a set of CRTCs, meaning we
can't have general purpose functions that gets a plane for a CRTC, as
there is no such one to one relationship.
For tests we still want to have helpers that makes writing tests easier,
so to prepare for those functions going away, make the tests do the
equivalent themselves.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
Musl doesn't seem to include this by default so explicitly including it
should fix compilation on Musl.
Tested with Clang 16/17 and GCC 14.
Error:
src/backends/meta-fd-source.c:70:3: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
close (fd_source->poll_fd.fd);
^
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3078
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3455>
Otherwise a tablet in relative mode will never have a tool set and
nothing happens on motion events - meta_wayland_tablet_seat_update()
simply exits early for tablet proximity, button or motion events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3410>
The include is currently satisfied by
window-x11-private → iconcache → x11-display-private
The icon cache is about to be removed, so add the missing include
directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3452>
Changing the MultiTexture may require a different set of pipelines when
the texture format is different. We keep track of the attached
MultiTextureFormat just like we do for the width and height.
This fixes misrendering when a client attaches buffers with different
MultiTextureFormats to the same surface.
Fixes: 3dd9f15eb ("shaped-texture: Start using MetaMultiTexture")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3456>
We want to run those tests in VKMS later with the same reference image.
To make the tests as close to each other as possible we use the same
resolution for the VKMS and the virtual output which is 640x480.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
This test currently only works because the monitor has the same width
and height. Generalize it to arbitrary monitor sizes by taking into
account that width and hight are swapped for some rotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
Most tests use the draw_surface function to draw a solid color to a
surface. This moves it from the shm-only path to WaylandBuffer which
makes all of those tests usable via dma-buf.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
The custom drawing requires adjusting the test. Instead of poking at
memory directly, we can just draw a color at certain coordinates which
makes it independent of the pixel format used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
It abstracts away the kind of buffer so clients can be tested with both
shm and dma-buf paths. We'll make use of it in the future by adding the
wayland tests to the TTY and KVM test suits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
When capturing the view we have to make sure the stage is actually
updated. In direct scanout mode the stage is unmodified and we can't
find the content we want to test.
Currently the ref-tests are all running on non-native setups where
direct scanout is impossible but we will change that soon!
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
