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

151–160 of 228 posts

Re: Separating the Wayland compositor and window manager

#151

Post by ChocolateGod »

Asooka wrote: post #74
asveikau wrote: post #3

The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.

Honestly, probably the best Linux GUI stack would look like a root Wayland server (not running as root ofc), inside which are nested a per-user Wayland servers (which can be switched between rendering to a monitor or offscreen for a remote login), inside which is nested an X11 server (which is freed from having to care about hardware), inside which runs a normal window manager.

Pretty sure Deepins DE uses this model

Re: Separating the Wayland compositor and window manager

#152

Post by ChocolateGod »

jauntywundrkind wrote: post #2

super interested to hear more on this. i'm a little thrown, because the Wayland diagram doesn't feel quite right. the compositor does lie between the kernel and the apps, but IIRC the apps have their own graphics buffers from the kernel that they are drawing into directly. the compositor then composites them together. to me, that feels more like the kernel is at the center of the diagram here: the wayland compositor…

> the compositor then composites them together. to me, that feels more like the kernel is at the center of the diagram here: the wayland compositor is between the kernel and the output / input.

It's also possible to use hardware planes to get the actual graphics device to composite for you directly from its video memory, effectively reducing latency to the lowest possible.

Re: Separating the Wayland compositor and window manager

#153

Post by ForHackernews »

FooBarWidget wrote: post #148
toast0 wrote: post #105

Earlier quoted context omitted.

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

They both appropriated the "blackboard bold" X https://www.popularmechanics.com/technology/apps/a44641211/t...

Re: Separating the Wayland compositor and window manager

#154

Post by gf000 »

sprash wrote: post #98
wmf wrote: post #96

Earlier quoted context omitted.

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.

Graceful degradation is a thing. If you don't get a response from a client that you are redrawing, you may just put a translucent shader on the window, show the user the changing borders immediately, and then resume whenever it's ready.

Re: Separating the Wayland compositor and window manager

#155

Post by [deleted] »

Gigachad wrote: post #125
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.

From a user perspective it just works, the online issues are all hypotheticals or very specific scenarios. On wayland my computer just works, my displays can have different dpi scales, my video doesn't tear, and programs don't have full access to record the screen and keylog without asking permission.

[deleted]

Re: Separating the Wayland compositor and window manager

#156

Post by gf000 »

mikkupikku wrote: post #9

If Wayland doesn't get this solved then I'll just use X11 forever, with coding agents to keep it running if I have to.

Yeah I'm sure coding agents will be able to accurately find some non-obvious bugs in such a big and complex code base as X server.

Re: Separating the Wayland compositor and window manager

#157

Post by badgersnake »

bandrami wrote: post #127
Gigachad wrote: post #126

Earlier quoted context omitted.

Why would I want software to know where my pointer is other than when the pointer is over the software's window?

Well, in my case, because the VCF on my synth sets its cutoff frequency based on the pointer's Y position and its resonance based on the pointer's X position

Sure, but that is pretty niche. My point was it’s pretty low friction for most people and certainly to try it.

But obviously be pragmatic, if it doesn’t work for you because you have a particular requirement, or even if it doesn’t offer any improvement over what you have then don’t use it.

Re: Separating the Wayland compositor and window manager

#158

Post by vidarh »

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…

> imposible to fix (within the confines of the existing protoco)

X11's extension mechanisms can - and has - been used to enable backwards incompatible protocol changes. E.g. BigRequest changes the length and format of every single protocol request.

Very few client libraries are only capable of speaking "the existing" protocol if you take that to mean the original unextended X11 protocol.

Adding an X11 extension that when enabled cleans up a lot of cruft would not have been a problem.

> where ideally the window manager would make choices about things before the process continues

Nothing stops you from introducing an extension that when enabled requires the client to wait for a new notification type before continuing, or re-defines behaviour. That said, using my own custom window manager, I don't know what you mean here. My WM does decide the initial window placement and size, and it's the clients damn problem if it can't handle a resize before I allow the window to be mapped.

The X protocol is crusty in places, but it is very flexible. People haven't fixed these things because they chose to invent compatibility hindrances that weren't real when their response was to invent an entirely new protocol with no compatibility at all.

Re: Separating the Wayland compositor and window manager

#159

Post by vidarh »

jbritton wrote: post #92
_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.

That's purely convention. It doesn't need to be the case. There's no functionality that enforces or depend on that.

Re: Separating the Wayland compositor and window manager

#160

Post by GuB-42 »

hedgehog wrote: post #94
_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.

X11 remote access have worked really well for me. And the best part is that it worked even when the client machine has no graphical subsystem installed. I can launch GUI applications remotely with a non-privileged account and it shows on my machine as if it was native.

Wayland can use RDP and some other remote desktop protocols, but it is not what I want, I want a window, not a desktop. There is Waypipe now, I heard it works fine now, but I am still doing "ssh -X", because it just works.

The problem with Wayland is that it is very much "batteries not included". To all the things that worked well in X11, the response has been "it can be done, our protocol is very flexible, ask the guys writing the compositor", not "that's how is done". The result, Wayland is 18 years old and it is only starting to work well, with some pain points still remaining, and display forwarding is one of them.

It is funny you mention a "reasonable path" by the way, as it is exactly that problem, I don't want a "reasonable path", I want it to work, and after 18 years, I think it is a reasonable expectation. To their credit, it seems we are getting there: waypipe, and now window managers, we may finally have feature parity.

Post reply on HN