Destroying the EGLSurface frees the underlying container structs. When
we call gbm_surface_release_buffer() with a gbm_surface the EGLSurface
was created from, doing that after the EGLSurface was destroyed results
in attempts to access freed memory. Fix this by releasing any buffer
first, followed by destroying the EGLSurface, and lastly, the
gbm_surface.
This was not a problem prior to CoglOnscreen turning into a GObject, as
in that case, the dispose-chain was not setup correctly, and the
EGLSurface destruction was done in the native backend implementation.
This also changes a g_return_if_fail() to a g_warn_if_fail(), as if we
hit the unexpected case, we still need to call up to the parent dispose
vfunc to not cause critical issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
It's handled by CoglOnscreenEgl's dispose() implementation. It was
failed to be invoked in the past because the old non-GObject web of
vtables were not setup correctly, meaning the old generic EGL layer of
the CoglOnscreen de-init was never invoked.
When the type inheritence was cleaned up, this mistake was not cleaned
up, so do that now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
Mutter would deny the application the right to resize itself during an
interactive resize, to avoid the user and the client to fight for the
size.
When the client is not allowed to resize, it would use the client rect
rather than the buffer rect.
As a result, the client window with client side decorations would
quickly shrink to its minimum size.
Use the buffer rect instead, so that the size really remains the same.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1674
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1777>
Meson doesn't seem to handle depending on generated headers, at least
when those headers are pulled in indirectly via another header file.
Luckily, we don't actually need to include the generated D-Bus boiler
plate in meta-monitor-manager-private.h, since the MetaMonitorManager
type no longer is based on the D-Bus service skeleton.
So, by moving the inclusion of the generated D-Bus header file into
meta-monitor-manager.c, we should hopefully get rid of the sporadic
build issues.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1819>
If there was only a single mode, add the common modes to provide options
to select other resolutions than the built in default. This avoids
issues where the connector listed multiple supported modes, but where
the common modes added would exceed the possible bandwidth. We could
probably make an attempt to filter out more modes from the common mode
list to avoid these issues, but it's likely that the driver already
lists suitable modes, meaning there is no point in adding the common
modes.
The common modes were initially added[0] to add modes to connectors with
a single bundled mode, so we shouldn't regress the original bug fix.
[0] https://bugzilla.gnome.org/show_bug.cgi?id=744544
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1232
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1824>
The intel DRM driver is known for not being able to handle multi head
setups when KMS modifiers are enabled, due to the implicitly selected
modifiers, while being more suitable for single head setups, cause
bandwidth issues when a certain number of monitor times resolution and
refresh rate is configured.
We don't yet support automatically finding a combination of modifiers
that work, and have because of this disabled KMS modifiers unless the
driver actually needs it.
Lets flip this configuration the other way around, changing the current
udev rule to decide wen to *disable* KMS modifier support, as it so that
only the Intel driver has this problem, while on the other hand, there
several drivers that requires modifiers to function at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
The input thread is in deep water doing the meta_is_*() check itself,
as that pokes the MetaMonitorManager managed by the main thread. Use
the getter from the MetaViewportInfo instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1793>
We need to pass this info from the main thread, as that pokes the
MetaMonitorManager underneath. Store it in the MetaViewportInfo
so that the input thread can use this information.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1793>
Use the new API to make sure the shaped texture has a valid size
during the next layout phase.
This is needed here because, quoting the previous commit:
When the texture size is invalidated using `invalidate_size()`, the new
size will only get calculated the next time `update_size()` is
called. This happens e.g. in `meta_shaped_texture_get_preferred_size()`
via `ensure_size_valid()`.
`update_size()` can chain up to `clutter_content_invalidate_size()`
as well as emitting a `size-changed` signal. If this happens during
layout, the result is a 'change the layout conditions during layout'
issue, causing heavy breakage in e.g. the Shell overview.
To fix this, expose `ensure_size_valid()` as API so callers can make
sure the texture has a valid size without creating redundant size
invalidations calls.
Note that if a buffer with a new size is attached we already trigger
`update_size()` explicitely, avoiding such situations.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1718
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
When the texture size is invalidated using `invalidate_size()`, the new
size will only get calculated the next time `update_size()` is
called. This happens e.g. in `meta_shaped_texture_get_preferred_size()`
via `ensure_size_valid()`.
`update_size()` can chain up to `clutter_content_invalidate_size()`
as well as emitting a `size-changed` signal. If this happens during
layout, the result is a 'change the layout conditions during layout'
issue, causing heavy breakage in e.g. the Shell overview.
To fix this, expose `ensure_size_valid()` as API so callers can make
sure the texture has a valid size without creating redundant size
invalidations calls.
Note that if a buffer with a new size is attached we already trigger
`update_size()` explicitely, avoiding such situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
If only a viewport destination size is set, the noop viewport has
to take the buffer scale into account.
If a viewport source but no viewport destination size is set, the
destination size is that of the viewport source, not of the whole
texture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1786>
If a client is naive enough to assume that it can set the selection while
it has got no surfaces, mutter will simply ignore the request and leave
the selection unchanged.
This is good and the expected behavior, however the poor client that did
this will enter in an inconsistent state where it "claimed" the selection,
but nobody told it that the wl_data_source is not current.
So, when the client is focused the next time, it will receive wl_data_offers
as usual, but it will still think all the time that it is owning the
selection. In the case of GTK, that takes client-side shortcuts, so any
attempted paste will still bring back the client-side aborted selection.
To fix this, cancel the selection right away if it happened while unfocused,
the client will be able to undo its own failed selection, and not assume
that future offers are its own.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1469
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1772>
It seems to be the preferred format of the Mesa V3D driver on
Raspberry Pi 4. If the compositor doesn't advertise it then Mesa will
fallback from `zwp_linux_dmabuf_v1` to `wl_drm`, incorrectly. Meaning
it will keep using a buffer with modifiers on an interface that does
not have modifiers.
Add support for `DRM_FORMAT_ABGR2101010`. It works, and prevents Mesa
from taking its broken fallback path.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1520
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1798>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
For Xwayland, mutter creates the sockets in the standard /tmp/.X11-unix
directory.
Yet, if that directory already exists, it may have been created by
another user with full control over the created socket.
To avoid that issue, if the directory /tmp/.X11-unix already exists,
check that the permissions are as we expect, i.e. the directory belongs
to either root or the user herself, is writable and has the sticky bit.
Thanks to fabian@ritter-vogt.de for reporting that issue.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1708
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1787>
Unlike other subsurface state, placement operations need to get
applied in order. As per spec:
```
Requests are handled in order and applied immediately to a pending
state. The final pending state is copied to the active state the
next time the state of the parent surface is applied.
```
Having placement operations being part of the subsurface state
makes it difficult to support arbitrary orderings. Make them
part of the parents surface pending state instead.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1691
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1768>
MetaInputSettings unref:ed the seat on destruction, but it never ref:ed
it on construction, meaning it "stole" the reference from the rightful
owner. Make MetaInputSettings less of a thief.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
XIQueryPointer allocates the button state mask that we were leaking in
some places. We need to manually free this, because there is no XI
function that would do this for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1728>
In case the shell ignores or can't accept the restart request we should
hide the message that has been just requested to be shown.
As per ::show-restart-message signal documentation, this has to be done by
emitting the signal with a NULL message.
So follow the API properly in such case
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1780>
In non-systemd managed session we are unable to start services on
demand. Instead, gnome-session will start everything at login time,
including any X11 related service (i.e. gsd-xsettings).
However, in order to start gsd-xsettings, Xwayland needs to be started
already. Otherwise it will connect to GNOME_SETUP_DISPLAY and login will
hang at that point.
Fix this by detecting whether mutter is running in a systemd unit. If it
is, we assume that we are systemd managed and the machinery to start the
services works fine. If not, we assume that the session management may
unconditionally try to start X11 related services and Xwayland must be
started in order to not block this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1771>
On Wayland MetaInputSettings is part of the input thread. Connecting
a GSettings binding to the default ClutterSettings could result in the
change notification being emitted on the input thread. This then could
end up triggering the same handler from two different threads at the
same time. In the case of the ClutterText layout cache it was attempting
to unref the same layout twice, leading to a crash.
This can be avoided by simply removing the GSettings bind. This does not
cause changes to this setting to be missed by ClutterSettings because it
itself already sets up a bind.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1696
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1776>
When deciding if `configure` event should be sent,
`meta_window_wayland_move_resize_internal` compares requested window size
with `window->rect` size. However, `window->rect` is only updated when `commit`
is received. So the following sequence produces incorrect result:
1. a window initially has size `size1`
2. `move_resize_internal` is called with `size2`. `configure` is sent
3. `move_resize_internal` is called with `size1` to restore original size,
but `commit` for `size2` haven't arrived yet. So `window->rect` still has size
`size1`, and thus new `configure` is not sent
4. `commit` for `size2` arrives, window changes size to `size2`
Expected window size in the end: `size1`
Actual: `size2`
To fix the issue, take size from pending `configure` events into account.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1627
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1755>
This eliminates the need for any render node or device nodes, thus can
be used without any graphics hardware available at all, or with a
graphics driver without any render node available.
The surfaceless mode currently requires EGL_KHR_no_config_context to
configure the initial EGL display.
This also means we can enable the native backend tests in CI, as it
should work without any additional privileges.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
