4d012e17a0
* 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> |
||
|---|---|---|
| .github/workflows | ||
| anvil | ||
| examples | ||
| src | ||
| .gitignore | ||
| .rustfmt.toml | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| Cargo.toml | ||
| LICENSE.txt | ||
| README.md | ||
| build.rs | ||
| doc_index.html | ||
| matrix_badge.svg | ||
README.md
Smithay
A smithy for rusty wayland compositors
Goals
Smithay aims to provide building blocks to create wayland compositors in Rust. While not being a full-blown compositor, it'll provide objects and interfaces implementing common functionalities that pretty much any compositor will need, in a generic fashion.
Also:
- Documented: Smithay strives to maintain a clear and detailed documentation of its API and its functionalities. Compiled documentations are available on docs.rs for released versions, and here for the master branch.
- Safety: Smithay will target to be safe to use, because Rust.
- Modularity: Smithay is not a framework, and will not be constraining. If there is a part you don't want to use, you should not be forced to use it.
- High-level: You should be able to not have to worry about gory low-level stuff (but Smithay won't stop you if you really want to dive into it).
Anvil
Like others, Smithay as a compositor library has its own sample compositor: anvil.
You can run it with cargo after having cloned this repository:
cd anvil;
cargo run -- --{backend}
The currently available backends are:
-
--winit: start anvil as a Winit application. This allows you to run it inside of an other X11 or Wayland session. -
--tty-udev: start anvil in a tty with udev support. This is the "traditional" launch of a Wayland compositor. Note that this requires you to start anvil as root if your system does not have logind available (consolekit support is planned). To use logind, you need to activate the associated cargo feature:cargo run --features logind -- --tty-udev