Hacker News Reader

Comment by vidarh | Hacker News Reader

I don't "actually want Wayland" because I want the simplicity of X and the ability to run my own wm, but I have no need for legacy X11 requests, for some values of "legacy". Whether this will become viable for me remains to be seen, but I need very little from my X11 server.

View on HN

Fair! Though I'm actually not sure I understand what you mean with simplicity. X11 is so vastly more complicated than Wayland.

For the server/compositor.

Not for the client, or if you want to write a wm and is forced to write a compositor.

And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.

So build on top of wlroots or something. DWL for example is super small...

Current status:

> 2025-08-16: dwl IS CURRENTLY UN-MAINTAINED. AT THE PRESENT TIME, I (@fauxmight) DO NOT HAVE THE TIME OR CAPACITY TO KEEP UP WITH wlroots CHANGES.

https://codeberg.org/dwl/dwl

I said build on top of wlroots, not DWL. And I only brought it up as an example of a small Wayland compositor/window manager because the poster I was replying to wants to build their own anyway. DWL is more interesting as a learning exercise than something to use.

The -IMO- important part of that quote is "NOT HAVE THE TIME OR CAPACITY TO KEEP UP WITH wlroots CHANGES".

X11 is backwards compatible, you do not have to "keep up" with its changes.

wlroots seemingly isn't. This is a significant issue when it comes to relying on most 3rd party libraries.

(i worked a _little bit_ on dwl) each wlroots upgrade is a pretty small diff on the dwl source. the annoying part is, as dwl is configured with patches, every patch author has to update their patch to the new 0.x, as dwl is quite minimal, and thus has no stable api. that being said, obviously, dwm doesn't have this problem :)

also, for dwl, the issue is that the initial author (not the guy that wrote that notice) is sorta mia, and he has control of the repo on codeberg, so we'd probably need to fork to be safe, and he may not want to take on project lead. (he checks every patch for merge conflicts with one another and upgrade breakages, god bless him lol)

> X11 is backwards compatible, you do not have to "keep up" with its changes.

That's certainly one way to say "no longer developed".

That was also true back when it was actively developed though. X apps compiled a long time ago still run fine today.

Xorg is still being under development, there is another fork in development too (XLibre) and you're in the comment thread for a project about a brand new X server written from scratch.

Usually things which are "no longer developed" do not have (at least) three implementations in development.

Mature projects often don't change much or quickly even when actively maintained or improved.

When things work further development is not always a positive.

> I said build on top of wlroots, not DWL.

Turns out, the wlroots API is so volatile atm that even the developer of the super small compositor DWL has to throw in the towel for now.

> DWL is more interesting as a learning exercise than something to use.

The same is said about DWM, its xorg counterpart, but I, for one, am a happy user of DWM.

Nearly every Wayland compositor is built on wlroots. Somehow they manage. But yeah, of course it's going to change more than X11, which is older than I am and more or less abandoned...

It's actively maintained by projects like RHEL which still have versions which are supported which in turn support X11.

Others are looking to run X11 wm under wayland with wayback, xlibre wants to keep it moving forward, and phoenix wants to replace it with a modern version.

This isn't what abandoned means.

No, I do not. I pointed out that with Wayland I'd be forced to. And DWL is an illustration of how much work that is relative to an X11 wm.

Why would I?

And DWL is not super small. It's hundreds of times larger than a minimal X wm, and couple of times as big as the wm I used.

And it's C. And it'd mean I would lose my session if I want to make changes and restart it.

What you're suggesting would be to put significant effort into replacing something that works with something that in terms of features I care about is strictly inferior.

Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.

Check out Louvre for example. Or Smithay if you like Rust. And if you want a bit more depth, there is wlroots of course (or the hyprland version). It is not really any harder than writing an X11 WM.

