Even then, "tinywl" which aims to be a "minimum viable product" Wayland compositor based on wlroots is almost 1k lines:
https://github.com/swaywm/wlroots/tree/master/tinywl
In Show HN: X11 tool to share a screen area in any video meetingswaywm
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 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
51 sourcesTinyWM for wlroots is also less than 1,000 LoC. ( https://github.com/swaywm/wlroots/blob/master/tinywl/tinywl.... )
> I can restart my wm without exiting my X session
Sway also has a "reload" feature that preserves all open applications.
In RubyWM – an X11 window manager in pure RubyAh yes, sway, the one of the waylands that refuses to add support for complex mouse/keyboard and alternate input devices. https://github.com/swaywm/wlroots/issues/2378 . You've been running a wayland, not wayland, because there is no "wayland": only many different waylands.
In Wayland vs. X – Overview>barrier has been unmaintained for a long time.
As if not having new features added for 2 years makes it stop working? barrier is perfectly fine on normal linux desktop installs. I actually use synergy 1.x personally which has been "unmaintained" for much, much longer. Except synergy 1.x will compile and run on anything from windows 98 to ubuntu 10.04 to latest arch. You can't get a waynergy or inputleap to compile on an OS more than 3 years old. And even then, as you say, it's crapshoot if the particular wayland you use will have libei; many like sway are actively hostile to it and never will: https://github.com/swaywm/wlroots/issues/2378
In Xorg being removed. What does this mean?I think these worries are unfounded atm, because compatibility is good for most applications, even though there are some tools specific to a compositor (e.g. waypipe for wlroots based compositors).
For the case of minimal window managers, there is wlroots, which is designed to be used to write a compositor. The first line of the wlroots repo[1] states: »Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.«
And there are at least three[2] actively maintained compositors based on wlroots. Sway being the most popular, the one for which wlroots was initially developed for.
I believe that there won't be too many incompatibilities, because there are 3 (4, including weston) wayland compositors developed (Gnome's, KDE's & wlroots based), all three of them hav
Read the rest
ing their own use cases. Using protocol extensions only useable on one compositor would limit the app to a subset of Linux Desktops (and mobile), so if possible, most apps won't use them.
PS: I just remembered one case of fragmentation: Activity Watch, a tool to keep track which apps are used how long and to track idle times, won't be able to support Gnome (mutter), because Gnome dev's won't implement the necessary freedesktop protocol extension. Sway (and KDE?) does, so it works on them. One solution would be to write a Gnome Shell extension, but yeah, it's not as easy as on X.org (reason being privacy, in this case).
[1] https://github.com/swaywm/wlroots
[2] https://arewewaylandyet.com/
waymonad has a somewhat more active fork here: https://github.com/L-as/waymonad, but it's still just a one-man show that got picked up at ZuriHac 2021 and then failed to gather sufficient momentum.
As a maintainer of xmonad upstream, I'm watching the waymonad project to see where it goes, but I have some concerns about its architecture which I'd love to see addressed before we'd officially endorse people to try switching. This is a copy of a message I sent to fellow xmonad developers a couple months ago:
> We should certainly take a look sooner or later. From a quick glance, I have some concerns about the general design of it:
> It's a compositor and window-manager in one. This is typical for Wayland, but there are lots of disadvantages:
> * Restarting the WM is just like restarting X: session over. Unacceptable for xmonad/waymonad, as we
Read the rest
don't reload config, we recompile and restart. Someone is apparently working on making Wayland compositors restartable, in general: https://indico.freedesktop.org/event/1/contributions/20/, though.
> * Another consequence of the WM and compositor being one is that they share memory leaks and GC pauses and signal handlers and whatnot. As much as I love Haskell, I'd prefer frames from an FPS shooter to be presented on screen by something else. Oh and did I mention the compositor/WM also handles input, making any GC pauses doubly painful?
> * Aside from operational issues, this also means all of that needs to be implemented. There's https://github.com/swaywm/wlroots/ (used by waymonad), a library that supposedly lets individual Wayland compositors implement less code, but it doesn't seem to be nowhere near what X gives us: we take care of window management and all the input/output handling is taken care of by other tools with their own configuration and tools. It simply doesn't seem to work that way in the Wayland world. There are other options like implementing a shell plugin for Weston, or possibly other libraries, I don't really understand the landscape.
> I may be wrong on some of these, as I didn't actually try to compile and run the thing.
> Anyway, I am convinced it'd be best if the compositor and WM were separate processes, ideally maintained by separate teams. You know, that old “do one thing and do it well” philosophy. And I have no idea how difficult would it be to make things work this way. If someone were to work on this, discovering the answer to this question would be one the first things to do.
I should probably clarify the wlroots handling IO thing: what I meant is that with Xorg, there are command-line tools like setxkbmap, xinput, xset, xmodmap, xcape, xrandr, autorandr and possibly others that a user can use to interact with the X server and tweak stuff, and from what I understand these don't have equivalents in the Wayland world that would work across WMs/compositors. I could be wrong, though, perhaps wlroots does have a standard protocol for such things and such tools already exist?
If last time you tried using Wayland was Sway, maybe this is the issue you were running into: https://github.com/swaywm/wlroots/issues/2889
TL;DR: Drag and drop involving chromium or electron windows has been buggy. wlroots/sway has not implemented _NET_CLIENT_LIST_STACKING, and both the fallback code inside Chrome/Chromium and the way sway has been stacking Xwayland windows have been buggy. A patch has been submitted to Chromium to fix the faulty fallback, the sway bug will be fixed, and wlroots will also support _NET_CLIENT_LIST_STACKING, so by the time the next sway release comes out everything should be ironed out.
In Use Alacritty instead of TermiteThere are more traditional window manager type compositor, you might be able to find something more to your tastes in this list...
https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
As a happy Openbox user, I'm planning on trying Waybox first I think. Waiting for the next Debian release though.
In HW accelerated Xwayland rendering for Nvidia mergedThis is one of the sort-of-frustrating as-a-user things about Wayland to me, that every compositor (nee window manager) has to implement capabilities like this for themselves, where-as in X, there was common tooling. And they'll all have different userland tools to use these capabilities.
here[1] for example is wlroots/sway implementing headless.
That said, the implementations are great, & really show how much Linux has progressed. For a while it wasn't possible (for some reason I wasn't having good luck with either mdi or dp dummy plugs on my type-c only laptop), but I'm really looking forward to using one laptop as a virtual desktop for another desktop, & this work is core to that effort. I like a lot that Gnome was super smart & made outputting a virtual monitor as a PipeWire stream built in!! Smart easy win to make screen capturing ev
Read the rest
en easier.
Edit: at my posting rate-limit, so tacking this on, especially to @spivak,
I like the diversity a lot, yes. But I still would like to see a situation other than gnome having it's own tooling to configure virtual monitors, wlroots having it's own, kde having it's own.
Is this just an insufficienct protocolization problem right now? Are there wayland protocols to do things like change a monitor's resolution? Or to change the mouse speed? I think of Wayland protocols as more between a running app and the compositor, which has all been nicely modularized & protocolized. But I don't understand what if any effort has been made to find a common ground to expose user tooling. It feels like they all have their own suite of command line utilities. Swaymsg in sway, for example. Whatever this virtual monitor tool gnome has. How do we begin to modularize these control interfaces?
[1] https://github.com/swaywm/wlroots/commits/master/backend/hea...
> This is not hacky or has higher power draw - the display has a minimum refresh rate, and sudden large changes in refresh rate can lead to visible flickering.
I get that[1]. It's a shame we can't specify next frame latency as well, it should be fairly predictable for video (or enable triple-buffering on the monitor side).
> It is negligible. Your GPU will do nothing most frames, and the panel power consumption comes from backlight.
I was basing this on a recent patchset with the following quote[2]:
> Enabling this feature also have the potential side effect of causing higher power consumption due to running a mode with lower resolution and base clock frequency with the highest base clock supported on the monitor as per its advertised modes
[1]: https://github.com/swaywm/wlroots/issues/1406#issuecomment-4...
[2]: https://www.phoronix.com/
Read the rest
This was a sway thing more than a Wayland thing and a PR for it was made back in March https://github.com/swaywm/wlroots/pull/2064 Edit: but not merged yet :/
Also it's (ironically) an X11 related issue which shows up do to XWayland backwards compatibility, not something new with Wayland.
Chrome also since supports Wayland natively so the workaround in that PR isn't even needed for it anymore. Electron is still a bit behind but it's looking like Electron 12 should have native Wayland support as well, until then the workaround for X11 app scaling is there.
There are still a few things I'd like to see land (which are closing in) before saying Wayland is a better fit for most users but better DPI scaling certainly isn't one, it was one of the first wins to land to be honest.
.
Regardless sway isn't for most users and will probably never be.
Read the rest
I'd look more to issues in KDE or similar where it's more focused on the "normal" use case, supports Nvidia just fine, and is expected to work out of the box.
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.
Caveat: this applies only to compositors based on wlroots, list of them here:
https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
The most mature compositors from this list are sway, wayfire, hikari, and cage. YMMV with other Wayland compositors, and if you have issues with them, you should speak to them, but not blame Wayland in general. If you have Nvidia hardware, you will also have to use the nouveau driver, and YMMV with that, too. I recommend Intel or AMD GPUs, both companies are much more cooperative with the FOSS community.
In I'm tired of this anti-Wayland horseshitI honestly think this complaint is completely bogus.
This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations.
The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] !
The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't.
[1]: https:
Read the rest
That's true, but wlroots (sway's compositor) has tried to fill some of that gap: https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
It has its own libraries for things like screensharing (xdg-desktop-portal-wlr) that should work across these window-manager-esque desktops.
In Wayland is not ready as a 1:1 compatible Xorg replacement just yetQt applications are almost certainly using the output scale property, I've tried those recently. I haven't tested Chromium's wayland backend recently, but Chromium is ignoring those physical values: https://github.com/chromium/chromium/blob/99314be8152e688baf...
Maybe your chromium is not using the Wayland backend correctly? If a Wayland application is using the physical values to determine scaling, instead of the output scale, that's a bug and you probably should consider reporting it. It's probably a mistake that the physical size information is there, it's unreliable as you have seen.
Edit: Rather than messing around with proxies, if you want to do a quick test to confirm, you could simply hack wlroots here to send a constant value: https://github.com/swaywm/wlroots/blob/b3e76d667855c16e97a4d...
In A few HiDPI tricks for LinuxShowing the 15 most recent of 51 sources. Enable JavaScript to search and browse every indexed mention.