network transparency ?
network transparency ?
Posted Jul 24, 2025 15:12 UTC (Thu) by ballombe (subscriber, #9523)Parent article: Wayback 0.1 released
This is required for a full Xorg replacement.
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]
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 ?