| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
