That guy is scaring me. 😬
That guy is scaring me. 😬
That guy is scaring me. 😬
That guy is scaring me. 😬
- The Wayland wire protocol aside, you have to do everything yourself: Manage display buffers (let’s say “on an OpenGL level”), handle monitors, handle mouse/keyboard/whatever input, … Basically everything that the X server does today. *You* have to write that code now.
- There is basically only one library that truly tries to help you here: wlroots https://gitlab.freedesktop.org/wlroots/wlroots/ (this is already a “third party” library, it’s from the Sway project; Sway being a port of i3wm to Wayland)
- On top of that, you implement decorations, window management, …
- Then there is a myriad of protocol extension and a little battle between GNOME, KDE, and the rest of the world. For example, GNOME wants to enforce client-side decorations, the others don’t. Many of the protocol extensions are still unstable. To give you an idea of what is meant by “protocol extension”: https://wayland.app/protocols/
- You very much need *an X11 compatibility layer* that runs on top of Wayland for backwards compatibility, and this is usually implemented in the compositor as well.
What X11 gave us was a server that allowed programs to draw windows. And then we could have totally different programs that managed those windows. This was *awesome*. Yes, there are problems. But instead of refining this model and extending it, we are being nudged into having “the Wayland compositor”, which is responsible for everything.
Wayland cares a lot about “each frame is perfect”. Clients draw a full frame into a buffer and then the compositor will use that buffer to assemble the next frame. So there is no more “flickering”, like we have with X11 now. (You’re probably used to it and don’t notice it.) This is one of the main goals and I *suspect* that this is part of the reason why everything has to be done in the compositor? Not sure.
I *think* it would be possible to split all this into different components. Problem is, nobody does it that way. There’s GNOME, which doesn’t care about any of this, they’re a huge project with a ton of manpower, they just do what they want. I don’t know what KDE does. Sway made wlroots, which is probably the best thing we have, but even Sway is just a library that you link against, so you end up with one single binary.
Just look at “TinyWL”, the “minimum viable product Wayland compositor based on wlroots”: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/tinywl/tinywl.c – Look at the size of that thing!
I heard people complain and give up, because Wayland/wlroots is moving so fast that they can’t keep up with their own “toy” compositor. @z3bra tried it and eventually gave up.
Note that there were many small Wayland compositors in the beginning, but they all died. I don’t know why, though.
Bottom line is: With X11, it was easy enough to write a window manager, so that one single person could do it. This allows me to run a fully customized desktop environment. With Wayland, there is no “server” anymore and I would have to do *so much more work*, that it’s just not feasible anymore. Result: I’d probably be stuck with *some* desktop environment that I’d hardly be able to customize. And that would suck *a lot*.
But that’s only the status quo. Maybe things will change dramatically, when X11 really dies. I suspect there’s a lot of demand for small niche compositors, and I hope that we will get into a similar situation like today (tons of WMs and DEs to chose from, or you write your own). But we’re a long way from that and things are *not* going in that direction.
- The Wayland wire protocol aside, you have to do everything yourself: Manage display buffers (let’s say “on an OpenGL level”), handle monitors, handle mouse/keyboard/whatever input, … Basically everything that the X server does today. *You* have to write that code now.
- There is basically only one library that truly tries to help you here: wlroots https://gitlab.freedesktop.org/wlroots/wlroots/ (this is already a “third party” library, it’s from the Sway project; Sway being a port of i3wm to Wayland)
- On top of that, you implement decorations, window management, …
- Then there is a myriad of protocol extension and a little battle between GNOME, KDE, and the rest of the world. For example, GNOME wants to enforce client-side decorations, the others don’t. Many of the protocol extensions are still unstable. To give you an idea of what is meant by “protocol extension”: https://wayland.app/protocols/
- You very much need *an X11 compatibility layer* that runs on top of Wayland for backwards compatibility, and this is usually implemented in the compositor as well.
What X11 gave us was a server that allowed programs to draw windows. And then we could have totally different programs that managed those windows. This was *awesome*. Yes, there are problems. But instead of refining this model and extending it, we are being nudged into having “the Wayland compositor”, which is responsible for everything.
Wayland cares a lot about “each frame is perfect”. Clients draw a full frame into a buffer and then the compositor will use that buffer to assemble the next frame. So there is no more “flickering”, like we have with X11 now. (You’re probably used to it and don’t notice it.) This is one of the main goals and I *suspect* that this is part of the reason why everything has to be done in the compositor? Not sure.
I *think* it would be possible to split all this into different components. Problem is, nobody does it that way. There’s GNOME, which doesn’t care about any of this, they’re a huge project with a ton of manpower, they just do what they want. I don’t know what KDE does. Sway made wlroots, which is probably the best thing we have, but even Sway is just a library that you link against, so you end up with one single binary.
Just look at “TinyWL”, the “minimum viable product Wayland compositor based on wlroots”: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/tinywl/tinywl.c – Look at the size of that thing!
I heard people complain and give up, because Wayland/wlroots is moving so fast that they can’t keep up with their own “toy” compositor. @z3bra tried it and eventually gave up.
Note that there were many small Wayland compositors in the beginning, but they all died. I don’t know why, though.
Bottom line is: With X11, it was easy enough to write a window manager, so that one single person could do it. This allows me to run a fully customized desktop environment. With Wayland, there is no “server” anymore and I would have to do *so much more work*, that it’s just not feasible anymore. Result: I’d probably be stuck with *some* desktop environment that I’d hardly be able to customize. And that would suck *a lot*.
But that’s only the status quo. Maybe things will change dramatically, when X11 really dies. I suspect there’s a lot of demand for small niche compositors, and I hope that we will get into a similar situation like today (tons of WMs and DEs to chose from, or you write your own). But we’re a long way from that and things are *not* going in that direction.
- The Wayland wire protocol aside, you have to do everything yourself: Manage display buffers (let’s say “on an OpenGL level”), handle monitors, handle mouse/keyboard/whatever input, … Basically everything that the X server does today. *You* have to write that code now.
- There is basically only one library that truly tries to help you here: wlroots https://gitlab.freedesktop.org/wlroots/wlroots/ (this is already a “third party” library, it’s from the Sway project; Sway being a port of i3wm to Wayland)
- On top of that, you implement decorations, window management, …
- Then there is a myriad of protocol extension and a little battle between GNOME, KDE, and the rest of the world. For example, GNOME wants to enforce client-side decorations, the others don’t. Many of the protocol extensions are still unstable. To give you an idea of what is meant by “protocol extension”: https://wayland.app/protocols/
- You very much need *an X11 compatibility layer* that runs on top of Wayland for backwards compatibility, and this is usually implemented in the compositor as well.
What X11 gave us was a server that allowed programs to draw windows. And then we could have totally different programs that managed those windows. This was *awesome*. Yes, there are problems. But instead of refining this model and extending it, we are being nudged into having “the Wayland compositor”, which is responsible for everything.
Wayland cares a lot about “each frame is perfect”. Clients draw a full frame into a buffer and then the compositor will use that buffer to assemble the next frame. So there is no more “flickering”, like we have with X11 now. (You’re probably used to it and don’t notice it.) This is one of the main goals and I *suspect* that this is part of the reason why everything has to be done in the compositor? Not sure.
I *think* it would be possible to split all this into different components. Problem is, nobody does it that way. There’s GNOME, which doesn’t care about any of this, they’re a huge project with a ton of manpower, they just do what they want. I don’t know what KDE does. Sway made wlroots, which is probably the best thing we have, but even Sway is just a library that you link against, so you end up with one single binary.
Just look at “TinyWL”, the “minimum viable product Wayland compositor based on wlroots”: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/tinywl/tinywl.c – Look at the size of that thing!
I heard people complain and give up, because Wayland/wlroots is moving so fast that they can’t keep up with their own “toy” compositor. @z3bra tried it and eventually gave up.
Note that there were many small Wayland compositors in the beginning, but they all died. I don’t know why, though.
Bottom line is: With X11, it was easy enough to write a window manager, so that one single person could do it. This allows me to run a fully customized desktop environment. With Wayland, there is no “server” anymore and I would have to do *so much more work*, that it’s just not feasible anymore. Result: I’d probably be stuck with *some* desktop environment that I’d hardly be able to customize. And that would suck *a lot*.
But that’s only the status quo. Maybe things will change dramatically, when X11 really dies. I suspect there’s a lot of demand for small niche compositors, and I hope that we will get into a similar situation like today (tons of WMs and DEs to chose from, or you write your own). But we’re a long way from that and things are *not* going in that direction.