Alpine Linux maintainer Ariadne Conill only started working on Wayback a few weeks ago, but in a blog post today they dive into a few more details about how much progress has already been achieved. To refresh your memory, Wayback allows you to run a legacy X11-based desktop environment on top of Wayland by running a stub Wayland compositor in front of Xwayland, capable of serving as a full X server. This way, the transition to Wayland and the removal of X.org from popular distributions won’t mean you can’t run X11-based desktop environments anymore.
Within just a few weeks, the project has made serious progress.
There’s a lot still left to do before we can confidently say that Wayback is ready for distributions to switch to. This work is across the stack: Wayback still needs to expose surfaces that Xwayland can use, Xwayland needs to implement a few new features such as cursor warping and some X extensions inside Xwayland itself need to be properly plumbed (such as Xinerama being able to make use of the Wayland output layout data).
Longer term goals aside, we are at most a few weeks away from the first alpha-quality release of Wayback. The main focus of this release is to get to a point where enough is working that users with basic setups and requirements can be reasonably served by Wayback in place of the X.org server, to allow for further testing. It’s already to a point where I am daily driving it.
↫ Ariadne Conill
Of course, there’s still tons of bugs to figure out and missing functionality to implement, but the fact that they’re just weeks away from a first alpha release is honestly impressive. I really hope Wayback picks up even more and gets adopted by other distributions as well, since it’s such an elegant and future-proof solution to a very real problem. It’s important that desktop environments that will not or cannot transition to Wayland remain available to Linux users regardless of their choice of Wayland or X11.
When facing the slow sunsetting of a windowing system, some people go off on deranged neofascist conspiracy rants against the woke illuminati, while others sit down and develop real forward-looking solutions. I’m glad virtually every Linux distribution that matters trusts the latter over the former.
I’m definitely going to follow this project as it seems to be a solution to my problem of wanting to move to Wayland but being held back by legacy X11 software. I’m going to play with this on my spare Void Linux box later this week.
@Morgan
Have you really moved to Wayland if 100% of your apps run as X11? What benefits does being on Wayback bring over continuing with Xorg?
If it really offers a benefit, best of luck. I hope it addresses your issue. Keep us posted on the results.
The biggest benefit is that this solution can be maintained beyond the sun-setting of X.org. It builds on the new infrastructure, while being a drop in replacement for legacy window managers and desktop environments.
Or put differently, you don’t need to build a retro rig with an old, unmaintained distro release when you want to run Fvwm95. You can just run it right on your shiny, modern monster rig.
@r_a_trip
I get that but Xorg is going to be well maintained for quite some time and your monster rig can still run it. Red Hat is obligated to support Xorg for RHEL9 until 2036 or so. I would expect other parties to chip in as well. And of course, there is now a fork.
But my question was more about what Wayback offers “now” for people like @Morgan above. I would think the most complete and bug-free X11 experience today would come from Xorg rather than Wayback. And by “today”, I mean the next year or so.
My question is driven by curiosity. I do not want people to think I am dumping on Wayback. I am excited to see the Alpine folks working on this.
Luckily, “today” there are going to be zero benefits over xorg.
However: xorg may be well maintained, but that doesn’t guarantee proper support from the graphics drivers, even in the near future (I expect the first problems with newly released hardware within 2-3 years). One would want a well-tested solution ready when that happens.
@Mote
> xorg may be well maintained, but that doesn’t guarantee proper support from the graphics drivers.
Fair point. That said….
Modern Xorg uses DRI, DRM, KMS, libinput, and Mesa. The same drivers (Mesa, AMDGPU, NVIDIA’s proprietary drivers) work for both Xorg and Wayland today. I doubt much has to be done to keep Xorg working with new hardware.
A huge amount of the Xorg code is also in Xwayland. If Xwayland is maintained, a lot of Xorg is maintained by proxy.
Red Hat is supporting Xorg as part of RHEL9 for the next decade. They may add new hardware support if required. As above, I doubt they will have to as Xorg is pretty much setup these days to use Wayland drivers.
What will cause Xorg to become obsolete is not hardware support but features and application compatibility. Wayback is not going to help with that.
LeFantome,
I agree, it’s working and support should be rather minimal. However I’m not so sure Xorg leadership are onboard with allowing Xorg to go forward long term. The fact that Xorg keeps working may be seen as an impediment to wayland and it could be a conflict of interest. Personally it’s not my intention to stick with X once wayland is working for me, but I still recognize it’s a weird situation for X fans who don’t want to switch.
I think you misunderstand my issues with Wayland. I have exactly two issues preventing me from running it full time: Font rendering (in KDE Plasma, haven’t seen it in GNOME), and full support for RDP and other remote control protocols. In other words, I’m 99% of the way there already.
I’m also thinking that Wayback may be good for more than just the Linux world; FreeBSD is making progress towards adopting Wayland, and Wayback can probably be ported to that OS as well.
Wayback is just a Wayland compositor. If you can run Wayback, you can run other Wayland compositors as well.
Wayback is just enough Wayland compositor to host Xwayland in rootful mode. Xwayland is already Xorg minus the DDX bits. Wayback replaces the DDX bits, providing a full Xorg replacement. Other Wayland compositors can do that too (including Cage that will run it full screen).
The benefit of Wayback for a distribution is not having to package Xorg or its fork (and not having to fight over which of those to package). It does not help anything run better or make anything easier to port (please correct this if I am wrong).
In practice, Wayland does not function as a Wayland compositor (even though it IS a Wayland compositor), as it does not host Wayland applicatons (only Xwayland). As Wayback only runs X11 applications, I do not understand why an end-user would prefer it over Xorg today.
The way I see it, if the Wayland font rendering issues in KDE Plasma can be fixed, and I can use Wayback to run those pesky apps that aren’t working yet in Wayland, I’ll be able to move to Wayland and still use the legacy apps.
This project just doesn’t make a lot of sense to me. The majority of the argument I’ve seen against Wayland is that it doesn’t implement some feature X, which user relies on. With this project implementing on top of Xwayland, don’t those problems still exist? I can see that the project now needs features to be implemented in Xwayland to complete some functionality, so they’re right back at square one. Seems like effort that could instead be invested in implementing missing features in Wayland/Xwayland, or porting remaining applications that have already stagnated to support Wayland.
Wayback doesn’t run the X11 applications (XWayland already does that). It runs X11 desktops and window managers on top of XWayland. Something that XWayland normally doesn’t do. So it is a way of running full X11 environments inside a rootful XWayland instance.
To add to your comment. It’s not clear that it’ll be more work than the work of porting every window manager to Wayland natively.
It’s also incorrect for the earlier poster to assume that effort can be redirected from A to B, when we’re talking about open source volunteer developers who maybe don’t want to work on B.
> This project just doesn’t make a lot of sense to me.
As a long-term initiative, I get it. I also get why the distribution devs want it as it means not having to package Xorg or its recent fork in the distribution at all and, importantly I think, it means not having to argue over which one of those to package. I do not know why an end-user would prefer Wayback over Xorg though, specifically for the next couple of years while Xorg is likely to work better.
> With this project implementing on top of Xwayland, don’t those problems still exist
Well, some of the problems will still exist but quite a few of the things people complain about will not.
Many of the “problems” with Wayland are rooted in security. A Wayland application cannot see or manipulate all pixels, or the keyboard, or the mouse for example.
Screen readers and autoclickers designed for X are not going to work in Wayland. And I cannot capture the screen of another window directly. Another big complaint of course is that you cannot run an X11 window manager, an application that takes over control of how other applications are displayed. Things like capturing the screen or manipulating input require the same kinds of “portals” on Wayland as are required for Flatpak applications because both kinds of applications essentially run in a “sandbox”.
Because Wayback runs an X server (Xwayland) full-screen and runs only X11 applications, I expect that most things work in Wayback as they do in X11. Explicitly, the goal is to allow the use of X11 window managers.
All this could be done by running Xwayland in rootful mode on any Wayland compositor. If you did that and ran Xwayland full-screen, you would basically have Wayback. Perhaps Wayback will take some extra steps to smooth over specific X11 use cases. We will see.
So most of the “Wayland” problems will be addressed though, no doubt, some of them would will. However, I expect that Wayback itself will introduce new bugs and limitations relative to running Xorg. At least, I would expect this at first. Wayback will improve over time.
The problem with Wayland is that X11 and Wayland both don’t really seem to solve real world problems for users. I mean sure if you want HDR color and run at 200hz maybe Wayland offers something that X11 doesn’t. But if you want to run an eGPU that plugs/unplugs regularly from a laptop and want to connect that eGPU without having to reboot the kernel/restart Wayland/X11 then both system seem to fail. Sure I can boot once, and have the eGPU connected, but if I disconnect/reconnect the eGPU then it all goes to shit. Either the eGPU doesn’t reconnect properly, or Wayland/X11 don’t detect the new displays until they are restarted which voids the whole point of it being “hotplug”. If you have to tear the entire desktop environment and all your apps down down to add a second GPU/output display then it’s not very hotplug or useful. This is something which Windows 10 and 11 both support without issue.
That’s an interesting example because for me HDR support is a very real world benefit of Wayland. I own an HDR-capable display, but I’ve yet to encounter an eGPU in the wild. But now that you mention it, you’ve got me curious if hotplug support is a problem for Wayland to solve or rather the Linux kernel.
@Darkmage:
Not quite. Last year I tried running an eGPU (Radeon 5700XT in a PCIe->USB4 adapter) on a mini PC running Windows 11, and unplugging the GPU would sometimes cause Windows to crash and the computer to reboot itself. I never did figure out if the eGPU adapter or the AMD drivers were the issue, I just went back to a normal sized PC for gaming and put my card in that (and switched to Void Linux for gaming on that machine, but that’s another story).
Here’s a whole host of issues with eGPUs on Windows, along with some solutions: https://egpu.io/forums/pc-setup/guide-generic-windows-10-solutions-for-egpu-bsod-crashing-and-system-freezing-link-state-power-management-tdrdelay-tdrddidelay-nvidia-power-management-settings/