4 ms·

That's easy to say in hindsight. It is only with the specific failures of Wayland that we see which lessons it could have learned from X11.

hsbauauvhabzb 10mo ago
I think the lack of base abstraction layer was pretty obvious from the start.
- the_why_of_y 10mo ago
  Since this is a Wayland thread, obviously the problem is a lack of a common implementation, which deviates from UNIX tradition. For those who want to complain how lack of choice between multiple implementations is an obvious problem and deviates from UNIX tradition, please wait until the next systemd thread.
  - hsbauauvhabzb 10mo ago
    Weird strawman, but you do you.
charcircuit 10mo ago
>That's easy to say in hindsight That's an easy way to excuse bad design. Look at the designs of other operating systems designed by professionals and you won't see windows managers having to handle raw inputs or being in the same process as the compositor.
- the_why_of_y 10mo ago
  Examples of other operating systems allegedly not designed by professionals: https://en.wikipedia.org/wiki/Desktop_Window_Manager https://en.wikipedia.org/wiki/Desktop_Window_Manager The Desktop Window Manager is a compositing window manager, meaning that each program has a buffer that it writes data to; DWM then composites each program's buffer into a final image. https://web.archive.org/web/20040925095929/http://developer.apple.com/documentation/MacOSX/COnceptual/SystemOverview/SystemArchitecture/chapter_3_section_4.html https://web.archive.org/web/20040925095929/http://developer.... The Quartz Compositor layer of Mac OS X comprises the window server and the (private) system programming interfaces (SPI) implemented by the window server. In this layer are the facilities responsible for rudimentary screen displays, window compositing and management, event routing, and cursor management. The window server is a single system-wide process that coordinates low-level windowing behavior and enforces a fundamental uniformity in what appears on the screen. It is a lightweight server in that it does not do any rendering itself, but instead communicates with the client graphics libraries layered on top of it. It is “agnostic” in terms of a drawing model. The window server has few dependencies on other system services and libraries. It relies on the kernel environment’s I/O Kit (specifically, device drivers built with the I/O Kit) in order to communicate with the frame buffer, the input infrastructure, and input and output devices.
  - charcircuit 10mo ago
    Window management on Windows is done by Explore which talks to DWM where the underlying windows live. Window management on MacOS is done by Dock which talks to Quartz Compositor where the underlying windows live.
    - abhinavk 10mo ago
      You are conflating Window Manager with Task Switcher programs.
      - charcircuit 10mo ago
        No, I'm not. Explore and Dock are responsible for more than just that.
        simondotau 10mo ago
        Sorry but you’re just wrong. Explore.exe and Dock.app are nere user interfaces and are not involved in the render pipeline of other apps.
        charcircuit 10mo ago
        I am talking about window management. Window management is about controling windows, windows managers should not care about how windows are rendered.
        dagmx 10mo ago
        1. Nobody else is talking about managing windows as a user. They’re talking about the system that manages windows for drawing and interaction. 2. You’re provably wrong even if someone followed your description because you can kill the dock or explorer process and still be able to switch between windows and move them around. Killing explorer is a little more heavy handed than killing the dock but it doesn’t take down the window manager.
secure 10mo ago
No, the lesson of “separate display server from window manager” was very clear when Wayland was started. People have been discussing this over the years ever since. (See also “client-side decorations” for another part of this issue that was heavily discussed.)
- mananaysiempre 10mo ago
  I seem to remember reading in an old paper (1990s?) that the asynchronous nature of the connection between the X server and the window manager results in essentially unfixable protocol-level races.
  - immibis 10mo ago
    Wayland has a philosophy of "every frame is perfect", which means fixing every race condition. However, X11 doesn't have this philosophy. If the window manager is slow and doesn't respond to a notification that a window has been resized, drawing the new window content over the old borders is the correct thing to do. What sense does it make to freeze the whole display just for a window border? Similarly, tearing gets pixels to the screen faster.
    - silon42 10mo ago
      Reacting somehow to user input, even if not perfect, is more important for me... That's why we have HW cursors, and frame interpolation in games, etc...
      - gf000 10mo ago
        HW cursor is an implementation detail, and are used by basically every wayland implementation. And reacting is one thing, big black rectangles blinking on screen is another.
    - mananaysiempre 10mo ago
      The races I recall being described were substantially worse, but that’s largely beside my point. My point is that, now that bare fillrate and framebuffer memory haven’t been a limiting factor for 15 to 20 years, it is a reasonable choice to build a desktop graphics system with the invariant of every frame being perfect—not even because of the user experience, but because that allows the developer to unequivocally classify every imperfect frame as a bug. Invariants are nice like that. And once that decision has been made, you cannot have asynchronous out-of-process window management. (I’m not convinced that out-of-process but synchronous is useful.) A reasonable choice is not necessarily the right choice, but neither is it moronic, and I’ve yet to see a discussion of that choice that doesn’t start with calling (formerly-X11) Wayland designers morons for not doing the thing that X11 did (if in not so many words). To be clear, I’m still low-key pissed that a crash in my desktop shell, which was deliberately designed as a dynamic-language extensibility free-for-all in the vein of Emacs or TeX, crashes my entire graphical session, also as a result of deliberate design. The combination of those two reasonable decisions is, in fact, moronic. But it didn’t need to be done that way even on Wayland.
