4 ms·

Unfortunately, I think Wayland really botched things. That's a shame because it would have been a great improvement. Wayland and friends have taken far too long

by dolni 4y ago

Unfortunately, I think Wayland really botched things. That's a shame because it would have been a great improvement. Wayland and friends have taken far too long to build and the tradeoffs to me, an end user, are not convincing. I tried to use Sway for a few months (as a regular user of i3) and I ran into too many frustrating issues to want to keep with it. The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers. IMO, we needed something not far off what X11 does. Really, X11 was fine but could use some rearchitecture for modern times and a purge of all the 80s drawing cruft nobody uses anymore. And address the input security stuff.

Crysstalis 4y ago
>The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers. No, not really. Everything that Wayland does is stuff that X11 compositors were already doing. With those the compositor is already taking on all processing of input, and the X11 server is only creating an additional unnecessary step by passing all the input through. Thus why that extra step was removed in Wayland.
amelius 4y ago
> The greatest problem with the Wayland protocol is how much work a compositor has to do. Sounds not like a very modular/orthogonalized approach, and also limiting the choice of the user.
- Crysstalis 4y ago
  It is as modular as any compositor wants to make it, for example Weston has a plugin system. Regarding the issue of "choice", please read this page: http://www.islinuxaboutchoice.com/ http://www.islinuxaboutchoice.com/
  - amelius 4y ago
    I mean, if you allow every compositor to implement its own plugin system, then you end up with a lot of fragmentation and you effectively lock the user into one particular compositor.
    - Crysstalis 4y ago
      So then you have to come up with a plugin system which everyone wants, which is probably not even possible because the definition of "plugin" is so vague that it could mean anything. If you ask me, fragmentation is just the default state of things in open source.
      - amelius 4y ago
        Yes, the default state is the state you get if you don't put any work into it. It is the "easy" state. Defining a good plugin system is not easy, true.
        Crysstalis 4y ago
        I remember at the time the Compiz developers were trying to get everyone else to either base their compositor on Compiz, or build in support for Compiz plugins. That might have been feasible if there was a working design, but Compiz plugins were very hacky and the code was a mess. IIRC the only desktop that actually did it was Unity, and that was discontinued. So you can see some of the troubles with that approach.
malcolmstill 4y ago
The Wayland protocol is fine and provides the modern features expected (“every frame is perfect”). But X is two things: a protocol and a de facto standard server that window managers could easily interface with. I wonder if we’d be in a different place if Wayland as well as offering the protocol also offered a de facto standard server (not simply a reference implementation in weston) with a window manager protocol that more or less forwards on client <-> server messages that a window manager would care about. Client buffers shared with the server can also be shared with the (separate) window manager process which then shares its composited buffer with the server for final rendering.
- Crysstalis 4y ago
  Somebody could design that but it is not clear why you would. You do not need a separate process for that.
- edflsafoiewq 4y ago
  It seems like the problem with Wayland is things that used to be solved by merging some code into X are now a big social synchronization problem, ie. get everybody to agree on a protocol.
  - Crysstalis 4y ago
    You still had the same problems in X. It was a bad idea to try to get protocol code merged into X unless you could get everyone to agree on it. Because ultimately, in either case it is still the same set of people who will be using any new protocols.
  - dolni 4y ago
    Yes, that's a large part of it. What we needed was a server and a standard library. Not a barebones protocol for everyone to implement with a different set of bugs. wlroots showed up too late to the game. Now we have GNOME, KDE, wlroots, and maybe some other implementations floating around out there.
    - 4y ago
5e92cb50239222b 4y ago
As long as X11 fans are going to complain without actually doing something, things are going to stay that way. Xorg developers had put it on life support years ago, and somehow nobody has stepped up to to their work. > X11 was fine People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever. Here's one of those articles (I think, but it's been years and I don't want to re-read it just to check): https://lwn.net/Articles/491509/ https://lwn.net/Articles/491509/
- dolni 4y ago
  I am not an X11 "fan". I use what works best for me. I put a lot of effort into using Sway and the experience sucked. > People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever. I never advocated keeping X11 and just doing cleanup. But the solution probably should look more like X11 than it does. For all that deep knowledge we have a project a decade old, with relatively low adoption and a number of critical blunders along the way (no forethought given to apps that need global keybinds, no forethought to screen capture). Wayland is shaping up to be a fragmented mess instead of the successor standard that the Linux desktop needed.
  - Crysstalis 4y ago
    >no forethought given to apps that need global keybinds Please see this pull request for a description of some of the current challenges with getting global shortcuts to work: https://github.com/flatpak/xdg-desktop-portal/pull/711 https://github.com/flatpak/xdg-desktop-portal/pull/711 >no forethought to screen capture The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it. In any case, X11 also does not have any forethought in relation to hotkeys or screen capture. Technically it has no API for either of those, it has APIs that allow all applications to intercept all keys, and to allow all applications to read the contents of any window. Those APIs can be used to do hotkeys and screen capture in a rudimentary and somewhat broken way but they are not ideal. Just copying those (or an API that looks like those) into Wayland would be an unwise idea.
