A lot of that is abstracted out od Sway, which aiui is supposed to help alleviate that issue: https://github.com/swaywm/wlroots
In Are We Wayland Yet?swaywm
wlroots
C2017–2024
swaywm / wlroots · Archived
wlroots
A modular Wayland compositor library
35Distinct people
51Mentions
1Explicit recommenders
2.3KGitHub stars
What to know before exploring
What it is
A modular Wayland compositor library
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Games: yes, albiet mostly through Xwayland, which is a compatibility layer. Most games Just Work through this compatibility layer. OBS works fine, but you need a plugin.…
ddevault used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- swaywm/sway · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year51 dated mentions
Observed mentions: 2017-10-19 17:28:42 UTC to 2024-10-15 06:43:18 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
wlroots
⚠️ Migrated to gitlab.freedesktop.org
This project has migrated to gitlab.freedesktop.org.
Pluggable, composable, unopinionated modules for building a Wayland
compositor; or about 60,000 lines of code you were going to write anyway.
wlroots provides backends that abstract the underlying display and input
hardware, including KMS/DRM, libinput, Wayland, X11, and headless backends,
plus any custom backends you choose to write, which can all be created or
destroyed at runtime and used in concert with each other.
wlroots provides unopinionated, mostly standalone implementations of many
Wayland interfaces, both from wayland.xml and various protocol extensions.
We also promote the standardization of portable extensions across
many compositors.
wlroots provides several powerful, standalone, and optional tools that
implement components common to many compositors, such as the arrangement of
outputs in physical space.
wlroots provides an Xwayland abstraction that allows you to have excellent
Xwayland support without worrying about writing your own X11 window manager
on top of writing your compositor.
wlroots provides a renderer abstraction that simple compositors can use to
avoid writing GL code directly, but which steps out of the way when your
needs demand custom rendering code.
wlroots implements a huge variety of Wayland compositor features and implements
them right, so you can focus on the features that make your compositor
unique. By using wlroots, you get high performance, excellent hardware
compatibility, broad support for many wayland interfaces, and comfortable
development tools - or any subset of these features you like, because all of
them work independently of one another and freely compose with anything you want
to implement yourself.
Check out our wiki to get started with wlroots. Join our IRC channel:
#sway-devel on Libera Chat.
wlroots is developed under the direction of the sway project. A variety of
wrapper libraries are available for using it with your favorite programming
language.
Building
Install dependencies:
meson
wayland
wayland-protocols
EGL and GLESv2 (optional, for the GLES2 renderer)
Vulkan loader, headers and glslang (optional, for the Vulkan renderer)
libdrm
GBM
libinput (optional, for the libinput backend)
xkbcommon
udev
pixman
libseat
If you choose to enable X11 support:
xwayland (build-time only, optional at runtime)
libxcb
libxcb-render-util
libxcb-wm
libxcb-errors (optional, for improved error reporting)
Run these commands:
meson build/
ninja -C build/
Install like so:
sudo ninja -C build/ install
Contributing
See CONTRIBUTING.md.
Read the full README on GitHubWhat Hacker News says
11 sourcesIt can't really (other than inside an x11 window maybe), not in its current state. I've heard that someone was working on some Wayland porting efforts, but idk about the state of that.
Looks like OpenBSD has a fairly up to date kms/drm stack now, but you also need:
- to have epoll - https://github.com/jiixyj/epoll-shim might just work
- to expose input devices from the kernel as evdev devices (good idea) or to implement support for your legacy protocol in wlroots / in other places for other compositors (terrible idea)
- to have a device enumeration and hotplug system and either have it pretending it's udev (as we do with https://github.com/FreeBSDDesktop/libudev-devd) or implement support for it in wlroots and everywhere
- direct session glue code at least e.g. https://github.com/swaywm/wlroots/blob/master/backend/sessio...
- but ideally,
Read the rest
a working session manager that supports acquiring drm+evdev devices over d-bus e.g. https://github.com/ConsoleKit2/ConsoleKit2/pull/116 && https://github.com/swaywm/wlroots/pull/1467
I think capturing desktop and screenshots should be addressed by standard Wayland extensions with integration with something like Pipewire as far as I know. I didn't follow the progress of that though.
Some details here: https://wiki.archlinux.org/index.php/PipeWire
Some features though are surely missing. Such as support for adaptive sync. No one really is pushing that forward.
See: https://github.com/swaywm/wlroots/issues/1406
As for Nvidia - don't waste your time on their proprietary drivers on Linux. They don't to play by the rules (refuse to upstream), so no need to spend time supporting their blobs.
In Understanding the working of X11 from the ground up (2017)> That last issue could be solved with a reusable library that provided basic compositor functionality for window managers. Except every member of the Wayland community has independently had that idea and written their own
Actually the opposite is true.
Recently everyone is converging on re-using the same compositor library, written by among others sway’s author: wlroots.
https://github.com/swaywm/wlroots
In The death watch for the X Window System has probably startedWhich NVIDIA graphics card do you own? I’m surprised Sway doesn’t support certain graphics cards.
I believe the goal of wlroots is to solve this problem:
> wlroots provides backends that abstract the underlying display and input hardware
https://github.com/swaywm/wlroots
In The death watch for the X Window System has probably startedYeah, aside from GNOME/KDE trying to do a smooth transition, it's kind of a breaking point for everything. We now have Sway as an i3 successor, for example. There are similar projects for other popular window managers, but from what I understand none of them are in a very usable state the way Sway is. This[0] page can serve as an informal list of all the Wayland compositors succeeding old window managers. Waybox is likely relevant to your interests.
[0] https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
In Debian 10 “Buster” Released> Anybody else have thoughts/plans on the future of X if Wayland really does take over?
I have been thinking about this for a few years at least (happy i3wm user).
I am looking at moving to Sway https://github.com/swaywm/sway (drop in replacement) at some point as it seems the development is really healthy. sircmpwn (Drew DeVault) has done a lot of really nice contribution to the FOSS community, in particular wlroots https://github.com/swaywm/wlroots I also thoroughly enjoy reading his blog https://drewdevault.com (articles from there often get posted here) there has been many a time I've read something he's written and thought "hear hear" in my mind.
It is also impacting my purchasing choices in regard to going for AMDGPU instead of NVIDIA for my next system that I plan to buy in a few months (mostly waiting for 3rd party Navi cards at t
Read the rest
his point).
Do note that the article is mainly about Wayland on the raspberry pi.
Of course Wayland isn't the default most places yet (Fedora being the big exception, I think), though you can install it on most distros.
I've been Wayland/Sway on NixOS for a while, and I really like it.
One question though - the article seems to say that wlroots is a Rust project, but it seems to very much be a pure C project? (https://github.com/swaywm/wlroots)
In Why don't we have Wayland on Raspberry Pi yet? (2018)I think the author is confusing something here
> The reference implementation of the protocol (Weston and it's associated libraries) is written in C. That means you could wrap the C code with Rust, which several people have done already [1] However, I get the impression that the results are not very 'rustic', meaning it's like you are coding C from Rust, instead of writing real Rust code.
> To address the problems of dealing with the existing native Wayland implementations, a couple of the Rust Wayland developers have joined together to build a new Wayland implementation in pure Rust called wlroots [2]
[1] https://github.com/Smithay/wayland-rs
[2] https://github.com/swaywm/wlroots
wlroots is written in C whereas wayland-rs - a Rust implementation of the wayland protocol (client and server) is written in - Rust.
I'm not familiar with eith
Read the rest
er project, but this just stood out immediately when looking at the Github pages.
tinywl is now tracked in the wlroots tree and receiving conservative updates to follow wlroots API changes:
https://github.com/swaywm/wlroots/tree/master/tinywl
Good luck!
In Wayland McWayface (a tutorial compositor) on the JVM using jextract>- Wine is unimplementable in Wayland. By design.
This is a complicated issue which requires a lot of background to explain and answering it in full beyond my patience.
>- Programs cannot set their own hotkeys in Wayland.
This is a feature, not a bug. Why should clients be responsible for dealing with conflicts between programs that use the same hotkey? What if the user wants to pick a different hotkey? Add keylogging concerns on top of that and the argument for this feature becomes pretty weak. Programs designed with Wayland in mind provide some kind of executable that can be bound to a key in the compositor to interact with their daemon.
>- Screenshotting and screen casting tools are unimplementable in Wayland, by design.
This is a lie, or at least a falsehood born from ignorance.
https://github.com/swaywm/wlroots/blob/master/protocol/w
Read the rest
lr-s...
https://github.com/swaywm/wlroots/blob/master/protocol/wlr-e...
>These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation.
A strong majority of Wayland compositors support these protocols, and talks are underway to improve the standardization process.
>- I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop's screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great.
X forwarding still works with Xwayland. Nothing was broken - we have tools for backwards compatability where Wayland is still catching up. Desktops are complicated and it takes a long time and a lot of work to implement them.
But no one is making you switch to Wayland. Keep using Xorg. I doubt you were going to switch anyway, the least you could do is stop spreading FUD.