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

141–150 of 228 posts

Re: Separating the Wayland compositor and window manager

#141

Post by hsbauauvhabzb »

_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…

> Although I'm not sure if it was the least resistance per se (as a social phenomenon), but just that it's an easier problem to tackle. Or maybe the authors means the same thing.

Or maybe it’s desktop environments pulling the ladder up behind them.

Re: Separating the Wayland compositor and window manager

#142

Post by gf000 »

bjoli wrote: post #140
throwthro0954 wrote: post #139

As a 25 year user of Linux I love wayland since cutting over to it about 5 years ago. No tearing ever, which I always had to battle with with X. Certain developers that must interact with the Wayland stack will have to do more work now, and some projects may not still be viable, I get it. I've been following the comments in Linux forums for years. But users exist too, and here is one data point for you.

I am still a bit sad that window shading isn't supported. I wonder if I am going to continue saying this until I am like all those people 20 years ago complaining about things they liked in CDE not being available in more modern DEs.

What do you mean by window shading?

Re: Separating the Wayland compositor and window manager

#143

Post by lloeki »

oofbaroomf wrote: post #11

I'm currently using a fully vibe-coded, personal River window manager that works just how I want it to. I switched to it after I realized I couldn't do everything I wanted in Hyprland (e.g. tile windows to equal areas instead of BSP by default). Simple example of how impactful this separation has been for me.

> tile windows to equal areas instead of BSP by default

hy3?

https://github.com/outfoxxed/hy3

(I'm an ex i3/now sway user and hy3 is the only way I can bear using hyprland)

Re: Separating the Wayland compositor and window manager

#144

Post by ChocolateGod »

akagusu wrote: post #106

Well, it only took 15 years to someone to fix one of many Wayland design flaws and start to make it feel usable. Now it will take another 15 years for people to settle down in a set of common protocols instead of writing their own extension protocols and others 15 years for window managers to mature at the same level of the X11 window managers. Then, people who think they know better than everyone else will throw Way…

If you reinvented Wayland, there's little reason you would t get the same thing.

The "limitations" are political, not technical.

Re: Separating the Wayland compositor and window manager

#145

Post by 1718627440 »

fc417fc802 wrote: post #109
the__alchemist wrote: post #47

Earlier quoted context omitted.

The hoop I recently jumped through: There's a type of input called "DeviceEvent" which is a bit lower level than "Window event". It also occurs even if the window isn't "active". Windows and X11 support this, but Wayland doesn't except for mouse movement. I noticed my program stopped working on Linux after I updated it. Ended up switching to Window Events, but still kind of irritating.

Isn't being able to read input while unfocused a huge security issue? Meanwhile if you have root you're still free to do so directly.

A Display server is not a security boundary. If you want that start your processes as different users.

Re: Separating the Wayland compositor and window manager

#146

Post by ChocolateGod »

1718627440 wrote: post #145
fc417fc802 wrote: post #109

Earlier quoted context omitted.

Isn't being able to read input while unfocused a huge security issue? Meanwhile if you have root you're still free to do so directly.

A Display server is not a security boundary. If you want that start your processes as different users.

> If you want that start your processes as different users.

How does this make any difference if they're going to connect to the same IPC that handles input/display?

The display server must absolutely enforce some kind of security boundary between clients. Clients that are running untrusted code (e.g. a web browser) must not be able to hijacked into controlling a potentially privileged client (e.g. a root terminal).

Re: Separating the Wayland compositor and window manager

#147

Post by throw_a_grenade »

ximm wrote: post #132

I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction. Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get…

I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent communities, they could have taken hint multiple times.

That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.

Re: Separating the Wayland compositor and window manager

#148

Post by FooBarWidget »

toast0 wrote: post #105
_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…

X11 has some tricky, imposible to fix (within the confines of the existing protoco) issues because of the seperation between Xserver and window manager. Things like (IIRC) initial window placement and what nots, where ideally the window manager would make choices about things before the process continues, but the reality of distributed systems makes everything hard. Combining some things into an integrated process fi…

I think it's quite ironic that everybody nowadays complains about Wayland and the "good old days" of X. Back in the day, everybody and their dog complained about X being "archaic", "slow", "takes 20 operations to draw a line", etc. XComposite and XRender were just hacks. Everybody hated on X and anything else was considered better.

On a tangent, also very ironic that X (the successor of Twitter) has the exact same logo as X (the window system). It's like Elon Musk just Googled for the first X logo that came along and appropriated that and nobody seems to notice or care.

Re: Separating the Wayland compositor and window manager

#149

Post by FooBarWidget »

throw_a_grenade wrote: post #147
ximm wrote: post #132

I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction. Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get…

I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent commu…

And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? When such alternatives don't exist, that's exactly how "they do stuff for free and nobody else is putting in the work to make something else" looks like.

The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.

Re: Separating the Wayland compositor and window manager

#150

Post by ChocolateGod »

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.

This has nothing to do with Wayland, only a poor implementation of a display server running a Javascript shell, namely called GNOME.
Post reply on HN