When using buffer transforms and viewports together, we currently
apply the transformation (read: rotation) first, resulting in
wrong buffer coordinates for viewport source rects.
Flip the order in whitch we apply our matrix transformations.
This can be tested e.g. via:
`weston-simple-damage --use-viewport --transform=flipped-180`
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1832>
If a subsurface first gets reordered and afterwards detached from
the parent before the parent surface got commited, we currently
would end up reattaching the subsurface to its previous parent.
While clients should avoid this behaviour, it's legit according
to the spec.
We already prevent similar cases where the subsurface is destroyed -
extend that check to detaching, which includes the destroy case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1831>
Currently when reordering subsurfaces, we un- and reparent all child
actors of the window actor. This is unnecessarily wasteful and
triggers bugs in clutter. While the underlying issue should be fixed
eventually, simply reorder the actors with the tools clutter provides
us with, avoiding those bugs and likely being faster as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1831>
Users who customized their workspace shortcuts before updating to
GNOME 40 are experiencing troubles when trying to use the same
keybinding for the horizontal shortcuts, because of hidden conflicts
with the vertical ones.
We can address this by registering the old shortcuts with Settings
without showing them in the UI, so that they are taken into account
by Settings' conflict resolution.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1740
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1814>
The X server generates a property change notification whenever it processes a
property change request, even if the value of the property is not changing. This
triggers libgdk to probe all display outputs, which can be slow depending on
which display driver and hardware are in use.
#0 0x00007f8e4d5e91a0 in XRRUpdateConfiguration () at /usr/lib/libXrandr.so.2
#1 0x00007f8e505208da in _gdk_x11_screen_size_changed (screen=0x5566e4b7e080, event=0x7ffe0e44bd60) at ../gdk/x11/gdkscreen-x11.c:1199
#2 0x00007f8e505066d1 in gdk_x11_display_translate_event (translator=0x5566e4b5b110, display=0x5566e4b5b110, event=0x7f8dec001b20, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkdisplay-x11.c:1201
#3 0x00007f8e505135a0 in _gdk_x11_event_translator_translate (translator=0x5566e4b5b110, display=0x5566e4b5b110, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventtranslator.c:51
#4 0x00007f8e50512c97 in gdk_event_source_translate_event (event_source=0x5566e4b764a0, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventsource.c:243
#5 0x00007f8e50512f57 in _gdk_x11_display_queue_events (display=0x5566e4b5b110) at ../gdk/x11/gdkeventsource.c:341
#6 0x00007f8e50497644 in gdk_display_get_event (display=0x5566e4b5b110) at ../gdk/gdkdisplay.c:442
#7 0x00007f8e5051301f in gdk_event_source_dispatch (source=0x5566e4b764a0, callback=0x0, user_data=0x0) at ../gdk/x11/gdkeventsource.c:363
#8 0x00007f8e516ecf9c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#9 0x00007f8e51740a49 in () at /usr/lib/libglib-2.0.so.0
#10 0x00007f8e516ec503 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#11 0x00007f8e508ef5fd in meta_run_main_loop () at ../src/core/main.c:928
#12 0x00007f8e508ef60e in meta_run () at ../src/core/main.c:943
#13 0x00005566e450842a in ()
#14 0x00007f8e50649b25 in __libc_start_main () at /usr/lib/libc.so.6
When GNOME is animating a display fade when the night light feature is toggled
on or off, it sends a lot of change requests for the CTM property in the
process, which triggers a lot of display probes from gdk. In the case of the
night light feature, the CTM itself is not actually changing, so these requests
are redundant. Fix this by caching the CTM value in the MetaOutputXrandr and
skipping the server requests if it's not being changed.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3978
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1816>
When we set the matrix, we checked the device mapping mode in the main
thread, then passed along the calculated matrix to the input thread for
application. This could however be racy, as the mapping mode is managed
in the input thread. Fix this by sending the unaltered matrix, having
the input thread checking the mapping mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1806>
The connector state wasn't properly predicted, as it earlied out if
the connector wasn't part of a mode set connector list.
Instead use the old CRTC to check whether it was used in any mode set,
and whether the connector was part of any new mode set, to predict
whether the connector is inactive or active.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
When a device only had mode sets which turned off monitors, not enabling
anything, there would be no KMS update created and posted, and the
active monitors would remain on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
On hybrid graphics system, the primary path used to transfer the stage
framebuffer onto the dedicated GPU's video memory preparing for scanout,
is using the dedicated GPU to glBlitFramebuffer() the content from the
iGPU texture onto the scanout buffer.
After we have done this, we reset the current EGL context back to the
one managed by cogl. What we failed to do, however, was to reset the
current EGL context when we inhibited the actual page flip due to having
entered power save mode.
When we later started to paint again, Cogl thought the current EGL
context was still the correct one, but in fact it was the one used for
the iGPU -> dGPU blit, causing various EGL surface errors, and as a side
effect, eventually hitting an assert.
Fix this by making sure we reset to the Cogl managed EGL context also
for this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
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>
