back
5 comments
X11 did nothing wrong. You hear me? Nothing.
X11 did a lot of things. None of them "wrong", just "badly conjoined at the spinal cord".

An X server is a fantastic example of how building drivers for deep hardware components should never have been written in userspace.

(If anyone wants: There's a fantastic talk at LCA a few years ago from Keith Packard about X's history: https://youtu.be/cj02_UeUnGQ )

X11's architecture, on the other hand, is arguably better than Wayland's. Server-side rendering is a great way to

It also has lots of flaws. "Mechanism, not policy" has to go, because you are trying to make a desktop environment, not draw arbitrary rectangles to the screen. It is already a given that there is one special client called the window manager; it would serve the architecture well to know that's the window manager instead of treating every client as if it could potentially be a window manager. But Wayland goes even further in this direction, eschewing things like icons, title bars and resize borders, which are basic expectations of a desktop environment. While X11's way of doing these things is esoteric, at least it has one. (If it were up to me, standardized window properties would be promoted to requests, so you'd just call xcb_set_window_title instead of fussing with atoms and window properties).

Another anecdote is HDR: Wayland seems to still have not standardized how it should work; meanwhile on X11, there is already protocol support for multiple pixel formats (1-bit, 4-bit, 8-bit, 16-bit, 24-bit displays) and you could just add 48-bit color to that list. That would be one of the things Wayland stripped out while striving for simplicity (since everyone had 24-bit colour at the time) that turned out to actually be important.

---

At some time before the heat death of the universe, I will get around to trying to fork Xorg and remove all the cruft and see where that goes. (Server-side rendering is not cruft. User-mode SVGA drivers are.)

I did minimal work on this already - as in, I downloaded Xorg's source code and had a look through. The whole configuration system has to go. The XFree86 driver code and driver abstraction has to go, and the DRM driver hard-wired in place. Using dlsym to locate compiled-in modules makes tracking dependencies impossible.

I suspect this has something to do with the state of Xorg: Nobody knows what it should and shouldn't do, and the module API for Xorg is the entirety of Xorg, so changing anything is liable to break someone's external module that wasn't on the "it should do this" list.

It wouldn't be the first time the X server was forked with the intention of cleaning it up: Xorg is a fork of XFree86, which was a fork of X386, which was based on something I don't remember.

There are some advantages and disadvantages of the approach.

However, there's just stuff that X assumes that isn't true anymore. A good example is how it handles input. How many cursors does a screen have? One machine? okay, One input device?

One of the folks behind both Wayland and X gave a fantastic talk on the issues and the hell. https://www.youtube.com/watch?v=HllUoT_WE7Y

I'll have to see the talk later. If a new input model is needed, why can't it be an incremental upgrade? I know that UI frameworks still have the traditional mouse down/up/move events, so they've been able to make it an incremental upgrade in that layer. If it's so incompatible that it can't coexist with the old model in the same connection, we make it an option for the client to request. If we're very very sure it's the future, we make it X11R8 or even X12 (the difference between X10 and X11 was smaller than this), we allow the server to support X11 and X12 clients and deprecate X11, and remove it after a very long time (if ever). All of this is still less invasive than Wayland.
The problem is what X11 didn't do: attract and retain maintainers.
The majority of SW developers want to make shiny new things, not fix old bugs.
It did have some of the worst code in open source. We didn't need to abandon the protocol, ABI & backwards compatibility (fuck Wayland sideways a broom) but a rewrite was sorely needed
It's true except no one wants to maintain it anymore because the code is a mess. This is how software dies.
You're confusing X11 with Xorg. There were X servers before Xorg and there will be X servers after. (Xwayland is one!)
x11 doesn't do much of anything to begin with, these days. It will still exist for the people that want to use it, but distros are right to not default to it anymore.
Did they ever fix the accessibility situation on Wayland? Non-accessible defaults are not great IMO.
The issue is still open for GNOME, so I would assume it still is very much a problem: https://gitlab.gnome.org/GNOME/mutter/-/issues/9
gnome and cosmic are both using accesskit for some of the parts that aren't completed yet.
Why can't we have a wayland server that can run different window managers like X did? That way, we only need one wayland compositor, and everyone can just write their own window managers.
This looks doable. Create a Wayland compositor that does not do visible window management itself, but exposes an API to help relatively easily port and run an ICCCM-compliant WM.

This looks so obvious that it ought to have been tried.

That’s what wlroots is (almost). Many wayland window managers use that to offload wayland stuff.
Mir is perhaps the closest thing to that ideal that I'm aware of. Maybe arcan, but I don't know anything about the architecture
TIL that Mir is not dead, but pivoted to be built on top of Wayland.
A big thanks to phkaeser for this work.

If I am ever forced to use Wayland (yes forced), I could very well seem my self using Compositor.

Great work!

It's the first, and hopefully the only, time I will say I'm glad I see something on Wayland. I had some nasty visual issues once with WindowMaker, I feel like such a fundamental move is needed.
I just skimmed but it looks like it’s missing something like WiNGs
If gnustep has a Wayland backend that would be a logical pairing.

I seem to recall WindowMaker had special support for gnustep's NeXT style detachable menus.