Commit Graph

27508 Commits

Author SHA1 Message Date
Hugo Carvalho
a450486422 Update Portuguese translation 2021-04-29 13:40:43 +00:00
Jonas Ådahl
efd9af1183 output/kms: Add back common modes on non-single mode outputs
But this time, filter out modes that exceed a roughly calculated maximum
bandwidth. This should avoid e.g. setting a 60 Hz 4K mode, when 4K is
limited to 30 Hz, but lower resolutions supporting 60 Hz.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4155
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1834>
2021-04-27 16:12:18 +00:00
Carlos Garnacho
b4a7f35146 backends/native: Unref/unset key repeat GSource when cleared
This GSource is not being properly unref nor the variable holding it
cleared. This on one hand leaks the GSource memory, on the other hand
may trigger warnings in keyboard_repeat() as the source may be
(reentrantly) cleared, yet we don't exit early as
seat_impl->repeat_source is never NULL.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1839>
2021-04-27 08:37:38 +00:00
Luna Jernberg
2337e0af8b Update Swedish translation 2021-04-22 21:31:55 +00:00
Robert Mader
7d3e2c5f9c shaped-texture: Fix damage propagation for rotated transforms with viewport
When a viewport source rect or destination size is set, `stex->dst_width`
gives us the the cropped and/or scaled size. At this step, we need the
uncropped/unscaled size however.

Note: this is only ever relevant if buffer transform and viewport are
used together - otherwise the values are the same.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1836>
2021-04-21 20:29:14 +02:00
Jonas Dreßler
99abb086fb window-actor-x11: Invalidate paint volume when shadow changes
The shadow size is factored into the paint volume MetaWindowActorX11
returns in its get_paint_volume() vfunc override, so we should
invalidate the paint volume every time that shadow might change.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1829>
2021-04-19 17:56:08 +00:00
Jonas Dreßler
2be30a3482 clutter/actor: Invalidate paint volumes of clones when ours changes
Turns out ClutterClones need a bit of extra handling as always, there's
currently nothing that invalidates a clones paint volume when the source
actors paint volume changes.

Since ClutterClones get_paint_volume() implementation simply takes the
source actors paint volume and returns that, we should make sure they
are kept in sync and invalidate the clones paint volume as soon as the
source actor gets its PV invalidated.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1829>
2021-04-19 17:56:08 +00:00
Tim Sabsch
af958e0650 Update German translation 2021-04-19 17:37:57 +00:00
Robert Mader
2ded9c4bf2 shaped-texture: Apply viewport and rotation in right order
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>
2021-04-19 15:03:05 +02:00
Robert Mader
6e00e5e6e7 wayland/subsurface: Avoid placement ops for detached subsurfaces
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>
2021-04-19 11:55:49 +00:00
Robert Mader
f7768874e5 window-actor/wayland: Cleaner subsurface reordering
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>
2021-04-19 11:55:49 +00:00
Piotr Drąg
f4f82bcb96 Update Polish translation 2021-04-17 14:52:42 +02:00
Jordi Mas
0b6565dfbc Update Catalan translation 2021-04-17 08:32:38 +02:00
Yuri Chornoivan
986ae69f88 Update Ukrainian translation 2021-04-15 15:59:47 +00:00
Florian Müllner
d2a492de94 data: Add back (hidden) shortcuts for vertical navigation
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>
2021-04-15 15:31:10 +00:00
Aaron Plattner
cf8efb5827 x11: Skip sending redundant CTM change requests
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>
2021-04-14 18:03:35 -07:00
Aaron Plattner
aa498dc27a x11: Rename atom to ctm_atom
This makes it clearer exactly what atom this is referring to.

Feedback from https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1816#note_1081588

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1816>
2021-04-14 18:02:00 -07:00
Jonas Ådahl
90eab42867 input-settings/native: Check mapping mode in input thread
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>
2021-04-14 19:16:22 +00:00
Jonas Ådahl
efde781747 input-settings: Make set_matrix() vfunc take const float array pointer
It shouldn't alter it, or take ownership, so clarify that by making it
constant.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1806>
2021-04-14 19:16:22 +00:00
Jonas Ådahl
e956078052 kms/connector: Properly predict connectors turning off
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>
2021-04-14 18:44:57 +00:00
Jonas Ådahl
4b78c8d84f renderer/native: Fix disabling monitors on otherwise unchanged device
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>
2021-04-14 18:44:57 +00:00
Jonas Ådahl
14f6869381 onscreen/native: Make sure to reset the EGL context after dGPU blit
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>
2021-04-14 17:42:32 +00:00
Jonas Ådahl
60a998bdbc onscreen/native: Release buffer before destroying EGLSurface
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>
2021-04-14 17:42:32 +00:00
Jonas Ådahl
abbbe8f755 onscreen/native: Remove redundant EGLSurface cleanup
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>
2021-04-14 17:42:32 +00:00
Olivier Fourdan
a2a161eb1e window/x11: Keep buffer size if resize is not allowed
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>
2021-04-14 16:51:21 +00:00
Olivier Fourdan
cc928ba7d2 window/x11: Allow window resize while moving
Commit f2328f11 would ignore any ConfigureRequest from X11 clients while
there is an interactive user operation in progress.

