_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Separating the Wayland compositor and window manager
imiric wrote 5 min ago:
I'm very excited about river.
I switched to niri a few months ago, and while I like it for the most
part, it feels too... busy for my taste. It defaults to a bunch of
animations and decorations, all of which I've turned off. I'm happy
with my current setup (aside from Wayland quirks[1]), but river's
design and simplicity are very appealing. It reminds me of the
philosophy of bspwm/sxhkd which I used for years on X11.
I do need scrollable tiling now that I've tried it, and I'm happy that
there are a couple of options to choose from with river.
[1]: Seriously, why does copy/pasting sometimes simply doesn't work?? I
often have to copy twice for it to succeed. It's not related to
Xwayland -> Wayland apps, and viceversa, or with copying from closed
windows, etc. I don't use nor want a clipboard "manager". I just want
my clipboard to work consistently. I've read many reports of this same
bug on different distros and DEs, and nobody has figured it out. It's
infuriating that such a basic feature is half-broken for a project that
is 17 years old now!
kyorochan wrote 30 min ago:
River was really great even before this split, so I'm very excited to
see what happens in the space in the future. I switched to Niri while
waiting for it to happen, and I'll probably switch back at some point.
If you were an Xmonad user I feel pretty confident in saying River is
the Wayland WM for you.
hparadiz wrote 1 hour 7 min ago:
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 - [1] 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.
URI [1]: https://github.com/rvaiya/keyd
csb6 wrote 1 hour 12 min ago:
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.
diegocg wrote 47 min ago:
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.
csb6 wrote 44 min ago:
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.
wmf wrote 56 min ago:
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.
csb6 wrote 52 min ago:
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.
WhyNotHugo wrote 16 min ago:
> It seems like instead of introducing another IPC protocol like
this project does
It doesn't introduce a new IPC, it uses the Wayland protocol with
the river-window-management-v1 extension. The extension mainly
defines new objects and verbs for them, but it's the same
protocol.
Separate process means that the window manager can be written in
any language (even, e.g.: Python).
csb6 wrote 1 min ago:
Interpreters for Python, Lua, etc. can be embedded so using
them does not require a separate process.
sly010 wrote 16 min ago:
... or the WM loads the compositor, or the WM links to a
compositor library (i.e. wlroots). The point is there are
options...
Honestly, every time this topic comes up, I feel like the person
complaining just doesn't want to put in the work and they are
angry that they don't get an easy win. And maybe that's a good
thing. Do we really need more half baked WMs?
_flux wrote 1 hour 43 min ago:
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 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.
(That and the remote access story needs to be fixed. It just works in
X11. Last time I tried it with a system that had 90 degree display
orientation, my input was 90 degrees off from the real one. Now, this
is of course just a bug, but I have a strong feeling that the way
architecture Wayland has been built makes these kind of bugs much
easier to create than in X11.)
Lerc wrote 1 hour 58 min ago:
So that's a Wayland ex-window manager then?
SilentM68 wrote 2 hours 12 min ago:
Insightful article. I don't recall ever viewing an easy-to-follow
lesson, tutorial or book for that matter that clearly explained the
various components of a Linux Desktop environment. Always had to follow
complicated and obscure guides to do this and that, when solving
issues, but seldom did any explain their functions clearly.
davispeck wrote 2 hours 45 min ago:
This is a really interesting direction.
Separating the compositor and window manager feels like one of those
ideas that seems obvious in hindsight, but the protocol/state-machine
design here shows why it took real work to make it practical.
Lowering the barrier for writing Wayland window managers without
forcing everyone to build a full compositor seems like a big win.
koolala wrote 2 hours 2 min ago:
Are you human? If yes sorry for the offensive question. Your account
is new.
wild_egg wrote 2 hours 45 min ago:
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.
WhyNotHugo wrote 13 min ago:
My reason for switching from i3 to sway (about 8 years ago) is DPI
support. High DPI is a pain in Xorg, and essentially impossible with
heterogeneous monitors.
The migration was a one way thing. Lots of things are smoother and
simpler, and not having to ever again touch Xorg.conf has improved my
quality of life.
To this day, I still have different monitors with different scale
factors.
hurricanepootis wrote 49 min ago:
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.
the__alchemist wrote 1 hour 28 min ago:
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.
john01dav wrote 2 hours 35 min ago:
> I can make it do basically anything I want
X11 can't do high refresh rates every time that I've tried to do so.
Telaneo wrote 2 hours 7 min ago:
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.
hparadiz wrote 1 hour 7 min ago:
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.
charcircuit wrote 33 min ago:
Works fine for me with 144/120 with the second as 60.
imiric wrote 3 min ago:
X11 can't fix climate change.
hulitu wrote 2 hours 29 min ago:
Huh ? It did in 2000.
badgersnake wrote 2 hours 36 min ago:
Sway is basically i3 on Wayland. You pretty much keep your config
file (with a few modifications), there really isnât much friction.
Thatâs not a reason to do it of course, for me the driver was
support for multiple monitors with different scaling requirements.
oofbaroomf wrote 2 hours 58 min ago:
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.
arikrahman wrote 33 min ago:
I encountered similar setbacks with hyprland ( [1] ), 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 ( [2] )
URI [1]: https://github.com/ArikRahman/hydenix
URI [2]: https://github.com/ArikRahman/dotfiles
locusofself wrote 1 hour 57 min ago:
BSP?
rvrb wrote 1 hour 40 min ago:
Binary space partitioning
mikkupikku wrote 3 hours 2 min ago:
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.
gzread wrote 2 hours 58 min ago:
You could use xlibre, although some people say it's a joke
asveikau wrote 3 hours 20 min ago:
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.
yason wrote 2 hours 25 min ago:
Not only a loss but a key disabler. Having used to having the same
customized window manager for decades it's impossible to change to
Wayland until there's a fully equivalent interface for managing
windows so that everything works as I want from mouse clicks to
keyboard shortcuts. Maybe it could be an existing window manager
adding support for River, or Wayback layer that reimplements an X11
desktop root on top of a minimal Wayland compositor, but none of the
current Wayland compositors even scratch the surface of this.
gf000 wrote 2 hours 53 min ago:
You only need a single implementation that exposes an API for running
a WM as an extension.
I don't really get why would it be a good idea to somehow mandate a
specific architecture design from the standard.
hrmtst93837 wrote 1 hour 11 min ago:
Handwaving "just expose an API" ignores the mess at the extension
boundary. Modular only works if the contract is airtight, and with
Wayland's churn and "sorta spec" documenation, that sounds
optimistic at best.
Every "flexible" API turns into a leaky mess unless someone is paid
to write the dullest test suite in existance, and nobody is.
Mandating one design is ugly, but pretending composition is free is
a fairy tale.
nine_k wrote 1 hour 59 min ago:
We need a compositor that exposes everything as an extension.
Preferably in a hot-reloadable, tweakable way, say, using Lua (with
JIT). And also exposing its APIs in a way that allows having an
analog of xdotool.
cosmic_cheese wrote 2 hours 59 min ago:
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 critical
weakness in Wayland's design.
gf000 wrote 2 hours 53 min ago:
How is a WM not just a simple plugin/extension? Find a display
server you like and write an extension for it!
cosmic_cheese wrote 2 hours 50 min ago:
That would suffice if I were only looking to build a WM, but my
goal is a full (lean) DE.
preisschild wrote 3 hours 19 min ago:
You can do that already with libraries such as wlroots or Smithay
jauntywundrkind wrote 2 hours 31 min ago:
Especially with LLMs, the cost here is down significantly. People
also drastically over-idealize what making an X window manager
entailed: sure X had it's compositor, but you had to build so so
much yourself.
I'm glad River is trying to create a bigger base here; this is way
cool. And it sort of proves the value of Wayland: someone can just
go do that. Someone can just make a generic
compositor/display-server now, with their own new architecture and
plugin system, and it'll just work with existing apps.
We were so locked in to such a narrow limited system, with it's own
parallel abstraction layer to what the kernel now offers (that
didn't exist when X was created). It's amazing that we have a
chance for innovation and improvement now. The kernel as a stable
base of the pyramid, wlroots/sway as a next layer up, and now River
as a higher layer still for folks to experiment and create with.
This could not be going better, and there's so much more freedom
and possibility; this is such a great engine for iteration and
improvement.
yjftsjthsd-h wrote 3 hours 10 min ago:
No, that still requires you to make the whole thing, you just get
help. For instance, I've run into a problem where I try some great
new compositor that uses wlroots, and even though wlroots has good
support for keyboard layouts I can't actually set the layout
because the compositor hasn't wired up that functionality.
jaen wrote 3 hours 11 min ago:
The article already addresses that...
It's not easy and the major compositors (Gnome, KDE) are NOT
wlroots based, making this point mostly moot anyway.
This protocol at least has a chance of using a custom WM with an
advanced compositor (which wlroots is not).
MarsIronPI wrote 3 hours 15 min ago:
That's not the same thing. It's way easier to write an X11 window
manager than to write a Wayland compositor, even with something
like wlroots, because the window manager can speak the same
protocol that clients speak, and it runs as a separate process.
As a concrete example, Emacs' EXWM package works by implementing an
X11 client library in Emacs Lisp, then using it to talk to the X
server (which is a separate process, so this works fine) and
telling it how to position windows.
Whereas on Wayland, this is not possible without re-implementing a
standalone compositor process, because otherwise architecturally it
doesn't work. Emacs can't both do the drawing and be drawn.
tazjin wrote 1 hour 49 min ago:
EWM implements a Wayland compositor as a native thread spawned by
a dynamic module in Emacs, it's a full compositor within the
Emacs process: [1] So it is architecturally possible (but
infeasible in plain Emacs Lisp).
For river (the thing this article is about) I wrote an Emacs WM,
but also opted for a dynamic module for the Wayland protocol
parts: [2] This one could technically be written in plain Emacs
Lisp, but I'm happy to use something that already has all the XML
codegen stuff for Wayland figured out. Dynamic modules work
pretty well, fwiw.
URI [1]: https://codeberg.org/ezemtsov/ewm
URI [2]: https://code.tvl.fyi/tree/tools/emacs-pkgs/reka
jauntywundrkind wrote 3 hours 29 min ago:
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 is between the kernel and the
output / input.
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 wayland compositors needing to do so much, i can't help but chuckle,
because it feels like the kernel does >50% of what X used to have to do
itself; it's a much simpler world, using the kernel's built-in
abstractions, rather than being multiple stacked layers of abstractions
(kernels + X's own).
it means that the task of writing the display-server / compositor is
much much much simpler. it's still hard! but the kernel is helping so
much. there's an assumed base of having working GPU drivers!
author appears to super know their stuff. alas the FOSDEM video they
link to is not loading for me. :(
one major question, since this is a protocol, how viable is it to
decompose the window management tasks? rather than have a monolithic
window manager, does this facilitate multiple different programs
working together to run a desktop? not entirely sure the use case, but
a more pluggable desktop would be interesting!
pmarin wrote 3 hours 8 min ago:
>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 wayland compositors needing to do so much, i can't help
but chuckle, because it feels like the kernel does >50% of what X
used to have to do itself; it's a much simpler world, using the
kernel's built-in abstractions, rather than being multiple stacked
layers of abstractions (kernels + X's own).
Are you an AI bot? Modern X11 server using DRM are more than 20 years
old. You are talking about how X11 servers worked in the 90's
wmf wrote 58 min ago:
That's what the anti-Wayland people want: for things to work
exactly as they did in the 90s. It's not an accident.
gzread wrote 2 hours 57 min ago:
The Xorg codebase still includes some of those old drivers and is
structured to allow them to exist.
pmarin wrote 2 hours 19 min ago:
Just to be clear the hardware abstraction layer used by wayland
and any current Xserver is exactly the same.
jauntywundrkind wrote 2 hours 30 min ago:
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!
pmarin wrote 2 hours 5 min ago:
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.
jauntywundrkind wrote 43 min ago:
X's drivers still wrap the kernels drivers in its own
abstraction layer.
It's vastly deeper than what Wayland does.
DIR <- back to front page