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>
Just because of implementation details, this is only relevant to Wayland,
and is done via ::effects-completed handlers there. Ideally, Clutter should
notice by itself about effects starting, finishing, and affecting picking.
Doing this in generic code seems slightly cleaner in the interim.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
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
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
For X11 clients running on Wayland, the actual texture is set by
Xwayland.
The shape, input and opaque regions, however are driven by X11
properties meaning that those may come at a different time than the
actual update of the content.
This results in black areas being visible at times on resize with
Xwayland clients.
To make sure we update all the regions at the same time the buffer is
updated, update the shape, input and opaque regions when the texture is
committed from when the Xwayland surface state is synchronized.
That fixes the remaining black areas being sometimes visible when
resizing client-side decorations windows on Xwayland.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1007https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
`meta_xwayland_surface_get_relative_coordinates()` may cause a crash if
the Xwayland surface has no window associated.
That can be observed when using drag and drop from an X11 window to a
Wayland native window:
```
at src/core/window.c:4503
at src/wayland/meta-xwayland-surface.c:200
at src/wayland/meta-wayland-surface.c:1517
at src/wayland/meta-wayland-pointer.c:1048
at src/wayland/meta-wayland-pointer.c:840
at src/wayland/meta-wayland-pointer.c:865
at src/wayland/meta-wayland-pointer.c:954
at src/wayland/meta-wayland-pointer.c:456
at src/wayland/meta-wayland-pointer.c:993
at src/wayland/meta-wayland-data-device.c:1004
at src/wayland/meta-wayland-data-device.c:1278
at src/wayland/meta-xwayland-dnd.c:326
```
Check if the xwayland surface has an associated MetaWindow prior to get
its buffer rect.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1073
There are two surface roles owning a MetaWindow: MetaWaylandShellSurface
(basis of MetaWaylandXdgToplevel, MetaWaylandXdgPopup,
MetaWaylandWlShellSurface, etc), and MetaXwaylandSurface.
With these two role types, the MetaWindow has two different types of
life times. With MetaWaylandShellSurface, the window is owned and
managed by the role itself, while with MetaXwaylandSurface, the
MetaWindow is tied to the X11 window, while the Wayland surface and its
role plays more the role of the backing rendering surface.
Before, for historical reasons, MetaWindow was part of
MetaWaylandSurface, even though just some roles used it, and before
'wayland: Untie MetaWindowXwayland lifetime from the wl_surface' had
equivalent life times as well. But since that commit, the management
changed. To not have the same fied in MetaWaylandSurface being managed
in such drastically different ways, rearrange it so that the roles that
has a MetaWindow themself manages it in the way it is meant to; meaning
MetaWaylandShellSurface practically owns it, while with Xwayland, the
existance of a MetaWindow is tracked via X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
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
