Wayland starting to work
Wayland starting to work
Posted Jan 27, 2026 19:40 UTC (Tue) by jmalcolm (subscriber, #8876)Parent article: Xfwl4: the roadmap for a Xfce Wayland compositor
A common complaint about Wayland is how much work each compositor has to do to implement Wayland. For X11, Xorg had essentially won the Linux desktop and everybody was using the same X server. Building an X11 window manager to run on top of Xorg was not that much work because Xorg itself was doing most of the heavy lifting. At least compared to implementing a Wayland compositor. At least, that is the story I keep hearing.
On Wayland, a lot of what Xorg was doing as the display server has to be done by each Wayland compositor independently.
But of course, we have seen libraries emerge that do most of the heavy lifting for you including wlroots, smithay, louvre, aquamarine, swc, and others. This is why you can have a new Wayland compositor project start like xfwl4 here as primarily the work of a single developer and yet suggest that they will have a first release available in just a few months (mid-2026 is 5 months from now).
And it is not just that these libraries address a core criticism of the Wayland approach. This is a massive improvement over the monolithic approach in Xorg. Not only does XFCE have a solid base to build on but they were able to select from multiple options to choose the one that was the best fit in terms of features, maturity, and language choice.
In choosing Smithay, XFCE is building on the same foundation as COSMIC and Niri. Good company. But beyond the compositor, Wayland requires you to implement the XDG-desktop-portal bridge. Many use the wlroots portal. GNOME, KDE and COSMIC build their own. Niri uses the one from GNOME. It will be interesting to see what XFCE settles on. Perhaps leveraging the work from COSMIC makes sense.
I see this as very similar to having multiple browser engines and JavaScript engines available on which to build web browsers. Most in the Open Source world would agree that having a single browser engine (Chromium perhaps) is a bad thing. We gnash our teeth over the health of Firefox. We cheer on efforts like Ladybird and Servo. And so we should in my view. Multiple implementations competing for market share drives innovation, increases quality, improves performance, and ensures that no single player has total market power over their user base. On the web, every implementation supports a different subset of web standards to varying degrees of completeness. But just as with the web, where things have matured to where most apps work well on most browsers, so will Wayland "engines" mature.
And even once we have many mature Wayland implementations for would-be compositor authors to choose from, anybody will be free to write another one if they think they can do it better (just as Ladybird is doing for the web).
The modularity of Wayland will prove to be one of its great strengths over time. Even though the best is yet to come, it is nice to read stories like this that demonstrate how far we have come.
