We passed the pointer to a GError * as user data on an async I/O call.
The callback function didn't make use of it, so it was never written to,
thus remained NULL, thus was dead code. Remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2446>
It works by using an X11 client to set the clipboard content, using a
mimetype that on purpose is not handled by the clipboard manager. The
test then makes sure we don't crash when trying to transfer data from
the old X11 selection source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The Xwayland server can go away at any time; when this happen we might
have a test client running, and for it to tear down more nicely, make
sure to avoid trying to clean up X11 resources on the old X11 display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
Xwayland can disappear at any time, for example during a new_async() or
read_async() call. When we eventually finalize the stream, the X11
display it was created for is gone, thus can't clean up the X11
resources. Handle this by making the MetaX11Display pointer a weak
pointer, and ignore cleaning up if it disappeared. This is fine since
the X11 server it created those resources one is gone already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The property doesn't necessarily exist when using drivers that doesn't
support atomic mode setting, and the way it worked will break night
light and other gamma related features. This makes things use the gamma
length; if it is higher than 0, it definitely supports it one way or the
other, i.e. GAMMA_LUT with the atomic backend, and drmModeCrtcSetGamma()
with the legacy/simple backend.
Fixes: 364572b95c
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2287
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
It doesn't depend on whether the CRTC is active or not, so always read
it. This is also useful to know whether a CRTC supports gamma, before it
is being turned on, without relying on the existance of properties.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
The COMPOSITOR_GRAB event route has effectively been replaced by
ClutterGrabs, which are no longer covered by the existing check.
So check for grabs as well to restore the old behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
The event-route is never set to COMPOSITOR_GRAB nowadays, so the
condition will never be met.
Furthermore, it is expected that ClutterGrabs only happen when
events are routed normally, so the remaining NORMAL check should
already fully cover the old COMPOSITOR_GRAB case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
We already bypass wayland if there is a ClutterGrab, so the case
that used to be covered by the event-route check is already handled,
and we can just remove the obsolete check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Since the new ClutterGrab API replaced the old plugin-modal hook,
the event-route is never set to COMPOSITOR_GRAB.
The code in question already checks whether the stage has a grab,
so we can just remove old checks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Initializing the event mask, SubstructureRedirectMask in particular,
before taking the manager selection fails with BadAccess. Fix this by
initializing said mask after taking the manager selection.
This fixes `--replace`.
Fixes: eb4307c350
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2432>
The code is already trying to avoid creating new laters when there
already is one for the queue type, but this wasn't working because the
ID of the later was never stored after creating a new one. This would
then result in as many laters as meta_display_queue_window() was called
and all of them would run the handler function, even if only the first
one had a non-empty window queue.
Similarly this was causing the later to not be removed if the window
queue got empty after meta_display_unqueue_window().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
Currently the signal is getting emitted accidentally, because even when
removing a window from the queue, the later handler of that queue will
still get run due to a bug. This bug is going to get fixed in the next
commit, but some things might depend on the signal getting emitted when
the visibility of a window has changed.
This change affects the behavior in two ways. First the signal is now
emitted immediately rather than from an idle. And second it now
correctly includes the window in the should_show or should_hide list.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
