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>
Lets wait until we have better ways to unredirect client buffers before
we start enabling KMS modifiers for amdgpu and nouveau; we end up with
mismatch between client buffer modifiers and primary plane modifier,
which right now needs to be the same for unredirection.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
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>
Updating the last_paint_volume while painting has proven itself to be
quite prone to issues: First we had to make sure actors painted by
offscreen effects get their last_paint_volumes updated correctly (see
0320649a1c), and now a new issue turned up
where we don't update the paint volumes while a fullscreen unredirect is
happening.
To stop those issues from happening and to lay the foundation for using
the last_paint_volume for other things, update the last_paint_volume in
a separate step before painting instead of doing it in
clutter_actor_paint().
To save some resources, avoid introducing another traversal of the
scenegraph and add that step into the existing step of updating the
stage_views lists of actors. To properly update the paint volumes, we
need to do that after finishing the queued redraws, which is why we move
clutter_stage_maybe_finish_queue_redraws() to happen before the new
clutter_stage_finish_layout().
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1699
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
The priv->paint_volume field of ClutterActor stores the cached paint
volume in the actors local coordinate system. It consist of the actors
paint volume itself and the union of all children paint volumes.
We want to invalidate those cached paint volumes according to the
following rules:
- If an actors transformation matrix changes, all paint volumes of the
parent-tree need to be invalidated (that's because the parent-volumes
have unioned the actors paint volume). Our own paint volume does not
need invalidation since the transformation matrix is not applied to it.
- If an actors allocation-size changes, its own paint volume and all the
volumes of the parent-tree need to be invalidated. That's because the
allocation-size is used as the size of the paint volume.
- If a clip gets set or clip_to_allocation gets enabled for an actor,
its own paint volume and all the volumes of the parent-tree need to be
invalidated. That's because the clip is factored in when creating the
paint volume.
So far we did this invalidation in various places and the invalidation
up the parent-tree happened inside clutter_actor_real_queue_relayout().
We did not invalidate on changes to the actors transformation matrices
and the invalidation in clutter_actor_real_queue_relayout() was more
like a "big hammer" that probably invalidated unnecessarily a few times.
So introduce proper infrastructure to invalidate those cached paint
volumes of actors only in the cases where they actually need to be
invalidated. To do that, we reuse the transform_changed() function and
introduce a new function queue_update_paint_volume() that invalidates
the paint volumes up the actor tree.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
ClutterActors can override the get_paint_volume() vfunc in case they
draw outside the allocation. That's used by a bunch of actors, for
example ClutterText or StViewport in gnome-shell.
In case of StViewport, the paint volume returned depends on the value of
the StAdjustment, which means when we start to cache paint volumes more
agressively in ClutterActor, we'll need to add API that allows
StViewport to invalidate the paint volume. So introduce
clutter_actor_invalidate_paint_volume() to invalidate the cached paint
volume.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
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>
The action might not have been triggered yet, as per its trigger
threshold. This doesn't mean we shouldn't reset the point(s) accumulated
so far.
This fixes those touchpoints persisting after disable/enable, thus
making gesture recognition fail from there on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1791>
We might want to perform distance/threshold checks in the ::prepare
vfunc, but we didn't record the last motion event yet. This used to
give a delta of 0/0 between the press and last motion coordinates,
despite the ClutterGestureAction having a trigger threshold. This
happens no longer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1791>
The usage of clutter_actor_get_preferred_width/height() for building the
pick box can trigger Clutters size negotiation machinery in case the
allocation of the actor is invalidated, with commit 82f3bdd1 we worked
around that by excluding actors with invalidated allocations from
picking.
There's no need to do that though, when picking we always want to
operate on the last known allocation of the actor, since that is what's
actually painted on the screen.
So instead of not picking at all when an actors allocation is
invalidated, just use the size of the last allocation. We still have to
factor in one extra case, that's when an actor hasn't gotten any
allocation yet: In that case we want to exclude the actor from picking
since the actor is not on the screen yet.
This fixes a regression introduced by the commit mentioned above where
picking wouldn't work on windows that have just been resized.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1674
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1784>
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>
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>
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>
