| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This fixes a use-after-free in the Sway patch to filter the Xwayland
shell [1].
The server is destroyed first, then the shell. The Xwayland process
might still be using the shell while running.
When the shell is destroyed, libwayland will invoke the global
filter (to figure out whether to send a wl_registry.global_remove
to clients). Then Sway will compare the client with
wlr_xwayland_server.client. However, at that point, the server is
gone.
Reset the server to NULL so that Sway can check whether the server
is still running.
[1]: https://github.com/swaywm/sway/pull/7647
|
|
86fc2199f85a ("build: unify naming for HAVE_* defines") has
switched over all other feature defines from HAS_* to HAVE_*, but
missed this one.
|
|
|
|
We're about to get one more Xwayland-related thing, and this header
already contains two things.
|
|
|
|
Automatically shutdown Xwayland 10s after all X11 clients have
gone away.
|
|
|
|
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
|
|
If XWayland terminates for any reason, xwm_set_cursor() has to
to be called again, so the cursor has to stick around.
|
|
One of many memory leaks detected by an asan build
|
|
|
|
The xwayland ready signals are used to do initial setup like starting xwm.
Discarding the signals means that the handler functions will not be called
in the case that Xwayland is restarted and thus, xwm managed clients fail.
Fixes #2174."
|
|
|
|
Split the server part of wlr_xwayland into wlr_xwayland_server. This
allows compositors to implement their own XWM when wlroots' isn't a good
fit.
|
|
When running wlroots compositors with Xwayland executable bits
unset, if DISPLAY is set to the display number wlroots has set
up, then X and gtk clients (at least) hang when they are ran.
X clients should fail with an error and exit while gtk clients
should fall back to wayland backend and run correctly. This is
because wlroots opened sockets for Xwayland but wasn't closing
them if Xwayland failed to start.
|
|
The documentation for wayland-server.h says:
> Use of this header file is discouraged. Prefer including
> wayland-server-core.h instead, which does not include the server protocol
> header and as such only defines the library PI, excluding the deprecated API
> below.
Replacing wayland-server.h with wayland-server-core.h allows us to drop the
WL_HIDE_DEPRECATED declaration.
|
|
This avoids leaking the FD to Xwayland and its children.
|
|
Let the compositor set it. This allows for multiple Xwayland instances to run
at the same time.
Fixes https://github.com/swaywm/wlroots/issues/1442
|
|
|
|
SOCK_CLOEXEC isn't POSIX.
|
|
This has been causing troubles for some of our users and only been there
for legacy reasons, we trust Xwayland just as much as your next program
and weston doesn't take any such care when starting it.
|
|
|
|
We don't require it, Xwayland doesn't require it, and all X11 apps I tried
don't need it.
|
|
|
|
Depending on the log verbosity, close the stdout/stderr streams.
|
|
|
|
|
|
Fixes #964
|
|
|
|
|
|
|
|
Makes the xwayland startup process two phased.
The first phase just initialises the X11 sockets.
The second phase starts the Xwayland server itself.
When starting xwayland lazily the second phase will be postponed until
a client has connected to the X11 socket.
Changes in behaviour:
The DISPLAY environment is now set immediately after the X11 sockets
are created.
When the Xwayland server is killed or crashes, the sockets will not be
recreated, but reused.
Fixes #849: Start up Xwayland lazily
|
|
|
|
Some systems don't have xwayland in /usr/bin, but in other paths.
wlroots was unable to find Xwayland binaries outside of standard locations
|
|
|
|
|
|
xwm.h was meant to be private, so move it to include/xwayland/xwm.h
We had an ifdef WLR_HAS_XCB_ICCCM in xwayland.h which was easy to move
to xwm, it is not safe to use the WLR_HAS_* in the public headers.
I checked a few of our current users and none rely on xwm.h being
public as expected (rootston, sway, hsroots)
|
|
This adds `wlr_xwayland_surface_is_unamanged`, to allow compositors more
fine grained control over XWayland focus.
A surface that is unmanaged should not receive focus, while other
windows that are just override redirect may want it (dmenu).
The way unamanged is determined is taken from wlc.
|
|
|
|
|
|
|
|
|
|
|
|
This is more robust than trying to recopy a few fields.
Note: wlr_xwayland->events.ready now resets after each trigger, so one can
hook on it again and be called when restart is ready
|
|
|
|
This is very ugly, there must be a better way to do that (not memset it?)
Meanwhile, this fixes rootston xwayland on restart
|
|
|
|
|
