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

51–60 of 228 posts

Re: Separating the Wayland compositor and window manager

#51

Post by hparadiz »

Lots of weird misinformation in the comments here. Wayland doesn't choose anything. It leaves the compositor to decide where to position a window and whether or not that window receives key presses or not. The program can't draw wherever it wants or receive system wide keystrokes or on behalf of another program. When appropriately implemented the screenshot system is built directly into the compositor. It's an API that let's a program request read access to a part of the screen and the compositor provides upon approval. It's much more secure that way and it works perfectly fine these days. Unfortunately not every compositor implements this.

However if you really really really wanna side step this you can look at keyd - https://github.com/rvaiya/keyd

A project that has a daemon run in the background as a root service and that can provide an appropriate shim to pass key strokes to anything you want.

And just to be clear the appropriate secure model is to have a program request to register a "global" hot key and then the compositor passes it to the appropriate program once registered. This is already a thing in KDE Plasma 6 and works just fine.

Re: Separating the Wayland compositor and window manager

#52

Post by wmf »

pmarin wrote: post #8
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…

>i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as w…

That's what the anti-Wayland people want: for things to work exactly as they did in the 90s. It's not an accident.

Re: Separating the Wayland compositor and window manager

#53

Post by wmf »

csb6 wrote: post #48

Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.

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.

Re: Separating the Wayland compositor and window manager

#54

Post by csb6 »

wmf wrote: post #53
csb6 wrote: post #48

Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.

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.

Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.

Re: Separating the Wayland compositor and window manager

#55

Post by hurricanepootis »

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.

I've been on wayland since KDE had it available (like the KDE 5 days) because it offered fractional HiDPI scaling that wasn't buns. As a laptop user, it has been one of the best features of Wayland.

Furthermore, getting stuff like VRR on Wayland working is way easier than X.org. And, Wayland also supports HDR.

Re: Separating the Wayland compositor and window manager

#56

Post by diegocg »

csb6 wrote: post #48

Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.

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.

Re: Separating the Wayland compositor and window manager

#57

Post by csb6 »

diegocg wrote: post #56
csb6 wrote: post #48

Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.

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.

Re: Separating the Wayland compositor and window manager

#58

Post by jauntywundrkind »

pmarin wrote: post #35
jauntywundrkind wrote: post #26

Earlier quoted context omitted.

Yes exactly. DRM exists, but there's still what I called the X "kernel", all of it's heavyweight abstractions. To the previous a-hole, frak you: not an AI. That's rude as frak. Also, you manage to be incredibly wrong. Even an AI wouldn't overlook such an obvious error; maybe it'd be better to have it replace you. So rude dude! Behave!

I am sorry if I mistaken you for a bot but the model you are describing have not been implenented by any graphic driver in decades.

X's drivers still wrap the kernels drivers in its own abstraction layer.

It's vastly deeper than what Wayland does.

Re: Separating the Wayland compositor and window manager

#59

Post by charcircuit »

hparadiz wrote: post #50
Telaneo wrote: post #34

Earlier quoted context omitted.

It runs just fine at 165 hz for me. Given that xrandr and CRTs have been around for a while, and both have supported high refresh rates for a long while, something seems fishy here. Something is probably at fault, but it's not X11.

X11 can't do different hz on different screens. If you have a dual screen setup where one screen is 165 hz and the other is 60 you're SOL.

Works fine for me with 144/120 with the second as 60.

Re: Separating the Wayland compositor and window manager

#60

Post by arikrahman »

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.

I encountered similar setbacks with hyprland (https://github.com/ArikRahman/hydenix), and I eventually wound up preferring scrollable tiling managers. I restarted from scratch with niri, and have found it to be a stable platform to develop against. Here's my current dotfiles (https://github.com/ArikRahman/dotfiles)
Post reply on HN