brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
589ec26b04
mutter/src/wayland/meta-wayland-shell-surface.c

347 lines
11 KiB
C
Raw Normal View History

wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
/*
* Copyright (C) 2012,2013 Intel Corporation
* Copyright (C) 2013-2017 Red Hat, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*
*/
#include "config.h"
#include "wayland/meta-wayland-shell-surface.h"
#include "compositor/meta-surface-actor-wayland.h"
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
#include "compositor/meta-window-actor-private.h"
wayland: Move tree updating to the shell surface role The shell surface role is the one where subsurfaces may exist, and it has direct relation to the MetaWindowActorWayland which currently has the subsurface stacking logic. Instead of directly finding the window actor when dealing with subsurfaces, notify the parent surface that the subsurface state changed, so that it can outsource the application of this information to the role. For subsurface roles, this simply means forward upward to the parent; for shell surface roles, this means regenerate the surface actor layering. This allows us to move away from accessing the window directly from the surface, which in turn allows us to change the ownership structure of windows. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-08 21:32:37 +00:00
#include "compositor/meta-window-actor-wayland.h"
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
#include "wayland/meta-wayland-actor-surface.h"
#include "wayland/meta-wayland-buffer.h"
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:28:28 +00:00
#include "wayland/meta-wayland-subsurface.h"
#include "wayland/meta-wayland-surface.h"
#include "wayland/meta-window-wayland.h"
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
typedef struct _MetaWaylandShellSurfacePrivate
{
MetaWindow *window;
gulong unmanaging_handler_id;
} MetaWaylandShellSurfacePrivate;
G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE (MetaWaylandShellSurface,
meta_wayland_shell_surface,
META_TYPE_WAYLAND_ACTOR_SURFACE)
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:28:28 +00:00
void
meta_wayland_shell_surface_calculate_geometry (MetaWaylandShellSurface *shell_surface,
MetaRectangle *out_geometry)
{
MetaWaylandSurfaceRole *surface_role =
META_WAYLAND_SURFACE_ROLE (shell_surface);
MetaWaylandSurface *surface =
meta_wayland_surface_role_get_surface (surface_role);
MetaRectangle geometry;
wayland: Replace manual GNode subsurface iteration with macro 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
2019-12-06 17:22:47 +00:00
MetaWaylandSurface *subsurface_surface;
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:28:28 +00:00
geometry = (MetaRectangle) {
wayland: Use surface size helper functions Use meta_wayland_surface_get_width / meta_wayland_surface_get_width to determine the size of a surface.
2018-06-29 15:53:21 +00:00
.width = meta_wayland_surface_get_width (surface),
.height = meta_wayland_surface_get_height (surface),
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:28:28 +00:00
};
wayland/surface: Use transactions for all sub-surface hierarchy changes 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>
2021-07-23 14:01:37 +00:00
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE (&surface->output_state,
subsurface_surface)
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:28:28 +00:00
{
wayland: Implement subsurface.place_below() for parents 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
2019-06-30 13:18:46 +00:00
MetaWaylandSubsurface *subsurface;
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:28:28 +00:00
wayland: Implement subsurface.place_below() for parents 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
2019-06-30 13:18:46 +00:00
subsurface = META_WAYLAND_SUBSURFACE (subsurface_surface->role);
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:28:28 +00:00
meta_wayland_subsurface_union_geometry (subsurface,
0, 0,
&geometry);
}
*out_geometry = geometry;
}
wayland/xdg-shell: Intersect set geometry with subsurface tree geometry Currently xdg-shell applies a geometry set with set_window_geometry unconditionally. But the specification requires: > When applied, the effective window geometry will be > the set window geometry clamped to the bounding rectangle of the > combined geometry of the surface of the xdg_surface and the > associated subsurfaces. This is especially important to implement viewporter and transformation.
2018-08-18 17:41:15 +00:00
void
meta_wayland_shell_surface_determine_geometry (MetaWaylandShellSurface *shell_surface,
MetaRectangle *set_geometry,
MetaRectangle *out_geometry)
{
MetaRectangle bounding_geometry = { 0 };
MetaRectangle intersected_geometry = { 0 };
meta_wayland_shell_surface_calculate_geometry (shell_surface,
&bounding_geometry);
meta_rectangle_intersect (set_geometry, &bounding_geometry,
&intersected_geometry);
*out_geometry = intersected_geometry;
}
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
static void
clear_window (MetaWaylandShellSurface *shell_surface)
{
MetaWaylandShellSurfacePrivate *priv =
meta_wayland_shell_surface_get_instance_private (shell_surface);
MetaWaylandSurfaceRole *surface_role =
META_WAYLAND_SURFACE_ROLE (shell_surface);
MetaWaylandSurface *surface =
meta_wayland_surface_role_get_surface (surface_role);
MetaSurfaceActor *surface_actor;
if (!priv->window)
return;
g_clear_signal_handler (&priv->unmanaging_handler_id,
priv->window);
priv->window = NULL;
surface_actor = meta_wayland_surface_get_actor (surface);
if (surface_actor)
clutter_actor_set_reactive (CLUTTER_ACTOR (surface_actor), FALSE);
meta_wayland_surface_notify_unmapped (surface);
}
static void
window_unmanaging (MetaWindow *window,
MetaWaylandShellSurface *shell_surface)
{
clear_window (shell_surface);
}
wayland: Use helper to set shell surface window The helper deals with updating the surface output state. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 08:26:24 +00:00
void
meta_wayland_shell_surface_set_window (MetaWaylandShellSurface *shell_surface,
MetaWindow *window)
{
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
MetaWaylandShellSurfacePrivate *priv =
meta_wayland_shell_surface_get_instance_private (shell_surface);
wayland: Use helper to set shell surface window The helper deals with updating the surface output state. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 08:26:24 +00:00
MetaWaylandSurfaceRole *surface_role =
META_WAYLAND_SURFACE_ROLE (shell_surface);
MetaWaylandSurface *surface =
meta_wayland_surface_role_get_surface (surface_role);
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
MetaSurfaceActor *surface_actor;
g_assert (!priv->window);
priv->window = window;
surface_actor = meta_wayland_surface_get_actor (surface);
if (surface_actor)
clutter_actor_set_reactive (CLUTTER_ACTOR (surface_actor), TRUE);
priv->unmanaging_handler_id =
g_signal_connect (window,
"unmanaging",
G_CALLBACK (window_unmanaging),
shell_surface);
wayland: Use helper to set shell surface window The helper deals with updating the surface output state. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 08:26:24 +00:00
window: Pass flag to meta_window_update_monitor() instead of bool The bool determines whether the call was directly from a user operation or not. To add more state into the call without having to add more boolenas, change the boolean to a flag (so far with 'none' and 'user-op' as possible values). No functional changes were made. https://gitlab.gnome.org/GNOME/mutter/issues/192
2018-08-24 10:54:50 +00:00
meta_window_update_monitor (window, META_WINDOW_UPDATE_MONITOR_FLAGS_NONE);
wayland: Use helper to set shell surface window The helper deals with updating the surface output state. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 08:26:24 +00:00
}
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
void
wayland: Rework asynchronous window configuration This changes how asynchronous window configuration works. Prior to this commit, it worked by MetaWindowWayland remembering the last configuration it sent, then when the Wayland client got back to it, it tried to figure out whether it was a acknowledgment of the configuration or not, and finish the move. This failed if the client had acknowledged a configuration older than the last one sent, and it had hacks to somewhat deal with wl_shell's lack of configuration serial numbers. This commits scraps that and makes the MetaWindowWayland take ownership of sent configurations, including generating serial numbers. The wl_shell implementation is changed to emulate serial numbers (assuming each commit acknowledges the last sent configure event). Each configuration sent to the client is kept around until the client one. At this point, the position used for that particular configuration is used when applying the acknowledged state, meaning cases where we have already sent a new configuration when the client acknowledges a previous one, we'll still use the correct position for the window. https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
2019-07-05 16:10:14 +00:00
meta_wayland_shell_surface_configure (MetaWaylandShellSurface *shell_surface,
MetaWaylandWindowConfiguration *configuration)
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
{
MetaWaylandShellSurfaceClass *shell_surface_class =
META_WAYLAND_SHELL_SURFACE_GET_CLASS (shell_surface);
wayland: Rework asynchronous window configuration This changes how asynchronous window configuration works. Prior to this commit, it worked by MetaWindowWayland remembering the last configuration it sent, then when the Wayland client got back to it, it tried to figure out whether it was a acknowledgment of the configuration or not, and finish the move. This failed if the client had acknowledged a configuration older than the last one sent, and it had hacks to somewhat deal with wl_shell's lack of configuration serial numbers. This commits scraps that and makes the MetaWindowWayland take ownership of sent configurations, including generating serial numbers. The wl_shell implementation is changed to emulate serial numbers (assuming each commit acknowledges the last sent configure event). Each configuration sent to the client is kept around until the client one. At this point, the position used for that particular configuration is used when applying the acknowledged state, meaning cases where we have already sent a new configuration when the client acknowledges a previous one, we'll still use the correct position for the window. https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
2019-07-05 16:10:14 +00:00
shell_surface_class->configure (shell_surface, configuration);
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
}
void
meta_wayland_shell_surface_ping (MetaWaylandShellSurface *shell_surface,
uint32_t serial)
{
MetaWaylandShellSurfaceClass *shell_surface_class =
META_WAYLAND_SHELL_SURFACE_GET_CLASS (shell_surface);
shell_surface_class->ping (shell_surface, serial);
}
void
meta_wayland_shell_surface_close (MetaWaylandShellSurface *shell_surface)
{
MetaWaylandShellSurfaceClass *shell_surface_class =
META_WAYLAND_SHELL_SURFACE_GET_CLASS (shell_surface);
shell_surface_class->close (shell_surface);
}
void
meta_wayland_shell_surface_managed (MetaWaylandShellSurface *shell_surface,
MetaWindow *window)
{
MetaWaylandShellSurfaceClass *shell_surface_class =
META_WAYLAND_SHELL_SURFACE_GET_CLASS (shell_surface);
shell_surface_class->managed (shell_surface, window);
}
wayland/surface: Let roles set DND functions The DND functions are role specific, with Xwayland surface being the special one. Let the roles set it instead of having per role like logic in MetaWaylandSurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:53:23 +00:00
static void
meta_wayland_shell_surface_assigned (MetaWaylandSurfaceRole *surface_role)
{
MetaWaylandSurfaceRoleClass *surface_role_class =
META_WAYLAND_SURFACE_ROLE_CLASS (meta_wayland_shell_surface_parent_class);
MetaWaylandSurface *surface =
meta_wayland_surface_role_get_surface (surface_role);
surface->dnd.funcs = meta_wayland_data_device_get_drag_dest_funcs ();
surface_role_class->assigned (surface_role);
}
wayland: Move calc-showing window logic to roles having windows https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:56:34 +00:00
static void
meta_wayland_shell_surface_surface_pre_apply_state (MetaWaylandSurfaceRole *surface_role,
MetaWaylandSurfaceState *pending)
{
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
MetaWaylandShellSurface *shell_surface =
META_WAYLAND_SHELL_SURFACE (surface_role);
MetaWaylandShellSurfacePrivate *priv =
meta_wayland_shell_surface_get_instance_private (shell_surface);
wayland: Move calc-showing window logic to roles having windows https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:56:34 +00:00
MetaWaylandSurface *surface =
meta_wayland_surface_role_get_surface (surface_role);
if (pending->newly_attached &&
wayland/surface: Overhaul handling of buffer use count 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>
2022-06-22 16:43:11 +00:00
!surface->buffer &&
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
priv->window)
meta_window_queue (priv->window, META_QUEUE_CALC_SHOWING);
wayland: Move calc-showing window logic to roles having windows https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:56:34 +00:00
}
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
static MetaWindow *
meta_wayland_shell_surface_get_window (MetaWaylandSurfaceRole *surface_role)
{
MetaWaylandShellSurface *shell_surface =
META_WAYLAND_SHELL_SURFACE (surface_role);
MetaWaylandShellSurfacePrivate *priv =
meta_wayland_shell_surface_get_instance_private (shell_surface);
return priv->window;
}
wayland: Move tree updating to the shell surface role The shell surface role is the one where subsurfaces may exist, and it has direct relation to the MetaWindowActorWayland which currently has the subsurface stacking logic. Instead of directly finding the window actor when dealing with subsurfaces, notify the parent surface that the subsurface state changed, so that it can outsource the application of this information to the role. For subsurface roles, this simply means forward upward to the parent; for shell surface roles, this means regenerate the surface actor layering. This allows us to move away from accessing the window directly from the surface, which in turn allows us to change the ownership structure of windows. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-08 21:32:37 +00:00
static void
meta_wayland_shell_surface_notify_subsurface_state_changed (MetaWaylandSurfaceRole *surface_role)
{
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
MetaWaylandShellSurface *shell_surface =
META_WAYLAND_SHELL_SURFACE (surface_role);
MetaWaylandShellSurfacePrivate *priv =
meta_wayland_shell_surface_get_instance_private (shell_surface);
wayland: Move tree updating to the shell surface role The shell surface role is the one where subsurfaces may exist, and it has direct relation to the MetaWindowActorWayland which currently has the subsurface stacking logic. Instead of directly finding the window actor when dealing with subsurfaces, notify the parent surface that the subsurface state changed, so that it can outsource the application of this information to the role. For subsurface roles, this simply means forward upward to the parent; for shell surface roles, this means regenerate the surface actor layering. This allows us to move away from accessing the window directly from the surface, which in turn allows us to change the ownership structure of windows. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-08 21:32:37 +00:00
MetaWindow *window;
MetaWindowActor *window_actor;
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
window = priv->window;
wayland: Move tree updating to the shell surface role The shell surface role is the one where subsurfaces may exist, and it has direct relation to the MetaWindowActorWayland which currently has the subsurface stacking logic. Instead of directly finding the window actor when dealing with subsurfaces, notify the parent surface that the subsurface state changed, so that it can outsource the application of this information to the role. For subsurface roles, this simply means forward upward to the parent; for shell surface roles, this means regenerate the surface actor layering. This allows us to move away from accessing the window directly from the surface, which in turn allows us to change the ownership structure of windows. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-08 21:32:37 +00:00
if (!window)
return;
window_actor = meta_window_actor_from_window (window);
meta_window_actor_wayland_rebuild_surface_tree (window_actor);
}
wayland/surface-role: Make geometry scale API return int Geometry scale are always ints, callers always assumed they were ints, but they were doubles. Make them ints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
2022-06-12 12:06:10 +00:00
static int
wayland/actor-surface: Turn get_geometry_scale() into a vfunc 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
2019-09-06 13:13:24 +00:00
meta_wayland_shell_surface_get_geometry_scale (MetaWaylandActorSurface *actor_surface)
{
MetaWaylandSurfaceRole *surface_role =
META_WAYLAND_SURFACE_ROLE (actor_surface);
MetaWaylandSurface *surface =
meta_wayland_surface_role_get_surface (surface_role);
backend: Get 'is-stage-views-scaled' from backend It did, but used the old backend singleton. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
2022-05-27 18:30:37 +00:00
MetaContext *context =
meta_wayland_compositor_get_context (surface->compositor);
MetaBackend *backend = meta_context_get_backend (context);
wayland/actor-surface: Turn get_geometry_scale() into a vfunc 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
2019-09-06 13:13:24 +00:00
MetaWindow *toplevel_window;
toplevel_window = meta_wayland_surface_get_toplevel_window (surface);
backend: Get 'is-stage-views-scaled' from backend It did, but used the old backend singleton. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
2022-05-27 18:30:37 +00:00
if (meta_backend_is_stage_views_scaled (backend) ||
!toplevel_window)
wayland/actor-surface: Turn get_geometry_scale() into a vfunc 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
2019-09-06 13:13:24 +00:00
return 1;
else
return meta_window_wayland_get_geometry_scale (toplevel_window);
}
wayland: Move check for present window out of the actor-surface class 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
2019-04-16 21:35:28 +00:00
static void
meta_wayland_shell_surface_sync_actor_state (MetaWaylandActorSurface *actor_surface)
{
MetaWaylandSurfaceRole *surface_role =
META_WAYLAND_SURFACE_ROLE (actor_surface);
MetaWaylandSurface *surface =
meta_wayland_surface_role_get_surface (surface_role);
MetaWaylandActorSurfaceClass *actor_surface_class =
META_WAYLAND_ACTOR_SURFACE_CLASS (meta_wayland_shell_surface_parent_class);
wayland: Don't access MetaWaylandSurface::window directly It'll be moved to the role owning it, accessed via a helper function implemented by the role. Currently it still just fetches the field in MetaWaylandSurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:37:04 +00:00
MetaWindow *toplevel_window;
toplevel_window = meta_wayland_surface_get_toplevel_window (surface);
if (!toplevel_window)
return;
wayland: Move check for present window out of the actor-surface class 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
2019-04-16 21:35:28 +00:00
wayland: Don't access MetaWaylandSurface::window directly It'll be moved to the role owning it, accessed via a helper function implemented by the role. Currently it still just fetches the field in MetaWaylandSurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:37:04 +00:00
actor_surface_class->sync_actor_state (actor_surface);
wayland: Move check for present window out of the actor-surface class 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
2019-04-16 21:35:28 +00:00
}
wayland: Untie MetaWindowXwayland lifetime from the wl_surface For the most part, a MetaWindow is expected to live roughly as long as the associated wl_surface, give or take asynchronous API discrepancies. The exception to this rule is handling of reparenting when decorating or undecorating a window, when a MetaWindow on X11 is made to survive the unmap/map cycle. The fact that this didn't hold on Wayland caused various issues, such as a feedback loop where the X11 window kept being remapped. By making the MetaWindow lifetime for Xwayland windows being the same as they are on plain X11, we remove the different semantics here, which seem to lower the risk of hitting the race condition causing the feedback loop mentioned above. What this commit do is separate MetaWindow lifetime handling between native Wayland windows and Xwayland windows. Wayland windows are handled just as they were, i.e. unmanaged together as part of the wl_surface destruction; while during the Xwayland wl_surface destruction, the MetaWindow <-> MetaWaylandSurface association is simply broken. Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740 Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762 https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
2019-09-04 16:35:08 +00:00
void
meta_wayland_shell_surface_destroy_window (MetaWaylandShellSurface *shell_surface)
{
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
MetaWaylandShellSurfacePrivate *priv =
meta_wayland_shell_surface_get_instance_private (shell_surface);
wayland: Untie MetaWindowXwayland lifetime from the wl_surface For the most part, a MetaWindow is expected to live roughly as long as the associated wl_surface, give or take asynchronous API discrepancies. The exception to this rule is handling of reparenting when decorating or undecorating a window, when a MetaWindow on X11 is made to survive the unmap/map cycle. The fact that this didn't hold on Wayland caused various issues, such as a feedback loop where the X11 window kept being remapped. By making the MetaWindow lifetime for Xwayland windows being the same as they are on plain X11, we remove the different semantics here, which seem to lower the risk of hitting the race condition causing the feedback loop mentioned above. What this commit do is separate MetaWindow lifetime handling between native Wayland windows and Xwayland windows. Wayland windows are handled just as they were, i.e. unmanaged together as part of the wl_surface destruction; while during the Xwayland wl_surface destruction, the MetaWindow <-> MetaWaylandSurface association is simply broken. Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740 Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762 https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
2019-09-04 16:35:08 +00:00
MetaWindow *window;
MetaDisplay *display;
uint32_t timestamp;
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
window = priv->window;
wayland: Untie MetaWindowXwayland lifetime from the wl_surface For the most part, a MetaWindow is expected to live roughly as long as the associated wl_surface, give or take asynchronous API discrepancies. The exception to this rule is handling of reparenting when decorating or undecorating a window, when a MetaWindow on X11 is made to survive the unmap/map cycle. The fact that this didn't hold on Wayland caused various issues, such as a feedback loop where the X11 window kept being remapped. By making the MetaWindow lifetime for Xwayland windows being the same as they are on plain X11, we remove the different semantics here, which seem to lower the risk of hitting the race condition causing the feedback loop mentioned above. What this commit do is separate MetaWindow lifetime handling between native Wayland windows and Xwayland windows. Wayland windows are handled just as they were, i.e. unmanaged together as part of the wl_surface destruction; while during the Xwayland wl_surface destruction, the MetaWindow <-> MetaWaylandSurface association is simply broken. Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740 Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762 https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
2019-09-04 16:35:08 +00:00
if (!window)
return;
display = meta_window_get_display (window);
timestamp = meta_display_get_current_time_roundtrip (display);
wayland: Don't access MetaWaylandSurface::window directly It'll be moved to the role owning it, accessed via a helper function implemented by the role. Currently it still just fetches the field in MetaWaylandSurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:37:04 +00:00
meta_window_unmanage (window, timestamp);
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
g_assert (!priv->window);
wayland: Untie MetaWindowXwayland lifetime from the wl_surface For the most part, a MetaWindow is expected to live roughly as long as the associated wl_surface, give or take asynchronous API discrepancies. The exception to this rule is handling of reparenting when decorating or undecorating a window, when a MetaWindow on X11 is made to survive the unmap/map cycle. The fact that this didn't hold on Wayland caused various issues, such as a feedback loop where the X11 window kept being remapped. By making the MetaWindow lifetime for Xwayland windows being the same as they are on plain X11, we remove the different semantics here, which seem to lower the risk of hitting the race condition causing the feedback loop mentioned above. What this commit do is separate MetaWindow lifetime handling between native Wayland windows and Xwayland windows. Wayland windows are handled just as they were, i.e. unmanaged together as part of the wl_surface destruction; while during the Xwayland wl_surface destruction, the MetaWindow <-> MetaWaylandSurface association is simply broken. Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740 Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762 https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
2019-09-04 16:35:08 +00:00
}
static void
meta_wayland_shell_surface_finalize (GObject *object)
{
MetaWaylandShellSurface *shell_surface = META_WAYLAND_SHELL_SURFACE (object);
meta_wayland_shell_surface_destroy_window (shell_surface);
G_OBJECT_CLASS (meta_wayland_shell_surface_parent_class)->finalize (object);
}
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
static void
meta_wayland_shell_surface_init (MetaWaylandShellSurface *role)
{
}
static void
meta_wayland_shell_surface_class_init (MetaWaylandShellSurfaceClass *klass)
{
wayland: Untie MetaWindowXwayland lifetime from the wl_surface For the most part, a MetaWindow is expected to live roughly as long as the associated wl_surface, give or take asynchronous API discrepancies. The exception to this rule is handling of reparenting when decorating or undecorating a window, when a MetaWindow on X11 is made to survive the unmap/map cycle. The fact that this didn't hold on Wayland caused various issues, such as a feedback loop where the X11 window kept being remapped. By making the MetaWindow lifetime for Xwayland windows being the same as they are on plain X11, we remove the different semantics here, which seem to lower the risk of hitting the race condition causing the feedback loop mentioned above. What this commit do is separate MetaWindow lifetime handling between native Wayland windows and Xwayland windows. Wayland windows are handled just as they were, i.e. unmanaged together as part of the wl_surface destruction; while during the Xwayland wl_surface destruction, the MetaWindow <-> MetaWaylandSurface association is simply broken. Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740 Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762 https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
2019-09-04 16:35:08 +00:00
GObjectClass *object_class = G_OBJECT_CLASS (klass);
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
MetaWaylandSurfaceRoleClass *surface_role_class =
META_WAYLAND_SURFACE_ROLE_CLASS (klass);
wayland: Move check for present window out of the actor-surface class 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
2019-04-16 21:35:28 +00:00
MetaWaylandActorSurfaceClass *actor_surface_class =
META_WAYLAND_ACTOR_SURFACE_CLASS (klass);
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
wayland: Untie MetaWindowXwayland lifetime from the wl_surface For the most part, a MetaWindow is expected to live roughly as long as the associated wl_surface, give or take asynchronous API discrepancies. The exception to this rule is handling of reparenting when decorating or undecorating a window, when a MetaWindow on X11 is made to survive the unmap/map cycle. The fact that this didn't hold on Wayland caused various issues, such as a feedback loop where the X11 window kept being remapped. By making the MetaWindow lifetime for Xwayland windows being the same as they are on plain X11, we remove the different semantics here, which seem to lower the risk of hitting the race condition causing the feedback loop mentioned above. What this commit do is separate MetaWindow lifetime handling between native Wayland windows and Xwayland windows. Wayland windows are handled just as they were, i.e. unmanaged together as part of the wl_surface destruction; while during the Xwayland wl_surface destruction, the MetaWindow <-> MetaWaylandSurface association is simply broken. Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740 Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762 https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
2019-09-04 16:35:08 +00:00
object_class->finalize = meta_wayland_shell_surface_finalize;
wayland/surface: Let roles set DND functions The DND functions are role specific, with Xwayland surface being the special one. Let the roles set it instead of having per role like logic in MetaWaylandSurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:53:23 +00:00
surface_role_class->assigned = meta_wayland_shell_surface_assigned;
wayland: Move calc-showing window logic to roles having windows https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-09 07:56:34 +00:00
surface_role_class->pre_apply_state =
meta_wayland_shell_surface_surface_pre_apply_state;
wayland: Move tree updating to the shell surface role The shell surface role is the one where subsurfaces may exist, and it has direct relation to the MetaWindowActorWayland which currently has the subsurface stacking logic. Instead of directly finding the window actor when dealing with subsurfaces, notify the parent surface that the subsurface state changed, so that it can outsource the application of this information to the role. For subsurface roles, this simply means forward upward to the parent; for shell surface roles, this means regenerate the surface actor layering. This allows us to move away from accessing the window directly from the surface, which in turn allows us to change the ownership structure of windows. https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
2019-10-08 21:32:37 +00:00
surface_role_class->notify_subsurface_state_changed =
meta_wayland_shell_surface_notify_subsurface_state_changed;
wayland: Move MetaWindow ownership to window owning roles 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
2019-10-09 07:57:40 +00:00
surface_role_class->get_window = meta_wayland_shell_surface_get_window;
wayland/actor-surface: Turn get_geometry_scale() into a vfunc 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
2019-09-06 13:13:24 +00:00
actor_surface_class->get_geometry_scale =
meta_wayland_shell_surface_get_geometry_scale;
wayland: Move check for present window out of the actor-surface class 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
2019-04-16 21:35:28 +00:00
actor_surface_class->sync_actor_state =
meta_wayland_shell_surface_sync_actor_state;
wayland: Restructure surface role building blocks code This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-20 09:40:22 +00:00
}
Reference in New Issue Copy Permalink