Wayland takes the wheel as Red Hat bids farewell to X.org
- Reference: 1701271691
- News link: https://www.theregister.co.uk/2023/11/29/rhel_10_dropping_x11/
- Source link:
A [1]blog post by Carlos Soriano Sanchez, head of the GPU team on RHEL, spells out news that doesn't come as a big surprise: the next version of Red Hat Enterprise Linux, expected in 2025, will drop X.org and will provide only a Wayland display server. As RHEL only offers GNOME, that means it will offer the Mutter compositor and nothing else.
When RHEL 8 [2]was released in 2019 , Wayland became the default display server, and when [3]RHEL 9 appeared three years later, [4]X.org was officially deprecated . Soriano Sanchez goes on to say:
The transition from the now 30+ year old X Window System to the newer Wayland-based stack has been happening for the past 15 or so years.
We found this statement amusing for two reasons. Firstly, the X window system is much closer to 40 than 30 – we [5]celebrated its 38th birthday in the middle of last year. X tore through its first ten major releases in just a few years. The [6]first version was in 1984, and the 11th – which is why it's called X11 for short – [7]was in 1987 .
Secondly, as we noted when a GNOME developer proposed that [8]Gtk5 drop X11 support , Wayland itself is getting old now. Work on it [9]started in 2008 ; if RHEL 10 does ship in 2025, Wayland will be 17. So at the time when the biggest enterprise Linux goes Wayland-only, that protocol will in the same general ballpark age-wise that X11 was when Kristian Høgsberg started work on its replacement. At that time, X11 had been around for 21 years.
[10]
The Reg FOSS desk remains somewhat skeptical about Wayland, but the critical mass is getting there. KDE 6 [11]will be Wayland-only . As it happens, personally, this vulture isn't a big fan of either GNOME or KDE, so it reassures us that two of the most popular Wayland holdouts are both adjusting their attitudes. Mint is [12]experimenting with support in Cinnamon , and [13]so is the Xfce team .
[14]
[15]
Over on the Arm side of things, the new desktop in [16]Raspberry Pi OS 5 has a sort of grafted-together LXDE and Wayfire, and it works (so long as you're not [17]using a touchscreen anyway). The Asahi team, working on Linux for Apple Silicon, announced six months ago that it was [18]only targeting Wayland .
Some of the big, important apps are getting there too. [19]Firefox 121 just went into beta, and it will default to rendering directly to Wayland instead of via the built-in XWayland server (don't panic: it will still work with X.org if you're not running Wayland). Another problematic app, the OBS Studio screencasting software, got native Wayland support in [20]version 27 . This was a deal-breaker for people doing – well, whatever it is that livestreamers do. Its appeal is likely to remain a mystery to this graybeard, if we're honest.
[21]Microsoft opens sources ThreadX under MIT license
[22]Data-destroying defect found after OpenZFS 2.2.0 release
[23]FFmpeg 6.1 drops a Heaviside dose of codec magic
[24]Revival of Medley/Interlisp: Elegant weapon for a more civilized age sharpened up again
The real significance of this isn't going to be the end user experience. There are still glitches, and some people will have to learn new methods and techniques. When we wrote that Xfce now has the [25]backing of Budgie in its Wayland efforts, the comments contained a whole conversation about piping Wayland desktops over SSH. For now, there are [26]accessibility issues such as with screen magnifier and screen magnifier tools, using VR headsets, and most of all with Nvidia driver support… but they will get ironed out.
The real issue is developer support. Red Hat's vast team of developers is the main force behind a huge amount of work on Linux, from the kernel down. In Red Hat's [27]own terms , it is upstream of almost the whole industry. X.org [28]still often has CVEs and someone has to maintain it, even if it's not getting new features any more. If Red Hat stops all its development efforts on X.org, it's not clear that anyone else will step up and volunteer.
[29]
One of the problems with how Wayland works is that each window manager must implement the profile for itself in its own codebase. Wayland is just a protocol, not a display server. There's no direct one-to-one match between Wayland's components and those of an X11-based system, but the point is that there's no central shared "Wayland server" for desktops to share and work together on. The closest thing to a "display server" in a Wayland system is the compositor, and that's much like the window manager under X11. Almost every desktop environment has its own, and very few share them with other environments.
X11 works on every UNIX™ and Unix-like OS, but [30]proprietary UNIX is dead . OSes such as AIX, Solaris, and HP-UX are in maintenance mode. The last commercial UNIX still selling is Apple's macOS, and it doesn't use X11 at all, although you can still download [31]XQuartz if you need it.
X.org was [32]forked from version 4.4 of [33]XFree86 in 2004 (XFree86 itself got to [34]release 4.8.0 around the time Wayland came into existence). X11 is a very large and complex piece of software, and as one of the primary corporate backers steps back from X.org and redeploys its developers, the future does not look good for this last cooperative implementation.
[35]
If nobody volunteers to take on the considerable workload of maintaining X.org, it will die. The task of getting OpenBSD, FreeBSD, NetBSD, and DragonflyBSD to all cooperate on maintaining a shared implementation, perhaps based on OpenBSD's [36]Xenocara , is probably even more difficult. Xenocara does run on Linux – [37]Hyperbola used it , but that OS is in the process of moving to a BSD base.
Our suggestion for anyone who wants to see the X Window System live is to urgently start working out what must be retained, and revive the [38]X12 initiative . Junk as much legacy as possible. X.org [39]recently dropped byte-swapped clients, so make X12 little-endian only – the [40]endianness holy war is over. Only allow true color, 24-bit (or higher) or nothing. No modern X environment uses a [41]font server , drop them. Some of this was already [42]being discussed [PDF] in 2005. Today, maybe render directly to [43]OpenVG or [44]Vulkan .
This would be an epic task, and without a commercial backer, it doesn't seem likely to happen. Perhaps it really is time to just let X die. If that seems drastic, we advise reading [45]chapter 7 of The Unix Hater's Handbook.
Perhaps the more independent-minded Unixes could do an end run around Wayland and [46]switch to Arcan instead . Or even start over. Don Hopkins, the author of that chapter, suggested to us that a better plan would be to reimplement something akin to [47]NeWS using JavaScript instead of PostScript. That sounds fun. ®
Get our [48]Tech Resources
[1] https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server
[2] https://www.theregister.com/2019/05/07/red_hat_enterprise_linux_8/
[3] https://www.theregister.com/2022/05/10/red_hat_enterprise_linux_9/
[4] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality#deprecated-functionality_graphics-infrastructures
[5] https://www.theregister.com/2022/06/22/the_x_window_system_just/
[6] https://www.talisman.org/x-debut.shtml
[7] https://groups.google.com/g/comp.windows.x/c/NFT3Ax2Io7g/m/Jn37aUty-2QJ?pli=1
[8] https://www.theregister.com/2022/07/05/gtk_5_might_drop_x11/
[9] https://cgit.freedesktop.org/wayland/wayland/commit/?id=97f1ebe8d5c2e166fabf757182c289fed266a45a
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZWduNLQvEtNZ7GcdZQS-DAAAAAE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[11] https://www.theregister.com/2023/07/13/wayland_is_coming/
[12] https://www.theregister.com/2023/10/27/mint_wayland_cinnamon6/
[13] https://www.theregister.com/2023/02/02/system76_cosmic_xfce_updates/
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZWduNLQvEtNZ7GcdZQS-DAAAAAE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZWduNLQvEtNZ7GcdZQS-DAAAAAE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.theregister.com/2023/11/03/raspberry_pi_os_5/
[17] https://github.com/raspberrypi/linux/issues/5682
[18] https://www.theregister.com/2023/05/17/asahi_linux_wayland_only/
[19] https://www.mozilla.org/en-US/firefox/121.0beta/releasenotes/
[20] https://obsproject.com/blog/obs-studio-27-released
[21] https://www.theregister.com/2023/11/28/microsoft_opens_sources_threadx/
[22] https://www.theregister.com/2023/11/27/openzfs_2_2_0_data_corruption/
[23] https://www.theregister.com/2023/11/24/ffmpeg_6_1/
[24] https://www.theregister.com/2023/11/23/medley_interlisp_revival/
[25] https://www.theregister.com/2023/11/20/budgie_switches_wayland_approach/
[26] https://community.learnlinux.tv/t/if-there-is-to-be-the-year-of-linux-desktop-accessibility-must-be-a-priority/1559/5
[27] https://www.redhat.com/en/blog/let-river-flow
[28] https://www.theregister.com/2023/10/09/in_brief_security/
[29] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZWduNLQvEtNZ7GcdZQS-DAAAAAE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[30] https://www.theregister.com/2023/01/17/unix_is_dead/
[31] https://www.xquartz.org/
[32] https://lwn.net/Articles/79302/
[33] https://www.xfree86.org/
[34] https://www.xfree86.org/4.8.0/README.html
[35] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZWduNLQvEtNZ7GcdZQS-DAAAAAE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[36] https://xenocara.org/
[37] https://www.hyperbola.info/news/milky-way-v03-release/
[38] https://www.x.org/wiki/Development/X12/
[39] https://who-t.blogspot.com/2023/01/x-servers-no-longer-allow-byte-swapped.html
[40] https://www.ietf.org/rfc/ien/ien137.txt
[41] https://docs.oracle.com/cd/E19199-01/816-3385/6m9lv5050/index.html
[42] https://www.openbsd.org/papers/eurobsd2005/herrb-hopf.pdf
[43] https://www.khronos.org/openvg/
[44] https://www.vulkan.org/
[45] https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47
[46] https://www.theregister.com/2022/10/25/lashcat9_linux_ui/
[47] https://foldoc.org/Network+extensible+Window+System
[48] https://whitepapers.theregister.com/
Wayland itself is getting old now...
What's the betting that someone starts developing a replacement for Wayland sometime soon?
Re: Wayland itself is getting old now...
So little to show for 17 years' effort. Why are we trusting these losers?
Apparently [1]Weyland doesn't support screensavers .
(elReg writers should ask JWZ for quotes more often; he's got the CV, worked at Mozilla, main dev for XScreenSaver etc. and he always has an opinion that would spice up an otherwise boring article)
[1] https://www.jwz.org/blog/2023/11/the-war-on-screen-savers-continues-apace/
Screensaver
But the Wayland compositor does the screen locker stuff - which is what you really need.
Show some fancy image or animation when it is locked ... who really cares ?
Re: Screensaver
Different people have different requirements, the fact they may be quite niche does not negate this.
It's not inconceivable that you wish a system on lock to :
run one or more programs to achieve desired actions
show something specific (say status), alerts etc. If it's less mission critical, let people run their Johnny Castaway.
Waylan support is coming to the Mate desktop
Which is [1]all that I really care about .
[1] https://mate-desktop.org/blog/2021-08-08-mate-1-26-released/
I wish it wasn't such a mess
Whilst Wayland basically works (for various definition of works) it's very sad that Wayland is so very obviously oriented towards commercial interests and Linux first, and X for all its many many faults generally worked cross platform and had agreed on some functionality that the vast majority of Xorg implementations feature.
This is written on a fanless FreeBSD system with built in basic Intel GPU running Wayland and the labwc compositor. Firefox works fine, as do OpenOffice, WINE, and various Wayland applications for the most part.
There are still many issues, largely down to the 'open' nature of Unix standards, and the Linux first (let's be honest : anything else very grudgingly considered) attitude to Wayland development.
labwc has an annoying 'snap to edge' feature if windows are placed in a particular position. There's probably a way around this, but even if I find it, it may be different on *every other compositor*.
labwc does feature various Wayland protocol enhancements. Other compositors do not, because even if they're based on a common compositor library, protocol updates in that library do not automatically flow through to updates in the compositor.
Leading from the above, you can't rely on something such a config file to position monitors on startup (as you can in Xorg) as it may not be supported by the compositor, and the syntax differs for each compositor that supports it. Once Wayland itself is fully running, a post startup script can call the protocol enhancement to move monitors, and that *is* compositor agnostic assuming the protocol is supported.
The reference Wayland compositor, Weston, IS LINUX ONLY. There's an old NetBSD port last time I looked, but the only up to date implementation is on Linux. The fact the reference compositor is not tested on a non Linux platform beggars belief.
It's still not clear to me how to position windows that use the overlay plane (such as clocks). I can start the programs, but then can't easily interact with them, because my compositor appears to have no built in support or documentation on this, it's not obvious via a search, and at that point I start to lose the will to live and just look at an actual physical clock instead.
17 years on, things like colour management are still not nailed down.
Driver support for older cards is lacking, particularly on Nvidia.
What it needs, and also what will never happen :
*ONE* compositor base that everything bolts on to. This must be a suitable base for all compositor addons from the largest commercial desktops to the smallest individual offering.
Cross platform first, or at the very least a way of gracefully handling a lack of functionality. If it doesn't built on Linux and BSD, it doesn't get released.
Development driven by design, not commercial interests. So Redhat/Canonical, or Nvidia/AMD/Intel can't move things towards 'oh, your graphics card is old, no support for you' [1]
As it is, things will coalesce around a small number of large desktop based compositors (i.e. GNOME), and any company with sense will insist on their open source supporting software running on : Linux (possibly x64 only), and GNOME Wayland. And nothing else. mmmmm open platforms, and choice. [2]
[1] To be fair this already happened multiple times in Xorg, it's just that most people didn't notice because drivers were re-written to support the new X interface (there are at least three I know of). However, Wayland seems potentially to offer a larger excuse and 'not all the drivers are open, and doing this costs money, so even though your card is easily capable of working with Wayland, it never will'.
[2] Also to be fair, this occurs with poorly written Xorg software also : 'what do you mean my function call to place an icon on the desktop or query desktop stuff is failing, because you're running a window manager with no desktop or icons'
Integrate Wayland into systemd
Problems solved.
As an alternative to X11 and Wayland,p erhaps Apple could open-source Color Quickdraw? That ran in 256KB of ROM (one quarter of one megabyte) and had probably the best documentation ever, in the form of the "Inside Macintosh" series of manuals.
But no... people are too attached to their GPU-accelerated screensavers.