Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Separating the Wayland compositor and window manager

isaacfreund.com

Post reply on HN
Print view View original

91–100 of 228 posts

Re: Separating the Wayland compositor and window manager

#91

Post by hparadiz »

Asooka wrote: post #71
sourcegrift wrote: post #69

At this point, take all the lessons of wayland, plan everything in advance rather than incrementally deciding basic things like screenshotting and then build something new, superseding wayland so that power users like me and app developers will stop clinging to X. Right now I have no confidence in wayland and I know I'm not alone.

It is 18 years old (started in 2008 IIRC) and just now approaching something usable. So on the one hand it is a really old project whose original design considerations became obsolete a decade ago - I remember people were very bothered by the performance loss of needing several process switches with the X11 damage model in order to push an update to the screen, but on today's multi-core hardware that is basically fre…

It's biggest hurdle is having to explain even to tech people on HN that it's actually a good idea to have a UI where a user can approve a screen sharing request. You'd think for folks that claim to care about security that'd be a prime concern. It really is so weird how difficult that is for people to grasp. The implementation is likewise not complicated. Seriously how hard is it to draw a box selector and show an okay / cancel box.

Re: Separating the Wayland compositor and window manager

#92

Post by jbritton »

_flux wrote: post #44

To me, this is the first time Wayland feels like it's not a waste of time. The display server does not need to have the complexity of window managing on top the surface management. I certainly share the author's sentiment: > Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance. Although I'm not…

On X11, the window manager handles the window decorations. So splitting them is going to involve some possibly non-trivial messaging and config.

Re: Separating the Wayland compositor and window manager

#93

Post by asveikau »

shevy-java wrote: post #72
cosmic_cheese wrote: post #10

Earlier quoted context omitted.

It's a damper on development of new WMs and DEs, too. I have ideas for my own desktop I'd like to explore at some point, and if I do it'll almost certainly be X11 based initially because it's so much more quick and easy to wrap one's head around and get the iteration loop up and running with. I'm not anti-Wayland and I think X11 has enough issues that it's worth transitioning over to something better but this is a cr…

The xserver may not be completely dead either: https:/github.com/X11Libre/xserver

I'm using X11 every day on my personal machines and don't see a need to switch at this time.

I think x11libre specifically is a little suspicious though. There's nothing wrong with the xorg packages I use today that requires a fork.

Re: Separating the Wayland compositor and window manager

#94

Post by hedgehog »

_flux wrote: post #44

To me, this is the first time Wayland feels like it's not a waste of time. The display server does not need to have the complexity of window managing on top the surface management. I certainly share the author's sentiment: > Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance. Although I'm not…

Remote access on X11 is a mess and I won't miss it, at least on Wayland everyone is funneled through EGL or Vulkan and there's a reasonable path to layering remote access on top of that.

Re: Separating the Wayland compositor and window manager

#95

Post by em-bee »

hedora wrote: post #84

Traditionally, X11 didn’t have compositors, and didn’t need the extra round trip wayland exists to remove. I wonder if there’s space for a project like xlibre (or x.org, if it were revived) to update the x11 protocol to fill whatever gap compositors were meant to fill. For what it’s worth, I’ve been moving all my machines to lxde. Apparently, I accidentally switched back to a compositor free desktop without noticing.…

you are looking for https://en.wikipedia.org/wiki/Compiz

note that compiz is also a windowmanager, so already then compositor and window manager were one unit.

Re: Separating the Wayland compositor and window manager

#96

Post by wmf »

sprash wrote: post #88
wmf wrote: post #53

Earlier quoted context omitted.

When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.

This also means low-performing clients can make the whole Desktop stutter/freeze and it is one of the many reasons the Wayland architecture is beyond idiotic. High responsiveness is obviously far more important than avoiding the occasional artifact.

Clients (apps) should still be async in Wayland; it's just the window manager that's tightly integrated. Wayland compositors should probably use some kind of fair queuing to prevent misbehaving apps from spamming the event loop but they probably don't.

Re: Separating the Wayland compositor and window manager

#97

Post by em-bee »

csb6 wrote: post #57
diegocg wrote: post #56

Earlier quoted context omitted.

Well, that's exactly what the article is about. Wayland put all together into one process I order to avoid unnecessary context switch. This protocol aims to keep the performance advantages of Wayland without giving up on separation of graphics c server and window manager.

I was responding to this comment in the article and wondering about the historical context: > Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.

already in X11 time, compositor and window manager were one unit: https://en.wikipedia.org/wiki/Compiz

why? because the compositor completely changed the geometry of the desktop. being 3-dimensional. now, today most wayland compositors are 2 dimensional, but they don't have to be. a window manager that works with a 2 dimensional compositor would not work with a 3 dimensional one and vice versa. the window managers listed in the article are only compatible with this particular compositor.

it seems to me that separating window managers from compositors from the start would have created the expectation that all window managers work on all compositors. that is not and will not be the case.

if all compositors start separating out the window manager then the result would be that as a user i now have to choose two components, a compositor and a window manager, and i have to make sure they are compatible.

Re: Separating the Wayland compositor and window manager

#98

Post by sprash »

wmf wrote: post #96
sprash wrote: post #88

Earlier quoted context omitted.

This also means low-performing clients can make the whole Desktop stutter/freeze and it is one of the many reasons the Wayland architecture is beyond idiotic. High responsiveness is obviously far more important than avoiding the occasional artifact.

Clients (apps) should still be async in Wayland; it's just the window manager that's tightly integrated. Wayland compositors should probably use some kind of fair queuing to prevent misbehaving apps from spamming the event loop but they probably don't.

Example: Windows can only be resized when the client finished drawing the new resized window. Otherwise you would get "visual artifacts". So typical operations dealing with window management can not be async when the insistence on the nonsensical "every frame is perfect" mantra is upheld.

Re: Separating the Wayland compositor and window manager

#100

Post by LeFantome »

shevy-java wrote: post #75
wild_egg wrote: post #19

I've never used a system with Wayland (been on i3 for ~15 years) but every time a project like this comes up, I have to wonder why Wayland is even a thing. So many hoops to jump through for things that should be simple. Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.

Many theories. A simple one is that corporations wanted more control. See systemd's rise - not related to wayland as such, but to corporate-driven influence. I am not saying all of the design is corporate-controlled. But a ton of propaganda is associated with how wayland was advertised, until some folks had enough with it and decided to stop buying the "xorg is dead" routine these corporations push on: https://github…

Xorg is not dead. It is maintained by one of those corporations you are talking about. And since 2/3 of the Xorg code is in Xwayland, they will be maintaining it for a very long time to come. It is not going anywhere.

But already a majority of Linux desktop users have stopped using it. And it will be 90% in the next 2-3 years. GNOME, KDE, Budgie, and COSMIC are effectively Wayland only now and XFCE and Cinnamon will be Wayland native before then.

The GTK5 devs do not have to “kill off” X11. But it is not really worth their time either.

Keep using Xorg, or Xlibre, or Phoenix. It should keep working.

But don’t mind if the rest of us keep building on Wayland.

By the way, I use Niri, a very cool and absolutely non-corporate Wayland compositor. Not sure how that fits into your narrative.

Post reply on HN