06c44ede55
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>
|
||
|---|---|---|
| .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