Red Hat has formally confirmed what many were thinking: Red Hat Enterprise Linux 10 will be doing away with X.Org Server support aside from XWayland.
For those making use of the Red Hat Enterprise Linux 10 in a desktop setting, RHEL10 due for release in H1’2025 will be Wayland-focused. X11 client support will only come via XWayland.
This does also further solidify the X.Org Server in effect being dead upstream. Red Hat engineers were typically the ones managing new X.Org Server releases as well as carrying on with various bits of development.
So X.Org fully dies on the 31st May 2035 with the end of Extended Life Cycle Support for RHEL 9. We have XOrg’s death day. Even if it will likely be on it’s death bed taking its final breaths for years before that.
I thought this as well but the more I think about it, the less true this seems. From an engineering point of view, it could last longer.
Xwayland is really just Xorg and Xwayland continues to be supported in RHEL10 and beyond.
Xorg and Wayland compositors have grown together in some ways. Both now use libinput, libdrm, and KMS for example. Those are not going away.
Xwayland is really just Xorg adapted to talk to Wayland instead of KMS and libinput. It is mostly the same code. So, Xorg will continue to benefit from the care and attention that Xwayland gets. Perhaps there may not be many new features but the code is not going to bit rot and security will continue to be addressed. While Xwayland does not use libinput or KMS, the Wayland compositor itself will, so those pieces are also going to be maintained including new features and new hardware support. Mesa is a common component as well.
So, while Red Hat may stop coordinating releases of Xorg at some point, a surprising amount of the code will still be actively maintained and current. It may not take a lot of work for somebody else to take over and bundle it up as a release.
What will probably kill Xorg is lack of demand.
Despite the anti-Wayland chatter, the migration to Wayland looks like it will gain substantial momentum this year and next and not only on Linux. Three to five years from now, the number of people that still care about Xorg ( as the primary display server - not as Xwayland ) may be very small indeed. Obviously it will be running on older systems for a long, long time but, ten years from now, installing Xorg on a new system is likely to be very rare ( like CP/M now rare ).
Red Hat may end up being one of the very last players that cares about Xorg after 2030. My guess is that most of the current never-Wayland crowd will have moved to it long before then.
Yeah, thank you for doing such a good explanation of it. I completely agree. Truth be told, the features I missed with Qtile on Wayland (some bugs that took a while to iron out, and are only fixed in qtile-git, as well as rounded corners, which are a work-in-progress, leaving me with only 1 issue with Qtile, that being how difficult Qtile Wayland is to install and set up, if only there was a working guide for doing so via pip, but pywayland and/or pywlroots via pip are usually broken), were all fixed by Hyprland, so I’m on Hyprland full time now, and I love it! There is only one minor issue I have (drop downs from Waybar’s systray are kinda broken on Hyprland, rendering weirdly, with strange black gaps between sections and rendering under, rather than over, windows).
This actually makes it sound like Xorg will be supported longer than I thought.
I understood RHEL9 to already be Wayland based and so I was expecting the clock to runout on Xorg when RHEL8 went off support. RHEL9 does default to Wayland but it sounds like Xorg remained a fully supported option for those that wanted it. The move to Wayland only being proposed for RHEL10 did not happen on RHEL9.
RHEL8 goes off support in 2029 but RHEL9 is supported until 2032. The implications of this article are that Red Hat will not put much energy into Xorg after 2025 ( RHEL10 ) but they will still have to support their customers. This at least means security fixes but it likely means continued viability of modern hardware to a certain extent as well.
Regardless, this also highlights one of the “hidden”‘contributions of Red Hat and how much the entire ecosystem relies on them. This can be seen as good or bad but I wish the public debate involving them would at least accurately reflect it.
And even beyond that, because any distro that ships Wayland by default does so because it has XWayland as a backup, which is essentially running an X server inside Wayland.
Agreed ( on the code ). Wayland and Xorg also share libinput, libdrm, KMS, and Mesa.
The biggest difference is that Red Hat will stop bundling this stuff up together, testing it, and created releases. Most of the actual code will still be maintained though.
Xwayland is likely to be with us a very long time. I do not see Motif adding Wayland support anytime soon for example. How long for GNUstep to hop on board?
Most interesting development. This is obviously still into the future but I also always had the impression that Redhat did a lot of work on the XOrg server. With this I think it’s actually dead once they no longer support RHEL 9 and older.
I won’t miss it, granted it’s not a bad implementation, but the design is showing its age. Apart from Wayland that I use, I’m also looking at Arcan’s progress from time to time. Obviously rather niche at the moment but projects like these make the ecosystem interesting.
This honestly still feels premature for a server based OS. I rely on x forwarding and an rdp server for some tasks, and as far as I know Wayland still doesn’t really have support for either of those.
People keep saying this, but X forwarding seems to work just fine with XWayland. I just tried a handfull of X programs between my machines, and neither are running X11. I don’t use it everyday to know the gotchas, but there you go. Programs that use shared memory pixel buffers (everything that isn’t xeyes realistically) even run better than I remember now that I have gigabit. >_< It’s still a way worse experience than VNC or RDP though.
Waypipe addresses forwarding. The major Wayland compositors support either RDP or VNC already I believe.
Gotcha on the forwarding, my issue with rdp forwarding is I want a server like xrdp, so users don’t need to be logged in locally, which I haven’t seen googling yet.
I assume you’re talking about X over SSH? That’s possible with Wayland via Waypipe. Also I’m not sure why RDP would require X, just a compositor being able to forward the video over network (which is perfectly possible with Wayland) and accepting inputs over network as well, which to my knowledge isn’t part of Wayland. Quick check says Gnome already offers RDP and that’s Red Hat’s DE.
Currently Gnome will only allow you to connect to a logged in session. It is more like screen sharing than RDP usually is.
I think it’s actually dead once they no longer support RHEL 9 and older.
That would be 2032.
Wayland will reach feature parity by the right? … Right?
deleted by creator
For many uses, Wayland has feature parity now or is even the superior option. That is how it can be the default on so many systems ( including RHEL9 as per the article ).
Compositors that do not provide the features that uses want will fail to compete ( what you mean by become useless I assume ).
That said, different users will want different things and, unlike X, Wayland allows competing compositors to address different communities. Some compositors will lack features some users want while offering features that other users need. A composite targeting embedded use cases may not need multi-monitor or fractional scaling features for example. A security focussed option may think that global hot-keys and external lock-screens are anti-features. I think the Wayland world could be quite interesting.
X11 is also just a protocol, and will live on with or without Xorg.
Right so I guess I should have over specified that I hope ALL the other bits that actually make it function the same will also catch up and for example something as basic as forwarding GUI programs will simply work without jumping through a bunch of tedious flaming hoops with pitfalls on either side. It doesn’t really matter to me that Wayland has decided it’s somebody else problem.
“Forwarding GUI programs” already works. Check out Waypipe.
Its pretty close and is so much better in terms of stability and reliability
This is the best summary I could come up with:
For those making use of the Red Hat Enterprise Linux 10 in a desktop setting, RHEL10 due for release in H1’2025 will be Wayland-focused.
Red Hat’s Carlos Soriano Sanchez confirmed on the Red Hat blog: "The result of this evaluation is that, while there are still some gaps and applications that need some level of adaptation, we believe the Wayland infrastructure and ecosystem are in good shape, and that we’re on a good path for the identified blockers to be resolved by the time RHEL 10 is out, planned to be released on the first half of 2025.
Xwayland should be able to handle most X11 clients that won’t immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9 for its full life cycle while resolving the specifics needed for transitioning to a Wayland ecosystem.
This decision will allow us to focus our efforts starting from RHEL 10 solely on a modern stack and ecosystem.
We are confident that Wayland will provide a solid platform and we’re excited to work with the community and all of our partners and customers on building the future for Linux."
Red Hat engineers were typically the ones managing new X.Org Server releases as well as carrying on with various bits of development.
The original article contains 450 words, the summary contains 216 words. Saved 52%. I’m a bot and I’m open source!
Makes sense