kaba0 4y ago
> The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers. Why is it unreasonable to ask that from a window manager in the general case? The protocol should provide for every basic feature suitable for the problem domain. But these things can be refactored out to third-party libs like wlroots, making a simple window manager implementation similarly easy as under X.

by dolni 4y ago

Crysstalis 4y ago

>The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers. No, not really. Everything that Wayland does is stuff that X11 compositors were already doing. With those the compositor is already taking on all processing of input, and the X11 server is only creating an additional unnecessary step by passing all the input through. Thus why that extra step was removed in Wayland.

amelius 4y ago

> The greatest problem with the Wayland protocol is how much work a compositor has to do. Sounds not like a very modular/orthogonalized approach, and also limiting the choice of the user.

Crysstalis 4y ago
It is as modular as any compositor wants to make it, for example Weston has a plugin system. Regarding the issue of "choice", please read this page: http://www.islinuxaboutchoice.com/ http://www.islinuxaboutchoice.com/
- amelius 4y ago
  I mean, if you allow every compositor to implement its own plugin system, then you end up with a lot of fragmentation and you effectively lock the user into one particular compositor.
  - Crysstalis 4y ago
    So then you have to come up with a plugin system which everyone wants, which is probably not even possible because the definition of "plugin" is so vague that it could mean anything. If you ask me, fragmentation is just the default state of things in open source.
    - amelius 4y ago
      Yes, the default state is the state you get if you don't put any work into it. It is the "easy" state. Defining a good plugin system is not easy, true.
      - Crysstalis 4y ago
        I remember at the time the Compiz developers were trying to get everyone else to either base their compositor on Compiz, or build in support for Compiz plugins. That might have been feasible if there was a working design, but Compiz plugins were very hacky and the code was a mess. IIRC the only desktop that actually did it was Unity, and that was discontinued. So you can see some of the troubles with that approach.

malcolmstill 4y ago

The Wayland protocol is fine and provides the modern features expected (“every frame is perfect”). But X is two things: a protocol and a de facto standard server that window managers could easily interface with. I wonder if we’d be in a different place if Wayland as well as offering the protocol also offered a de facto standard server (not simply a reference implementation in weston) with a window manager protocol that more or less forwards on client <-> server messages that a window manager would care about. Client buffers shared with the server can also be shared with the (separate) window manager process which then shares its composited buffer with the server for final rendering.

Crysstalis 4y ago
Somebody could design that but it is not clear why you would. You do not need a separate process for that.
edflsafoiewq 4y ago
It seems like the problem with Wayland is things that used to be solved by merging some code into X are now a big social synchronization problem, ie. get everybody to agree on a protocol.
- Crysstalis 4y ago
  You still had the same problems in X. It was a bad idea to try to get protocol code merged into X unless you could get everyone to agree on it. Because ultimately, in either case it is still the same set of people who will be using any new protocols.
- dolni 4y ago
  Yes, that's a large part of it. What we needed was a server and a standard library. Not a barebones protocol for everyone to implement with a different set of bugs. wlroots showed up too late to the game. Now we have GNOME, KDE, wlroots, and maybe some other implementations floating around out there.
  - 4y ago

5e92cb50239222b 4y ago

As long as X11 fans are going to complain without actually doing something, things are going to stay that way. Xorg developers had put it on life support years ago, and somehow nobody has stepped up to to their work. > X11 was fine People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever. Here's one of those articles (I think, but it's been years and I don't want to re-read it just to check): https://lwn.net/Articles/491509/ https://lwn.net/Articles/491509/

dolni 4y ago
I am not an X11 "fan". I use what works best for me. I put a lot of effort into using Sway and the experience sucked. > People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever. I never advocated keeping X11 and just doing cleanup. But the solution probably should look more like X11 than it does. For all that deep knowledge we have a project a decade old, with relatively low adoption and a number of critical blunders along the way (no forethought given to apps that need global keybinds, no forethought to screen capture). Wayland is shaping up to be a fragmented mess instead of the successor standard that the Linux desktop needed.
- Crysstalis 4y ago
  >no forethought given to apps that need global keybinds Please see this pull request for a description of some of the current challenges with getting global shortcuts to work: https://github.com/flatpak/xdg-desktop-portal/pull/711 https://github.com/flatpak/xdg-desktop-portal/pull/711 >no forethought to screen capture The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it. In any case, X11 also does not have any forethought in relation to hotkeys or screen capture. Technically it has no API for either of those, it has APIs that allow all applications to intercept all keys, and to allow all applications to read the contents of any window. Those APIs can be used to do hotkeys and screen capture in a rudimentary and somewhat broken way but they are not ideal. Just copying those (or an API that looks like those) into Wayland would be an unwise idea.

kaba0 4y ago

> The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers. Why is it unreasonable to ask that from a window manager in the general case? The protocol should provide for every basic feature suitable for the problem domain. But these things can be refactored out to third-party libs like wlroots, making a simple window manager implementation similarly easy as under X.