| Age | Commit message (Collapse) | Author |
|---|
|
This allows users to setup event listeners before the server is
actually started.
|
|
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.
|
|
|
|
|
|
This allows users to specify a delay after which the Xwayland process
terminates itself when there are no more X11 clients connected.
|
|
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
|
|
|
|
This allows compositors to handle touch pointer emulation manually,
instead of having Xwayland do it [1].
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/691
|
|
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.
|
|
Remove fill_arg and replace it with stack-allocations and simple
array-filling.
|
|
Logging the raw Xwayland command-line was incomplete, uninformative
and confusing for end-users. Instead, print a proper message in
English.
|
|
eec2e1d3b16ba40c85483badcc7809277274ce5d 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.
|
|
Xwayland's -listen option was deprecated in [1] in favor of -listenfd.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/593
|
|
Instead of walking PATH like a previous proposal [1], this one
checks that the Xwayland path specified in the pkg-config file
exists.
I think this is a reasonable compromise:
- Users that don't have Xwayland installed system-wide won't get
a bogus DISPLAY env variable set up.
- Users that have WLR_XWAYLAND set won't be affected by this check.
- Users that have Xwayland installed system-wide and a different
Xwayland in their PATH still get their custom Xwayland.
- Users that don't have Xwayland installed system-wide but have it
somewhere else in PATH are left out. But this is pretty niche,
and they can just set WLR_XWAYLAND.
[1]: https://github.com/swaywm/wlroots/pull/2314
|
|
This function may end up being called more than once if the Xwayland
binary does not exist on the system.
|
|
Closes: https://github.com/swaywm/wlroots/issues/2154
|
|
Xwayland has its own special handling for signals like SIGSEGV/SIGABRT.
Instead of leaving the job to the OS, it tries to walk up the call stack
(badly, because a lot of information is missing), print the stack trace
to stdout, then exit(1). This is very annoying because it prevents
Xwayland crashes from being easily debugged.
Xwayland has a flag "-core" that aborts instead of exiting. This allows
the OS to generate a coredump. It's far from perfect but better than
nothing, I guess.
|
|
This accidentally slipped through 1b0e4c7.
|
|
When debugging Xwayland-related issues, a common first step in debugging
has been to ask the reporter to move their real Xwayland to
/usr/bin/Xwayland.bin, and create a shell script starting Xwayland with
extra arguments under the original /usr/bin/Xwayland location.
Introducing a `WLR_XWAYLAND` environment variable makes this less
invasive, by allowing the user to swap out Xwayland without resorting to
global system changes (or source patches).
|
|
|
|
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."
|
|
This prevents a very unlikely crash in `xwayland_socket_connected`.
Refs #2163.
|
|
|
|
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.
|
