4 ms·

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 W

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

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