5 ms·
Experimental X11 Compatibility Layer
- nobody9999 1y agoFrom the README: "Wayback is an experimental X compatibility layer which allows for running full X desktop environments using Wayland components. It is essentially a stub compositor which provides just enough Wayland capabilities to host a rootful Xwayland server."
- ajb 1y ago"It is intended to eventually replace the classic X.org server in Alpine, thus reducing maintenance burden of X applications in Alpine, but a lot of work needs to be done first." OT but what's the use case for running gui applications in alpine? I've mostly seen it used as a container OS on servers. Are people using it for kiosks?
- lproven 1y agoAlpine is a full distro. It's perfectly capable of being used as a desktop OS and I do so myself.
- thdhhghgbhy 1y agoVery naive question, but what is the difference between this and XWayland?
- lproven 1y agoAIUI: you need an existing compositor to run Xwayland. An X server is a display server: it can run on its own, and apps can output to it, with nothing else running. When one program runs early on and provides windows furniture, that's a window manager. If that program (or associated ones with a uniform look and feel) also provides UI functionality so you don't need to use a command prompt, such as tools to launch apps, see and manage files, edit text files, mount and unmount media, and maybe things like see the time, adjust system settings, do calculations, etc. then that is called a desktop environment. Wayland is not like this. Wayland is a protocol. There are no separate display servers. What under X is called a "window manager" usually talks Wayland and so other apps talk directly to the WM over Wayland in order to display stuff. There's no bottom layer program, no server. The WM is the display server. Without a WM you can't run anything. That means you need a Wayland compositor to run anything else, such as XWayland. This means that you can't use an X WM to be the compositor, because the layer needed to run the WM is not there until another different app provides the Wayland environment, and then it's the WM and your X WM can't take over. Remove the compositor, there's no GUI. This is not a question of whipping out the tablecloth from under a fully-laid table. It's removing the table. So what this project looks like is a compositor that isn't a WM and so enables Xwayland to run full-screen as the root window, letting you use an X WM as your desktop with no Wayland WM. It sounds of great interest to me because whereas there are about half a dozen X desktops and environments I like, some I've been using for decades now, there is not a single Wayland environment I would be willing to use.
- hakfoo 1y ago> There's no bottom layer program, no server. The WM is the display server. Without a WM you can't run anything. IMO, this is Wayland's original sin. The "Display Server" part of things is tens of thousands of lines of dealing with obtuse hardware and protocol technicalities. It needs to be fast, reliable, secure, and up to date, but otherwise is very much anonymous infrastructure. The "Compositor/Window Manager" part of things is relatively small and likely to be much more opinionated on what features and behaviour it offered. In the X11 days, a Window Manager could be simple enough to fit in a chapter of a book (the O'reilly X11 books had one IIRC). For Wayland, because they're under one hood, to get to the same place, you're looking at a huge, ongoing development effort, even if that consists of importing something like wlroots and building on top. That's enough to severely crimp the array of choices available. People are being told they have to give up their X11 workflows and configurations, and the replacements are often lacking in some dimension (less functional, difficult to configure the same way, more resource intensive) Nobody should be surprised there was hostility and pushback! Maybe the way to go would have been instead of building the ugliest possible Windows Vista On An Old Pentium 4 That Doesn't Qualify For Aero Glass look on Weston, they should have focused on building a "shim compositor" library that was specifically designed to ease porting X11 window managers, by providing APIs that looked similar to existing X11 ones.
- thdhhghgbhy 1y agoVery clearly written, thank you.
- lproven 1y agoThanks!
- saurik 1y agoThis just feels like the kind of thing the people who built Wayland should have focussed on for their first real release, as that would have allowed them to simply deprecate X11 immediately with a "better" architecture rather than go to war for a decade (and build up a ton of bad will in the process) forcing people to first try to make major adaptations to everything.
- creatonez 1y agoIt uses XWayland under the hood -- it is an implementation of rootful XWayland that is presumably properly integrated, rather than being glued to a window. Meaning you get the full Xorg desktop, and things like panels will (hopefully) properly snap to the side of the screen instead of displaying as a window.
- resoluteteeth 1y agoI think this probably makes more sense for people who want to keep using x11 environments than trying to fork/maintain xorg.
- bandrami 1y agoI always wondered why they didn't start with this, like the way Pipewire basically inserted itself in place of pulse/jack.
- bitwize 1y agoThis is something I did a few months ago, with Xwayland on top of Weston running in kiosk mode. It was kind of a pain in the ass -- Xorg with extra steps. (Xwayland is a build of Xorg with a Wayland DDX.) I'd much rather just use Xorg with the modesetting driver. This project only exists so that the author -- who has significant pull within the Alpine project -- can "get ahead of" Xlibre, adoption of which is considered a violation of the Alpine code of conduct.
- LeFantome 1y agoIs that really it? To cut off Xlibre at the pass? Because I am struggling to understand what the advantage of this over just using Xorg. I think 90% of desktops will be Wayland as we leave 2027 (and more than 50% are now). I also think installing even Xwayland may be niche in 5 years. That said, Xwayland will be maintained by Red Hat until 2040 at least (minimum required for even RHEL 11). Xorg itself will be maintained intil at least 2032 and, by others, probably a decade or more after that. Xorg already uses lininput, DRI, KMS, and Mesa and shares a lot of code with Xwayland. So keeping it going will not be hard. So, what is the advantage of this approach over just using Xorg? I mean, if your goal is to run a legacy X11 window manager that is.
- bitwize 1y agoAgain, Xwayland is Xorg, just with a Wayland DDX backend.If you check out the xorg-server source tree, you can build your own Xwayland with appropriate configuration. Beyond just doing an end run around nazi X forks, I think the idea here is to get everybody on Wayland by hook or by crook. The Xorg developers explicitly DO NOT want you to use Xorg, especially not with a direct hardware backend (even modesetting). Wayland is their solution for a much-needed replacement. and, going forward, aside from bugfixes Xwayland will be the only supported/maintained X solution. But really the idea is to keep Xwayland around only for legacy apps, so we'll probably see no new features or protocols added to Xwayland except perhaps to better integrate with Wayland desktops. Xwayland itself will be slated for deprecation and eventual removal from the latest versions of most major distros in the next ten years or so.