* xwayland: Add LaunchHelper
Calling fork() in a multi-threaded process is a bad idea. I am getting
crashes at exit() and "man fork" says that only async-signal-safe
functions can be called after forking in a multi-threaded process.
exit() is not async-signal safe. Thus, forking needs to happen before
any threads are created.
This commit adds a LaunchHelper to the public API. This is a handle to a
forked child process. So far this does not do much, but the intention is
to use this later instead of fork()ing directly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* xwayland: Move the fork dance to LaunchHelper
No functional changes intended. This only moves the code over and does
not actually use the LaunchHelper for anything.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Move checking the launch status to LaunchHelper
This should again have no functional changes, but the error log output
might change slightly, since an IOError instead of a NixError is
returned.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* xwayland: Set $DISPLAY earlier
This way, the WM already gets the correct value of $DISPLAY.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* xwayland: Use the launch helper process
FD passing is now used to give the display number and the sockets to the
launch helper process. That process then forks of the actual process
that spawns Xwayland. Once Xwayland started, this is reported back with
another write on the pipe.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Add to the comment explaining Xwayland startup
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Please rustfmt
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Make clippy happy
Signed-off-by: Uli Schlachter <psychon@znc.in>
When starting xwayland with smithay, the first time I would get the
following output (do not ask what happens with displays 0, 1, 2. That's
not important right now):
Dec 29 14:13:31.031 DEBG Attempting to aquire an X11 display lock, D: 3, smithay_module: XWayland
Dec 29 14:13:31.032 DEBG X11 lock aquired, D: 3, smithay_module: XWayland
Dec 29 14:13:31.032 INFO Initialization completed, starting the main loop.
When killing the process with ctrl-c and starting it again, this
happened:
Dec 29 14:13:29.138 DEBG Attempting to aquire an X11 display lock, D: 3, smithay_module: XWayland
Dec 29 14:13:29.138 DEBG Failed to acquire lock, D: 3, smithay_module: XWayland
Dec 29 14:13:29.138 DEBG Lock was blocked by a defunct X11 server, trying again, D: 3, smithay_module: XWayland
Dec 29 14:13:29.139 DEBG Attempting to aquire an X11 display lock, D: 3, smithay_module: XWayland
Dec 29 14:13:29.139 DEBG X11 lock aquired, D: 3, smithay_module: XWayland
Dec 29 14:13:29.139 INFO Cleaning up X11 lock., smithay_module: XWayland
Dec 29 14:13:29.139 DEBG Attempting to aquire an X11 display lock, D: 4, smithay_module: XWayland
Dec 29 14:13:29.139 DEBG X11 lock aquired, D: 4, smithay_module: XWayland
Dec 29 14:13:29.139 INFO Initialization completed, starting the main loop.
The reason for the above behaviour is the
smithay::xwayland::x11_sockets::open_x11_sockets_for_display() failed.
The code successfully acquired the lock file, but then could not bind
the sockets. More specifically, the concrete socket in /tmp/.X11-unix/
already existed and thus bind() failed with EADDRINUSE.
(The code in X11Lock::grab() would then drop the already acquired
X11Lock and its Drop impl deleted the socket. Thus, when I started
things again, this time it successfully acquired display 3.)
Fix this removing the socket before trying to bind it.
This is also done by wlroots: In xwayland/sockets.x, the function
open_socket() has the same job as smithay's open_socket() function.
However, for non-abstract sockets, it would first unlink the target
before trying to bind:
if (addr->sun_path[0]) {
unlink(addr->sun_path);
}
Signed-off-by: Uli Schlachter <psychon@znc.in>
Here is a lock file not created by smithay:
$ xxd /tmp/.X0-lock
00000000: 2020 2020 2020 2035 3537 0a 557.
And this is a lock file created by smithay:
$ xxd /tmp/.X23-lock
00000000: 2020 2020 3130 3733 3332 107332
As you see, the difference is a trailing newline (0x0a).
Lock files 1 to 22 where also created by smithay, because I started it a
couple of times. Reading these lock files fails, since the code expects
a file with at least 11 bytes of content: It uses read_exact() with a
buffer of length 11 in the Err()-branch of the match that this commit
modifies.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Handling SIGUSR1 requires setting a signal handler, which is a global
resource. This can also cause problems in the presence of threads, since
every thread needs to set up a signal handler. This commit instead
changes the code to use a pipe instead (actually a UnixStream). When the
child closes the pipe, the parent wakes up and knows "to do something".
Fixes: https://github.com/Smithay/smithay/issues/246
Signed-off-by: Uli Schlachter <psychon@znc.in>
slog-stdlog has a significant dependency tree and is basically unsued if
the downstream crate of Smithay always provides a logger (like anvil),
so it is not really needed.
* Rename priviledged to privileged in backend/drm/mod.rs
* Fix a number of typos in comments
* Fix typos in string literals
* Wrap identifiers with backticks in doc comments
* Spelling and capitalisation in doc comments
* Use XWayland in comments
This seems to be the standard capitalisation, even though the executable
is called `Xwayland`.
* Use Glium instead of glium in comments
* Use DRM and API in comments
* Fix remaining occurrence of 'priviledged'
* Reformat code to appease Travis' rustfmt
Gary Guo
Uli Schlachter
Uli Schlachter
Eric Anholt
Victor Berger
Victor Berger
Jonas Platte
Victor Brekenfeld
Colin Benner
Jonas Platte
Colin Benner