4 ms·

It forces some kind of modularity. Maybe that is a good thing. We don't have all features of X11 in Wayland but we also have features in Wayland that are missin

It forces some kind of modularity. Maybe that is a good thing. We don't have all features of X11 in Wayland but we also have features in Wayland that are missing in X11. I have been on Wayland for a while now and I can't say I am really suffering. There are some tings I'd like improved further but the protocol is evolving all the time. I think we'll get there. Also the decision is already made by the big distros anyways. They seem to be mostly happy.

wahern 27d ago
> It forces some kind of modularity. Wayland is the complete opposite of modular; that's why the compositor has to handle everything. The claimed problem with X11 was it was too modular, easy for different clients to control various aspects of the environment, but perhaps too easy, lacking a security policy framework to limit client access. (Or at least a framework that was fully baked. Wayland put an end to such initiatives.) The lack of modularity in Wayland has been widening the rift between the desktop environments. It's as-if KDE and GNOME each forked X11 and went their own ways.
- throwaway84932 27d ago
  > Wayland is the complete opposite of modular Not true. Wayland simply cuts out the middleman. Making the compositor the display server is one of the best things Wayland did. This brings so many advantages, such as true tear-free graphics and lower input latency.
  - account42 26d ago
    The middle man was there to make sure everyone understood each other. Now simple things like taking a screenshot requires programs to speak multiple different languages.
    - throwaway84932 26d ago
      Again, not true: if you want to take a screenshot in a generic way, you have to go through the XDG portal API, which is generic across all the compositors that support them, i.e. most of them.
      - wahern 26d ago
        The XDG Portal framework is obscenely complex (PipeWire, D-BUS over separate channels, etc), still requires each individual compositor and other components to specifically implement various aspects for things like screen sharing, and there's a ton of broken edges between the myriad interacting components. All-in-all the complete opposite of modular. And that's the point. X11 provided a framework for all of this. Not perfect, but deliberately extensible. The Wayland alternatives are so much more complicated and brittle, and have to work around the limitations of Wayland. The effort expended by groups like freedesktop.org to architect and standardize new features would have been (and was) so much more productive in the X11 world.
        throwaway84932 26d ago
        I understand where you're coming from, but there is no turning back at this point. Sure, you could still run dwm on Xorg or Xlibre and pretend Wayland doesn't exist, but the reality is that the vast majority of Linux distributions and desktop environments have already committed to this stack, and application developers are going to target these portals. There's also talk of D-Bus eventually being replaced with Varlink [0], showing that this whole ecosystem is still very much a moving target. What feels like endless breakage and friction right now is really just the noise of a massive architectural migration in progress. Eventually, the dust will settle, the APIs will stabilize, and the whole stack will become boring, reliable, and really good. That is how I prefer to look at it. If you want to see things move in a specific direction or address any particular problem, the best path forward is to get involved and participate in the projects that interest you. [0] - https://www.youtube.com/watch?v=NsVhkz2Xl0E&t=1415s https://www.youtube.com/watch?v=NsVhkz2Xl0E&t=1415s
  - ToyKeeper 26d ago
    > This brings so many advantages, such as true tear-free graphics and lower input latency. Curiously, people always seem to list the same advantages, and it's a very short list. Fewer (but still non-zero) torn frames are the top of the list pretty much every time, since that was the very first thing its creator listed in his original goals... but that's a pretty small benefit in exchange for breaking entire categories of functionality. Like, it looks smoother when I scroll, but features I rely on heavily every day are forbidden. As for input latency... that doesn't seem like it was ever a problem. Using X11, I'm able to get 500 to 1000 inputs per second even on a potato PC. That's faster than the frame rate of pretty much any screen, and fast enough even for audio / midi purposes. Reducing input latency from ~1.5ms to ~1.0ms doesn't really matter when the timeslice scheduling has ~6ms of jitter on an average system, a common screen only draws a frame every ~16ms, and many input devices have 50+ ms of their own additional latency. > if you want to take a screenshot in a generic way, you have to go through the XDG portal API This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. Like many things users need, they decided it was someone else's problem, and threw it over the fence for the fragmented ecosystem of downstream projects to solve. So each downstream project came up with their own workarounds for essential features not existing. The solutions had to be built entirely outside of Wayland, and even after years of development, the solutions are still incomplete, unreliable, complex, and full of caveats. It required (and still requires) everyone except Wayland's core devs to write a lot more code for less functionality than they used to get with a couple of simple API calls. They had to architect entire complex infrastructure layers in order to work around a missing feature in the core protocol, since the core devs stubbornly refused to allow it. Similar situation for input automation and remote control. It's a common thing people need. I use it every day and can't use the notebook at my desk without it... but the Wayland folks refused to solve it, so it had to be done outside of Wayland. For example, one workaround is to give the user direct access to the kernel so they can create fake input devices at a kernel level, and generate the inputs they need, which Wayland then sees as a local physical keyboard or mouse. So... problem solved, from Wayland's point of view. The user gets what they need, sort of, and it's implemented outside of Wayland, so Wayland doesn't have any security issues. But... and this is a big "but"... the solution involves giving users device-level kernel access. Which seems significantly worse than the issue it was originally trying to solve. > I understand where you're coming from, but there is no turning back at this point. A position of "sure it has major problems, but it's too late now" is not a position of progress. Much like the situation with pulseaudio being deployed everywhere then replaced with pipewire, it's almost never too late to fix bad software architecture. As you said, this whole ecosystem is still very much a moving target. The ideal solution would be the creation of a new system which supports the features, protocols, and APIs of the older system(s), in a way which "just works". But that requires a very different mindset from the people behind it. Instead of "not my problem, someone else can deal with it" like the Wayland policy, a proper solution needs people to adopt a "the buck stops here" approach, and take responsibility for making the entire system work. Things like accessibility, network transparency, automation, and legacy support... need to be built in from the ground up, not rejected or treated as an afterthought for someone else to handle.