exe34 10mo ago
No, this was a major point of discussion right at the start. They chose to ignore it.
- naikrovek 10mo ago
  They should have looked at Plan9 and the Rio window manager there. I don’t know how GPU acceleration would have fit in, but I bet it would have been trivial provided the drivers were sufficient. All of Rio in Plan9 is 6K lines of code and it’s a more powerful display protocol and window manager (all of the fundamentals are there but none of the niceties) than anything else I’ve ever seen. The defacto way to remote into a Plan9 system from any OS even today is to use a client side program which implements it all the same way Plan9 does.
  - tuna74 10mo ago
    The beauty with Free Software and Linux distros is that "they" don't have to do it, anyone who wants to (including you!) can do it.
    - Oxodao 10mo ago
      In theory. In practice, every app is designed for X11 or Wayland, building your own means you need to follow what most people use anyway if you want to have any working app on your system, or rewrite every app yourself
      - tuna74 10mo ago
        5-10 years ago there were no apps designed for Wayland. If you build it they (app developers) might actually come!
    - exe34 10mo ago
      yep, that's why I stuck with x11, as it still does everything I need it to do. it's actually never crashed since they stopped fixing it.
DonHopkins 10mo ago
It also failed to learn the lessons it should have learned from NeWS.
StopDisinfo910 10mo ago
Disagree. You need this amount of control to be able to properly filter and secure things. Wayland actually learnt that from X security extensions failure. To me, Wayland failures are more on the organisational and change management part. In inside, it would probably have been better to provide a core library rather a reference implementation. Also, a lot of pieces needed to fall into place once the ball started rolling and some of them like PipeWire took quite some time to be ready. The sorry fragmentation and complete unwillingness to work together of the various Linux DE also didn't help. I think Gnome constant NIH syndrome and overall capture of Freedesktop has a lot to do with where we are.
hakfoo 10mo ago
Wayland should have been been a research project rather than a full replacement for X11. Build it as a proof of concept implementation with just enough functionality that enthusiasts can get it up and running and add to the conversation early on. Then when you build the real X11 killer you can say "we know people want media keys and screen sharing/capture to Just Work so they're table stakes" and "the hardware-support side of a compositor is a big lift, so maybe we delegate that away from the code that positions windows and draws menus on the screen"

hsbauauvhabzb 10mo ago

I think the lack of base abstraction layer was pretty obvious from the start.

the_why_of_y 10mo ago
Since this is a Wayland thread, obviously the problem is a lack of a common implementation, which deviates from UNIX tradition. For those who want to complain how lack of choice between multiple implementations is an obvious problem and deviates from UNIX tradition, please wait until the next systemd thread.
- hsbauauvhabzb 10mo ago
  Weird strawman, but you do you.

charcircuit 10mo ago

>That's easy to say in hindsight That's an easy way to excuse bad design. Look at the designs of other operating systems designed by professionals and you won't see windows managers having to handle raw inputs or being in the same process as the compositor.

the_why_of_y 10mo ago
Examples of other operating systems allegedly not designed by professionals: https://en.wikipedia.org/wiki/Desktop_Window_Manager https://en.wikipedia.org/wiki/Desktop_Window_Manager The Desktop Window Manager is a compositing window manager, meaning that each program has a buffer that it writes data to; DWM then composites each program's buffer into a final image. https://web.archive.org/web/20040925095929/http://developer.apple.com/documentation/MacOSX/COnceptual/SystemOverview/SystemArchitecture/chapter_3_section_4.html https://web.archive.org/web/20040925095929/http://developer.... The Quartz Compositor layer of Mac OS X comprises the window server and the (private) system programming interfaces (SPI) implemented by the window server. In this layer are the facilities responsible for rudimentary screen displays, window compositing and management, event routing, and cursor management. The window server is a single system-wide process that coordinates low-level windowing behavior and enforces a fundamental uniformity in what appears on the screen. It is a lightweight server in that it does not do any rendering itself, but instead communicates with the client graphics libraries layered on top of it. It is “agnostic” in terms of a drawing model. The window server has few dependencies on other system services and libraries. It relies on the kernel environment’s I/O Kit (specifically, device drivers built with the I/O Kit) in order to communicate with the frame buffer, the input infrastructure, and input and output devices.
- charcircuit 10mo ago
  Window management on Windows is done by Explore which talks to DWM where the underlying windows live. Window management on MacOS is done by Dock which talks to Quartz Compositor where the underlying windows live.
  - abhinavk 10mo ago
    You are conflating Window Manager with Task Switcher programs.
    - charcircuit 10mo ago
      No, I'm not. Explore and Dock are responsible for more than just that.
      - simondotau 10mo ago
        Sorry but you’re just wrong. Explore.exe and Dock.app are nere user interfaces and are not involved in the render pipeline of other apps.
        charcircuit 10mo ago
        I am talking about window management. Window management is about controling windows, windows managers should not care about how windows are rendered.
        dagmx 10mo ago
        1. Nobody else is talking about managing windows as a user. They’re talking about the system that manages windows for drawing and interaction. 2. You’re provably wrong even if someone followed your description because you can kill the dock or explorer process and still be able to switch between windows and move them around. Killing explorer is a little more heavy handed than killing the dock but it doesn’t take down the window manager.

