bspwm
bspwm copied to clipboard
baskerville
On Wayland
I'm just a bit curious what your thoughts are on Wayland, and if you'd be willing to consider porting/rewriting bspwm for Wayland?
If so I wouldn't mind helping out, although I can't guarantee that I'll have all that much time to work on it.
It would have to be a pretty complete re-write and a fork. Unfortunately, sxhkd would have to be built-in to the window manager because wayland clients can't intercept key presses. Alternatively, you could build a pluggable compositor and dynamically load a window manager, key binding manager, and lock screen manager as plugins.
Personally, I'd use https://github.com/michaelforney/swc to provide the underlying wayland support.
If it happens, it would be a rewrite (probably in Rust) with a testable core.
This would be very, very awesome. Another +1 for me. Any particular reason for rust? Just curious.
I'd like to point out that there's also a library on its way to the default Wayland distribution (not yet in 1.8 but likely in 1.9) called libweston. If I've understood correctly, it includes the building blocks to create a basic Wayland compositor, handle input etc. isolated from the Weston reference compositor. It includes, for example, a basic compositor code which every Wayland WM would otherwise have to reimplement.
I like Rust too. But what is the difference between rust and c? Isn't c faster a lot?
I like Rust too. But what is the difference between rust and c? Isn't c faster a lot?
We are talking about a window manager here. Many tasks of a window manager are triggered by user interaction, such as selecting a window or switching desktops. The difference in performance between Rust and C for tasks such as this lies in the range of a few milliseconds, I presume. Users don't notice that.
If you are talking about something like a webserver that has to handle as many requests per second as possible, then every bit of performance counts. If you are talking about a program that mostly reacts or signals events to a human user, you have the benefit of slow human reaction times.
I don't actually know the performance characteristics of Rust, but I would assume that it's faster than Python or Lua, which we know is fast enough for WMs.
More imporant would be the linking- and startup time (eg think of Java-programs such as Eclipse), but as Rust is pre-compiled I doubt that is much of an issue.
//edit: Also +1 for a wayland-version of bspwm
+1 for Rust.
We are talking about a window manager here. Many tasks of a window manager are triggered by user interaction, such as selecting a window or switching desktops. The difference in performance between Rust and C for tasks such as this lies in the range of a few milliseconds, I presume. Users don't notice that.
What about memory usage, a slight difference such as 100MB don't affect much but it may be a big difference for those whose RAM is less than 1GB.
I don't actually know the performance characteristics of Rust, but I would assume that it's faster than Python or Lua, which we know is fast enough for WMs.
I don't know about Lua, but I am sure Rust is a lot faster than Python.
And I hope the Rust can add more feature such as monocle when rewriting in Rust.
@pickfire
Rust has the same performance characteristics as C or C++. It's statically compiled, with manual memory management, using value types by default.
The biggest slow-down on the Rust side is mandatory array bounds checks, which are replaced by iterators which safely eliminate them most of the time.
Rust also has some features that have the potential to make it faster than C or C++- more control over pointer aliasing, and stronger safety when using pointers into other objects, which allow for more compiler optimizations and more easily maintained program optimizations.
Rust's compiler is, however, a lot newer than most C compilers, so while it does usually match/beat/approach C-level performance, there are still cases where it can be improved.
Can't offer much dev assistance, but I'd certainly be happy to test a Wayland version of bspwm.
For this to work, someone will need to start drawing up a spec. To my knowledge, creating things like an external hotkey daemon or a bar with Wayland is trickier because of how it deals with compositors.
The plans for libweston look promising – seems it could some day serve as a sane base for a small compositor without the need of reinventing the wheel (ie. doing the low level graphics stuff etc.). The plugin design is still an open question. Hopefully they'll come up with a good plugin interface – if I understand correctly, that's what we'd need to create external hotkey daemons etc. I'd say there's no rush to Wayland as there are things just like this that need some time to mature.
Of course, there are also swc and wlc, and sway is making great progress.
I would also love to help out with something like this. bspwm + rust + wayland would be awesome!
Hm, NVIDIA drivers just added Wayland support today, seems things are nearing actual usability soon.
I'm kinda on the fence about this. On one hand, I'm not a huge fan of Wayland, specifically because of the reasons listed here that make programming for it so difficult, e.g. "sxhkd would have to be built-in to the window manager because wayland clients can't intercept key presses."
On the other hand, this is (apparently) a proposal to rewrite my favorite wm in my favorite language.
Not gonna say I know enough to make anything close to bspwm, but I will say I have some experience using the XCB binding for Rust (from cloning wmutils and cloning swm). I'll definitely try to help out if this happens.
e.g. "sxhkd would have to be built-in to the window manager because wayland clients can't intercept key presses."
Yes and not at all. bspwm would only have to provide sxhkd with the keyboard events instead of sxhkd gathering it from X. That's more or less Wayland's way of doing things: the compositor has the last word, but it doesn't mean it has to do everything.
I don't know if freedesktop has arrived at any conclusions regarding hotkey daemons, but there could be be a cross-desktop standard interface for them.
Hi, there is a i3 -> Wayland rewrite going on (Sway). You may want to take a look on it, just in the case of still not.
+1 to bspwm in rust on Wayland! with the candlestick in the dining room...
Just going to chime in here with my experience making a Wayland compositor (and my current work of moving awesome over to Wayland).
If you want to use Rust, in terms of bindings the most stable and mature one right now is probably wlc.rs. It is bindings to wlc, which is the framework Sway (C), Way Cooler (Rust + Lua), and Fireplace (Rust) uses.
However, wlc is on life support right now, and while forks exist the majority of development is going to wlroots (which is spear headed by the Sway developer, but it's written in C). I plan to move Way Cooler over to wlroots and I'm experimenting with bindings while I wait for it to stabilize.
Another option is the one Fireplace is going with, Smithay which is a compositor framework written entirely in Rust. Development is a little slower with this, but once it is complete it will be more easy to verify as safe, be easier to use with Rust, and could potentially be used in a core Wayland implementation written in Rust (basically everybody uses the reference implementation, due to churn and it being the defacto reference to understanding Wayland in depth).
What if the rewrite was done in Haskell? There's even a Haskell implementation of the wayland protocol: https://github.com/abooij/sudbury
Also, for reference there are other tiling window managers for wayland in addition to sway such as http://way-cooler.org/ which is already written in Rust.
An update on using Rust to write a Wayland compositor for 2018:
if you want to use Rust, you two best options are either Smithay (though progress is slow, not sure how complete this is) or wlroots-rs (might still be buggy / have safety holes I haven't fixed, but is currently used by Way Cooler and is generally pretty solid).
There's currently a (very incomplete) guide using C here. I plan to write one for Rust later this year since it's a little different and I want to encourage others to use my Rust bindings 😉
It's not written in Rust but just in C, but in case any of you is interested in working on this, here's a repo you can join.
One advantage of Rust over dart, is that it doesn't need any runtime while still enforcing type safety
As long as we're talking rewrites, a bspwm with 9P -- like wmii -- would be very cool.
Something to consider...
@Gingersnap1991 I don't think there's any point in implementing wmii as a part of bspwm, it could easily be created outside of it
For those that are interested, there is a Wayland re-write going on over at SourceHut by Simon Zeni called bspwc. I don't believe it's in a usable state (or even close) but perhaps the community may be able to help. As it mentions in the README, there is an IRC for the project on Freenode, #bspwc.
Wayland would be great, rust with smithay looks promising but they need more contributors. Also would be great to make it more dwm users friendly / alternative layouts?
I would not write a Wayland compositor in Rust (with Smithay, wlroots, or otherwise). A wayland client can be in Rust, sure. But definitely not a Wayland compositor.
Context for that strong opinion: I'm the way-cooler dude, posted earlier in this thread. Though I eventually abandoned way-cooler, in the end it was fully in C. No Rust at all. It's much, much easier to write a Wayland compositor in C. There's plenty of boring reasons (the reference implementation of the protocol is in C, most compositors are in C, wlroots is in C, etc) but the main reason is that Rust's safety system gets in the way too much for this specific problem.
Despite wayland-rs being a full re-implementation of Wayland in Rust, the "memory model" of Wayland is designed such that it's hard to represent in Rust safely. The "lifetimes" of the objects in Wayland can't be determined statically, so you're forced to use awkward API solutions to enforce the user to clean up their pointers. This is before you even get to general thread safety, I never designed wlroots-rs to be used by more than a single thread.
Even if that was solved (neither wlroots-rs (my attempt) or wayland-rs was able to) there is so much other libraries that need to be interacted with that are written in C (look at the non-build dependencies here: https://github.com/swaywm/wlroots#building) that you'll need to RiiR (or produce safe bindings for, which is the same amount of effort) the entire userland graphics stack.
Just use C.
I could not agree more with Timidger. As much as everyone loves rust, I do not believe that it will be the healthy approach to writing a wayland compositor. There is a strong lesson to be learnt from him there.
Moving on. After bspwc was abandoned and left for anyone to take over the reigns, I wonder what the plan is moving forward? Gnome and KDE already have their wayland side stable and smooth. Even Ubuntu will be making wayland the default choice with the upcoming 21.04. When will we start making a move with bspwm as well then?
My dilemma is failing to leave bspwm and use another wayland compositor. There is nothing similar or half as good in my eyes. X11 is starting to have some seriously annoying limitations/shortcomings (at least for me) otherwise.
I can only hope from here on...
X11 is starting to have some seriously annoying limitations/shortcomings
@Erothas Out of curiosity. Which limitations/shortcomings do you mean?
X11 is starting to have some seriously annoying limitations/shortcomings
@Erothas Out of curiosity. Which limitations/shortcomings do you mean?
Oh sure. Here you go:
- Multihead/multimonitor setups with freesync, and different refresh rates and resolutions actually function as intended on wayland.
- Despite fiddling around with compton and now picom, I still have never had a truly tear-free experience. Yes, these compositors did make it significantly better. But it never completely eliminated the issue; at least for me. Wayland is also a compositor in and of itself. So, you do not have to rely on any picoms, forks and hassles too.
- I have always been (unfortunately) a windows user. There will always be a time when I am forced to use that garbage without choice. Coming back to Linux always felt clunky. X11 feels noticeably slow and laggy. The moment I tried wayland, I felt the exact snappy feeling I got on windows 10. And I am not talking about the speed of launching applications. I honestly can't describe it exactly. It's like the delay between a mouse click/movement and your eyes catching it on screen? INPUT DELAY. That's probably it.
- Wayland is modern code that play well with our day and age technology and computers. So, expect noticeably better battery life and lighter GPU utilization.
Building up on the last point, you get many other little advantages here and there such as better implementation of most things that utilize your screen space like screen sharing. It has better scaling and overall security. Under the hood? It's a lot simpler and cleaner compared to the mess that X11 has become.
You could probably look up more technical details if you are interested for more :)
A would-be author of a Wayland port should avoid trying to replicate bspwm's architecture 1-1. I've never used bspwm, but looking over its design it uses sxhkd as a client daemon to respond to user inputs -- this would need a custom Wayland protocol to act as a client to the compositor. There is no standard "give me all input so I can override it" protocol for the clients.
Unless there's something else very-X11 like somewhere I didn't see, you should be able to get by with standard Wayland protocols and maybe some of the wlroots ones.
A would-be author of a Wayland port should avoid trying to replicate bspwm's architecture 1-1. I've never used bspwm, but looking over its design it uses
sxhkdas a client daemon to respond to user inputs -- this would need a custom Wayland protocol to act as a client to the compositor. There is no standard "give me all input so I can override it" protocol for the clients.Unless there's something else very-X11 like somewhere I didn't see, you should be able to get by with standard Wayland protocols and maybe some of the wlroots ones.
That was actually something I always had in mind. Though, I believe that whenever the bspwm goes wayland, the differences won't be as noticeable for the end user. I feel like it's possible to retain most of the functionality and feel of the original bspwm with minor changes here and there.
I think finding that "would-be author" is the biggest challenge here. Baskerville seems like he has his hands full. And I feel like no one else would be willing to take on the task on his shoulders. Sad times for me :(
A would-be author of a Wayland port should avoid trying to replicate bspwm's architecture 1-1. I've never used bspwm, but looking over its design it uses
sxhkdas a client daemon to respond to user inputs -- this would need a custom Wayland protocol to act as a client to the compositor. There is no standard "give me all input so I can override it" protocol for the clients.Unless there's something else very-X11 like somewhere I didn't see, you should be able to get by with standard Wayland protocols and maybe some of the wlroots ones.
Actually creating sxhkd for wayland instead of just including input protocol in compositor is bad idea, becuase it would work only with bspwm not other compositors like on X11 where for example I'm using sxhkd with Herbstluftwm. Author can just include sxhkd in compositor as custom config file for keybinds which is easier than playing with custom client to handle keybinds when compositor itself must have input protocol implemented to do that...
+1 for using C over Rust. There is no reason to use Rust because of its security features. To exploit a vulnerability (bufferoverflow, for example) in a WM or a compositor, a program has to be launched on a machine. If an untrusted program is launched, the machine is already compromised without exploits. So if there is a bufferoverflow in bspwm, it's 99% not exploitable without RCE in another program.
Also, I assume Wayland API is more stable with C rather than Rust (Wayland is written in C).
Moreover, there are more C developers than Rust devs, so the project will grow faster with C.
Also, I assume Wayland API is more stable with C rather than Rust (Wayland is written in C).
Moreover, there are more C developers than Rust devs, so the project will grow faster with C.
Do you even know anything related to Wayland? there is no "API" and no, Wayland isn't written in C by any chance since it's Dsiplay Protocol described in XML files. Wayland API doesn't exists, it's libwayland which is Wayland Implementation in C, you can implement in what you want, there is really good Wayland-rs implementation in Rust + it's own libs based on this implementations, same as wlroots for libwayland.
Ok than my assumption failed, nevermind. I said Wayland while I meant libwayland because libwayland is de-facto standard for anything that works with Wayland. Again, why choose Rust when we 1) have already written C programs; 2) don't need Rust security features?..
You all may be interested in river:
river is a dynamic tiling wayland compositor that takes inspiration from dwm and bspwm.
You all may be interested in river:
river is a dynamic tiling wayland compositor that takes inspiration from dwm and bspwm.
Yea, I have been aware of the river project for a number of months by now. It's unfortunate for me to say, but I mostly gave up on it for the time being. It has been receiving minor commits here and there, while missing crucial features such as damage tracking. And there doesn't seem to be any pace being picked any time soon.
I understand that the author is very busy with his education studies (I think? I could be mixing two people together). So I have nothing to blame him for. It's just that I don't think it's wise for the average user to be venture in at the same time. Wayland is already relatively "obscure".
That being said, it is definitely already usable as a bare-bones wayland window manager. So, if you are okay with a beta project, then go wild.
I would honestly love to see what baskerville has to say about the wayland path right around this time. His last response here was from a long time ago. While it doesn't seem like he is interested, but I would still like to see what he thinks if anything changed for him.
You all may be interested in river:
river is a dynamic tiling wayland compositor that takes inspiration from dwm and bspwm.
Yea, I have been aware of the river project for a number of months by now. It's unfortunate for me to say, but I mostly gave up on it for the time being. It has been receiving minor commits here and there, while missing crucial features such as damage tracking. And there doesn't seem to be any pace being picked any time soon.
I understand that the author is very busy with his education studies (I think? I could be mixing two people together). So I have nothing to blame him for. It's just that I don't think it's wise for the average user to be venture in at the same time. Wayland is already relatively "obscure".
That being said, it is definitely already usable as a bare-bones wayland window manager. So, if you are okay with a beta project, then go wild.
I would honestly love to see what baskerville has to say about the wayland path right around this time. His last response here was from a long time ago. While it doesn't seem like he is interested, but I would still like to see what he thinks if anything changed for him.
Minor commits? Actually they are working on new versions of custom protocols for options and tiling... (unstable branch). I don't think if you understand that Wayland isn't easy to work with even through wlroots. (good understanding and opengl knowledge is needed) You actually mentioned damage tracking as missing feature, sure it's should be added anytime soon but before you start adding proper xwayland and damage tracking you should first add core protocols + custom protocols (if you plan to implement them) because it's just makes your life easier.
Presonally I don't see any similiarities between bspwm and river since river doesn't even provide bsp tiling and it's just work in different way where user difine own tiling features, laouts and others through making own IPC through implementing their tiling protocol in desired language.
I'm working on Compositor also in Zig but it's a bit problematic because Zig isn't officialy released as 1.0+ yet and they are changing some things so adding bigger features (damage tracking, xwayland, advanced input/output etc.) now will force you to actually rewrite parts of code or mayby whole compositor depending on changes in syntax, std and bindings.
Dev of swhkd here, I have started working on https://github.com/waycrate/NextWM which intends to be a bspwm clone wayland compositor with excessive documentation to act as a base for other aspiring compositor developers to learn from.
NextWM will probably not be ready anytime soon but we'll see how it goes..
@Shinyzenith not starting an argument here, but since you are the author of both, I find it interesting that you chose to write swhkd in Rust but NextWM in Zig. Is it more of a personal decision for learning or was there a specific reason why you thought Rust was not a suitable langugae or that Zig was more suitable?
@Shinyzenith not starting an argument here, but since you are the author of both, I find it interesting that you chose to write swhkd in Rust but NextWM in Zig. Is it more of a personal decision for learning or was there a specific reason why you thought Rust was not a suitable langugae or that Zig was more suitable?
Life cycle of pointers created by wlroots library inherently violate rusts memory model. Eg: when you unplug your monitor at runtime, the wl_output pointer becomes a null pointer which the compiler loves to check at compile time hence it's hard to wrap it in safe rust. This has been attempted previously by the way-cooler project and they eventually gave up as the api required lots of glue code to maintain and was overall messy and eventually died off.
In comes smithay. Smithay is pure rust libwayland implementation. They also provide abstractions to build compositors but just isn't as mature as wlroots and needs a lot more boilerplate to even get a functioning global compositor space setup. That being said, writing wayland clients in smithay is amazing.
https://aakash.is-a.dev/blogs/nextwm/ this blog post that I wrote a bit back explains my experience with various languages attempting to write wayland compositors. In the blog post I mention using python, and I did try it and development with it was a breeze but having to send patches to bind every single function I wanted that wasn't already bound was a pain. That being said im maintaining both the zig and python versions.
Why rust for swhkd?
I was considering zig for swhkd but rust filled these two important pillars:
- It's fast.
- I can just write it and forget about it because it's a stable language unlike zig.