wahern 27d ago

> It forces some kind of modularity. Wayland is the complete opposite of modular; that's why the compositor has to handle everything. The claimed problem with X11 was it was too modular, easy for different clients to control various aspects of the environment, but perhaps too easy, lacking a security policy framework to limit client access. (Or at least a framework that was fully baked. Wayland put an end to such initiatives.) The lack of modularity in Wayland has been widening the rift between the desktop environments. It's as-if KDE and GNOME each forked X11 and went their own ways.

throwaway84932 27d ago
> Wayland is the complete opposite of modular Not true. Wayland simply cuts out the middleman. Making the compositor the display server is one of the best things Wayland did. This brings so many advantages, such as true tear-free graphics and lower input latency.
- account42 26d ago
  The middle man was there to make sure everyone understood each other. Now simple things like taking a screenshot requires programs to speak multiple different languages.
  - throwaway84932 26d ago
    Again, not true: if you want to take a screenshot in a generic way, you have to go through the XDG portal API, which is generic across all the compositors that support them, i.e. most of them.
    - wahern 26d ago
      The XDG Portal framework is obscenely complex (PipeWire, D-BUS over separate channels, etc), still requires each individual compositor and other components to specifically implement various aspects for things like screen sharing, and there's a ton of broken edges between the myriad interacting components. All-in-all the complete opposite of modular. And that's the point. X11 provided a framework for all of this. Not perfect, but deliberately extensible. The Wayland alternatives are so much more complicated and brittle, and have to work around the limitations of Wayland. The effort expended by groups like freedesktop.org to architect and standardize new features would have been (and was) so much more productive in the X11 world.
      - throwaway84932 26d ago
        I understand where you're coming from, but there is no turning back at this point. Sure, you could still run dwm on Xorg or Xlibre and pretend Wayland doesn't exist, but the reality is that the vast majority of Linux distributions and desktop environments have already committed to this stack, and application developers are going to target these portals. There's also talk of D-Bus eventually being replaced with Varlink [0], showing that this whole ecosystem is still very much a moving target. What feels like endless breakage and friction right now is really just the noise of a massive architectural migration in progress. Eventually, the dust will settle, the APIs will stabilize, and the whole stack will become boring, reliable, and really good. That is how I prefer to look at it. If you want to see things move in a specific direction or address any particular problem, the best path forward is to get involved and participate in the projects that interest you. [0] - https://www.youtube.com/watch?v=NsVhkz2Xl0E&t=1415s https://www.youtube.com/watch?v=NsVhkz2Xl0E&t=1415s
- ToyKeeper 26d ago
  > This brings so many advantages, such as true tear-free graphics and lower input latency. Curiously, people always seem to list the same advantages, and it's a very short list. Fewer (but still non-zero) torn frames are the top of the list pretty much every time, since that was the very first thing its creator listed in his original goals... but that's a pretty small benefit in exchange for breaking entire categories of functionality. Like, it looks smoother when I scroll, but features I rely on heavily every day are forbidden. As for input latency... that doesn't seem like it was ever a problem. Using X11, I'm able to get 500 to 1000 inputs per second even on a potato PC. That's faster than the frame rate of pretty much any screen, and fast enough even for audio / midi purposes. Reducing input latency from ~1.5ms to ~1.0ms doesn't really matter when the timeslice scheduling has ~6ms of jitter on an average system, a common screen only draws a frame every ~16ms, and many input devices have 50+ ms of their own additional latency. > if you want to take a screenshot in a generic way, you have to go through the XDG portal API This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. Like many things users need, they decided it was someone else's problem, and threw it over the fence for the fragmented ecosystem of downstream projects to solve. So each downstream project came up with their own workarounds for essential features not existing. The solutions had to be built entirely outside of Wayland, and even after years of development, the solutions are still incomplete, unreliable, complex, and full of caveats. It required (and still requires) everyone except Wayland's core devs to write a lot more code for less functionality than they used to get with a couple of simple API calls. They had to architect entire complex infrastructure layers in order to work around a missing feature in the core protocol, since the core devs stubbornly refused to allow it. Similar situation for input automation and remote control. It's a common thing people need. I use it every day and can't use the notebook at my desk without it... but the Wayland folks refused to solve it, so it had to be done outside of Wayland. For example, one workaround is to give the user direct access to the kernel so they can create fake input devices at a kernel level, and generate the inputs they need, which Wayland then sees as a local physical keyboard or mouse. So... problem solved, from Wayland's point of view. The user gets what they need, sort of, and it's implemented outside of Wayland, so Wayland doesn't have any security issues. But... and this is a big "but"... the solution involves giving users device-level kernel access. Which seems significantly worse than the issue it was originally trying to solve. > I understand where you're coming from, but there is no turning back at this point. A position of "sure it has major problems, but it's too late now" is not a position of progress. Much like the situation with pulseaudio being deployed everywhere then replaced with pipewire, it's almost never too late to fix bad software architecture. As you said, this whole ecosystem is still very much a moving target. The ideal solution would be the creation of a new system which supports the features, protocols, and APIs of the older system(s), in a way which "just works". But that requires a very different mindset from the people behind it. Instead of "not my problem, someone else can deal with it" like the Wayland policy, a proper solution needs people to adopt a "the buck stops here" approach, and take responsibility for making the entire system work. Things like accessibility, network transparency, automation, and legacy support... need to be built in from the ground up, not rejected or treated as an afterthought for someone else to handle.