If no viewport is set, the neutral viewport is the surface size
without viewport destination size applied - i.e. transform and
scale applied to the buffer size. Change it accordingly, giving
us the same values we'd return in `get_width` in this case.
As result, this only changes cases where a viewport destination
size but no viewport source rectangle is set.
The change fixes exactly such cases, e.g. the Gstreamer Wayland
sink. Can be tested with: `gst-play-1.0 --videosink=waylandsink`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
When checking panel orientation on logical monitors we should take
panel orientation transform to check it's properly applied, so ensure
that we're checking the right one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
Commit 2289f56112 ("monitor-manager: Don't apply unneeded orientation
changes") added an early return to handle_orientation_change () in case
the transform is unchanged.
But this did not take the correction of the transform for devices
with 90° mounted panels into account causing a desired orientation
change to get skipped if the new orientation matches the corrected
logical orientation from the previous transform setting.
Fix this by calling meta_monitor_crtc_to_logical_transform () on the
transform before comparing it, matching the
meta_monitor_crtc_to_logical_transform () call in
create_for_builtin_display_rotation ().
Related: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
When Xwayland was not initalized, we'd still clean things up. What this
accidentally meant was that the uninitialized display number 0 was
cleanud up, which very likely was main display of the host session.
What this meant in practice was that /tmp/.X11-unix/X0 was often
removed, causing every Flatpak X11 application to fail to start until
Xwayland was restarted nad the X0 socket file was restored.
Fix this in two ways: firstly only shutdown Xwayland if we ever started
it, i.e. if the X11 display policy was not 'disabled'. This should fix
the issue most of the times. Secondly only clean up the socket if it was
ever initialized. This should fix things if the socket creation failed,
as if it did, the name would be set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2162>
Needs a couple of changes to make tests pass again:
* mesa-dri-drivers needs explicit installation to install swrast dri
driver
* wireplumber needs to be started inside the D-Bus session
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2142>
A popup surface can be remapped multiple times using the same
wl_surface, if a new xdg_popup object is created. To properly handle
this, we need to reset the 'dismissed_by_client' boolean to false, as
otherwise we won't allow new buffer commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
Change to use the headless backend with a virtual monitor, instead of
the nested backend. This means tests can create and use virtual input
devices, which isn't possible with the nested backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
The roundtrip in the handle-configure function could in theory (and in
practice in the future) happen to receive another configure event. If we
send yet another invalid geometry the second time, we log one time too
many in the server, which fails the test. Avoid this by ignoring the
second configure event; it's enough to pass through the error handling
path once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
This won't change anything for 60Hz displays but higher refresh rate
users will benefit.
Using Nvidia EGLStreams on a 240Hz monitor for example (refresh interval
~4.1ms), the maximum render time allowed before dropping to 120Hz is now
3.6ms whereas it was previously 2.1ms.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2158>
When Cogl gained support for importing pixmaps, I think there was a
misunderstanding that there is a difference in how it works in GLX and
EGL where GLX needs to rebind the pixmap in order to guarantee that
changes are reflected in the texture after it detects damage, whereas
with EGL it doesn’t. The GLX spec makes it pretty clear that it does
need to rebind whereas the EGL spec is a bit harder to follow. As a
fallout from Mesa MR 12869, it seems like the compositor really does
need to rebind the image to comply with the spec. Notably, in
OES_EGL_image_external there is:
"Binding (or re-binding if already bound) an external texture by calling
BindTexture after all modifications are complete guarantees that
sampling done in future draw calls will return values corresponding to
the values in the buffer at or after the time that BindTexture is
called."
So this commit changes the x11_damage_notify handler for EGL to lazily
queue a rebind like GLX does. The code that binds the image while
allocating the texture has been moved into a reusable helper function.
It seems like there is a bit of a layering violation when accessing the
GL driver internals from the EGL winsys code, but I noticed that the GLX
code also includes the driver GL headers and otherwise it seems pretty
tricky to do properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2062>
We are using internal API that has the benefit of checking that the
focus surface still matches, but has the drawback that it does not
check the MetaWaylandKeyboard state.
In order to fix this, look for keyboard focus and serial matches
specifically when triggering activation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2148>
The GBM support in the NVIDIA driver is fairly new, and to make it
easier to identify whether a problem encountered is related to using GBM
instead of EGLStreams, add a debug environment variable to force using
EGLStream instead of GBM.
To force using EGLStream instead of GBM, use
MUTTER_DEBUG_FORCE_EGL_STREAM=1
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2045
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2132>
We created pipes for the stdout of the spawned mock services. This
resulted in the pipe being filled if enough things were logged, as
nothing was reading from it. Change this to allow for two modes:
verbose - where output is logged to the parent stderr, as well as non-verbose
(default) - where things are logged directly to /dev/null.
This fixes frozen tests when running with --repeat and a high enough
repeat count.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2139>
This is notably necessary with transformations, since these don't
trigger allocation machinery, but may affect the actor under the
pointer.
Visible e.g. with GNOME Shell's "Application does not respond"
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
With Wayland handling all events as they come, this code now just
performs motion compression for events that will be handled by Clutter
widgetry.
The intent to opt tablets and styli out of motion compression was
early and fast client handling, since that is now covered in a generic
manner, this code is superfluous. We don't really need the extra events
for these devices in compositor widgetry either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
We essentially create those at the time they need to be handled, and
use shortcuts that avoid the event from being queued up. It's too much
of a short cut though, these events are also of interest to the Wayland
event handlers, e.g. to handle pointer state changes (e.g. repicks due
to the pick actor being destroyed) immediately, instead of at the next
event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
If we are still under the "clear area" of the pick actor, we forget
to update the coordinates. This is usually not needed, unless we
need to repick again for non-event circumstances (e.g. pick actor
is destroyed). This will ensure the right pointer coordinates are
used afterwards in those situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Traditionally, the next repaint would also involve picking, which
would correct the actor under the pointer. This now does not happen
out of the box, so we really are waiting for the next pointer event
here.
To avoid the pointer/cursor to lag behind, trigger an immediate
repick here, that will look up the new actor under the pointer
coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
And resort to it first, unless we are told to ignore the cache
(e.g. after relayouts). This avoids further pick context operations
while the pointer is on the current actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
This safe area is the region (in stage coordinates) where the pointer
is ensured to stay within the current actor. This is not used yet, but
will be used for optimizations in pointer picking.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
