Some interesting Linux industry news for you here, as the long road towards Wayland by default everywhere is taking another big step with Red Hat Enterprise Linux (RHEL) removing the Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases.
From their announcement by developer Carlos Soriano Sanchez posted November 27th:
We want to recognize the significant effort all these organizations and individuals have made, especially the rest of the upstream community, without whom this project would never be so mature. This effort gave us the confidence to first make Wayland default for most use cases in RHEL 8, followed up with the deprecating of Xorg server in RHEL 9, with the intention of its removal in a future release. Earlier this year (2023), as part of our RHEL 10 planning, we made a study to understand Wayland’s status, not only from an infrastructure perspective, but also from an ecosystem perspective. 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.
With this, we’ve decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. 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. It’s important to note that “Xorg Server” and “X11” are not synonymous, X11 is a protocol that will continue to be supported through Xwayland, while the Xorg Server is one of the implementations of the X11 protocol.
Red Hat and their engineers have their fingers in many pies across the Linux space, so this is a pretty big move, and one they say will enable them to "tackle problems such as HDR, increased security, setups with mixed low and high density displays or very high density displays, better GPU/Display hot-plugging, better gestures and scrolling, and so on" — which of course will end up benefiting everyone because that's how open source works.
Have you fully switched over to Wayland yet?
Quoting: RenardDesMersI was shopping for a new monitor for black Friday and was debating with myself about how useful would HDR and Freesync features be since Wayland can't support those yet and I don't really know when they'll get decent support.
Hopefully the wayland folks remember about the gamers when prioritizing the missing features.
Plasma 6 releasing in Feb has planned support for HDR, Valve's gamescope supports HDR on AMD since early this year
Quoting: wvstolzingDennis Ritchie's 'anti-foreword' to that book is hilarious. In fact, I'll just quote the whole thing:The illustrations aren't bad either:
Quoting: RenardDesMersI was shopping for a new monitor for black Friday and was debating with myself about how useful would HDR and Freesync features be since Wayland can't support those yet and I don't really know when they'll get decent support.
Hopefully the wayland folks remember about the gamers when prioritizing the missing features.
KDE Plasma 5.27 has support for Adaptive Sync in the Display options. KDE 6 should also bring in HDR support.
Last edited by t3g on 30 November 2023 at 2:12 am UTC
Since i use MATE as my Desktop Environment, i dont really have a choice currently either, so i dont really pay attention to the hypetrains going on with wayland. Everything i use/need works perfectly on X11 so far so no rush with that.
Will see again in 2 years
i can feel gentoo pushing the agenda every time they don't understand a package who can still be forked and saved
Quoting: Soulprayer[...]That is disheartening to read...
according to PCSX2 developers, Wayland is "super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster" and have disabled it in their distributions.
But:
QuotePCSX2 still supports Wayland. It just prefers the XCB/XWayland platform by default. You can set the I_WANT_A_BROKEN_WAYLAND_UI environment variable and experience the brokenness for yourself on the AppImage builds, or add the wayland socket to the flatpak.
![](https://www.gamingonlinux.com/templates/default/images/emoticons/sad.png)
Quoting: SoulprayerHa, I wonder if anyone who uses Redhat actually uses it with a GUI, or is on a new enough version for them to be using Wayland. I've installed it for testing to make sure some scripting I needed for work would do what I want it to, and am lazy so install the full desktop. They have a funky enough support things that I've been paying the 50 bucks a year for it. Even though they eventually allowed a free Developer version. But it has such a limited amount of packages, I still go back to Debian...Quoting: slaapliedjeI use a Nitrokey. Copy/Paste in it is broken under Wayland.I wonder if Redhat has Nitrokey-Users
Quoting: BlackBloodRumThat's actually my work flow, use the saved nitrokey password to unlock KeePassXC. I think the reason it doesn't work in nitrokey is because it's still using an old version of Qt that hasn't been updated to be Wayland 'aware'. I may see if I can recompile it on my system to see if that fixes it, assuming it'll compile clean with a newer Qt.Quoting: slaapliedjeWayland may not be entirely to blame here.Quoting: SoulprayerI was already unhappy that EndeavourOS is dropping XFCE support.One of the 'fun' little breakages I've found... I use a Nitrokey. Copy/Paste in it is broken under Wayland. The way it works under Xorg, I can right click on the tray icon, select password slot label, and the password is copied into the clipboard...
But i will always love XFCE as my favorite desktop.
according to PCSX2 developers, Wayland is "super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster" and have disabled it in their distributions.
But:
QuotePCSX2 still supports Wayland. It just prefers the XCB/XWayland platform by default. You can set the I_WANT_A_BROKEN_WAYLAND_UI environment variable and experience the brokenness for yourself on the AppImage builds, or add the wayland socket to the flatpak.
Under Wayland, this doesn't work at all, and the only way I can get it to work is to open the full UI, go to the slot where it's saved, click show password, then copy and paste it that way. That goes from 1 click to like 8... all because Wayland hasn't implemented all of the Xorg clipboard tricks.
KeePassXC has similar functionality, where you can select an entry, click copy and then paste it elsewhere. It also prevents it being added to clipboard history, and clears it out of your clipboard after a set time.
It does all this on Wayland just fine. So, perhaps Nitrokey could follow a similar method?
See more from me