wlroots and smithay (I'm not familiar with louvre) do a lot of the difficult work for you, that most compositors will do without much variation but there's still a lot that compositor writers still have to do. It's still a significantly larger task than, for example, writing an X11 WM.

(Well, writing an X11 WM that also includes a built-in compositor is a bit more than just the WM, but I'd say still less than writing a Wayland compositor using wlroots or smithay. For example, xfwm4's compositor is around 5300 lines of C, which is... not nothing, but not crazy either.)

https://github.com/CuarzoSoftware/Louvre

Yeah, no I have my own wm in Ruby that is fewer lines of code than a typical Wayland Hello World, and that does what I want. I have no reason to want to throw that away for something that doesn't offer me any features I care about, and removes features I do. Such as the ability to just restart my wm if I make a change to it without affecting my current session at all.

Unless you can show me a solution that lets me replace my tiling and floating wm in ca 1500 lines of Ruby, what you're offering me is inferior to what I have with X

It's called an extension. What's the point of mandating a (bad) IPC API?

Th point is that with X I could start with less than 100 lines and switch to using my wm, and stepwise refine it while using it.

You might consider that a bad API, but to me any solution without it is massively inferior and not something I will ever consider.

What's the simple way for a bash script to get the title of the currently focused window? In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.

It shouldn't be hard, all I want to do is fuzzy match window titles to named audio streams in pipewire, but "Oohh noo that's a security flaw!" say the patronizing Wayland developers who care more about making their own lives as developers simple than supporting basic desktop functionality.

> In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.

I don't know what you expect people to prove other than that X and Wayland both have the same problem but since X is so complicated there is only one implementation to begin with, which makes it look like X has solved the problem even though it suffers from exactly the same problem.

There are in fact multiple implementations of X and xdotool works with all of them. Typical Wayland advocate, doesn't know what the fuck he's talking about while telling people to just ignore the problems they have with Wayland, probaby because you don't even understand the problem in the first place. Why did you even respond to me? To insult me? To waste my time?

> There are in fact multiple implementations of X and xdotool works with all of them

Are there non-Xorg X servers for Linux that are usable? Asking because I'd like to try them if they exist

> all I want to do is fuzzy match window titles to named audio streams in pipewire,

> basic desktop functionality

I feel your pain, but find your idea of "basic" functionality amusing.

That said, `pw-dump` / `pactl` will give you client names, which often match the window titles.

I know how to get the audio stream names, the problem is the window titles. With X it's easy, just call xdotool. I'm sure it's probably easy enough on Windows and MacOS too. Wayland is the weird one for making focused window titles privileged information.

Anyway, I do think I've created what should be considered basic desktop functionality here, a simple hotkey that mutes or otherwise changes the volume only of the focused window. Every desktop should have it.

This is just one of the tools I've made for myself with X which I do not want to do without and this makes Wayland a non-option for me. If I can't use X and can't replicate things like this with Wayland, then maybe I should switch to MacOS at that point because the dream of controlling my own computer seems like it's dying anyway.

Wayland is approximately correct in this case and Windows and Mac are behind the security curve for bincompat reasons; window titles certainly leak PII. There should be a way to do it, but it is sensitive information.

Is there any documented attack on macOS or Windows that utilized window title information?

Never in history. If you have software running on your system attacking you then you have so many more issues than the adversary knowing your window titles.

Sure, but again there's no interest in actually making a standard way to do it. I can understand it being something that arbitrary applications probably shouldn't be able to access, but that somehow turns into no way to do it, or complete fragmentation where every DE does it with arbitrary differences (or, more realistically, some DEs support it and others don't).

Okay; is there a way to do it? Can I, the user, decide that I do actually want a program to see titles? Or is it still impossible because 17 years isn't enough to implement utterly trivial APIs that people want?

You are aware that by default programs you run have access to your entire home directory, right? Applying any restrictions to them in the windowing protocol is security theater.

Afaik Xorg is 'only' like ~500k lines of code, which is not huge by the standards of large porjects. In fact, one of the major counter arguments against Wayland, is that the compositor + a few core libs, like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code (which has a ton of unused cruft).

> like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code

I absolutely don't buy this.

You shouldn't, cause it's wrong.

libwayland is 40k lines of code. wlroots is 60k loc.

And just to check, sway is about 49k loc.

I remember Wayland scared me off of Linux when I tried to switch to Ubuntu a few years ago. I couldn’t watch a movie without jiggling my mouse every few minutes. At the time I feel like it was like “yeah that feature doesn’t exist yet” or something. So I switched back to Windows. It looks like there’s workarounds now but I’ve mostly switch to my fantastic M1 MacBook Air at this point.

Wayland still doesn't support screensavers last I checked, which is wild to me. Truly bizarre that such longstanding feature is just absent.

It's a matter of designing and proprosing a protocol for it. X11's screensaver support was also a protocol extension.

There probably hasn't been much interest in it because screens can easily be powered off remotely, which was not the case in 1992.

Yeah, most of those real gaps have been solved at this point. I'd encourage you to give it a shot now with Avahi

Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).

It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).

That sounds cool, but TBQH the last thing I want to do is make myself dependent on some obscure piece of tech I've only heard of once before (just now.) My plan is to keep running X as long as I can manage to make it run. If river finds traction and is well known to me in 10 years then I'll consider it then.

This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.

I don't have any interest in river. I have my own wm that does exactly what I want, so why would I switch?

Wayland doesn't solve any problems I have, and would create new ones, such as having to adapt to new tools or write my own compositor.

Battery life just isn't a relevant consideration for me.

Reply on news.ycombinator.com