Wayback 0.1 released
Version 0.1 of the Wayback project has been released:
Wayback is an X11 compatibility layer that allows for running full X11-only desktop environments using Wayland. It is essentially an X11 server backed by Wayland, leveraging wlroots and Xwayland. Our goal is for Wayback to eventually be a completely drop-in replacement to the Xorg binary, thus reducing maintenance burden for distro maintainers.
Ever since Wayback was announced on June 28, we have been making lots of progress to get it as stable and functional as possible, and while this is a preview release it is already daily-driveable by users with simple requirements, as long as they don't mind bugs.
The release is considered alpha-quality and is missing a number of features, including multi-monitor support and DPMS, but adventurous users can find the code here.
Posted Jul 24, 2025 15:12 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (25 responses)
Posted Jul 24, 2025 15:38 UTC (Thu)
by callegar (guest, #16148)
[Link] (22 responses)
Cannot avoid noticing that lately network transparency is finally almost there even on wayland, by using waypipe + xwayland-satellite. The former is for the wayland applications, the second to let applications that would normally rely on xwayland to go through waypipe too. Incidentally, I would really like to see waypipe integrate xwayland-satellite support.
On the other hand, your question prompts me to ask another one. For X11 applications over the network, many people prefer xpra to the native X11 protocol, since xpra is way more efficient and resilient to bad network. However, xpra needs xdummy and xdummy is xorg. So if xorg goes away, substituted by wayback, is there going to be something to cater for xpra and other users of xdummy?
Posted Jul 24, 2025 16:36 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Jul 24, 2025 17:06 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link]
Posted Jul 24, 2025 17:55 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link] (18 responses)
> xdummy is xorg. So if xorg goes away
Xwayland is just Xorg. Xwayland is Xorg with the device dependent part designed to talk to Wayland instead of hardware. So, Xorg is not really going way as long as Xwayland exists.
You can view Xwayland as the evolution of how Xorg talks to hardware
- old Xorg
- modern Xorg
- Xwayland (still Xorg really)
So, as they say on their Freedesktop home page, Wayback is "Just enough Wayland to make Xwayland work".
If you have a full Wayland environment, you use Xwayland to run X11 applications on Wayland (usually rootless--in their own window). If you use Wayback, you are running Xwayland as a traditional X server.
Posted Jul 24, 2025 18:42 UTC (Thu)
by pm215 (subscriber, #98099)
[Link] (2 responses)
Posted Jul 24, 2025 18:50 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Wayback is an implementation of the Wayland protocol that uses Linux KMS to drive the hardware, and provides enough support for XWayland to translate all interesting X11 protocol to Wayland protocol. XWayland, in turn, doesn't know how to drive hardware directly, but it does know how to handle the bit of Wayland protocol that lets you use a GPU (via Linux DRM) to render to a GPU-side buffer, and share that buffer with the compositor.
So, Wayback drives the scanout hardware and the input devices, in terms of Wayland protocol. XWayland then translates between this simpler protocol, and X11 protocol, using Wayland protocol to request GPU access from Wayback, and driving the GPU directly.
Posted Jul 24, 2025 20:06 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link]
> if Xwayland is X11 on the top and talks to Wayland to access the hardware, what is Wayback doing?
Ok. First X11. On X, you have a display server that displays the window contents of X11 applications. One of those applications will act as the "window manager". I assume we all know what an X11 window manager does. The important thing is that, on an X server, the window manager is just one of the applications. You can run an X server without a window manager if you want. All our X11 window managers run on the same X server (typically Xorg). The Xorg server talks to the hardware and also to the applications (via the X11 protocol).
Now to Wayland. Wayland is a protocol just like X11 is a protocol. And, like with X11, it is what applications use to communicate with the display server. The difference is that, in Wayland, there is not one display server like with Xorg. There is no universal Wayland server. Instead, we have what are called "compositors". A compositor is like a display server and window manager all wrapped up in one. When we say that we are running "on Wayland" we really mean that we are running on a Wayland compositor that uses the Wayland protocol. This is why people constantly say "Wayland is just a protocol" because there is no "Wayland" to run on. There are only Wayland compositors that use the Wayland protocol. It is the Wayland compositors that talk to the hardware. Examples are hyprland, niri, kwin (KDE), and mutter (GNOME).
So, the answer to your question is that Wayback is a Wayland compositor and Xwayland is a Wayland application. Wayback is a super-specialized Wayland compositor designed only to host Xwayland and not other Wayland applications. The only "Wayland" app running on Wayback will be Xwayland in rootful mode which itself provides an X server that X11 applications can run on top of.
It is Hardware > Wayback (Wayland compositor) > Xwayland > X11 applications
You can actually use any Wayland compositor to run Xwayland as above. The difference is that most Wayland compositors are designed to run multiple Wayland applications and to manage those applications as individual windows. As such, Xwayland is usually used in rootless mode where every X11 app gets its own Wayland window. Wayback is a Wayland compositor designed to run only Xwayland in kiosk mode.
Ok, the above needs a tweak. Wayback is more than just a compositor. Replace everything I said above with wayback-compositor (specifically the compositor) which is just one component of the project. There are also other parts to Wackback. For example, wayback-session sets up things like environment variables and tries to execute .xinitrc amongst other things. It runs wayback-compositor. This makes the Wayback / Xwayland combination function more like a true drop-in replacement for Xorg.
Posted Jul 24, 2025 19:05 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Jul 24, 2025 21:33 UTC (Thu)
by callegar (guest, #16148)
[Link] (3 responses)
Will wayback be capable of running as a "virtual" X11 server (i.e. a screenless one)? In addition to replacing the "legacy" xorg server will it also provide the same functionalities as xdummy, so that xpra can use it?
Posted Jul 24, 2025 21:38 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Jul 26, 2025 23:05 UTC (Sat)
by callegar (guest, #16148)
[Link] (1 responses)
Posted Jul 25, 2025 14:23 UTC (Fri)
by daenzer (subscriber, #7050)
[Link] (9 responses)
> Xwayland is Xorg with the device dependent part designed to talk to Wayland instead of hardware. So, Xorg is not really going way as long as Xwayland exists.
That's not quite accurate.
Xwayland and Xorg are two out of several DDXen (for Device-Dependent X) in the xserver tree. While they share most of the code (so-called DIX for Device-Independent X, making up ~93% of Xwayland and ~69% of Xorg), the remaining DDX code is completely specific to each DDX, neither of them depends on the other.
Posted Jul 25, 2025 20:35 UTC (Fri)
by jmalcolm (subscriber, #8876)
[Link] (8 responses)
Thank you for the correction and especially for the percentages.
My response was targeted at @callegar and their worry about what will happen to xdummy after "Xorg goes away".
What I was trying to convey is how much of the code is shared between Xorg and Xwayland. I agree that "Xorg is not really going way as long as Xwayland exists" is an overstatement. That said, I think the fear that Xorg is "going away" is overstated as well.
Xorg will be maintained by Red Hat as part of Red Hat 9 until the mid-2030s. The two-thirds of the code that Xorg shares with Xwayland will be maintained for a couple of decades and perhaps longer. In addition, the Xorg DDX leverages KMS, DRM, and libinput which are all essential components in Wayland as well. Xorg will not disappear or even break tomorrow (even if we all stop using it). At least, that is my take.
Posted Jul 26, 2025 0:48 UTC (Sat)
by himi (subscriber, #340)
[Link] (7 responses)
I think that's stretching the definition of "maintenance" a little - with no active upstream for Xorg, Red Hat will be restricted to doing limited bug fixing and potentially security fixes; anything more than that would demand they invest in developers capable of doing more significant work on what is a massively painful codebase. Maybe that would be easier than it seems to me, at least in the short to medium term, given the large overlap between Xwayland and Xorg, but by the time RHEL9 is EoL it's going to be a nightmare, and of limited value given by then they'll be supporting several newer releases that depend on whatever the state of Wayland is at the time they pin the major system components for the release.
Following the active stream of development on major system components is the only viable option in the long term for a distro, even one that can throw a *lot* of resources at the problem. Slapping an "Enterprise Support" label on a moribund codebase can't change the fact that the project is effectively dead (or heading that way).
Posted Jul 26, 2025 17:25 UTC (Sat)
by jmalcolm (subscriber, #8876)
[Link] (6 responses)
> Red Hat will be restricted to doing limited bug fixing and potentially security fixes
Well, Red Hat has been the prime maintainer of Xorg for years now and that is essentially all they have been doing already. With the exception of one developer, Xwayland was the only part seeing any development. And 95% of Xwayland is in Xorg too.
The one developer I mention above has forked the project and is no longer part of Xorg. What I was addressing is the idea that Xorg will "go away" or "break". I do not think that it will as long as Red Hat is supporting it. I agree though that it will not evolve either.
I keep hearing about how adding "new hardware" will be a problem but even recent hardware, like Intel Arc for example, has not required any real changes to Xorg. The Xorg modesetting driver offloads to the kernel (KMS and DRM). Xorg uses libinput and udev (same as Wayland) and the rest is userland (Mesa) which is also common between Xorg and Wayland. As long as you are not looking for new functionality, new hardware that uses KMS and DRM will probably work just fine with Wayland. Xorg and Wayland essentially use the same drivers at this point.
Anyway, we agree that Xorg is dead. There are no new features coming. The biggest problem is that it will not run Wayland-only apps and there will be many of those in the coming years. But I expect Xorg to keep working as it does not for quite a while (unless Linux changes the KMS and DRM subsystems I suppose). Does that mean distros will package it? Maybe not.
Posted Jul 26, 2025 20:16 UTC (Sat)
by intelfx (subscriber, #130118)
[Link]
The problem is not "new hardware" which is essentially a straightforward evolution of existing hardware. The problem is fundamentally new hardware[1], [2].
[1]: https://lobste.rs/c/sjm2l4
Posted Jul 28, 2025 15:22 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (4 responses)
Right now, there's no hardware you're likely to want to run X11 on that assumes that you do the flip dance; but with zero minimum rate VRR becoming more of a thing, and with compressed scan out becoming more popular, there's a risk that future hardware won't let you write to the scanout buffer while it's being scanned out, and won't start sending the scanout buffers to the display until you tell it that you're done flipping buffers.
At that point, Xorg has a serious problem; the hardware assumes (because everybody but Xorg works this way) that once you've handed a scanout buffer to it, nothing will read or write that buffer (so it can handle compression, delta updates etc ignoring future writes to the buffer), and that you'll tell it when there's a complete set of buffers to send. But Xorg assumes the opposite on both of those - and thus you have an "exciting" mismatch between what hardware wants, and what Xorg can supply.
One answer is to not buy newer hardware, missing out on higher quality displays. But that's going to end up being unpopular. Another is to make the same changes to Xorg as Xwayland uses to flip buffers for Wayland purposes; but that needs someone who cares about Xorg working on newer hardware to make the changes, and fix all the assumptions that get broken by this change.
And, of course, there's the risk that a future C compiler (for current CPUs or new ones) simply fails to compile Xorg code with the intended meaning; the code's history predates ANSI C89, so there's a good chance that there are assumptions buried in there that have held true for GCC/AMD64 to date, but that aren't guaranteed by POSIX or ISO, and that will not hold true in future. RHEL doesn't really care about this problem (unless it's in code shared with other servers in the project), because RHEL9 has already chosen compiler versions, and simply won't update the compiler if it'll break things.
Posted Jul 28, 2025 20:18 UTC (Mon)
by jmalcolm (subscriber, #8876)
[Link] (3 responses)
> there's a risk that future hardware won't let you write to the scanout buffer while it's being scanned out, and won't start sending the scanout buffers to the display until you tell it that you're done flipping buffers
Thank you so much for this!
> make the same changes to Xorg as Xwayland uses to flip buffers for Wayland purposes
I am a little hazy on what this means. 90% or more of Xwayland code is shared with Xorg and they are maintained together. Most changes to Xwayland are changes to Xorg too, unless they are in the small amount of code that talks to Wayland. Perhaps you are saying that the buffer flip stuff is in that code.
A lot of the Xorg DDX code is video drivers that few people use. Most hardware is supported by KMS and DRM even on Xorg via the modesetting driver. By the time you include KMS, DRM, udev, libinput, Mesa, and Xwayland, there is more code shared by Xorg and Wayback than there is different. Of course, it is still the weakest link that breaks the chain.
Your explanation really helped explain how Xorg could stop working on new hardware, even if it is still working overall.
> there's the risk that a future C compiler (for current CPUs or new ones) simply fails to compile Xorg code
The risk of not compiling feels overblown. If this does happen, I expect it will be in an old xf86 driver that has few users and that can be abandoned without much risk to the overall project. The Xorg DDX that people actually use is modesetting, which first appeared in 2008 and was updated to DRM 3.2 around 2020. How crusty can it be? libinput support is from 2014. And the entire DIX (non-DDX) layer is actively maintained as Xwayland. Even beyond RHEL9 and Ubuntu LTS, many continue to rely on Xorg (like the BSD universe). It is unlikely that a compiler update is going to break Xorg--at least not for very long.
Can you build Xorg with gnu99 or even C11 as a compiler flag today? I will have to try it. If so, it will be a long time indeed before Open Source compilers cannot build it.
It feels strange for me to be on this side of the argument. On other forums, I am considered Wayland shill. I do think that perhaps 50% of Linux desktops are Wayland already that this will be 90% or more in 3 years. I believe that even using Xwayland will be niche in 5 years as very few applications that normal people use will require X11. And there will be scores of Wayland only apps by 2030. So, I do not think that Wayback will still be viable as a daily driver by then. People will cling to their favourite X window managers forever but I cannot see them living without all these popular apps. I do not expect Xorg to break but that does not mean that I think people should use it, or even that they will.
Posted Jul 28, 2025 20:38 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
And I'm not talking about drivers at all - forget libinput, forget modesetting, forget udev, forget Xwayland etc, I'm just talking about the DDX code in the Xorg xserver itself. That stuff has a long history and while it may be possible to compile it with -std=gnu99 or -std=c11, that's not the risk I'm talking about; instead, I'm talking about the risk that it contains some form of UB that has so far been benign, but with a future compiler change results in the whole codebase being misunderstood by a future compiler.
If someone was actively maintaining it, it'd not be a huge risk - but the risk I see is that compilers are in a position to say "not our problem, that's actually UB, and only a tiny number of people still use it anyway", while no-one is maintaining the code, thus no-one is in a position to rewrite the problematic code into a form without UB. Even worse if the UB is in a bit that's only used on Linux (there are conditionally included bits), so the BSD folk won't save you.
Posted Jul 29, 2025 7:15 UTC (Tue)
by daenzer (subscriber, #7050)
[Link]
Posted Jul 29, 2025 9:55 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
At this point, all the remaining users of Xorg notice that something's wrong - users of Xvfb, Xwayland and other X11 servers built from the xserver code tree see no problem, because it's Xorg-specific assumptions that's broken. But there's been quite a few changes, and none of them are obviously the cause. Someone ends up having to volunteer to bisect the code base, and finds the problem change - but you can't "just revert" it, because too many other changes are stacked on top - and in any case, it's not obvious why this change breaks Xorg, because it seems unconnected. Instead, someone has to work out what the assumption was that got broken, and fix forward.
Posted Jul 24, 2025 17:05 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link]
Almost everything Wayback does is actually provided by Xwayland which is really just Xorg with the DDX (Device Dependent X) layer replaced by Wayland. Wayback is a super stripped down Wayland compositor that provides just enough to allow Xwayland to run.
So, while it is true that you are technically running "on Wayland" since the compositor and Xwayland use the Wayland protocol to talk to each other, you are really just running an X11 server. You cannot run Wayland applications on Wayback.
Since both Wayland and Xorg both use the KMS and DRM drivers and libinput on Linux, Wayback and Xorg are pretty similar really.
For a distro, which already has to ship all the Wayland stuff plus Xwayland anyway, being able to provide an X11 server with the addition of a tiny compositor is a big win (less than 100k I believe).
As an aside, you can have "network transparency" with Wayland. Checkout Waypipe and Wayland Transpositor (wprs).
Posted Jul 25, 2025 14:11 UTC (Fri)
by daenzer (subscriber, #7050)
[Link]
Posted Jul 24, 2025 15:26 UTC (Thu)
by callegar (guest, #16148)
[Link] (7 responses)
Posted Jul 24, 2025 15:29 UTC (Thu)
by jzb (editor, #7867)
[Link]
It is about running desktop environments that were not ported to wayland, right? Yes. Their homepage says, "Wayback is essentially a stub Wayland compositor which sits in front of Xwayland. It implements only what is needed for a rootful Xwayland to run, essentially acting as a full X server backed by Wayland. This allows using X11-only desktop environments and window managers under a Wayland base."
Posted Jul 24, 2025 17:23 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link] (5 responses)
However, while you are running "on Wayland", you are not "in Wayland". This is just an alternative way of running an X11 server and will not run anything that does not work on Xorg. In particular, Wayback cannot run Wayland applications.
From a software preservation point of view, this will allow you to keep running Open Look, CDE, FVWM, and Trinity for a long time. This is awesome. However, they are going to become less and less useful as daily driver desktops as more and more applications become Wayland only.
This is happening already. The first time I tried Wayback, I tested FVWM and the first application I tried to launch was foot because it is a small and fast terminal. When it would not launch I thought it was a Wayback bug until I realized that foot is a Wayland only application. I launched konsole and it worked fine. Not a big deal for now but I am sure we will see some Wayland only toolkits used to write apps people want to use. When GTK5 launches in 2027 or so, there will be many popular applications that will not run on X11 anymore.
Posted Jul 24, 2025 18:35 UTC (Thu)
by eean (subscriber, #50420)
[Link]
I suspect Xwayland will live for a long time for old games and the like.
Posted Jul 26, 2025 7:19 UTC (Sat)
by linuxrocks123 (subscriber, #34648)
[Link]
For Wayland-only applications, you can use 12to11. I have no intention of ever migrating to Wayland, and 12to11 is my planned solution for dealing with any future applications that do not have X11 support.
Posted Jul 31, 2025 8:45 UTC (Thu)
by anton (subscriber, #25547)
[Link] (2 responses)
If Wayback does not run Wayland applications, that's unlikely to be a problem, because I am not using any such applications now, and if they don't run on my system, it's unlikely that I will get used to them. It would have to be a killer application to make me want to use it.
Well, actually it's most likely that it's a web browser; their maintainers always seem to embrace newfangled stuff and have little considerations for supporting the breadth of existing users; e.g., in earlier times browsers could display on a remote X display; that became impractically slow at some point.
Posted Jul 31, 2025 16:39 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Aug 26, 2025 13:05 UTC (Tue)
by daenzer (subscriber, #7050)
[Link]
That's mixing up rootless vs rootful Xwayland.
Rootless Xwayland is used for seamless integration of X client windows in a Wayland session, via one Wayland surface per top-level X window. In this case, Xwayland is started by the Wayland compositor, and the latter has to act as the X window manager (XWM). Running another XWM isn't possible in this case.
Wayback OTOH uses rootful Xwayland, which uses a single Wayland surface for the X root window and otherwise works mostly like any other X server. Any XWM can be used in this case.
> in earlier times browsers could display on a remote X display; that became impractically slow at some point.
FWIW, Firefox runs well (including HW acceleration using the GPU on the remote machine) as a native Wayland client via Waypipe, which is conceptually similar to SSH X forwarding.
Posted Jul 24, 2025 18:24 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (27 responses)
Seriously: What the heck is the advantage of Wayback? As opposed to, say, starting a "normal" wlroots-ish Wayland compositor like Sway, turning off all its mouse and keyboard shortcuts, and opening a fullscreen Xwayland root window?
The end result should be exactly the same, except that (a) this way you can still run wayland-only programs and (b) nobody needs to spend time and effort fixing the holes and bugs that Wayback comes with.
Posted Jul 24, 2025 18:43 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Wayback changes that - you have an X11 server with no second tier of window management, just pure X11 protocol, and it's implemented by having the hardware driven by Wayback, while XWayland provides X11 protocol.
In turn, this enables the removal of the DDX layer, plus all code that only exists to handle hardware; you keep Xwayland, Xnest, Xephyr, Xvfb, Xquartz and Xwin (subject to maintenance on all of those), but drop Xorg and all the code relating to direct hardware access.
Posted Jul 24, 2025 20:23 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link] (23 responses)
> 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]
Posted Jul 24, 2025 23:18 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
For this, they need to support some stuff like scripts for starting up the particular thing that users always used to get, and weird stuff like making xrandr under Xwayland get Wayback to do the applicable thing with additional monitors (which is presumably not a priority for Cage).
Posted Jul 25, 2025 14:41 UTC (Fri)
by daenzer (subscriber, #7050)
[Link]
While that's technically true, it wouldn't be great user experience. Windows of Wayland & X clients wouldn't be properly mixed, the former would either be in front of all X client windows or not visible at all.
> (b) nobody needs to spend time and effort fixing the holes and bugs that Wayback comes with.
It's little code on top of wlroots.
Posted Jul 25, 2025 1:29 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
https://arcan-fe.com/2024/12/25/arcan-0-7-the-all-tomato/
network transparency ?
This is required for a full Xorg replacement.
network transparency ?
network transparency ?
network transparency ?
network transparency ?
-- talked to all the hardware via its own drivers and configured video modes itself in userspace
-- relies on the Linux kernel to set video modes (KMS) and to provide video drivers (DRM)
-- relies on the libinput library to talk to keyboards, mice, tablets, etc.
-- talks only to Wayland - relies on Wayland to talk to hardware for both input and output
-- Wayland talks to KMS, DRM, and libinput
network transparency ?
Wayland is a protocol for sending data between a combined compositor+WM on one side, and client applications on the other. It doesn't even require that hardware exists.
network transparency ?
network transparency ?
network transparency ?
network transparency ?
network transparency ?
Can you better clarify what is `wpra`?
network transparency ?
network transparency ?
network transparency ?
network transparency ?
network transparency ?
network transparency ?
[2]: https://lobste.rs/c/jk95te
The fundamental issue that's likely to bite with future hardware is that Xorg assumes that you can write to the scanout buffer as it's being scanned out; but macOS, Android, Windows, Wayland etc are all designed to write to a second buffer, and "flip" that buffer to scanout when it's ready to go, leaving the scanout buffer unmodified until the hardware says its done with it. Xorg also assumes that scanout is constantly taking place on its own schedule, and that it doesn't need to tell the hardware to send the scanout buffer to the display.
network transparency ?
network transparency ?
The buffer flip stuff in Xwayland is in the Wayland protocol code; it's not shared with Xorg at all.
network transparency ?
network transparency ?
Thinking about it overnight, the most likely risk to Xorg is that a change in the DIX layers breaks an assumption that Xorg depends upon. Because no-one's actively developing Xorg, nobody notices at the time, but other changes to the xserver code base stack up on top of it. Eventually, one of the changes stacked up that depends on the change that breaks the assumption is a security-relevant fix, and distros update their Xorg packages with all the changes to xserver since their last Xorg package release.
Most likely risk to Xorg
network transparency ?64
network transparency ?
Not about applications, but about desktop environments, right?
Not about applications, but about desktop environments, right?
Not about applications, but about desktop environments, right?
Not about applications, but about desktop environments, right?
Not about applications, but about desktop environments, right?
Not about applications, but about desktop environments, right?
This is a way of running window managers and desktop environments not available on Wayland.
That's great! So Wayback will allow me to continue to use twm, which I have used since IIRC 1992; just a few weeks ago I read that Xwayland allows me to use X applications, but not window managers. Good to see that weakness addressed.
Not about applications, but about desktop environments, right?
Not about applications, but about desktop environments, right?
Owch
The DDX layer in the X.org xserver is basically unmaintained at this point; it's only being kept around because if you really need a X11 server to run your application stack, and you don't want it to run under a second tier of window management (as provided by Sway or similar), you have no other choices.
Owch
Owch
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
Owch
Owch
Alternatives to Wayback