secure 10mo ago

No, the lesson of “separate display server from window manager” was very clear when Wayland was started. People have been discussing this over the years ever since. (See also “client-side decorations” for another part of this issue that was heavily discussed.)

mananaysiempre 10mo ago
I seem to remember reading in an old paper (1990s?) that the asynchronous nature of the connection between the X server and the window manager results in essentially unfixable protocol-level races.
- immibis 10mo ago
  Wayland has a philosophy of "every frame is perfect", which means fixing every race condition. However, X11 doesn't have this philosophy. If the window manager is slow and doesn't respond to a notification that a window has been resized, drawing the new window content over the old borders is the correct thing to do. What sense does it make to freeze the whole display just for a window border? Similarly, tearing gets pixels to the screen faster.
  - silon42 10mo ago
    Reacting somehow to user input, even if not perfect, is more important for me... That's why we have HW cursors, and frame interpolation in games, etc...
    - gf000 10mo ago
      HW cursor is an implementation detail, and are used by basically every wayland implementation. And reacting is one thing, big black rectangles blinking on screen is another.
  - mananaysiempre 10mo ago
    The races I recall being described were substantially worse, but that’s largely beside my point. My point is that, now that bare fillrate and framebuffer memory haven’t been a limiting factor for 15 to 20 years, it is a reasonable choice to build a desktop graphics system with the invariant of every frame being perfect—not even because of the user experience, but because that allows the developer to unequivocally classify every imperfect frame as a bug. Invariants are nice like that. And once that decision has been made, you cannot have asynchronous out-of-process window management. (I’m not convinced that out-of-process but synchronous is useful.) A reasonable choice is not necessarily the right choice, but neither is it moronic, and I’ve yet to see a discussion of that choice that doesn’t start with calling (formerly-X11) Wayland designers morons for not doing the thing that X11 did (if in not so many words). To be clear, I’m still low-key pissed that a crash in my desktop shell, which was deliberately designed as a dynamic-language extensibility free-for-all in the vein of Emacs or TeX, crashes my entire graphical session, also as a result of deliberate design. The combination of those two reasonable decisions is, in fact, moronic. But it didn’t need to be done that way even on Wayland.

exe34 10mo ago

No, this was a major point of discussion right at the start. They chose to ignore it.

naikrovek 10mo ago
They should have looked at Plan9 and the Rio window manager there. I don’t know how GPU acceleration would have fit in, but I bet it would have been trivial provided the drivers were sufficient. All of Rio in Plan9 is 6K lines of code and it’s a more powerful display protocol and window manager (all of the fundamentals are there but none of the niceties) than anything else I’ve ever seen. The defacto way to remote into a Plan9 system from any OS even today is to use a client side program which implements it all the same way Plan9 does.
- tuna74 10mo ago
  The beauty with Free Software and Linux distros is that "they" don't have to do it, anyone who wants to (including you!) can do it.
  - Oxodao 10mo ago
    In theory. In practice, every app is designed for X11 or Wayland, building your own means you need to follow what most people use anyway if you want to have any working app on your system, or rewrite every app yourself
    - tuna74 10mo ago
      5-10 years ago there were no apps designed for Wayland. If you build it they (app developers) might actually come!
  - exe34 10mo ago
    yep, that's why I stuck with x11, as it still does everything I need it to do. it's actually never crashed since they stopped fixing it.

DonHopkins 10mo ago

It also failed to learn the lessons it should have learned from NeWS.

StopDisinfo910 10mo ago

Disagree. You need this amount of control to be able to properly filter and secure things. Wayland actually learnt that from X security extensions failure. To me, Wayland failures are more on the organisational and change management part. In inside, it would probably have been better to provide a core library rather a reference implementation. Also, a lot of pieces needed to fall into place once the ball started rolling and some of them like PipeWire took quite some time to be ready. The sorry fragmentation and complete unwillingness to work together of the various Linux DE also didn't help. I think Gnome constant NIH syndrome and overall capture of Freedesktop has a lot to do with where we are.

hakfoo 10mo ago

Wayland should have been been a research project rather than a full replacement for X11. Build it as a proof of concept implementation with just enough functionality that enthusiasts can get it up and running and add to the conversation early on. Then when you build the real X11 killer you can say "we know people want media keys and screen sharing/capture to Just Work so they're table stakes" and "the hardware-support side of a compositor is a big lift, so maybe we delegate that away from the code that positions windows and draws menus on the screen"