3 ms·

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

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).

saurik 1y ago
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.
- LeFantome 1y ago
  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”.

saurik 1y ago

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.

LeFantome 1y ago
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”.