"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?
AIUI: 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.
This 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.
To be clear, XWayland itself has been available since 2013. Rootful XWayland is more complex and generally not desirable because it's leaving a lot of potential improvements on the table, while requiring you to implement a bunch of quirks to support things that were already adequately replaced.
You also still don't get an easy solution to much of what users actually tend to complain about -- which are the lower level components and driver support that Xorg had that wasn't matched by Wayland until recently. There's a whole entire stack of low level stuff developed over decades that made "just install linux" possible on so many PCs. The higher level components that something like XWayland or Xephyr implements is only a miniscule fraction of the Xorg codebase, that has largely remained the same since the 1980s (but is surprisingly easy to maintain on its own).
I know about XWayland, but trying to go to war to modify an infinite number of random window managers and the ecosystem of tools that plugged into the X backend is, to me, the thing which should have been avoided by thinking about the project more as a massive rearchitecting of the stack. If you do build that -- even if it is kind of difficult, though frankly I can't imagine it is actually HARD and not merely BORING (which is a big problem with software developers where they conflate that: most of the job is, in fact, boring, and you have to embrace that) -- you could just delete the X codebase as you expanded hardware support, rather than being stuck in some weird limbo where a bunch of tooling out there is still having to be ported or even rebuilt for Wayland.
While many people desire this “total compatibility” with Xorg idea, the Wayland team sees this as an anti-feature.
Many things on X are done the way they are because all processes can see all pixels and all devices. Wayland does not want that. So, tools built to these requirements will not work. And, obviously, they cannot be “fixed”.
But Wayland is a better architecture, at least when it comes to 'here is my output, put it on the display plz' situations, it was always going to be a painful migration process because there's not a single toolkit.
That's not to say there's some non technical decisions which are making porting a lot harder *cough cough* mouse warping *cough cough*
I mean, does it? I was under the impression that it enforced double- or even triple- buffering, which is NOT what you want in "here is my output, put it on the display plz" situations. Maybe you are implying that they finally fixed that?... but, the fact that they tried to cram all this stuff down everyone's throats first before fixing obvious deficiencies--leading to a bunch of obsolete understandings over totally fair complaints about software a decade too early being constantly evangelized by asshats on forums saying you're dumb for still using X11 when Wayland was not even a half-baked solution--is extremely dumb.
What people do not seem to get is that Wayland is what they wanted Xorg to be. A lot of what Wayland could not do were things they did not think it should do.
In some cases, the Wayland team has been dragged kicking to implement things. In other cases, they have stood firm and we will be leaving them behind.
The people that developed Wayland were the exact same people that developed X.Org. I'm sure they thought of all possible options because they are actually very smart people.
Well: 1) it isn't always the case that the people who develop a system in the center of an ecosystem are actually the people who know best how the entire ecosystem should work (and in fact there is an entire trope of second system effect destroying such a reboot); 2) it isn't at all obvious to me (and in fact it feels incredible to me) that the people who put most of the effort into X.Org decades ago are actually "the exact same people" who are in charge of maintaining it today; and 3) the specific thing we are talking about here has been discussed numerous times in the past decade by people developing low-latency and high-performance apps--such as games, which is where you really want to be able to get the display server out of the way--and was, in fact, known to introduce a ton of latency that they were going to figure out how to fix some day (a similar situation to how Wayland completely fucked up display scaling by forcing integer scaling, which required patching later and now is a wart in the architecture already).
Graphics-stack developers have known that in order to keep pace with Windows and macOS, X needed to be replaced, since the 90s at the latest. The only question was with what. The Xorg developers came up with a solution: Wayland. The hackers who wrote Xorg are in unanimous agreement that X is obsolete and you should be using Wayland instead. The next step, now ongoing, is to coordinate with DEs and distros to remove X support altogether.
You should use Wayland because it's what's supported. It's what all future Linux graphical software will be ported to. In a few years, it'll be impossible to get an X version of even a recent web browser. The best time to abandon X was 30 years ago. The second best time is now.
And yet, abandoning X for Wayland--not to start developing Wayland, but to actually stop using X and start using Wayland--is MUCH easier to do now than it was to do five years ago, despite all of the people (maybe including yourself) who were INSISTENT that you had to do it IMMEDIATELY or suffer some kind of consequence.
This is a similar situation to the people who were all screaming that you had to ditch Python 2 to upgrade to Python 3 immediately after it came out, and that if you didn't you were somehow dumb, even though they finally started to fix all of the upgrade deficiencies and regressions only with something around Python 3.5: there's a time to upgrade, and that time is never immediately upon introduction.
It 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.
"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."
This 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.
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.
Again, 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.
I always wondered why they didn't start with this, like the way Pipewire basically inserted itself in place of pulse/jack.
I think this probably makes more sense for people who want to keep using x11 environments than trying to fork/maintain xorg.
"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?
Alpine is a full distro. It's perfectly capable of being used as a desktop OS and I do so myself.
Very naive question, but what is the difference between this and XWayland?
AIUI: 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.
This 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.
To be clear, XWayland itself has been available since 2013. Rootful XWayland is more complex and generally not desirable because it's leaving a lot of potential improvements on the table, while requiring you to implement a bunch of quirks to support things that were already adequately replaced.
You also still don't get an easy solution to much of what users actually tend to complain about -- which are the lower level components and driver support that Xorg had that wasn't matched by Wayland until recently. There's a whole entire stack of low level stuff developed over decades that made "just install linux" possible on so many PCs. The higher level components that something like XWayland or Xephyr implements is only a miniscule fraction of the Xorg codebase, that has largely remained the same since the 1980s (but is surprisingly easy to maintain on its own).
I know about XWayland, but trying to go to war to modify an infinite number of random window managers and the ecosystem of tools that plugged into the X backend is, to me, the thing which should have been avoided by thinking about the project more as a massive rearchitecting of the stack. If you do build that -- even if it is kind of difficult, though frankly I can't imagine it is actually HARD and not merely BORING (which is a big problem with software developers where they conflate that: most of the job is, in fact, boring, and you have to embrace that) -- you could just delete the X codebase as you expanded hardware support, rather than being stuck in some weird limbo where a bunch of tooling out there is still having to be ported or even rebuilt for Wayland.
While many people desire this “total compatibility” with Xorg idea, the Wayland team sees this as an anti-feature.
Many things on X are done the way they are because all processes can see all pixels and all devices. Wayland does not want that. So, tools built to these requirements will not work. And, obviously, they cannot be “fixed”.
But Wayland is a better architecture, at least when it comes to 'here is my output, put it on the display plz' situations, it was always going to be a painful migration process because there's not a single toolkit.
That's not to say there's some non technical decisions which are making porting a lot harder *cough cough* mouse warping *cough cough*
I mean, does it? I was under the impression that it enforced double- or even triple- buffering, which is NOT what you want in "here is my output, put it on the display plz" situations. Maybe you are implying that they finally fixed that?... but, the fact that they tried to cram all this stuff down everyone's throats first before fixing obvious deficiencies--leading to a bunch of obsolete understandings over totally fair complaints about software a decade too early being constantly evangelized by asshats on forums saying you're dumb for still using X11 when Wayland was not even a half-baked solution--is extremely dumb.
Wayland was written by the Xorg dev team.
What people do not seem to get is that Wayland is what they wanted Xorg to be. A lot of what Wayland could not do were things they did not think it should do.
In some cases, the Wayland team has been dragged kicking to implement things. In other cases, they have stood firm and we will be leaving them behind.
The people that developed Wayland were the exact same people that developed X.Org. I'm sure they thought of all possible options because they are actually very smart people.
Well: 1) it isn't always the case that the people who develop a system in the center of an ecosystem are actually the people who know best how the entire ecosystem should work (and in fact there is an entire trope of second system effect destroying such a reboot); 2) it isn't at all obvious to me (and in fact it feels incredible to me) that the people who put most of the effort into X.Org decades ago are actually "the exact same people" who are in charge of maintaining it today; and 3) the specific thing we are talking about here has been discussed numerous times in the past decade by people developing low-latency and high-performance apps--such as games, which is where you really want to be able to get the display server out of the way--and was, in fact, known to introduce a ton of latency that they were going to figure out how to fix some day (a similar situation to how Wayland completely fucked up display scaling by forcing integer scaling, which required patching later and now is a wart in the architecture already).
Graphics-stack developers have known that in order to keep pace with Windows and macOS, X needed to be replaced, since the 90s at the latest. The only question was with what. The Xorg developers came up with a solution: Wayland. The hackers who wrote Xorg are in unanimous agreement that X is obsolete and you should be using Wayland instead. The next step, now ongoing, is to coordinate with DEs and distros to remove X support altogether.
You should use Wayland because it's what's supported. It's what all future Linux graphical software will be ported to. In a few years, it'll be impossible to get an X version of even a recent web browser. The best time to abandon X was 30 years ago. The second best time is now.
And yet, abandoning X for Wayland--not to start developing Wayland, but to actually stop using X and start using Wayland--is MUCH easier to do now than it was to do five years ago, despite all of the people (maybe including yourself) who were INSISTENT that you had to do it IMMEDIATELY or suffer some kind of consequence.
This is a similar situation to the people who were all screaming that you had to ditch Python 2 to upgrade to Python 3 immediately after it came out, and that if you didn't you were somehow dumb, even though they finally started to fix all of the upgrade deficiencies and regressions only with something around Python 3.5: there's a time to upgrade, and that time is never immediately upon introduction.
Very clearly written, thank you.
Thanks!
It 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.
From 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."
This 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.
Is 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.
Again, 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.