As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.
wayland/data-device: Hook up data devices to seats
They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.
wayland: Don't get Wayland compositor via singleton getter
This means via the ownership chain or equivalent.
xwayland: Hook up manager to Wayland compositor
Same applies to the drag-n-drop struct.
xwayland: Make X11 event handling compositor instance aware
This avoids finding it via singletons in the callee.
xwayland: Don't get Wayland compositor from singleton
xwayland: Pass manager when handling dnd event
window/xwayland: Don't get Wayland compositor from singleton
xwayland/grab-keyboard: Don't get backend from singleton
xwayland: Don't get backend from singleton
wayland: Always get the backend from the context
This means traveling up the ownership chain or equivalent when
necessary.
wayland: Hook up data devices, offers and sources to the compositor
This allows tying them to a context without going through any
singletons.
wayland: Don't get display from singleton
xwayland: Don't get display from singleton
tablet: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This code path is important for "empty" commits to ensure we schedule
frame callbacks even if previous commits didn't cause stage redraws.
There is, however, no reason to schedule updates on all stage views
instead of only those the actor is on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
Move the use count from a separate MetaWaylandBufferRef struct to the
MetaWaylandBuffer class, and remove the former.
The buffer use count is now incremented already in
meta_wayland_surface_commit, since the Wayland protocol defines the
buffer to be in use by the compositor at that point. If the buffer
attachment ends up being dropped again before it is applied to the
surface state (e.g. because another buffer is committed to a
synchronized sub-surface before the parent surface is committed),
the use count is now decremented, and a buffer release event is sent if
the use count drops to 0.
Buffer release events were previously incorrectly not sent under these
circumstances. Test case: Run the weston-subsurfaces demo with the -r1
and/or -t1 command line parameter. Resize the window. Before this
change, weston-subsurfaces would freeze or abort after a few resize
operations, because mutter failed to send release events and the
client ran out of usable buffers.
v2:
* Handle NULL priv->buffer_ref in
meta_wayland_cursor_surface_apply_state.
v3:
* Remove MetaWaylandBufferRef altogether, move the use count tracking
to MetaWaylandBuffer itself. Much simpler, and doesn't run into
lifetime issues when mutter shuts down.
v4:
* Warn if use count isn't 0 in meta_wayland_buffer_finalize.
* Keep pending_buffer_resource_destroyed for attached but not yet
committed buffers. If the client attaches a buffer and then destroys
it before commit, we ignore the buffer attachement, same as before
this MR.
v5:
* Rebase on top of new commit which splits up surface->texture.
* MetaWaylandSurfaceState::buffer can only be non-NULL if
::newly_attached is TRUE, simplify accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Preparation for potentially calling meta_wayland_transaction_apply some
time after surface commit, in which case doing it in the former would be
too late: The client may legally destroy the attached wl_buffer
immediately after commit, in which case meta_wayland_buffer_attach would
spuriously fail and disconnect the client (or possibly even crash mutter
due to NULL error).
Requires splitting up the surface texture between protocol and output
state, and propagating from the former to the latter via
MetaWaylandSurfaceState.
v2: (Jonas Ådahl)
* Move meta_wayland_surface_get_texture call to separate line.
* Use g_autoptr for GError.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
And keep track of the hierarchy separately for the Wayland protocol and
for output. Protocol state is updated immediately as protocol requests
are processed, output state only when the corresponding transaction is
applied (which may be deferred until the next commit of the parent
surface).
v2:
* Directly add placement ops to a transaction, instead of going via
pending_state.
* Use transaction entry for the sub-surface instead of that for its
parent surface.
v3:
* Use transaction entry for the parent surface again, to ensure proper
ordering of placement ops, and call
meta_wayland_surface_notify_subsurface_state_changed only once per
parent surface.
* Drop all use of wl_resource_add_destroy_listener, transactions are
keeping surfaces alive as long as needed.
v4:
* Rebase on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501
* Drop ClutterActor code from meta_wayland_surface_apply_placement_ops.
(Robert Mader)
v5:
* Rename MetaWaylandSubSurfaceState to MetaWaylandSurfaceSubState, since
the next commit adds not sub-surface specific state to it.
v6:
* Move include of meta-wayland-subsurface.h from
meta-wayland-transaction.c to .h, since the latter references
MetaWaylandSubsurfacePlacementOp.
v7:
* Drop superfluous !entry check from meta_wayland_transaction_apply.
v8:
* Rename output/protocol fields to output/protocol_state. (Jonas Ådahl)
v9:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_add_placement_op.
v10:
* Fix a few style issues per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
While the check for `clutter_actor_has_mapped_clones` clearly indicates
an intention to take clones into account, the following code
does not do so, likely because it predates the introduction of
`clutter_actor_is_effectively_on_stage_view()`.
Switch to that newer API in order to take clones into account. This
avoids unnecessary `wl_surface_send_enter()` and `wl_surface_send_leave()`
events when entering the overview, reducing client work.
This also avoids unnecessarily allocating a `cairo_region_t`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2502>
The extra stage update we schedule in `apply_state()` is mainly
needed in two situations:
- a partial update happened only in obscurred or off-screen parts
of a surface
- a surface requests frame callbacks without having done damage,
notably the (in)famous Firefox vsync implementation.
Commit 0330ce1f15 limited the update to cases when the actor
was mapped, breaking it for Firefox in the overview.
Remove the mapped check again and get the stage from the backend,
restoring previous behaviour.
Fixes 0330ce1f15
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1957
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2034>
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>
Wayland clients using buffers without alpha channel are not expected to
set an opaque region. However, we rely on the opaque region for the fast
painting path in `MetaShapedTexture`.
Thus, make sure to always set an opaque region internally in those cases.
For X11 clients, wo do so already.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1463
There's no need to update the outputs recursively in case the actor gets
mapped or unmapped. That's because mapping happens recursively itself,
so if a window with multiple subsurfaces is shown, all subsurfaces will
receive a "notify::mapped" signal.
Since this was the only remaining user of
meta_wayland_surface_update_outputs_recursively(), we can now remove
that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1358
ClutterActors new "stage-views-changed" signal fits pretty well for the
updating of wl_outputs a MetaWaylandActorSurface is on: With that signal
we get notified if the surface moved to a different CRTC, of which every
output has at least one.
So start listening to that signal, which fixes a bug where the wl_output
of a surface changes, but its allocation remains the same (which means
no signals triggering an update of the outputs will be emitted) and no
enter/leave events for the new wl_outputs are sent to the client. This
can happen when a monitor is hotplugged but the new allocation is
exactly the same as the old one even though it's on a different monitor.
Since the "stage-views-on-changed" signal will also get emitted when a
parent actor of the surface is moved, this means we can now remove the
call to meta_wayland_surface_update_outputs_recursively() on window
position changes or the completion of window-effects.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1358
There's no reason to notify the surface that its geometry changed when
the visibility of the actor changes. This is only needed to update the
outputs of the surface, so do that directly instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
We started listening to notify::mapped with commit
5eb5f72434 in order to emit
wl_surface.leave events consistently when a surface gets hidden. This
caused a problem with the ClutterClones used in the overview, since
those temporarily map and unmap the windows for painting, spamming
wl_surface.leave and enter events to all surfaces.
We can easily fix that by also treating mapped clones as mapped, which
means the surface should also be on a wl_output when the overview is
shown.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1141https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
We started listening to "notify::position" on surface actors with commit
08e4cb54. This commit was done to fix a regression from commit cf1edff9,
which forgot to handle some cases like the actual WindowActor and not
the SurfaceActor (which is a child of the WindowActor) moving (that was
fixed by listening to MetaWindows "position-changed" signal). Also that
commit introduced meta_wayland_surface_update_outputs_recursively(),
which updates the outputs of all (sub-)surfaces in case any position
changed and made sure subsurfaces also get their outputs updated in case
the parent actor moved.
Connecting to the "notify::position" signal, which the above commit also
did is now superflous though because position changes will queue a
relayout and the actors allocation will change during the next
allocation cycle, notifying the "allocation" property which we also
listen to.
So save some resources and stop listening to that signal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
Currently a buffer use count always reaches zero before it is replaced.
This is due to the fact that at the point a new buffer is attached, the
last potential user releases it (the stage) since the currently
displayed frame has a composited copy of the buffer.
This may however change, if a buffer is scanned out directly, meaning it
should not be released until the page flip callback is invoked.
Prepare for this by making the buffer reference a heap allocated struct,
enabling us to keep a pointer to it longer than the buffer is attached.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
The role determines how a relative coordinate is calculated. More
specifically, using clutters API to transform coordinates is only
accurate right after a clutter layout pass but this function is used
e.g. to deliver pointer motion events which can happen at any time. This
isn't a problem for Wayland clients since they don't control their
position, but X clients do and we'd be sending outdated coordinates if a
client is moving a window in response to motion events.
This was already done already, but now move the Xwayland specific logic
to the Xwayland surface role, keeping the generic transformation logic
in the generic actor surface role.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
XWayland clients get their opaque region set from their window, not the
surface. Doing both resulted in the surface constantly overwriting the
opaque region - effectively disabling culling of XWayland clients.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1049
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
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
The vfunc is not called when a surface commits its state, but when the
state is applied. Make this clearer by changing the name to
"apply_state" (and "pre_apply_state").
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The name didn't communicate it was about surface state, and it somewhat
confusingly had the name "pending" in it, which could be confused with
the fact that while it's used to collect pending state, it's also used
to cache previously committed pending state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
We're expected by MetaWaylandSurface to always pick the frame callbacks
out from the pending state when committing (applying) so that no frame
callbacks are unaccounted for. We failed to do this if our actor for
some reason (e.g. associated window was unmanaged) was destroyed. To
handle this situation better, store away the frame callbacks until we
some later point in time need to pass them on forward.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/893
A frame callback without damage is still expected to be responded to.
Implement this by simply queuing damage if there are any frame callbacks
requested and there is no damage yet. If there already is damage,
we'll be queued already, but with more correct damage. Without we simply
need to make sure we flush the callbacks if any area of surface is not
occluded.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/457https://gitlab.gnome.org/GNOME/mutter/merge_requests/839
Correct silly mistake where the MetaWaylandSurface was passed as the
user_data of the surface actor destroy signal handler, instead of the
expected MetaWaylandActorSurface.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/844
This allows us to implement more sophisticated logic for the different
cases. For DnD surfaces, use the geometry scale of the monitor where
the pointer is, instead of incorrectly assuming '1' as it was before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
Flatten the subsurface actor tree, making all surface actors children
of the window actor.
Save the subsurface state in a GNode tree in MetaWaylandSurface, where
each surface holds two nodes, one branch, which can be the tree root
or be attached to a parent surfaces branch, and a leaf, which is
used to save the position relative to child branch nodes.
Each time a surface is added or reordered in the tree, unparent all
surface actors from the window actor, traverse all leaves of the
tree and readd the corresponding surface actors back to the window
actor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/664
Geometry scale is applied to each surface individually, using
Clutter scales, and not only this breaks subsurfaces, it also
pollutes the toolkit and makes the actor tree slightly too
fragile. If GNOME Shell mistakenly tries to set the actor scale
of any of these surfaces, for example, various artifacts might
happen.
Move geometry scale handling to MetaWindowActor. It is applied
as a child transform operation, so that the Clutter-managed
scale properties are left untouched.
In the future where the entirety of the window is managed by a
ClutterContent itself, the geometry scale will be applied
directly into the transform matrix of MetaWindowActor. However,
doing that now would break the various ClutterClones used by
GNOME Shell, so the child transform is an acceptable compromise
during this transition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Now that MetaShapedTexture is a ClutterContent implemetation that
is aware of its own buffer scale, it is possible to simplify the
event translation routines.
Set the geometry scale in MetaSurfaceActor, and stop adjusting the
surface scale when translating points. Also remove the now obsoleted
meta_wayland_actor_surface_calculate_scale() function.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
MetaWindowActor is the compositor-side representative of a
MetaWindow. Specifically it represents the geometry of the
window under Clutter scene graph. MetaWindowActors are backed
by MetaSurfaceActors, that represent the windowing system's
surfaces themselves. Naturally, these surfaces have textures
with the pixel content of the clients associated with them.
These textures are represented by MetaShapedTexture.
MetaShapedTextures are currently implemented as ClutterActor
subclasses that override the paint function to paint the
textures it holds.
Conceptually, however, Clutter has an abstraction layer for
contents of actors: ClutterContent. Which MetaShapedTexture
fits nicely, in fact.
Make MetaShapedTexture a ClutterContent implementation. This
forces a few changes in the stack:
* MetaShapedTexture now handles buffer scale.
* We now paint into ClutterPaintNode instead of the direct
framebuffer.
* Various pieces of Wayland code now use MetaSurfaceActor
instead of MetaShapedTexture.
* MetaSurfaceActorWayland doesn't override size negotiation
vfuncs anymore
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
All child classes of `MetaWaylandShellSurface` as well as
`MetaWaylandSurfaceRoleXWayland` should only sync their actor if
their toplevel surface has a window. Currently this check is done
in the actor-surface class, but not all surface classes have a
toplevel window, e.g. dnd-surfaces.
Move the check to the right places.
For subsurfaces this assumes that the subsurface is not the child of
a window-less surface (like, as stated above, e.g. a dnd-surface).
If we want to support subsurfaces of window-less surfaces in the future
we have to extend the check here.
But as this is not a regression, ignore this case for now.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/537
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
It is based on and very similar in nature to buffer transforms.
From the specification:
> The global interface exposing surface cropping and scaling
> capabilities is used to instantiate an interface extension for a
> wl_surface object. This extended interface will then allow cropping
> and scaling the surface contents, effectively disconnecting the
> direct relationship between the buffer and the surface size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
The central part here is to recalculate the surface size accordingly
and to translate surface damage into buffer damage.
The choosen approach additionally lays groundwork for wp_viewporter
support, which is closely related in its nature.
A further explanation of buffer transforms from the specification:
> The purpose of this request is to allow clients to render content
> according to the output transform, thus permitting the compositor
> to use certain optimizations even if the display is rotated.
> Using hardware overlays and scanning out a client buffer for
> fullscreen surfaces are examples of such optimizations.
When a xdg-toplevel is reset, the window and actor are recreated, and
all state is cleared. When this happened, we earlied out from the
xdg-toplevel commit handler, which would mean that if the client had
queued frame callbacks when resetting, they'd be left in the pending
commit state, later hitting an assert as they were not handled.
Fix this by queuing the frame callbacks no the new actor, so that they
are emitted whenever the actor is eventually painted.
https://gitlab.gnome.org/GNOME/mutter/issues/240
This was done for input regions in commit 718a89eb2f (Thanks Jonas
for the archaeology!) but opaque regions follow the same scaling.
This brings less evident issues as opaque regions are just used for
culling optimizations.
Commit 6a92c6f83 unintendedly broke input/opaque region calculations
on hidpi. Most visible side effect is that clicking is only allowed
in the upper-left quarter of windows.
The surface coordinates are returned in logical unscaled buffer
size. We're however interested in actor coordinates (thus real
pixels) here.
As it is a bit of a detour how the scale to be applied is calculated,
refactor a meta_wayland_actor_surface_get_geometry_scale() function
that we can use it here, and use it consistently for surface size and
the given regions.
As per specification
> The compositor ignores the parts of the input region that
> fall outside of the surface.
> The compositor ignores the parts of the opaque region that
> fall outside of the surface
This fixes culling problems under certain conditions.
And ensure the actor is no longer reactive even though it might live longer
because of close effects, GCs, and whatnot. This ensures the actor is not
eligible for pointer picking within the destruction of its surface.
Closes: #188
