Owch
Owch
Posted Jul 24, 2025 20:23 UTC (Thu) by jmalcolm (subscriber, #8876)In reply to: Owch by smurf
Parent article: Wayback 0.1 released
> What the heck is the advantage of Wayback?
I initially had mostly the same reaction.
If you want an X server, surely Xorg itself is a better one (from the user perspective)
The benefit is not to the user but to the distro. It means not having to package Xorg anymore.
And there is some PR benefit to Wayland. People think that X11 support has improved in Wayland somehow.
But what you may be saying is that we could already do all this without having to create Wayback. And indeed when I asked, nobody could tell me what the difference was between Wayback and running Xwayland on Cage (in kiosk mode). Because Cage already exists obviously. Or on Sway as you suggest.
The answer I think is the "drop-in" nature of Wayback. For example, Wayback executes .xinitrc at start-up. So Wayback is going to feel more comfortable to current Xorg users. Fair enough.
But technically, this is not a very big advance. Which explains I suppose how Wayback has made such rapid progress. The project kicked off just a couple of weeks ago and it already works well enough that it would meet the needs of many Xorg users.
Posted Jul 25, 2025 9:08 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (22 responses)
Thus, the user-visible reason to try this and switch to it if it works for you (or make a note to try it again later if you hit a limitation) is that Xorg will, sooner or later, have to be dropped for technical reasons. Wayback is maintained, so should survive.
A technical way to look at it is that Xorg's DDX is unmaintained; Wayback is effectively gluing a new, maintained DDX to the bottom of XWayland.
Posted Jul 25, 2025 13:21 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (8 responses)
So I gather from this thread that the difference between "run Wayback" and "run a kiosk-y Wayland compositor and rooted XWayland on top" is that the former will have slightly fewer possibly-moving parts, and try for Xorg compatibility (.xinit, xrandr and whatnot), in exchange for being unable to run any actual Wayland clients.
Correct?
Posted Jul 25, 2025 13:49 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (7 responses)
So your kiosk-y Wayland compositor is basically a Wayland-first world, and you nest Xwayland in it to give you an X11 world inside your Wayland world. Wayback, in contrast, is an X11-first world, where Wayland is being used as an implementation detail to make implementing an X11 server easier than doing the whole thing from scratch (since you reuse Xwayland to do all the X11 protocol handling, glamor acceleration of X11 rendering primitives and extensions etc).
Posted Jul 25, 2025 14:42 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (6 responses)
I think it's all down to (a) all the emphasis on Wayland, and (b) the emphasis on "Wayland is a protocol". Which leaves me at least wondering "how does anything ACTUALLY happen?". What's behind that protocol? What actually carries out all those instructions?
I guess it's those things called compositors? Are they each an equivalent of Xorg? If so, it does seem weird to have so many. Or is Weston the grand-daddy of them all, and they're all basically slightly modified versions of Weston? If so, why? It seems a bit strange ...
I'm pretty certain I don't understand what a compositor actually IS. And if, as I suspect, all compositors share a large amount of their code base (even if that is a result of calling into even lower levels of code), why can't there just be a central library core of primitives, and GTK/Qt/Sway et al all just implement their own special requirements with a namespaced extension? Rather than a complete new compositor?
From the Pov of someone who likes things to add up, this whole Wayland thing seems to have far too much magic at the "compositor and below" level ... and if I'm confused, I would think a lot of other people are too ...
Cheers,
Posted Jul 25, 2025 15:07 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (2 responses)
Yes, it's those things called compositors. A compositor is basically (exactly) a Wayland server, just like Xorg is a X11 server.
Except that in X11 world, you'd also have an actual *compositor* (which provides the modern GPU-based rendering of windows as textures) running beside the X11 server as a stand-alone program, plus a *window manager* as another stand-alone program, and the Xorg server itself is basically reduced to an overcomplicated IPC server with some input handling baked in.
In Wayland world, a Wayland compositor is now an equivalent of all three, because at some point it was recognized that the compositor and the window manager are the ones doing most work, and you can cut out the middleman.
> I'm pretty certain I don't understand what a compositor actually IS. And if, as I suspect, all compositors share a large amount of their code base (even if that is a result of calling into even lower levels of code), why can't there just be a central library core of primitives, and GTK/Qt/Sway et al all just implement their own special requirements with a namespaced extension? Rather than a complete new compositor?
Naturally, there now is one library that aims to do just that: wlroots. Many smaller compositor projects are already using it to share the common low-level code. GNOME and KDE aren't using it, because their X11 compositor/window-manager code bases were *already* doing most of that work themselves and it was easier for them to just keep doing it, rather than expend effort on rebasing their huge codebases on top of some other library which didn't even exist back then.
The part about namespaced extensions is already how it works, except that there aren't really any *toolkit*-specific extensions, they are mostly *compositor*-specific or *purpose*-specific.
Posted Jul 25, 2025 17:16 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
So Wayback now adds another variation to the mix :-) It's basically a standard Wayland compositor, but rather than providing its own window manager (as they're supposed to do) it calls upon XWayland to do the job instead. So all the user sees is the standard X front end, but any Wayland apps expecting the compositor to provide a window manager get a bit of a shock :-)
Quite neat, actually :-)
> The part about namespaced extensions is already how it works, except that there aren't really any *toolkit*-specific extensions, they are mostly *compositor*-specific or *purpose*-specific.
So how do you share purpose-specific extensions across compositors? I was thinking along the lines of - with the extension name - you could just add your code to wlroots so it's available to any compositor, but if it's got an X- type name, it's down to the proposer to maintain/support it until it's formally adopted by the community ...
Cheers,
Posted Jul 25, 2025 17:43 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Extensions are named, and if you're sharing across compositors, you "just" have to get everyone to agree on the name to use to find the required protocol objects. Because all objects have dynamic numbers in Wayland, you can't just hard-code an object number to find an extension.
You may want to read the Wayland protocol docs, which include a comparison to modern X11 architecture, and you might find the Wayland Protocol Documentation worth browsing. If you're running a Wayland protocol desktop (instead of an X11 protocol desktop), you might also want to try Waycheck to see which Wayland extensions your desktop supports.
Posted Jul 25, 2025 15:16 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (1 responses)
At the bottom of the stack, you have the Linux kernel, providing KMS and DRM for controlling graphics hardware, Linux event-based input for input devices, and udev for hardware detection. This is unchanged.
The next level up is the Xorg server. This uses KMS, DRM, event input and udev to have control of your hardware, reserved to the Xorg server. It talks X11 protocol to clients.
You then have two special X11 clients; one is called the "compositor" and the other the "window manager". The compositor tells the Xorg server to lie to other clients about their rendering, and to let it do all the rendering to a special compositor overlay window, which hides all the other X11 windows, and ensures that what the compositor renders is what you see. The window manager is responsible for window decorations (title bars etc), moving windows to the right place on screen etc. The window manager uses X11 protocol to add extra windows to the screen, attached to client windows, which provide title bars, resize corners etc. The compositor draws everything that you see, using X11 protocol.
X11 protocol, in turn, provides many different ways to draw to your windows:
This adds up to a lot of indirection; for example, xeyes uses core protocol; the window manager also uses core protocol to tell the X server where to put things. Then, the X server doesn't render what xeyes asked it to, but instead puts xeyes rendering into a buffer, and uses an X extension protocol to tell the compositor what region of the buffer has changed. The compositor then typically uses DRI to get direct access to the GPU, uses X extension protocol to get access to the contents of the buffer, draws to the compositor overlay using the GPU directly (bypassing the X server), then tells the X server that it can present the compositor overlay to the screen via X extension protocol.
Wayland simplifies this model. First, there's no way to ask the Wayland server to draw for you; it just provides equivalents of MIT-SHM and DRI. and lets you render however you like. Second, instead of having an X server lie to you and say that you're rendering straight to the screen (and then coordinating over IPC to send your output buffer across to a compositor that sends it back to the X server to render to the real screen), you know that you're sending an output buffer to a compositor, and that the compositor is directly rendering to the real screen.
As a result, instead of KDE providing a compositor and window manager (separate logical entities) in kwin_x11, which communicate with the X server and have to remain in sync with it (since the X server is the final arbiter of state, KDE now provides kwin_wayland, which does the same as kwin_x11 did, but without talking back and forwards to an X server. Similar applies to GNOME etc. There's shared code wherever people want it, from libwayland if all you want is a shared protocol implementation, through to wlroots if you want something that lets you build your compositor to behave just like an X11 compositor and window manager combination.
This is, FWIW, basically the same as the X11 world, but without a superfluous X server process in the middle, and thus without the requirement that if you want to do something new, you first teach the X server how to relay information between clients and compositors, and then teach your compositor how to do the new thing.
Posted Jul 29, 2025 7:53 UTC (Tue)
by taladar (subscriber, #68407)
[Link]
Posted Jul 25, 2025 15:24 UTC (Fri)
by jmalcolm (subscriber, #8876)
[Link]
> Are they each the equivalent of an Xorg
Short answer is yes, each compositor is a display server, like an X Server that speaks Wayland instead of X11.
Imagine that Wayland was HTML. A Wayland compositor is like a web browser. Does it seems strange to have multiple web browsers? Most of the time, the argument seems to be that we need more of them.
Web developers write web applications that they expect to work on any web browser. Same for Wayland. A Wayland application should work on any Wayland compositor.
Like the earlier days if the web, not all compositors support all features yet. The situation is pretty good now but it will improve over the next couple of years.
Also, like with web browsers, people rarely write their own from scratch. There are several toolkits now for creating Wayland compositors. These are things like wlroots, louvre, and smithay. GNOME and KDE made their own. Just like I can use chromium to create my own web browser while avoiding 99% of the hard work and plumbing, I can use one of these foundations to create a Wayland compositor. Also, a lot of the functionality in Wayland is outside the compositor too, like XDG desktop portals and things like Waypipe. A compositor author can choose to use existing solutions or provide their own.
Posted Jul 25, 2025 21:34 UTC (Fri)
by jmalcolm (subscriber, #8876)
[Link] (1 responses)
> Xorg is slowly collapsing under the weight of legacy DDX support
You sound knowledgeable. Please help me correct the gaps in my understanding.
My view is that, these days, Xorg uses the modesetting driver for most hardware. This offloads responsibility to the kernel (eg. KMS and DRM) and to userland (eg. Mesa). As such, Xorg itself does not really need to be updated, even when new hardware appears. KMS, DRM, udev, libinput, and Mesa are all used with Wayland as well so they are all going to be maintained regardless of what is going on with Xorg.
When you say "legacy DDX support", I assume you mean all the non-modesetting DDX drivers in the Xorg tree. Is this correct? I understand that many of these are largely unmaintained. It was my impression though that few of us are using these anymore, having migrated to xf86-video-modesetting.
So, how is "Xorg is slowly collapsing under the weight of legacy DDX support"? Please expand on this.
> There is likely to come a point where a distro trying to use a current C compiler will be unable to build Xorg at all
Is this only because of these old DDX drivers? If so, could we just remove the offending driver (which probably has few or no users) and let xf86-video-modesetting take over? I suppose very old hardware may stop working but at least Xorg itself will still build.
Or are there other parts of Xorg that you think are at risk of bitrotting in this way?
Red Hat will maintain Xorg until the mid-2030s as part of RHEL9. And there are other folks that may keep Xorg going (eg. the BSD distros). I assume the risk of Xorg not compiling is quite a long way off pragmatically. But I want to better understand the risks you are raising.
Posted Jul 26, 2025 10:54 UTC (Sat)
by farnz (subscriber, #17727)
[Link]
In particular, you've got XAA, EXA and probably legacy remnants of other acceleration architectures. You've got userspace mode setting code that's kinda gnarly and problematic, including hooks to let you reprogram PCI bridges under the kernel's nose for things like AGP support. There's just a lot of stuff here that's probably not used any more, but because there's so much of it from the XFree86 days and earlier, there's a lot to remove, and each removal runs the risk of breaking a user with a very fragile setup.
The problem is that no-one is volunteering to rip out everything not needed for modesetting and libinput drivers from the Xorg DDX, risking breaking obscure setups in the process. It's not the drivers that's the problem - it's the code to support the drivers that's the issue.
And the core issue is that nobody knows when a compiler change will break the legacy code in Xorg; it's code with history that predates ANSI C in 1989, and nobody's actively working on it. It might continue working, unchanged, forever; or it might suddenly stop working when a new GCC version comes out. RHEL isn't affected if that happens, because they lock down the compiler version at release, so a new GCC version that stops Xorg compiling won't affect RHEL9, and RHEL10 onwards don't contain Xorg.
Posted Jul 26, 2025 5:16 UTC (Sat)
by wtarreau (subscriber, #51152)
[Link] (10 responses)
Because I don't want to sound negative, since Xwayback seems to be an improvement in the wayland situation, but all this stuff still sounds extremely complicated and brittle compared to "just" running an Xorg (or Xfree) server!
Also I've never understood why nobody implements the X server in a native wayland compositor so that it just accepts the two protocols on input at once, letting both X11 and wayland applications coexist on the same screen. Maybe it just stems from technical limitations of the wayland spec, but that could also be a great experiment to see how to improve that spec for a future version. X11 didn't start great instantly, it took several iterations.
The huge number of components involved makes me think the thing is awkwardly designed and that everyone is trying to provide one extra component to interface between two existing ones and translate something or reduce the number of incompatible apps.
Posted Jul 26, 2025 6:40 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Hah. Do you remember the Xorg history?
It first started as a project to _modularize_ the XServer. That's how you got dozens of packages for various parts of X: https://www.x.org/wiki/GoingModular/ It helped by reducing the incestuous code relations between unrelated parts and improved the general X code quality. It also removed the bad old imake system. Just to give you some perspective, GNU Autotools were considered to be a lot _superior_ to it.
But eventually the modularity turned out to be superfluous with so few Xorg developers, so the source code got merged into one repository. It's still internally modular, though.
Posted Jul 26, 2025 14:11 UTC (Sat)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
Posted Jul 28, 2025 19:18 UTC (Mon)
by madscientist (subscriber, #16861)
[Link]
Posted Jul 26, 2025 7:21 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
A lot of the current Wayland ecosystem developers are the same developers that did all that work. Running XWayland on top of a single-purpose Wayland compositor isn't really any more fragile or complicated than running Xorg - something is consuming the X protocol and passing pixels off to something that knows how to speak to the hardware, it's just that in a traditional X server those two components were tightly bound together and in Wayback they're communicating over a well-defined protocol. If anything, it's a more modular approach.
Posted Jul 28, 2025 10:47 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Jul 26, 2025 7:33 UTC (Sat)
by kreijack (guest, #43513)
[Link] (2 responses)
I think that "arcan" has something like you suggest. It is a wayland compositor with a natively X protocol support.
Xwayland does the same thing, but it is "wayland compositor" agnostic, being able to work with all the compositors. Likely we will never have a single compositor (at least I expected that there will be a duopoly with kde and gnome compositors, the wlroot ones will be a minority ). So having Xwayland as separate project will help to have less duplicated code.
Posted Jul 26, 2025 14:17 UTC (Sat)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
Posted Jul 29, 2025 10:38 UTC (Tue)
by luci (subscriber, #178086)
[Link]
By each environment being able to have its own display server (the compositor), they at least get to control the entire user experience more carefully.
Posted Jul 26, 2025 10:58 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (1 responses)
Note that a big chunk of the issue is that Xorg's DDX has hooks sprinkled throughout it to allow the best hardware acceleration ideas of 1984 onwards to do their job. Many of those are completely dead now, but nobody is digging through to work out which ones are completely unused by all current users, which ones can easily deleted because you can return a "not supported" error to the drivers, and which ones still matter.
Wayback is a lot less complex and brittle than the Xorg codebase, because it's able to jettison all the layers and layers of history; instead, Xwayland translates X11 protocol to a much simpler Wayland protocol (doing a lot of the rendering itself using OpenGL and glamor). Wayback handles the hardware interface, and the simpler Wayland protocol. It also avoids the problem of "what if I remove this code, and I break some obscure setup?", because it's a new X11 server,
For an analogy, I could make every backend web server support HTTP/3 over QUIC, HTTP/2, HTTP/1.1, HTTP/1.0, HTTP/0.9, TLS with full certificate validation for the public web, IPv4, IPv6, load balancing to other backend servers etc, with special hooks in place so that if the incoming request is HTTP/1.1, you get to handle it differently to how you handle the same request over HTTP/2, and with the option to behave differently if this is a direct client request versus if this is load balanced from another server; that's roughly what Xorg ends up doing, because what's right for hardware acceleration has changed over the decades.
Or I could have a backend web server supporting HTTP/2 and a private CA only, talking only on IPv6 and have a high quality front-end proxy that handles the details of web-facing TLS, load balancing, HTTP/1.1, HTTP/3, QUIC, HTTP/1.0, IPv4 etc, which is roughly the Wayback architecture, with Wayback being the backend, and Xwayland being the high quality front-end proxy.
Posted Jul 26, 2025 14:22 UTC (Sat)
by wtarreau (subscriber, #51152)
[Link]
The basic reason this exists at all is that Xorg is slowly collapsing under the weight of legacy DDX support. There is likely to come a point where a distro trying to use a current C compiler will be unable to build Xorg at all, and there's already no-one around who's willing and able to fix the issues in Xorg so that it'll continue to build, and function on future kernel versions with newer hardware.
Why Wayback, not Xorg
Why Wayback, not Xorg
Exactly that - it's reasonable, as an end user, to see Xorg and Wayback as two different implementations of the same thing, just that Wayback is a maintained X11 server, while Xorg isn't.
Why Wayback, not Xorg
Why Wayback, not Xorg
Wol
Why Wayback, not Xorg
Why Wayback, not Xorg
Wol
Wayback shouldn't, AFAICT, set the WAYLAND_DISPLAY environment variable, and thus Wayland clients won't connect to it - it's using Wayland as an implementation detail of an X server, rather than as something to expose more generally.
Why Wayback, not Xorg
Let's start by describing a modernish X11 on Linux stack (something I was running in 2012 or so).
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
The trouble point is not the drivers; it's the interface layer between the DIX (which is shared with Xwayland, Xvfb and other X11 servers in the same project) and the drivers. Most of that interface layer is not useful when you're using xf86-video-modesetting and the libinput based input driver (whose name I've forgotten), but it can be used by other drivers, such as the NVidia proprietary driver or the synaptics driver, or even other drivers that are kept secret to an institution.
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
Why Wayback, not Xorg
No, we're in this situation because the people who used to be maintaining Xorg, and modularising it to make it maintainable into the future stopped doing so, and nobody who's happy working on C code that has history predating ANSI standardisation in 1989 has stepped up to take over maintenance.
Why Wayback, not Xorg
Why Wayback, not Xorg