Currently the EGLDevice code gets the display and calls eglInitialize.
As a follow-up it checks the required EGL extensions - technically it
could check the EGL device extensions earlier.
In either case, eglTerminate is missing. Thus the connection to the
display was still bound.
This was highlighted with Mesa commit d6edccee8da ("egl: add
EGL_platform_device support") + amdgpu.
In that case, since the eglTerminate is missing, we end up reusing the
underlying amdgpu_device due to some caching in libdrm_amdgpu. The
latter in itself being a good solution since it allows buffer sharing
across primary and render node of the same device.
Note: we should really get this in branches all the way back to 3.30.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/619
Fixes: 934184e23 ("MetaRendererNative: Add EGLDevice based rendering support")
Cc: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
When stage views are scaled with fractional scales, the cursor rectangle
won't be aligned with the physical pixel grid, making it potentially
blurry when positioned in between physical pixels. This can be avoided
by aligning the drawn rectangle to the physical pixel grid of the stage
view the cursor is located on.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/413https://gitlab.gnome.org/GNOME/mutter/merge_requests/610
Attaching a NULL buffer should hide the cursor sprite. In these cases,
we we'll have neither surface nor buffer damage, so also update when we
just attached a NULL buffer.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/630
When 252e64a0ea moved the texture
ownership to MetaWaylandSurface, it failed to handle the case when a
NULL-buffer is attached, leaving the texture reference in place. This
caused issues when the surface should have been hidden (e.g. attaching a
NULL buffer to a cursor surface for hiding the cursor sprite).
Related: https://gitlab.gnome.org/GNOME/mutter/issues/630
Starting from commit 7713006f5, during X11 disposition we also unmanage the
windows using the xids hash table values list.
However, this is also populated by the X11 Meta barrier implementation and then
contains both Windows and Barriers.
So when going through the values list, check whether we're handling a window or
a barrier and based on that, unmanage or destroy it.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/624https://gitlab.gnome.org/GNOME/mutter/merge_requests/605
As per commit 7718e67f, destroying the compositor causes destroying window
actors and this leads to stack changes, but at this point the stack was already
disposed and cleared.
So, clear the stack when any component that could use it (compositor, and X11)
has already been destroyed.
As consequence, also the stamps should be destroyed at later point.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/623https://gitlab.gnome.org/GNOME/mutter/merge_requests/605
Naming the keyboard accessibility settings `a11y_settings` wrongly
assumes there will never be any other type of accessibility settings.
Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future
confusion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
To emulate X11 grabs, mutter as a Wayland compositor would disable its
own keyboard shortcuts and when the X11 window is an override redirect
window (which never receives focus), it also forces keyboard focus onto
that X11 O-R window so that all keyboard events are routed to the
window, just like an X11 server would.
But that's a bit of a “all-or-nothing” approach which prevents
applications that would legitimately grab the keyboard under X11 (like
virtual machine viewers) to work by default.
Change “xwayland-allow-grabs” to control whether the keyboard focus
should be locked onto override redirect windows in case of an X11 grab.
For stringent needs, careful users can still use the blacklisting
feature (i.e. a list containing “!*”) to prevent grabs from any X11
applications to affect other Wayland native applications.
https://gitlab.gnome.org/GNOME/mutter/issues/597
MetaProfiler is not built when -Dprofiler=false, and that
breaks the build since MetaBackend unconditionally imports
and uses it.
Fix that by wrapping MetaProfiler in compile-time checks.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/603
Having a cursor role with a NULL renderer is valid state, and even desirable
on tablets (eg. after proximity out). In those cases it should be
interpreted as the cursor surface not being over any output.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/545
We're currently emitting the 'grab-op-end' signal when the grab prerequisites
are met, but when display->grab_op is still set to a not-NONE value and thus
meta_display_get_grab_op() would return that in the signal callback.
And more importantly when this is emitted, devices are still grabbed.
Instead, emit this signal as soon as we've unset all the grab properties and
released the devices.
Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/1326https://gitlab.gnome.org/GNOME/mutter/merge_requests/596
We're currently emitting the 'grab-op-end' signal when the grab prerequisites
are met, but when display->grab_op is still set to a not-NONE value and thus
meta_display_get_grab_op() would return that in the signal callback.
And more importantly when this is emitted, devices are still grabbed.
Instead, emit this signal as soon as we've unset all the grab properties and
released the devices.
Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/1326https://gitlab.gnome.org/GNOME/mutter/merge_requests/596
We handle this in backend specific code for x11, so do the wayland
bits here. We can only honor this on applications that request focus
on a surface after a startup request, as we do need an explicit
surface to apply the workspace on (and we don't have additional clues
like WMCLASS on X11). Notably, gtk_shell1.notify_startup doesn't suffice.
Another gotcha is that the .request_focus happens when the surface is
already "mapped". Due to the way x11 and the GDK api currently work (first
reply on the startup id, then map a window, then request focus on that
window). This means the surface will ignore at this point
window->initial_workspace, so it must be actively changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/544
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/674
On a successful DnD operation we may expect the wl_data_source and
wl_data_offer to live long enough to finish the data transfer, despite the
grab operation (and other supporting data) being gone.
When that happens, the compositor expects a wl_data_offer.finish request to
notify that it finished. However the client may still chose not to send that
and destroy the wl_data_offer instead, resulting in the MetaSelectionSource
owner for the DnD selection not being unset.
When that happens, the DnD MetaSelectionSource still exists but it's
detached from any grab operation, so will not be unset if eg. the drag
source client destroys the wl_data_source. This may result in crashes when
the next drag operation tries to replace the owner DnD MetaSelectionSource.
Check explicitly for this case, in order to ensure the DnD owner is unset
after such operations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/591
Extract the next buffer -logic into a new function. This allows to
simplify copy_shared_framebuffer_cpu () making it more readable.
This change is a pure refactoring, no functional changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/593
Since commit 956ab4bd made libcanberra mandatory, we never use
the system bell for handling the `audible-bell` setting. So
instead of reacting to settings changes with the exact same call
to XkbChangeEnabledControls(), just call it once when initializing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/598
When running in slow or busy machines (hey CI!) or under valgrind headless
tests could fail because of a non fatal warning during initialization.
So define a fatal handler that ignores the frame counter warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
Creating a window could take some time, causing false-positive failures when
running in slower or busy hardware like:
window 1/2 isn't known to Mutter
So before we proceed in doing any operation on it, wait for the client.
Do this in the test runner instead of repeating the same in every .metatest.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
This debug statement is actually applied all the times, while it could be useful
for crashes analysis, these days the same can be done using `MALLOC_CHECK_` and
`MALLOC_PERTURB_` env variables.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
This argument instructs Xwayland to exit when there are no further
client connections. However we eventually want to handle restarts
ourselves (where, notably, mutter's will be at least the last client
connection).
This behavior could also induce race conditions on startup with clients
that quickly open and close a display, which is a more pressing issue.
Also, add -noreset back (which was also removed in commit 054c25f693 that
added -terminate). We don't want to reset the X server to a pristine state
in that situation either.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
Code underneath seems to handle errors properly, or be x11-agnostic
entirely, this is apparently here to save a few XSync()s on X11. Just
drop this windowing dependent bit to make things cleaner.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
Code underneath seems to handle errors properly, and this is apparently
here to save a few XSync()s on X11. Just drop this windowing dependent
bit to make things cleaner.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
It is now separated into meta_xwayland_start(), which picks an unused
display and sets up the sockets, and meta_xwayland_init_xserver(), which
does the actual exec of Xwayland and MetaX11Display initialization.
This differentiation will be useful when Mutter is able to launch Xwayland
lazily, currently the former calls into the latter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
In all places (including src/wayland) we tap into meta_x11_display* focus
API, which then calls meta_display* API. This relation is backwards, so
rework input focus management so it's the other way around.
We now have high-level meta_display_(un)set_input_focus functions, which
perform the backend-independent maintenance, and calls into the X11
functions where relevant. These functions are what callers should use.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
