If a window is unmapped too quickly, we might receive UnmapNotify before
we get the corresponding wl_surface, which will later lead to
associating the same window twice. To fix this, move the NULL surface
check to xwayland_surface_dissociate(), which makes resetting the
unpaired link and the wl_surface object ID unconditional.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3552
The dep allows us to check dep variables to discover supported
features. With the binary we assume none of the features are
supported. If a user forgets to install the pkg-config file (e.g.
because it's in a split package) we end up incorrectly disabling
all features. Instead let's error out.
Rename xwm_map_shell_surface() to xwayland_surface_associate().
This function doesn't actually "map" the surface in Wayland
parlance, the wl_surface may not have a buffer attached yet.
This can be used to know when wlr_xwayland_server decides to start
a new Xwayland process. At that point the wl_client has already
been created but the Xwayland process hasn't been started yet.
Always keep it initialized, so that we don't have to check for
xsurface->surface_id.
Will help with WL_SURFACE_SERIAL support, which adds a new way for
a surface to be unpaired.
This allows whatever the user calls from the signal handlers to react to observe
the new state rather than the old, e.g. that a surface is no longer mapped in
the unmap handler.
The original commit introduced a bug by transposing the order of
some of the fields in xcb_size_hints_t. Since XCB ICCCM support is
required now, we can just eliminate the duplicate structs.
With minor changes:
- Remove #ifdef HAS_XCB_ICCCM guards
- Fix #includes
- Fix references to local size_hints struct
This reverts commit 12b9b1a4bd.
Using Xwayland -displayfd means we don't need to worry about handling
SIGUSR1 to second guess when Xwayland is ready and write to the pipe:
just let it do that write when it would be sending SIGUSR1 otherwise.
Closes: #3356
A launchee notifies with a "remove"¹ message when done starting up.
Catch these and forward to the compositor. This allows the compositor to
end the startup sequence that might have been started by another
protocol like xdg-activation.
We don't handle other messages since we expect the launcher to use a
wayland protocol like xdg-activation.
While `_NET_STARTUP_ID` helps to associate toplevels with startup-ids
this signals the end of the startup sequence.
1) https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
Currently, upon activating a surface, wlroots restacks it on top of all
others.
This may not necessarily be correct from the calling compositor's point
of view, where having focus may not imply being top-of-stack (e.g.,
focusing a window under an always-on-top window).
In Sway's case, this means that focused tiling windows will always be on
top of floating windows, at least in the order communicated to X11 apps.
This breaks drag-and-drop from a focused tiling X11 window to a floating
X11 window which partially obscures the former.
This is a breaking change; to retain the previous behavior, users that
were calling
wlr_xwayland_surface_activate(xsurface, true);
should now be calling
wlr_xwayland_surface_activate(xsurface, true);
wlr_xwayland_surface_restack(xsurface, NULL, XCB_STACK_MODE_ABOVE);
As more options are added, more fields will be duplicated. Let's
just embed the struct in wlr_xwayland_server so that we don't need
to keep both in sync.
This property is present on all modern X11 instances. The nonpresence of
it requires applications to fall back to XQueryTree-based logic to
determine stacking logic (e.g., to determine what surface should get
Xdnd events).
These code paths are effectively untested nowadays, so this makes it
more likely for wlroots to "break" applications. For instance, the
XQueryTree fallback path has been broken in Chromium for the last 10
years.
It's easy enough to maintain this property, so let's just do it.
Fixes#2889.
eec2e1d3b1 introduced logic to use the Xwayland
binary discovered via pkg-config.
While the newly introduced checks correctly used the binary from pkg-config,
the actual execution still used the previous PATH-search logic.
`_NET_WM_PID` is unreliable: it is optional and even if set it may
contain PIDs from sandbox namespaces or remote systems.
Prefer XRes v1.2 QueryClientIds method which returns PIDs as seen by the
Xwayland server.
