3 ms·

While technically correct, this misses the point. Very few features are part of the core Wayland protocol; off the top of my bind, there's the input methods, an

While technically correct, this misses the point. Very few features are part of the core Wayland protocol; off the top of my bind, there's the input methods, and a few ways to describe shared memory with the compositor and some callbacks to handle device registration. That's it. For example, top level windows and popups themselves are an extension in Wayland (xdg_shell protocol rather than the defunct wl_shell), and so is the rather basic feature of compositing on the GPU (dma_buf) rather than going through some shared CPU memory.

jcelerier 6y ago
> Very few features are part of the core Wayland protocol; but that is the main critique. Most of the things not being part of core means that there is a lot more fragmentation of the linux desktop than there was with X, which is unilaterally a bad thing.
- akvadrako 6y ago
  The Wayland base can be implemented in a library, like wlroots, which complete compositors could use. Currently compositor developers prefer separate implementations and it's really their choice.
  - jcelerier 6y ago
    the fact that the system provides a choice is the issue that leads to fragmentation (which is the main problem). Saying "people could just do / not do X" absolutely never ever ever works, not in politics, not in programming, not in "not being an asshole to each other", not in "not using firearms", etc - things have to be enforced & unescapable at some point if we want sanity.
    - ywei3410 6y ago
      I’m not entirely sure that I understand your point. Here are the facts which I think we can agree on. * X11 is a protocol * Wayland is a protocol * X11 and Wayland are not compatible protocols * Wayland protocols are all public * XOrg is an implementation of the compositor of the X11 protocol * wl_roots is a toolkit used for creating compositors From this, it follows that: * Anyone can theoretically write another X11 compositor which implements a subset of the functionality * Anyone can write a Wayland compositor which implements a subset of the functionality I really don’t understand where this supposed extra fragmentation is coming from — unless your objection is that we have more than one Wayland compositor? I don’t see that as a particularly bad; in the same way I don’t see having GNOME, i3 and XFCE existing is necessarily problematic.
      - corty 6y ago
        The wayland protocol (with the very few standard common extensions) does far less than the X11 protocol. There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own incompatible variant of the Wayland protocol. In that sense, it is not one Wayland protocol but a whole cesspool of them... It will also get worse, because the architecture of wayland forces an implementer of a compositor (which replaces an X11 window manager) to implement a lot of the display functionality all over again. Wayland itself is just a lib that helps a little with it. In X11 terms, just imagine every window manager developer doing development against their own fork of X.org or a reimplementation of it. Wayland is designed in such a way that it causes incompatibility and fragmentation.
        ywei3410 6y ago
        > There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own incompatible variant of the Wayland protocol. Well no — this is where I disagree. The extensions are standard and hosted within the repository [1]. A repository may support their own proprietary protocol, after all it’s an XML file, but practically speaking without distributing it through the repository means that you won’t get any clients to actually use it. It is wrong to suggest that there is a huge proliferation of interfaces. It is true that the core Wayland protocols support less functionality than X11. It’s also true that developers implementing windowing managers need to do more work — however, again I point you towards wl_roots, libinput etc. as examples to show that you don’t need to implement anything from scratch unless you want to. I don’t believe this particular design doesn’t have trade-offs, but to pretend that it has no benefits is also incorrect. The fact that there are less core protocols means that you can implement a simpler compositor if you should so wish. There are comments in this thread pointing to the usage of Wayland in different devices as an application of this. [1] https://github.com/wayland-project/wayland-protocols https://github.com/wayland-project/wayland-protocols

jcelerier 6y ago

> Very few features are part of the core Wayland protocol; but that is the main critique. Most of the things not being part of core means that there is a lot more fragmentation of the linux desktop than there was with X, which is unilaterally a bad thing.

akvadrako 6y ago
The Wayland base can be implemented in a library, like wlroots, which complete compositors could use. Currently compositor developers prefer separate implementations and it's really their choice.
- jcelerier 6y ago
  the fact that the system provides a choice is the issue that leads to fragmentation (which is the main problem). Saying "people could just do / not do X" absolutely never ever ever works, not in politics, not in programming, not in "not being an asshole to each other", not in "not using firearms", etc - things have to be enforced & unescapable at some point if we want sanity.
  - ywei3410 6y ago
    I’m not entirely sure that I understand your point. Here are the facts which I think we can agree on. * X11 is a protocol * Wayland is a protocol * X11 and Wayland are not compatible protocols * Wayland protocols are all public * XOrg is an implementation of the compositor of the X11 protocol * wl_roots is a toolkit used for creating compositors From this, it follows that: * Anyone can theoretically write another X11 compositor which implements a subset of the functionality * Anyone can write a Wayland compositor which implements a subset of the functionality I really don’t understand where this supposed extra fragmentation is coming from — unless your objection is that we have more than one Wayland compositor? I don’t see that as a particularly bad; in the same way I don’t see having GNOME, i3 and XFCE existing is necessarily problematic.
    - corty 6y ago
      The wayland protocol (with the very few standard common extensions) does far less than the X11 protocol. There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own incompatible variant of the Wayland protocol. In that sense, it is not one Wayland protocol but a whole cesspool of them... It will also get worse, because the architecture of wayland forces an implementer of a compositor (which replaces an X11 window manager) to implement a lot of the display functionality all over again. Wayland itself is just a lib that helps a little with it. In X11 terms, just imagine every window manager developer doing development against their own fork of X.org or a reimplementation of it. Wayland is designed in such a way that it causes incompatibility and fragmentation.
      - ywei3410 6y ago
        > There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own incompatible variant of the Wayland protocol. Well no — this is where I disagree. The extensions are standard and hosted within the repository [1]. A repository may support their own proprietary protocol, after all it’s an XML file, but practically speaking without distributing it through the repository means that you won’t get any clients to actually use it. It is wrong to suggest that there is a huge proliferation of interfaces. It is true that the core Wayland protocols support less functionality than X11. It’s also true that developers implementing windowing managers need to do more work — however, again I point you towards wl_roots, libinput etc. as examples to show that you don’t need to implement anything from scratch unless you want to. I don’t believe this particular design doesn’t have trade-offs, but to pretend that it has no benefits is also incorrect. The fact that there are less core protocols means that you can implement a simpler compositor if you should so wish. There are comments in this thread pointing to the usage of Wayland in different devices as an application of this. [1] https://github.com/wayland-project/wayland-protocols https://github.com/wayland-project/wayland-protocols