Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Should You Write a Wayland Compositor? (tudorr.ro)
40 points by todsacerdoti on Jan 26, 2021 | hide | past | favorite | 10 comments


Another Wayland compositor written in Zig is ifreund/river [1].

Isaac, the author, gave a talk on choosing C vs Rust vs Zig on Zig SHOWTIME a while back [2] and also has an upcoming talk at FOSDEM 21 [3]

[1] https://github.com/ifreund/river [2] https://www.youtube.com/watch?v=mwrA5IRGpfU [3] https://fosdem.org/2021/schedule/event/zig_wayland/


this talk is phenomenal thank you. he explains (timestamp: https://youtu.be/mwrA5IRGpfU?t=330) why he didn't go with Rust and it's quite puzzling what he says. I don't know enough about Rust if that's the case. To rephrase:

"Rust was an obvious contender but it lacked good support for wlroots. there was a project which attempted to address this but they gave up after 12 months of work and 1000 commits. Rust's strong safety guarantees and memory management conflict with wlroots which assumes a longer lifetime of pointers. If you unplug your monitor with wlroots this pointer receives an event that means the output has disappeared and needs to be validated (see here https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-...).*

This is strange because Rust positions itself as a system language so I'd have imagined these scenarios are all over the place and unsafe Rust would be the way most of this is solved?


> I'd have imagined these scenarios are all over the place

Not as many as you'd imagine, really.

The core issue here is that lifetimes are a static validation mechanism. But wlroots has pointers that have a dynamic invalidation mechanism. There have been a few big attempts in systems like this to try and validate everything as statically as possible, and just like you'd imagine, the mis-match leads to pain. Rust absolutely has ways of doing dynamic validation, some including unsafe, as you've noticed. But some folks will try to push the boundaries. And that can often be really good! That's how progress is made. But like any experiment, sometimes it doesn't work out well.


What he mentions is wlroot-rs. If you're interested, here's the post from its author about the difficulties faced which lead to stopping development. http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...

It was discussed here back then https://news.ycombinator.com/item?id=19778738


> Some power users also haven’t switched to Wayland because their gimmicky window manager doesn’t have a Wayland equivalent (XMonad, Awesome, Bspwm and the others).

My first thought was that the author was being unnecessarily and unhelpfully dismissive. Then I skimmed the rest of the article and I think if you take it as "compositors are way bigger than window managers were in X, so if you want to write what would've been a window manager then you should consider working on top of an existing compositor" then it makes sense. I'm wondering if maybe it's just a language thing.


I took it mainly as a joke. There are so many window managers for Linux, most with a small but dedicated user base. The time it takes for any "new" technology to reach every one of them is usually substantial.

On a separate note, as an i3 user I should check out away again. Last time I tried it (multiple years ago), it had a fairly substantial amount of input lag. Kind of turned me off of anything based on wlroots.


> it had a fairly substantial amount of input lag

I use sway since ~2 years and i never experienced such thing. I you can still reproduce you should definitely look into it and email the maintainers, i'm sure it's a bug. Right now sway is feature frozen and it seems to be rock-solid. Screen capture works with pipewire (which is a breath of fresh air in comparison with the pulse/jack combo) and the xdg-desktop-portal extension. At this point i'm not sure i'll switch to something else in my lifetime!


As I said, it's been awhile. Was the latter half of 2016 when I tried.

I had bumped into it while trying to write a "system compositor / fullscreen shell" which would run another wayland compositor inside for the purpose of desktop recording. It would convert the wayland buffer handles into vaapi surfaces so I could use the GPU's video encoder. Most compositors never really picked up support for running nested, so I had abandoned that project.

I was super intrigued about wayland because it caused all the drivers to truly support offscreen accelerated rendering, I was also hoping to turn it into a remote desktop thing where you could actually run 3D apps in the future as well.


Probably shouldn't have used the word "gimmicky" which makes it sound very dismissive. I don't see tiling as a gimmick, but rather a critical element of my day to day workflow, for example.


Yeah, I think just using a different word would fix it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: