10 ms·

The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to w

by dTal 4y ago

The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11. So it's a ton more work to write a Wayland compositor than an X11 window manager, and most of it is tedious boilerplate that almost certainly has nothing to do with your motivation for writing a new compositor in the first place. This in turn affords many more opportunities to introduce bugs, missing functionality etc. I trust "weird" compositors much less than I trust "weird" X11 window managers - it's more like using an alternative Xorg than an alternative WM. "...there is still a lot of boilerplate involved in writing a compositor, much more than for an X11 window manager, namely setting up your own rendering code, registering and storing input devices and screens in your own data structures, passing input events to windows, calculating bounds for bars and other overlays (courtesy of layer-shell) and others. X11 handles all of this for you..." https://tudorr.ro/blog/technical/2021/01/26/the-wayland-experience/ https://tudorr.ro/blog/technical/2021/01/26/the-wayland-expe... <edit> Several people mentioning wlroots. I can't say I've ever attempted it myself, but if you take a look at the blog post above, the author is very clear on the fact that even with the benefit of wlroots (which they highly praise) writing a Wayland compositor is still a lot more work than writing an X11 window manager (which they have also done, so they are something of an authority). wlroots doesn't abstract everything away, it just gives you a bunch of useful tools. "With Wayland, you handle everything, even with wlroots."

3836293648 4y ago
Yeah, but wlroots is taking the role of Xorg there, leaving WM writers to mostly just write the WM
- Izkata 4y ago
  I'm just wondering how long it'll be until someone uses wlroots to write a client/server architecture like Xorg...
  - TingPing 4y ago
    It will never be a popular way to use Wayland because its just a worse design.
  - Cloudef 4y ago
    It already exists and its called xwayland. Most wayland compositors also have X11 WM inside them...
    - Izkata 4y ago
      You misunderstand: I'm not talking about the X protocol, I'm talking about some new all Wayland thing just so window managers can be separated from the other things you'd otherwise have to implement.
      - pantalaimon 4y ago
        I think Mir can do that
      - Cloudef 4y ago
        Yes and ironically Xwayland is that, but you probably want something like Arcan
charcircuit 4y ago
So just push all that shared logic into a library that alternative Wayland compositers can all use. eg. wlroots
gizmo686 4y ago
This compositor, like most Wayland compositors, uses the wlroots library, so most of that tedious work is already handled for you.
zokier 4y ago
On the other hand, there is nothing in Wayland that prevents anyone from writing a compositor that splits off some window management tasks to a separate process. Afaik nobody has bothered to do so yet, but if there is demand then it could be done. Or maybe there isn't that much demand for such thing.
- dTal 4y ago
  The blog post mentions Wayfire, which has a plugin architecture, so not separate processes but an abstraction boundary at least - which is the more important thing.
- zajio1am 4y ago
  Does not phoc / phosh work like that?
- boudin 4y ago
  River does that for the windows layout https://github.com/riverwm/river https://github.com/riverwm/river
