The acked configuration is removed from the pending configuration list
by acquire_acked_configuration(), but finish_move_resize() does not free
the data after applying the configuration.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1020
As recommended by the docs for `g_settings_schema_source_get_default`:
> The returned source may actually consist of multiple schema sources
> from different directories, depending on which directories were given
> in XDG_DATA_DIRS and GSETTINGS_SCHEMA_DIR. For this reason, all lookups
> performed against the default source should probably be done recursively.
Now it's actually found and works again, including subpixel font smoothing.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1447https://gitlab.gnome.org/GNOME/mutter/merge_requests/1017
ClutterActors width and height can be reset to automatically use the
preferred (calculated) value by setting the width or height to -1, so
far this only works by setting it using `clutter_actor_set_width()` or
`clutter_actor_set_height()`, make sure it can also be done using the
"width" and "height" GObject properties.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1018
Where possible, try to export the buffer rendered by the primary GPU as a
dmabuf and import it to the secondary GPU and turn it into a DRM FB for
scanout. If this works, we get a zero-copy path to secondary GPU outputs.
This is especially useful on virtual drivers like EVDI (used for DisplayLink
devices) which are not picky at all about what kind of FBs they can handle.
The zero-copy path is prioritised after the secondary GPU copy path, which
should avoid regressions for existing working systems. Attempting zero-copy
would have the risk of being less performant than doing the copy on the
secondary GPU. This does not affect the DisplayLink use case, because there is
no GPU in a DisplayLink device.
The zero-copy path is prioritised before the primary GPU and CPU copy paths. It
will be tried on the first frame of an output and the copy path is executed
too. If zero-copy fails, the result from the copy path will take over on that
frame. Furthermore, zero-copy will not be attemped again on that output. If
zero-copy succeeds, the copy path is de-initialized.
Zero-copy is assumed to be always preferable over the primary GPU and CPU copy
paths. Whether this is universally true remains to be seen.
This patch has one unhandled failure mode: if zero-copy path first succeeds and
then fails later, there is no fallback and the output is left frozen or black.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
With all the three paths this is quite a handful of code, and it was mostly
duplicated in two places. A follow-up patch would need to introduce a third
copy of it. Therefore move the code into a helper function.
There are two behavioral changes:
- The format error now prints the string code as well, because it is easy to
read.
- The g_debug() in init_dumb_fb() is removed. Did not seem useful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
There will be another place where I need to release the dumb buffers but not
destroy the whole secondary_gpu_state, so extract this bit of code into a
helper.
The checks of fb_id are dropped as redundant with the check already in in
release_dumb_fb ().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
release_dumb_fb () checks 'map' to see if anything needs freeing. Other places
are checking fb_id instead. The checks maybe redundant, but let's reset all
fields here while at it, so that all the checks work as expected.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
Simplify the bo freeing functions by not checking what the copy mode is. This
matches what swap_secondary_drm_fb () already does. g_clear_object () is safe
to call even if the value is already NULL.
The copy mode does not change mid-operation. If it did, this change would
ensure we still clean up everything. So this is more future-proof too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
To mirror what happens in meta_onscreen_native_swap_buffers_with_damage(), warn
here too if next_fb is not NULL. This makes it clear to the reader of what the
expectations are inside this function.
Ensuring next_fb is NULL as the first thing in the function will make all error
paths equal: no longer some failures reset next_fb while others don't. Removing
such special cases should reduce surprises.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
Just pass it in to the vertex shader like in GLES, it's one less thing
to vary between drivers. mutter is, shall we say, not a heavy user of
point primitives, so any performance impact (it might be measurable, who
knows) is not an issue. Again, the feature flag remains to be cleaned up
in a future commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/995
We're always running through the GLSL pipeline so the fixed-function
alpha test is never invoked. This change does not yet remove the
alpha-test feture bit from the context because this bit of uniform
handling is going to be simplified in a future commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/995
If we end up trying to do a mode set on a DRM state that has already
changed behind our back without us yet having seen the hotplug event we
may fail with `EINVAL`. Since the renderer layer doesn't handle mode set
failure, it'll still try to page flip later on, which will then also
fail. When failing, it'll try to look up the cached mode set in order to
retry the mode set later on, as is needed to handle other error
conditions. However, if the mode set prior to the page flip failed, we
won't cache the mode set, and the page flip error handling code will get
confused.
Instead of asserting that a page flip always has a valid cached mode set
ready to look up, handle it being missing more gracefully by failing to
mode set. It is expected that things will correct themself as there
should be a hotplug event waiting around the the corner, to reconfigure
the monitor configuration setting new modes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
On Xwayland, freezing actor updates on sync requests means the
server-side frame and shadows repaint will be frozen as well, which
causes the shadow to show black at times when resizing X11 clients
which support NET_WM_SYNC.
Using freeze/thaw commits prevents the content from changing, yet the
shape window still needs to be updated when frozen otherwise the
difference in shape induced by the on-going resize operation will show
as well, even if the toplevel window has its commits frozen.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=767212
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/858
To address the black shadows that sometimes show during resize with
Xwayland, we need to update the window shape regardless of the frozen
status of the window actor.
However, plain Xorg does not need this, as resized windows do not clear
to black, so add a new vfunc to window/x11 to indicate whether or not
the backing windowing system (either plain X11 or Xwayland) would
require the shape to be always updated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Currently, the window actor freeze/thaw implementation sets the frozen
state of the surface actor using `meta_surface_actor_set_frozen()`.
If we want to expand that behavior to also freeze/thaw commits for X11
windows running on Xwayland, we need to have a specific vfunc to abstract
that in the window actor specific implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
To make sure the frame is painted before the commits are thawed, freeze
the commits when invalidating the GDK window, only to thaw to it after
the actual frame draw is performed or the frame is destroyed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Make sure we freeze commits before resizing the window as this will
clear the frame to black.
Set the "thaw on paint" flag so that the post paint for window actor X11
can then thaw the freeze initiated prior to the resize and keep the
freeze/thaw balanced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
To be able to thaw commits following a resize that might have frozen
commits, to keep freezes and thaws even, we need a way to tell whether
a repaint should also thaw commits.
Add a flag to `MetaWindowX11` and the appropriate functions to set and
query it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Xwayland may post damages for an X11 window as soon as the frame
callback is triggered, while the X11 window manager/compositor has not
yet finished updating the windows.
If Xwayland becomes compliant enough to not permit updates after the
buffer has been committed (see [1]), then the partial redraw of the X11
window at the time it was posted will show on screen.
To avoid that issue, the X11 window manager can use the X11 property
`_XWAYLAND_ALLOW_COMMITS` to control when Xwayland should be allowed to
post the pending damages.
Add `freeze_commits()` and `thaw_commits()` methods to `MetaWindowX11`
which are a no-op on plain X11, but sets `_XWAYLAND_ALLOW_COMMITS` on
the toplevel X11 windows running on Xwayland.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
See-also: https://gitlab.gnome.org/GNOME/mutter/merge_requests/855https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
At the moment we only disarm the watchdog timer set up for SYNC counter
requests if we're in the middle of a resize operation.
It's possible that the resize operation finished prematurely by the user
letting go of the mouse before the client responded. If that happens, when the
client finally updates mutter will erroneously still have the watchdog timer
engaged from before until it times out, leading to resizes for the next second
or so to not get processed, and the client to get blacklisted from future sync
requests.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
This avoids using bogus geometric values from an unmapped actor to
determine whether an actor is on a logical monitor or not. This would
happen when committing to a subsurface of a yet to be mapped toplevel.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
Without 'wayland/surface-actor: Reset and sync subsurface state when
resetting' this test would fail.
This also adds a simple framework for testing lower level Wayland
semantics.
In contrast to the test-client and test-driver framework, which uses
gtk and tests mostly window management related things, this framework is
aimed to run Wayland clients made to test a particular protocol flow,
thus will likely consist of manual lower level Wayland mechanics.
A private protocol is added in order to help out clients do things they
cannot do by themself. The protocol currently only consists of a request
meant to be used for getting a callback when the actor of a given
surface is eventually destroyed. This is different from the wl_surface
being destroyed due to window destroy animations taking an arbitrary
amount of time. It'll be used by the first test added in the next
commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
As with most other state that ends up being pushed to the actor and the
associated shaped texture, also push the texture and the corresponding
metadata from the actor surface. This fixes an issue when a toplevel
surface was reset, where before the subsurface content was not properly
re-initialized, as content state synchronization only happened on
commit, not when asked to synchronize.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
A actor surface may be reset by an xdg_toplevel if a NULL buffer is
attached. This should reset the actor state of the toplevel to an empty
state, while unmapping the previous actor. Subsurfaces, however, should
stay intact, including their relationship to the toplevel. They should
also not be yanked away from the actor of the actor surface prior to it
resetting, so that a window-destroy animation can include the subsurface
actor.
This fixes a potential crash when a subsurface tries to commit to its
wl_surface after the destroy animation of the toplevel has finished, as
the actor would at that point have been destroyed and cleared from the
actor surface struct, causing a segmentation fault.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
Similar to wl_list_foreach(), add
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE() that iterates over all the
subsurfaces of a surface, without the caller needing to care about
implementation details, such as leaf nodes vs non-leaf nodes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
While it's not very relevant now, as we would rarely create it anyway
since the buffer nor texture never changes for a surface, it will be in
the future, as the actor state (including its content,
MetaShapedTexture) will be synchronized by the MetaWaylandActorSurface
at a later point in time, and not by MetaWaylandSurface, at state
application time.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
The method `relative_motion_across_outputs` is used to adjust the
distance/delta of a mouse movement across multiple monitors to take the
different scale factors of those monitors into account. This works by
getting the adjacent monitors that the movement-line/vector intersects
with and adjusting the final position (or end point of the
movement-line) by multiplying the parts of the line spanning across
different monitors with the scale factors of those monitors.
In the end of this calculation, we always want to set the new end
coordinates of the relative motion to the new end coordinates of the
adjusted movement-line. We currently only do that if all adjacent
monitors the line is crossing actually exist, because only then we end
up inside the "We reached the dest logical monitor" else-block and set
`x` and `y` to the correct values. Fix that and make sure the returned
values are also correct in case an adjacent monitor doesn't exist by
adding separate `target_x` and `target_y` variables which we update during
each pass of the while loop so we're always prepared for the while loop
exiting before the destination monitor was found.
Thanks to Axel Kittenberger for reporting the initial bug and tracking
the issue down to `relative_motion_across_outputs`.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/774
