wayland.fyi minimalist wayland special interest group

Home of minimalist wayland special interest group.

Many have claimed that wayland 'sucks', the goal of this site is to not only promote and make alternative wayland software which fits the label of 'minimalist', but also to disprove many of the claims people make against wayland.

smaller wayland

wayland at its core is a very simple wire protocol, nothing more, the default implementation sits at just around ~10k lines of code, what is big is what is made on top of it, which usually in mainstream wayland is some sort of compositor library based around GLES or vulkan (although pixman backend is sometimes offered it is a second-class citizen), bringing in such big rendering pipelines always results in complex, messy systems that are impossible to understand for mere mortals, or a buttload of protocol extensions, or an xdg-desktop-portal, whatever the hell that is.

we are offering an alternative, it might not be perfect, but we found omitting 'modern' renderers and some features to be good enough for our workflow, similarly much of the insanity surrounding freedesktop can be ignored simply by not implementing certain protocols or 'wayland' features. a list of Wayland.fyi Approved ™ software is available at the bottom of the page.

the case of wlroots

wlroots kinda sucks... but what are the issues?

there are a couple:

• it's big. huge, even.
• brings in a lot of badly designed and overly large protocol extensions.
• wlroots is extremely linux-centric: it is hard to get working on minimalist Linux distros without udev.
• when statically linked causes symbol conflicts with sway (to be fair this is an issue on sway's side)
• because of its udev dependency and requirement for seat management, it does not work natively on BSD, and needs "compatibility shims" (read as shitty hacks). our compositor library neuswc works natively on all BSDs, without shitty hacks.
• wlroots is fast moving and unstable: hobby projects like dwl are left unmaintained due to developers not being able to keep up with changes.
• wlroots is fairly low level: good for some use cases, a bit (a lot) of a pain for people to make their own compositors easily, which is why wayland has a lot less options than X on that front.

some interesting talk and work that could potentially make wlroots suck a fair bit less (while not solving the fact that it's overengineered):

• udev discussion (archived)
• a pr making udev optional (rejected)

• static linking discussion

NOTE: despite claiming to be "60,000 lines of code you were going to write anyway." it is closer to 80k and swc proves even then it is not true :P

TL;DR it could be worse, but it could be also way better

the case of X11

All graphics on UNIX are bad, that's because modern UNIX is barbaric technology, but X11 is the worst offender of being barbaric.

full X11 stack is millions of legacy lines of code, workarounds, and wasn't even a good design in theory. they made a library called libXfixes. when you need a library just for fixes you know it's bad. or libXfont2... Xorg is so old they made a sequel to the font library!

Have you ever tried to look at its source code? it is best you don't...

Essentially (for better or worse) it’s not the 1990s anymore.

X11 client code often looks simpler because there is a lot that you do not see (nor do you want to), and even more which you will never use.

Wayland makes what you do more explicit rather than relying on crusty abstractions (and boy, are they crusty).

X11 is the antithesis of small, minimalist software.

misinformation

Often in discussions around wayland vs X, various weird, wonderful, and incorrect claims appear, this disproves them, you can link directly to any of the sections below

# "Wayland being composited by default is bad"

Compositing is not fancy animations or transparency, in effect it usually means drawing just what you need, where you need. X11 Compositors are separate from the X server, runs as a client, redirects all windows into offscreen pixmaps, and re-draws with effects or v-sync. On wayland, there is no unified server. the compositor is the server. it handles all drawing, input management, and compositing the final scene. Although the same word is used, compositing on X and Wayland are not the same thing!

# "X11 is minimal/good/better than Wayland"

Here's a quote about X from 1998, just to illustrate how not only is it not good, it was actually never good!

"X-Windows: ...A mistake carried out to perfection. X-Windows: ...Dissatisfaction guaranteed. X-Windows: ...Don't get frustrated without it. X-Windows: ...Even your dog won't like it. X-Windows: ...Flaky and built to stay that way. X-Windows: ...Complex nonsolutions to simple nonproblems. X-Windows: ...Flawed beyond belief. X-Windows: ...Form follows malfunction. X-Windows: ...Garbage at your fingertips. X-Windows: ...Ignorance is our most important resource. X-Windows: ...It could be worse, but it'll take time. X-Windows: ...It could happen to you. X-Windows: ...Japan's secret weapon. X-Windows: ...Let it get in your way. X-Windows: ...Live the nightmare. X-Windows: ...More than enough rope. X-Windows: ...Never had it, never will. X-Windows: ...No hardware is safe. X-Windows: ...Power tools for power fools. X-Windows: ...Putting new limits on productivity. X-Windows: ...Simplicity made complex. X-Windows: ...The cutting edge of obsolescence. X-Windows: ...The art of incompetence. X-Windows: ...The defacto substandard. X-Windows: ...The first fully modular software disaster. X-Windows: ...The joke that kills. X-Windows: ...The problem for your problem. X-Windows: ...There's got to be a better way. X-Windows: ...Warn your friends about it. X-Windows: ...You'd better sit down. X-Windows: ...You'll envy the dead."

let me add one more: X-Windows: ...Begging for replacement since 1998.

See also: The case of X11

# "Wayland and X11 are similar in any way"

very false, the whole model is fundamentally different. X11 is a network-transparent unified server with window management and composting handled by clients, Wayland is not network-transparent, because it’s not 1985. On Wayland compositors ARE the server, and handles window management, input handling, etc. on X, clients speak a rich (lit: overcomplicated) protocol that tells the server what to draw in the client window. On wayland, clients simply submit fully rendered buffers to the compositor.

# "Wayland has built in security policy/CSD support/something I don't like"

Wayland does not have much “built in”. What you probably don't like is a compositor or a compositing library. Wayland itself provides very little, and it's trivial to omit the parts you dislike. Although inputs on Wayland are usually only sent to the client they are intended for (nooo!!! my keylogger!!), this could also be solved if you so desired. Because the compositor handles all input, it could easily forward said input to all clients.

# "We can save X if we reimplement it in zig for some reason"

Phoenix is a waste-of-time project (while quite impressive), rewriting a piece-of-shit protocol in a language with a new breakingchange every 5 minutes is not a good idea! nor is shoehorning arguably the worst bits of wayland into the already-terrible Xorg! We already have a solution to run X software, it's called Xwayland!

wayland.fyi approved

ok, so most wayland software sucks, X sucks more, what can you do about it? well, here’s a list of some actually simple and well designed wayland software you can use, from libwayland, to compositor libraries, to compositors, to applications. The criteria are:

• implemented in a sane and portable language
• small, hackable codebase
• does not rely on very big protocol extensions
• does not have any 'linux-isms' and is portable to atleast one non-linux unix-like operating system

libraries:

• libwayland: the classic core wayland code and protocol
• freeway: a slightly smaller, simpler libwayland implementation with fewer dependencies and native NetBSD kqueue support
• wld: a primitive drawing library that targets wayland
• swc: a wonderful library for creating simple tiling wayland compositors, using wld
• neuwld: a fork of wld with proper font rendering, and more features in the works
• neuswc: a fork of swc with many more features and fixes implemented, including wallpapers, screenshots, and better cursor handling
• zig-swc: zig native bindings for neuswc with interoperability with zig-wayland

compositors:

• nyctal: tiny wayland compositor implemented in Go
• velox: a simple tiling compositor based on swc
• hevel: a scrollable, floating compositor inspired by plan9 UX paradigms, based on neuswc
• wsxwm: a tiling compositor from creator of sxwm based on neuswc
• neuwm: a wayland compsitor based neuswc, forked from wsxwm and inspired by hevel
• tohu: a small fork of the wsxwm compositor with tiling removed, based on neuswc
• slgro: a floating keyboard-driven compositor with moving, resizing, and centering for neuswc, configured in lua
• shko: a highly configurable, floating, scrolling and zooming keyboard-oriented compositor written in zig, using neuswc
• dwc: dynamic wayland compositor based on neuswc
• sunday: a tiling compositor that gives a 3x3 grid of workspaces, made in zig using neuswc
• klatka: a kiosk-style compositor for neuswc
• wmonad: a swc compositor written in haskell
• howl: a neuswc-based compositor controlled by an external client program

utilities:

• st-wl: a port of the suckless terminal emulator to wayland, using wld
• hst: a pre-patched and freeway-compatible version of st-wl with better font rendering using neuwld
• havoc: a minimal and modern wayland terminal emulator
• hack: a native-wayland version of plan9port’s acme editor with theming support, using neuwld
• swiv: tiny image viewer for wayland, using neuwld ^{(a fork by uint)}
• swclock: a xclock-like analog clock program for wayland, using neuwld
• wlclock: simple wayland clock without using any drawing libraries
• wlED: simple wayland text editor without using any drawing libraries
• wev: small tool for debugging events on a wayland window
• dmenu: dmenu for wayland, using wld
• neumenu: updated dmenu fork for wayland using neuwld
• swall: wallpaper setter for neuswc
• mojito: featherweight, lemonbar-compatible bar for neuswc-based compositors
• chum: area selector for neuswc similiar in spirit to slop(1)

misc:

• neu-nix: nix flake for neulibs packages
• neu-kiss: kiss repo for wayland.fyi stuff
• fork of void-packages: void packages with some stuff listed here

contribute

Do you know or made a program which fits our criteria? Have you find a typo or formating issue, or just want to add something?

Call 1-800-WAYLAND or send a patch to our mailing list on sourcehut

community

#derive on ergo.chat

/derive/ on 9larp forum

#swc on libera.chat (please mind this is the original channel made by mcf, respect everyones time here, low quality discussions should go to #derive)

recommended reading

• wayland book a fundamental guide thru wayland internals
• wayland from scratch a guide to making a wayland client with as little as possible
• pure wayland wayland without X
• X is a dangerous virus a piece of ancient wisdom
• A guide for wayland.fyi stuff: a guide on setting up and running a full swc-based enviroment on Alpine

as seen on...

• youtube
• youtube
• glaucus linux wiki... for some reason
• lobste.rs
• 4chan's /g/ every other month for some reason
• tiktok, I am not linking that
• probably somewhere else