sprash 4y ago
> "With Wayland, you handle everything, even with wlroots." The observable effect of this is that the long tail of niche projects like X11 window managers, custom toolkits or small applications (that don't carry around extremely heavy dependencies like GTK/Qt) gets decimated. The assumption that this is done on purpose is plausible.
- tadfisher 4y ago
  Plausible, but not realistic or actually happening, because there's nothing at the protocol level that prevents the long tail of small compositors, toolkits or applications from implementing a Wayland backend.
  - sprash 4y ago
    > there's nothing at the protocol level that prevents the long tail Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level". As example: Compare the Wayland "Hello World" [1] with X11 "Hello World" [2]. If you want to add the ability to take screenshots it gets exponentially worse. (Also the Wayland version is not even capable to render strings.) 1.: https://github.com/emersion/hello-wayland/blob/master/main.c https://github.com/emersion/hello-wayland/blob/master/main.c 2.: https://rosettacode.org/wiki/Window_creation/X11#C https://rosettacode.org/wiki/Window_creation/X11#C
    - QUrprUd1nCeicw 4y ago
      >Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level". No, all those can be solved with client libraries. X11 had Xlib and the other client libraries. Those X11 libraries don't make sense in Wayland, but the client libraries that stayed relevant (freetype, cairo, etc) can still be used. >If you want to add the ability to take screenshots it gets exponentially worse. No, in both modern X11 or Wayland, you should use the same API for screenshots: the XDG screenshot portal. >Also the Wayland version is not even capable to render strings. Sure it is, but you have to use client-side rendering. Client-side rendering is also the norm in X11, since decades ago when Xft was released as another one of those client libraries. That X11 hello world is short because it's using obsolete APIs.
kaba0 4y ago
An X11 window manager is more akin to a gnome extension than a proper window manager. Just because writing such a plugin is easy shouldn’t make our expectations all that different. And frankly, for putting together a window manager the proper choice of action is extending an already existing compositor.
QUrprUd1nCeicw 4y ago
>The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11. That comparison is a bad one to make. Compared to just a window manager, that's correct. But you have to compare Wayland compositors to X11 compositors and for that it's about the same amount of work. Either one expects you to bring your own rendering because that's the main benefit of writing a compositor. It also might make sense to compare X11 window managers to compositor plugins. The reason people seem to prefer wlroots is precisely because it offers more power and more control over the just writing a window manager.
- dTal 4y ago
  It's not a bad comparison to make when people are writing entire new compositors just to provide, say, a tiling experience - exactly the way they used to write window managers. I understand you're trying to be "fair" to Wayland here but the fact is there is a lack of an abstraction boundary where there used to be one. Maybe that abstraction boundary can be reinstated by a well-written compositor with a plugin architecture, but that isn't standard the way the window manager interface is (unless you can persuade everyone to use that one compositor).
  - QUrprUd1nCeicw 4y ago
    I think you're missing that authors of tiling window managers don't actually want to go back to the X11 way of doing things. They don't want to write a basic window manager or a plugin. That abstraction boundary is bad and it's extremely limited. That's why the X Composite extension was created in the first place. There was a chance to go in the opposite direction with Wayland. People did actually make plugin APIs but they never became standard, few developers wanted to use them. Instead wlroots became popular because it allows a lot more power and flexibility over compositing. The compositing approach is what allows Hyprland to have those nice transparencies and animations. So it's not that I'm trying to be fair to Wayland, I'm actually trying to be fair to X11 compositors. You're skipping that whole step that happened in the mid-2000s when you make your comparison. People wanted to make compositors all along.
dathinab 4y ago
> wayland compositor is still a lot more work than writing If you speak about a probably working one instead of a toy one the difference between X11 and wlroots isn't that big AFIK. It's just that with X11 you could create a toy compositor with very little lines of code and that's not possible anymore. But then toy compositors also kinda don't matter in the grater picture so it's not really a problem.
roenxi 4y ago
There were some mis-steps with Wayland being too light [0] - but we're entering an exciting new era where people start experimenting in the graphics space again. wlroots might be enough, or there might be a few attempts to get the supporting libraries right. But it'll be solved in time. [0] There was a subtle mechanism-not-policy error where they made screenshots impossible without some back-channel being available. In hindsight, there should have been mechanisms for sharing buffers at the protocol level. "Can't share" turned out to be a forced policy, and the wrong one.
- p_l 4y ago
  Like many other things (including, originally, copy-paste), you were supposed to use your desktop environment's support for this over to-be-specified D-Bus API
- QUrprUd1nCeicw 4y ago
  No, that wasn't a mis-step and it wasn't the wrong policy. Wayland is primarily concerned with taking buffers and telling the GPU to put them on the screen. Buffer sharing between clients is more concerned with the opposite: taking GPU buffers and turning them back into CPU-readable pixels so software can do arbitrary processing on them. Those are two very different concerns. And because screenshots are a privileged operation, this will always need to go through a back-channel anyway to handle the security aspect. Otherwise you'll end up with a repeat of X11 again where any Wayland client connected to the server can scrape the screen at all times. So for desktop use there's really no reason to ever put it in a Wayland protocol. The design from the beginning was to keep privileged operations (like screenshots and input grabs) out and that still holds true now.
  - roenxi 4y ago
    That is the view they took; but that view involved a decade-long process to get a Wayland ecosystem to where we could reliably screenshot the full screen. Still isn't possible in Debian Stable if I recall correctly. Wayland is the future, but lets not put on too brave a face. The design for accessing the composited output was bad and it fell over in practice. There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop. If someone wants to "install Wayland", technically they might end up having to research which framework they have to work with to make a Zoom call and screen share, which could be incompatible with Google Meets and screen sharing. Indeed, that dynamic will force centralisation on a specific set of libraries just like X used to with drivers - for no particular reason other than they didn't feel like scoping out the original specification a little more practically. If all the Wayland compositors are going to be expected to use the same library, they may as well have included it as an appendix back in '08 and saved all the mucking around in the mean time. This is hardly the end of the world and I do think the people involved in Wayland made a good attempt. But hindsight is 20/20 and the wart is now quite obvious.
alexvoda 4y ago
The article at the link you posted is about the Cardboard WM. Shoutout for Cardboard, an awesome Wayland compositor and a rare example of Scrolling Tiling window management. https://gitlab.com/cardboardwm/cardboard https://gitlab.com/cardboardwm/cardboard
tudurom 4y ago
I'm the author of the mentioned blog post. The situation changed a little bit since I published the post, which is that wlroots finally gained upstream the scene graph API, which abstracts away a lot of the painful parts of compositor development, mostly the parts about rendering windows and damage tracking. It is hard to quantify how much buggy, or less buggy, are "amateur" Wayland compositors compared to their X11 counterparts. While it is true that a Wayland compositor programmer has to code by hand a lot of boilerplate as I explained in the article, now that the absolute ugliest yet-still-essential parts have been abstracted away in the scene graph API (before, if you didn't implement damage tracking, you had to basically say goodbye to your laptop's battery), besides the other ugly yet-still-essential parts that are already the entirety of wlroots, now compositor writers have the sweet-spot where they can integrate the special behaviour their compositor is all about with nicer graphics, rendering, input handling etc. IMO, this actually leaves room for less bugs, and all around a much better, and stable, experience, than what one would get with an X11 WM + a X11 compositor on top. And, looking at this compositor, Hyprland, it looks like just that. It's a nice dynamic tiling compositor, but it also has some very slick graphics, animations, config system. Looks like nothing I've seen before in the ricing space. And by quickly looking through its source code, it looks like it benefited massively from wlroots and from the scene graph API, plus all the other Wayland protocol extensions that are implemented ready-to-use in wlroots. Great work from the community!

by dTal 4y ago

3836293648 4y ago

Yeah, but wlroots is taking the role of Xorg there, leaving WM writers to mostly just write the WM

Izkata 4y ago
I'm just wondering how long it'll be until someone uses wlroots to write a client/server architecture like Xorg...
- TingPing 4y ago
  It will never be a popular way to use Wayland because its just a worse design.
- Cloudef 4y ago
  It already exists and its called xwayland. Most wayland compositors also have X11 WM inside them...
  - Izkata 4y ago
    You misunderstand: I'm not talking about the X protocol, I'm talking about some new all Wayland thing just so window managers can be separated from the other things you'd otherwise have to implement.
    - pantalaimon 4y ago
      I think Mir can do that
    - Cloudef 4y ago
      Yes and ironically Xwayland is that, but you probably want something like Arcan

charcircuit 4y ago

So just push all that shared logic into a library that alternative Wayland compositers can all use. eg. wlroots

gizmo686 4y ago

This compositor, like most Wayland compositors, uses the wlroots library, so most of that tedious work is already handled for you.

zokier 4y ago

On the other hand, there is nothing in Wayland that prevents anyone from writing a compositor that splits off some window management tasks to a separate process. Afaik nobody has bothered to do so yet, but if there is demand then it could be done. Or maybe there isn't that much demand for such thing.

dTal 4y ago
The blog post mentions Wayfire, which has a plugin architecture, so not separate processes but an abstraction boundary at least - which is the more important thing.
zajio1am 4y ago
Does not phoc / phosh work like that?
boudin 4y ago
River does that for the windows layout https://github.com/riverwm/river https://github.com/riverwm/river

sprash 4y ago

> "With Wayland, you handle everything, even with wlroots." The observable effect of this is that the long tail of niche projects like X11 window managers, custom toolkits or small applications (that don't carry around extremely heavy dependencies like GTK/Qt) gets decimated. The assumption that this is done on purpose is plausible.

tadfisher 4y ago
Plausible, but not realistic or actually happening, because there's nothing at the protocol level that prevents the long tail of small compositors, toolkits or applications from implementing a Wayland backend.
- sprash 4y ago
  > there's nothing at the protocol level that prevents the long tail Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level". As example: Compare the Wayland "Hello World" [1] with X11 "Hello World" [2]. If you want to add the ability to take screenshots it gets exponentially worse. (Also the Wayland version is not even capable to render strings.) 1.: https://github.com/emersion/hello-wayland/blob/master/main.c https://github.com/emersion/hello-wayland/blob/master/main.c 2.: https://rosettacode.org/wiki/Window_creation/X11#C https://rosettacode.org/wiki/Window_creation/X11#C
  - QUrprUd1nCeicw 4y ago
    >Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level". No, all those can be solved with client libraries. X11 had Xlib and the other client libraries. Those X11 libraries don't make sense in Wayland, but the client libraries that stayed relevant (freetype, cairo, etc) can still be used. >If you want to add the ability to take screenshots it gets exponentially worse. No, in both modern X11 or Wayland, you should use the same API for screenshots: the XDG screenshot portal. >Also the Wayland version is not even capable to render strings. Sure it is, but you have to use client-side rendering. Client-side rendering is also the norm in X11, since decades ago when Xft was released as another one of those client libraries. That X11 hello world is short because it's using obsolete APIs.

kaba0 4y ago

An X11 window manager is more akin to a gnome extension than a proper window manager. Just because writing such a plugin is easy shouldn’t make our expectations all that different. And frankly, for putting together a window manager the proper choice of action is extending an already existing compositor.

QUrprUd1nCeicw 4y ago

>The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11. That comparison is a bad one to make. Compared to just a window manager, that's correct. But you have to compare Wayland compositors to X11 compositors and for that it's about the same amount of work. Either one expects you to bring your own rendering because that's the main benefit of writing a compositor. It also might make sense to compare X11 window managers to compositor plugins. The reason people seem to prefer wlroots is precisely because it offers more power and more control over the just writing a window manager.

dTal 4y ago
It's not a bad comparison to make when people are writing entire new compositors just to provide, say, a tiling experience - exactly the way they used to write window managers. I understand you're trying to be "fair" to Wayland here but the fact is there is a lack of an abstraction boundary where there used to be one. Maybe that abstraction boundary can be reinstated by a well-written compositor with a plugin architecture, but that isn't standard the way the window manager interface is (unless you can persuade everyone to use that one compositor).
- QUrprUd1nCeicw 4y ago
  I think you're missing that authors of tiling window managers don't actually want to go back to the X11 way of doing things. They don't want to write a basic window manager or a plugin. That abstraction boundary is bad and it's extremely limited. That's why the X Composite extension was created in the first place. There was a chance to go in the opposite direction with Wayland. People did actually make plugin APIs but they never became standard, few developers wanted to use them. Instead wlroots became popular because it allows a lot more power and flexibility over compositing. The compositing approach is what allows Hyprland to have those nice transparencies and animations. So it's not that I'm trying to be fair to Wayland, I'm actually trying to be fair to X11 compositors. You're skipping that whole step that happened in the mid-2000s when you make your comparison. People wanted to make compositors all along.

dathinab 4y ago

> wayland compositor is still a lot more work than writing If you speak about a probably working one instead of a toy one the difference between X11 and wlroots isn't that big AFIK. It's just that with X11 you could create a toy compositor with very little lines of code and that's not possible anymore. But then toy compositors also kinda don't matter in the grater picture so it's not really a problem.

roenxi 4y ago

There were some mis-steps with Wayland being too light [0] - but we're entering an exciting new era where people start experimenting in the graphics space again. wlroots might be enough, or there might be a few attempts to get the supporting libraries right. But it'll be solved in time. [0] There was a subtle mechanism-not-policy error where they made screenshots impossible without some back-channel being available. In hindsight, there should have been mechanisms for sharing buffers at the protocol level. "Can't share" turned out to be a forced policy, and the wrong one.

p_l 4y ago
Like many other things (including, originally, copy-paste), you were supposed to use your desktop environment's support for this over to-be-specified D-Bus API
QUrprUd1nCeicw 4y ago
No, that wasn't a mis-step and it wasn't the wrong policy. Wayland is primarily concerned with taking buffers and telling the GPU to put them on the screen. Buffer sharing between clients is more concerned with the opposite: taking GPU buffers and turning them back into CPU-readable pixels so software can do arbitrary processing on them. Those are two very different concerns. And because screenshots are a privileged operation, this will always need to go through a back-channel anyway to handle the security aspect. Otherwise you'll end up with a repeat of X11 again where any Wayland client connected to the server can scrape the screen at all times. So for desktop use there's really no reason to ever put it in a Wayland protocol. The design from the beginning was to keep privileged operations (like screenshots and input grabs) out and that still holds true now.
- roenxi 4y ago
  That is the view they took; but that view involved a decade-long process to get a Wayland ecosystem to where we could reliably screenshot the full screen. Still isn't possible in Debian Stable if I recall correctly. Wayland is the future, but lets not put on too brave a face. The design for accessing the composited output was bad and it fell over in practice. There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop. If someone wants to "install Wayland", technically they might end up having to research which framework they have to work with to make a Zoom call and screen share, which could be incompatible with Google Meets and screen sharing. Indeed, that dynamic will force centralisation on a specific set of libraries just like X used to with drivers - for no particular reason other than they didn't feel like scoping out the original specification a little more practically. If all the Wayland compositors are going to be expected to use the same library, they may as well have included it as an appendix back in '08 and saved all the mucking around in the mean time. This is hardly the end of the world and I do think the people involved in Wayland made a good attempt. But hindsight is 20/20 and the wart is now quite obvious.

alexvoda 4y ago

The article at the link you posted is about the Cardboard WM. Shoutout for Cardboard, an awesome Wayland compositor and a rare example of Scrolling Tiling window management. https://gitlab.com/cardboardwm/cardboard https://gitlab.com/cardboardwm/cardboard

tudurom 4y ago

I'm the author of the mentioned blog post. The situation changed a little bit since I published the post, which is that wlroots finally gained upstream the scene graph API, which abstracts away a lot of the painful parts of compositor development, mostly the parts about rendering windows and damage tracking. It is hard to quantify how much buggy, or less buggy, are "amateur" Wayland compositors compared to their X11 counterparts. While it is true that a Wayland compositor programmer has to code by hand a lot of boilerplate as I explained in the article, now that the absolute ugliest yet-still-essential parts have been abstracted away in the scene graph API (before, if you didn't implement damage tracking, you had to basically say goodbye to your laptop's battery), besides the other ugly yet-still-essential parts that are already the entirety of wlroots, now compositor writers have the sweet-spot where they can integrate the special behaviour their compositor is all about with nicer graphics, rendering, input handling etc. IMO, this actually leaves room for less bugs, and all around a much better, and stable, experience, than what one would get with an X11 WM + a X11 compositor on top. And, looking at this compositor, Hyprland, it looks like just that. It's a nice dynamic tiling compositor, but it also has some very slick graphics, animations, config system. Looks like nothing I've seen before in the ricing space. And by quickly looking through its source code, it looks like it benefited massively from wlroots and from the scene graph API, plus all the other Wayland protocol extensions that are implemented ready-to-use in wlroots. Great work from the community!