[HN Gopher] Separating the Wayland compositor and window manager
___________________________________________________________________
Separating the Wayland compositor and window manager
Author : dpassens
Score : 185 points
Date : 2026-03-15 15:09 UTC (7 hours ago)
(HTM) web link (isaacfreund.com)
(TXT) w3m dump (isaacfreund.com)
| jauntywundrkind wrote:
| 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:
| >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
| gzread wrote:
| The Xorg codebase still includes some of those old drivers
| and is structured to allow them to exist.
| jauntywundrkind wrote:
| 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:
| 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:
| X's drivers still wrap the kernels drivers in its own
| abstraction layer.
|
| It's vastly deeper than what Wayland does.
| pmarin wrote:
| Just to be clear the hardware abstraction layer used by
| wayland and any current Xserver is exactly the same.
| wmf wrote:
| That's what the anti-Wayland people want: for things to work
| exactly as they did in the 90s. It's not an accident.
| asveikau wrote:
| 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.
| preisschild wrote:
| You can do that already with libraries such as wlroots or
| Smithay
| MarsIronPI wrote:
| 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:
| 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:
| https://codeberg.org/ezemtsov/ewm
|
| 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:
| https://code.tvl.fyi/tree/tools/emacs-pkgs/reka
|
| 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.
| MarsIronPI wrote:
| Oh, reka looks interesting. Thanks for linking it. I
| don't disagree with you about dynamic modules, I just
| think that EWM's architecture shouldn't be necessary. (In
| which I think we agree?)
| jaen wrote:
| 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).
| yjftsjthsd-h wrote:
| 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.
| jauntywundrkind wrote:
| 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.
| cosmic_cheese wrote:
| 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:
| 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:
| That would suffice if I were only looking to build a WM,
| but my goal is a full (lean) DE.
| shevy-java wrote:
| The xserver may not be completely dead either:
|
| https:/github.com/X11Libre/xserver
| anthk wrote:
| Xenocara > Xlibre. Also, the NetBSD guys have a fork too.
| LeFantome wrote:
| Check out Louvre. Wayland compositors may not be as hard as
| you thought.
|
| Or build on River as this article suggests.
| gf000 wrote:
| 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.
| nine_k wrote:
| 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.
| hrmtst93837 wrote:
| 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.
| yason wrote:
| 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.
| Asooka wrote:
| 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.
| wmf wrote:
| Pretty close to Wayback.
| mikkupikku wrote:
| 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:
| You could use xlibre, although some people say it's a joke
| anthk wrote:
| Just use Xenocara and stop reusing LLM slopware.
| oofbaroomf wrote:
| 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.
| locusofself wrote:
| BSP?
| rvrb wrote:
| Binary space partitioning
| arikrahman wrote:
| 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)
| wild_egg wrote:
| 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.
| badgersnake wrote:
| 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.
| john01dav wrote:
| > 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.
| hulitu wrote:
| Huh ? It did in 2000.
| Telaneo wrote:
| 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:
| 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:
| Works fine for me with 144/120 with the second as 60.
| imiric wrote:
| X11 can't fix climate change.
| hedora wrote:
| You joke, but the wayland protocol leaves this up to the
| compositor. Nothing in the protocol prevents your desktop
| environment from doing this.
| the__alchemist wrote:
| 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.
| hurricanepootis wrote:
| 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.
| WhyNotHugo wrote:
| 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.
| imiric wrote:
| > not having to ever again touch Xorg.conf has improved my
| quality of life
|
| I haven't touched xorg.conf in decades. I suppose you might
| have to do it to configure some unique setup, but for me this
| hasn't been an issue in a long time.
|
| Now with Wayland, instead of having to touch a single config
| file, we have to learn how each compositor/WM is configured,
| and do it there instead. It hardly seems like an improvement
| in that regard, IMO.
| imiric wrote:
| I'm with you. I haven't had major issues with X11 for a good
| couple of decades. Ever since I didn't have to manually edit
| xorg.conf, I forget when that happened.
|
| Granted, my requirements were simple, a laptop and occasionally
| one external monitor, though the issues I did run into were
| related to graphics drivers and NVIDIA shenanigans, but not to
| X11.
|
| Now that I'm on Wayland, I do feel that visuals are slightly
| more responsive and crisper, but honestly, it wasn't worth
| replacing a bunch of my programs, significantly altering my
| workflow, and dealing with numerous new issues I didn't have to
| deal with before.
|
| Unfortunately, the momentum is now fully with Wayland, and it's
| only a matter of time until X11 stops being supported
| altogether. The XLibre project is a noble idea, but a few
| contributors can't maintain an entire ecosystem on their own.
| shevy-java wrote:
| 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.com/X11Libre/xserver
|
| It will be interesting to see what will happen though. The GTK
| devs said they will help kill off xorg with GTK5. KDE also
| wants to kill xserver. It would be kind of cool if that would
| not happen - imagine if a non-corporate controlled ecosystem
| would emerge. Not likely to happen, but it would be a lot of
| fun. As well as more real competition with wayland. Wayland
| broke its biggest promise: that it is a viable alternative to
| the xorg-server. I don't want to lose any feature, so it is a
| drawback for me.
| davispeck wrote:
| 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:
| Are you human? If yes sorry for the offensive question. Your
| account is new.
| davispeck wrote:
| Yes, I am!
|
| I've been working in the tech field for a while, but I'm new
| to HN. I'd never explored the platform in depth before, and
| recently decided to start participating and interacting with
| people here.
|
| The discussions and knowledge shared here have already been
| very valuable to my own learning. So I hope to contribute to
| the community in the same way... but I felt I needed to be
| more active in the community before that.
|
| If anyone is curious or still has questions, I can also share
| my LinkedIn or GitHub.
| SilentM68 wrote:
| 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.
| Lerc wrote:
| So that's a Wayland ex-window manager then?
| _flux wrote:
| 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.)
| csb6 wrote:
| 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.
| wmf wrote:
| 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:
| 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.
| sly010 wrote:
| ... 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?
| WhyNotHugo wrote:
| > 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:
| Interpreters for Python, Lua, etc. can be embedded so
| using them does not require a separate process.
| MarsIronPI wrote:
| What about Emacs? That's the usecase I care about. Until
| I can get Emacs to manage my Wayland windows ala EXWM,
| I'm sticking to X.
| donaldihunter wrote:
| You'll be looking for
| https://code.tvl.fyi/about/tools/emacs-pkgs/reka
| diegocg wrote:
| 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:
| 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.
| hparadiz wrote:
| 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.
| kyorochan wrote:
| 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.
| imiric wrote:
| 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 not 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 in a project that is 17 years old now!
| sourcegrift wrote:
| 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.
| Asooka wrote:
| 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 free and
| everyone is using browser engines and writing their GUI in
| javascript anyway. But on the other, do you really want to
| spend another 10-20 years rewriting the Linux GUI stack from
| scratch only to reimplement "Wayland with best established
| extensions"?
| hedora wrote:
| 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. High framerate, vsync/tear-free and
| high dpi work fine. So does fractional scaling, but I disable it.
|
| Personally, I'd rather these hypothetical x11 devs focused on
| reverse engineering hdmi vrr (blocked by lawyers at the moment),
| and HDR / expanded color spaces.
___________________________________________________________________
(page generated 2026-03-15 23:00 UTC)