network transparency ?
network transparency ?
Posted Jul 25, 2025 20:35 UTC (Fri) by jmalcolm (subscriber, #8876)In reply to: network transparency ? by daenzer
Parent article: Wayback 0.1 released
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.
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