Wayland is just a protocol. The WMs, compositors and applications need to implement the features the X server used to provide.
Those that don’t will become useless when X is gone.
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.
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.
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.
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?
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.
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.
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.
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.
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.
I’ve been using PipeWire this year on my Void Linux laptop & desktop. It’s been mostly OK but has a few problems. For years I have been using plain ALSA (with no custom configuration) because pulseaudio causes me regular issues across multiple machines (mostly silently failing).
Pros:
I don’t have to use Chromium for my mic to work on online video conf (WTF Firefox)
“EasyEffects” lets me quickly fix crappy youtube audio (bad gain normalisation, way too much sibilance) with a minimum of effort.
Cons:
Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
First time setup is complicated, involving environment variables, dbus user session buses and multiple daemons (running just pipewire isn’t enough). Why can’t it handle this all itself? Surely it should notice if these things are missing and just fix it itself? Compare this to straight ALSA where you (1) do nothing and then (2) everything works (except Firefox mic support)
I can’t have multiple audio outputs all unmuted at the same time. Eg my headphone output and my rear speaker output. If I override this (using alsamixer) then it gets forgotten next boot anyway, it seems to be out of scope of PipeWire’s understanding.
Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
Well, how much lennart is in this thing? Not only can that predict how well it’s going to work, but also how soon it’ll be fixed, how responsive the ‘team’ will be to bug reports, how compatible it’ll be with other system components AND whether ‘compatibility’ will be achieved before the entire OS has been systematically imported into (and badly replicated by) the project.
If you check SystemD, its a HUGE step up, which is why everyone is using it now (whereas, the old scripts had race conditions, were a pain to write and other issues). Anyone who has written both can tell you how much better things are now…
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it’s more likely a bug in the drivers… It might not be obvious on ALSA directly, but that doesn’t mean an issue doesn’t exist there…
And honestly, the situation before PulseAudio was awful. Audio not working was a common issue, and low latency audio was the least of anyone’s problems. Whereas, these days, because of Pulseaudio, even gaming is a thing now (back then, I even saw issues on tuxracer, and Unreal tournament back in the days).
In regards to setup, most distributions will handle that anyway I’m guessing. So not sure why the configuration process should matter unless you’re in Arch or Slackware? As long as the distribution handles it, it shouldn’t matter. It’d really a non-issue honestly.
I do a lot of middleware development and we’re regularly blamed by users for bugs/problems upstream too (which is why we’ve now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren’t related to us). In practice, very few people have issues with Pulseaudio (I haven’t seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
If you check SystemD, its a HUGE step up, which is why everyone is using it now
I think that’s a “winners write history” situation. There were other options at the time that might have been better choices. Everyone uses it now because of Redhat and Debian being upstream to most users, desktop and corporate. I was not surprised by Redhat adopting it (it’s their own product) but Debian was quite the shock.
Yes systemd is definitely a step up from traditional initscripts (oh god). In terms of simplicity, reliability and ease of configuration however it’s a step below other options (like runit). I don’t have distro management experience but, given the problems I’ve encountered with different init systems over the years, I suspect there would be less of a maintenance burden with the other options.
I’m very curious about the downvotes to this one. May I ask people’s thoughts? Perhaps I’m too vague? I can put a bigger story about my experiences with various init systems in production & research if people are interested.
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it’s more likely a bug in the drivers… It might not be obvious on ALSA directly, but that doesn’t mean an issue doesn’t exist there…
I probably made the overlap unclear, sorry:
Pipewire issues: My 2023 desktop and 2016 laptop, very different hardware.
Pulseaudio issues: All of my pre-2023 desktops and several family laptops
I do a lot of middleware development and we’re regularly blamed by users for bugs/problems upstream too (which is why we’ve now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren’t related to us).
Eep, that’s annoying. You also probably don’t have direct interaction with the users most of the time (they’re not your customer) which makes this worse, people in a vacuum follow each other’s stories.
In practice, very few people have issues with Pulseaudio (I haven’t seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
There might be a bias here because these problems are not persistent, ie a reboot fixes them.
In regards to setup, most distributions will handle that anyway I’m guessing. So not sure why the configuration process should matter unless you’re in Arch or Slackware? As long as the distribution handles it, it shouldn’t matter. It’d really a non-issue honestly.
That’s potentially more things different distros can do differently and more issues your middleware will start getting blamed for.
Yes it’s not a problem for user-friendly distros, but why does the user friendliness problem exist anywhere anyway? It’s better to fix problems upstream, not downstream.
on discord on linux you can’t screenshare with desktop audio, I think this might be already fixed in newer electron versions (but discord is closed source and has not updated their electron in a long time)
As a workaround, you could use OBS and use OBS’s virtual camera so Discord is streaming what it thinks is a camera, and set up whatever you want to share on your desktop through OBS.
I’m assuming this is a “dedicated app” (i.e. apt install discord). I was capable of streaming the video, but sound was a different beast. Audio streaming on discord was a no go. I was finally able to do it with pipewire and using discord-screenaudio
I have discord installed from the flatpak. Screen sharing works but it doesn’t share audio from the applications. Discord-screenaudio and web browser discord have been suggested to me but they don’t work with unfocused push to talk. I’ve also tried xwaylandvideobridge but that didn’t stream the audio either.
In F/OSS, it is not unusual for software to stay below 1.0 version for a long time yet still get a lot of use. Just look at how long OpenSSL, for example, was at 0.9.something, while already being of crucial importance to a lot of internet infrastructure.
The reasons for this are varied, but the most important is probably simply that free software developers don’t feel the pressure to call a product 1.0 when they don’t believe it is ready to be called that.
Pipewire makes me feel like I’m a bit stupid. I keep reading about it, I read the introduction and FAQ on their website, yet I still couldn’t tell you what that thing even does. All I know is it’s a slightly less buggy drop-in replacement for pulseaudio, and pulseaudio is something I use because Firefox forces me to. (I would still be on plain old ALSA if it weren’t for Firefox.)
Also, it definitely did not “just work” for me out of the box, I had to do quite some digging and some very non-obvious stuff to get it to a) start up and b) let me use my microphone. I still don’t even know what “starting up” really means for pipewire (is there a daemon or something?), the website likes to pretend that isn’t a thing, but without doing some stuff to start it up, audio just won’t work for pulseaudio and pipewire applications…
For a long time, people shat all over pipewire and said it wasn’t viable as a replacement for the existing Linux audio stack, but clearly that hasn’t ended up being the case
When it was brand new there were some edge case bugs that broke on certain workflows and hardware, but that’s pretty much entirely fixed now and I’m guessing for a long time now it’s been more universally stable than pulseaudio was.
Also, some people just pointlessly dislike anything that’s new, or because it breaks their spacebar heating
I was experimenting with the Cadence tools from KXStudio. These are mostly made for JACK, but PipeWire has a JACK interface so it should work. It’s similar to helvum, but with more options.
Not sure right now which one (maybe Carla), but one of these programs also support adding sound effect nodes that have their own GUI! You probably want to use it in multi-client or patchbay mode
My audio set up is using jack on Ubuntu. If I were to start using pipewire, does it replace jack? Or do you use it alongside jack? I use mostly ardour, hydrogen, renoise and bitwig.
qjackctl will actually connect to pipewire, I use its graph window a lot to route audio when the default volume control isn’t enough. But yeah it does (or can) replace jackd.
phoronix.com
Hot