Yet, the user should be allowed to move a window while the X11 client is
resizing it, as the two operations are not intrinsically incompatible.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1674

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1777>
2021-04-14 16:51:21 +00:00
Jonas Ådahl
91117bb052 monitor-manager: Don't include generated code in header file
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>
2021-04-14 16:22:24 +00:00
Jonas Ådahl
4c7a846dc8 output/kms: Only add common modes for single mode connectors
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>
2021-04-14 15:15:52 +00:00
Jonas Ådahl
1f3c5bd316 kms/impl-device-atomic: Remove useless warning
No much use having a "g_return_if_fail (expr);" when we "if (expr)
return;" just above.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1820>
2021-04-14 12:53:25 +00:00
Jonas Ådahl
dc35514fb4 renderer: Switch open coded list clearing to g_clear_list()
The same for MetaRendererNative.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1820>
2021-04-14 12:53:25 +00:00
Jonas Ådahl
1a7f4d49f3 renderer/native: Remove unused function parameter
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1820>
2021-04-14 12:53:25 +00:00
Jonas Ådahl
a40b040cd6 seat-native: Remove left-over function declaration
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1820>
2021-04-14 12:53:25 +00:00
Jonas Ådahl
c822c799e4 kms/impl-device: Fix some argument naming mistakes
It was left-overs from when the MetaKmsImpl was not per device.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1820>
2021-04-14 12:53:25 +00:00
Jonas Ådahl
8867b11e19 launcher: Use gnome.gdbusgen and add prefix to generated API
This is more in line with how generated D-Bus boilerplate work, lets
stay consistent.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1820>
2021-04-14 12:53:25 +00:00
Jonas Ådahl
ad1bffc002 backend/native: Disable KMS modifiers for amdgpu and nouveau as well
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>
2021-04-14 07:14:24 +00:00
Jonas Ådahl
da3baba980 backend/native: Only disable KMS modifiers for i915
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>
2021-04-14 07:14:24 +00:00
Aleksandr Mezin
90e3d9782d Revert "wayland/window: Correct detection whether to send configure"
It breaks more than it fixes.

After commit [1] Shell doesn't trigger the original issue [2] anymore.

[1]: ba0b9239d3
[2]: https://gitlab.gnome.org/GNOME/mutter/-/issues/1627

This reverts commit 236e9ec68f.

Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1723

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1804>
2021-04-14 06:36:09 +00:00
Carlos Garnacho
f92232ae4f backends/native: Check whether views are scaled via MetaViewportInfo
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>
2021-04-13 10:32:14 +00:00
Carlos Garnacho
24dbfbfcf2 backends: Store whether views are scaled in MetaViewportInfo
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>
2021-04-13 10:32:14 +00:00
Jonas Dreßler
5a565b4258 clutter/actor: Update all last_paint_volumes before painting
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>
2021-04-12 15:18:31 +00:00
Jonas Dreßler
3d17e8d590 clutter/actor: Properly invalidate cached paint volumes of actors
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>
2021-04-12 15:18:31 +00:00
Jonas Dreßler
7aa147829d clutter/actor: Add API to invalidate cached paint volumes
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>
2021-04-12 15:18:31 +00:00
Nathan Follens
a796edd892 Update Dutch translation 2021-04-01 19:20:37 +00:00
Robert Mader
a09c914230 wayland/actor-surface: Call ensure_size_valid() on shaped-texture
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>
2021-03-29 15:47:25 +00:00
Robert Mader
5772c27e04 shaped-texture: Expose ensure_size_valid() API
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>
2021-03-29 15:47:25 +00:00
Robert Mader
50ba52b1b5 shaped-texture: Use G_APPROX_VALUE to compare viewport source rects
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
2021-03-29 15:47:25 +00:00
Robert Mader
1bfd932f15 region-utils: Fix typo in crop_and_scale() fastpath
Fixes 09b1bbb1cf

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1786>
2021-03-29 15:17:48 +00:00
Robert Mader
52547cb9ea shaped-texture: Viewport update calculation fixes
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>
2021-03-29 15:17:48 +00:00
Carlos Garnacho
1d82e0f236 core: Drop X11 error trap from pointer warping code
This code is backend-agnostic, and should not do anything special
about X11. Drop these error traps, and let the backend deal with
the possible errors.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1725
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1807>
2021-03-29 13:54:06 +02:00
Carlos Garnacho
1b1f852086 backends/x11: Add traps around XIPointerWarp call
This is left up to higher level code, which is not too nice.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1807>
2021-03-29 13:52:31 +02:00