leftwm / leftwm

A tiling window manager for Adventurers
http://leftwm.org
MIT License
2.84k stars 185 forks source link

Wayland #1035

Open TH3-S4LM0N opened 1 year ago

TH3-S4LM0N commented 1 year ago

Describe the feature

There was some talk about Wayland support in the discord, and I've personally been looking into a fair bit. It just makes more sense to do something formal on the actual repo. I also just wanted to make a general info dump somewhere and a sort of todo list. I'm also making this as it's a lot of work and I for sure can't do the whole thing myself. In my opinion what needs to happen for Wayland support is this (completely up for debate, what the issue is for):

After all that there's the obvious task of actually implementing Wayland support. My understanding is that there are 2 options for how to interface with Wayland:

In my experience after trying both I would say Smithay is too based around its own event loop and being the integral part of compositors built from the ground up with it. wayland-client seems to me to be more what LeftWM is looking for as an already established project.

Of course this will break pretty much everything related to LeftWM besides LeftWM itself (themes that use leftwm-*, all packages). A wayland branch or something would be nice once there's actual code to be pr'd.

A policy or something about Nvidia is something to be thought through, as I'm sure yall've heard the horror stories, whether that be no Nvidia support or special features.

As of my answers to the questions below, I would say LeftWM will be completely irrelevant with ~6 months without Wayland as X is dead or on life support depending on how you look at it (on Linux).

How important is this feature to you?

LeftWM is unusable without it

How important do you think is this feature for the average LeftWM user?

No one uses LeftWM because this is missing

Eskaan commented 1 year ago

This may also cause a rework of leftwm command as it can just call a function instead of having to write the command to a state file.

I don't think so. You would still have one daemon process that is your window manager, and then start a new process by calling the subcommand. The state socket is then used to communicate between the two processes, which brings me to one of my ideas: Rework the code so it uses dbus instead of a manual state file. To be honest, I haven't looked into this idea as much atm, but I think what we do with our state file is exactly that dbus does.

Everything needs to be reworked into 1 binary

Also, I am against squishing all of leftwm into one single binary. I propose two binaries like leftwm (the WM) and left-tools (all other utilities).

Now that I think about it, we could also include leftwm-theme via a git submodule and a cargo feature.

A wayland branch or something would be nice once there's actual code to be pr'd.

I think you can just go and create a pr on a not yet existing branch; it will be created upon merge.

0323pin commented 1 year ago

I would say LeftWM will be completely irrelevant with ~6 months without Wayland as X is dead or on life support depending on how you look at it.

Latest release was on 2023-02-07 and the one prior to that was 2022-12-19. The only issue I have with Wayland is wlroots being written with Linux only in mind. Wayland is far from being close to usable on non-Linux systems. Right now LeftWM runs flawless on non-Linux systems (*BSD and even MacOS through xquartz).

So, by all means bring Wayland support to the table but, please do not kill X straight away.

TH3-S4LM0N commented 1 year ago

The only issue I have with Wayland is wlroots being written with Linux only in mind. Wayland is far from being close to usable on non-Linux systems. Right now LeftWM runs flawless on non-Linux systems (*BSD and even MacOS through xquartz).

We aren't using wlroots as there are no maintained bindings anymore. That's just a general Wayland issue.

So, by all means bring Wayland support to the table but, please do not kill X straight away.

I never said anything about killing X off, there's no reason to delete stuff that works. X isn't exactly getting breaking updates anymore so there shouldn't have to be almost any work done to maintain the X part of LeftWM, but Wayland should be the new focus. For Linux though (which I would say it's safe to assume is most users) what I said stands.

TH3-S4LM0N commented 1 year ago

which brings me to one of my ideas: Rework the code so it uses dbus instead of a manual state file. To be honest, I haven't looked into this idea as much atm, but I think what we do with our state file is exactly that dbus does.

Actually this is a pretty good idea, as along with making all the leftwm-* more centralized with how they do things (or lack there of as leftwm itself is doing the things) it could also lead to some possible bspwm ipc type stuff (i get it's not the same thing but there are interesting possibilities).

Also, I am against squishing all of leftwm into one single binary. I propose two binaries like leftwm (the WM) and left-tools (all other utilities).

Wouldn't that be 3 though: leftwm (the wm), lefthk & left-tools (everything that's not leftwm or lefthk).

hertg commented 1 year ago

As of my answers to the questions below, I would say LeftWM will be completely irrelevant with ~6 months without Wayland as X is dead or on life support depending on how you look at it (on Linux).

That seems like an overstatement, X will still be prevalent for years to come, for better or worse.


While I personally do not have any experience with Wayland whatsoever, I'm very much looking forward to getting Wayland support into LeftWM and am glad if this gets some push. There are however quite a lot of preparations necessary, namely to abstract away most of the logic in a display-server agnostic manner. LeftWM to this day still has quite some annoyances and re-occurring bugs that it shouldn't have, which is also why there is still no 1.0 release. My assesment is that there are some things we need to get in order first, by iteratively refactor parts of the code and properly isolate unrelated parts from each other.

There will be no Wayland Support in 6 months. It's just too big of a task, and a big-bang approach to refactor everything at once is unlikely to succeed. But we will be much closer to Wayland-Support in 6 months if we gradually improve the codebase and simultaneously build up a proper abstraction layer between WM logic and the display-server. We can do both at once, getting closer to Wayland Support, while still continuously improving LeftWM on X.

Also, duplicate of #71

TH3-S4LM0N commented 1 year ago

That seems like an overstatement, X will still be prevalent for years to come, for better or worse.

Although that is admittedly my somewhat exaggerated guesstimate, I did not say X was going to magically break within 6 months. What I'm saying is that X isn't getting any newer, and by extent LeftWM isn't either. While you'll totally be able to keep adding more features to LeftWM, it's not because an X update opened up new possibilities. Until LeftWM moves to Wayland, LeftWM is tied to the past, and only getting better because it doesn't yet have 'full featureset'.

I am aware of #71 but that was more of a "will yall eventually do wayland" rather than a "ok lets do wayland now".

mike-lloyd03 commented 1 year ago

No one uses LeftWM because this is missing

I'm in the opposite boat. I'm still on X because of LeftWM. I tried Sway and it... just wasn't LeftWM. But with more and more distros shipping with Wayland DEs, I doubt there will be a lot of people wanting to try LeftWM if it means switching to X11.

I'd love to contribute to this effort. I'm fairly comfortable with Rust but display servers and compositors are way beyond me. But I'd love to participate in testing if/when we get there.

D-Brox commented 1 year ago

Wayland is far from being close to usable on non-Linux systems.

That's actually a common misconception. Wayland is just a protocol, so as long as a compositor implements it natively, Wayland could theoretically work on any OS.

For example, there are many stable ports of wayland compositors on both FreeBSD and DragonFly BSD that have been working well for years now, and it's even on FreeBSD's documentation now. I believe I read somewhere NetBSD and OpenBSD also had basic support, but I'm not sure.

So LeftWM with Wayland could work on BSD, at least on FreeBSD and DragonFly BSD at the moment, and more *BSDs in the future. Heck, it could work on windows with WSLg's wayland support.

0323pin commented 1 year ago

That's actually a common misconception.

Yes and no.

Yes, here's my laptop running NetBSD, velox (swc, no wlroots) on wayland 3 years ago. Didn't get a screenshot tool to work at the time.

20200225-104931

No, not really.

stable ports of wayland compositors on both FreeBSD and DragonFly BSD

Not necessarily, Dragonfly uses FreeBSD ports as base, simply translating build instructions to their D-ports system. So, just because it's there doesn't mean it works. It could, I haven't tested but, it's not a guarantee.

So LeftWM with Wayland could work on BSD

For sure, but a lot of work is required. Right now, if I use wayland I'm stuck on a US keyboard layout, which is far from ideal as my keyboard is not US.

So basically, somethings work already but, it's miles away from being usable.

That said, by all means do bring in wayland support but, don't drop X just yet.

VuiMuich commented 1 year ago

Correct me if I am wrong, but as far as I understood wayland last time I dug into this topic, lots of the functionality that in X11 the WM handles is treated as display server territory in Wayland. So I guess we need to bisect the leftwm-core crate and move such things to the displayserver crate. And then I guess it would make more sense to start the leftway compositor as its own crate that relies on leftwm-core, lefthk, leftwm-layout and possible other crates we might start as we proceed to further split the core into libs.

As others stated, I don't see X die anytime soon, so I also don't see the X11 side of leftwm getting abandoned in favor of wayland either. Of course providing support to users on both display server sides will become tricky at some point, but I guess this is just a chance to grow the number of people being competent enough to help out new users on both ends.

Edit: Just to put things into perspective I looked up qtile and waymonad. Waymonad still seems pretty dead afaict. For qtile it startet with commit 1265 in January 2019 and "ended" as stable with commit 2517 in June 2021...

stevensonmt commented 1 year ago

No one uses LeftWM because this is missing

I'm in the opposite boat. I'm still on X because of LeftWM. I tried Sway and it... just wasn't LeftWM. But with more and more distros shipping with Wayland DEs, I doubt there will be a lot of people wanting to try LeftWM if it means switching to X11.

I'd love to contribute to this effort. I'm fairly comfortable with Rust but display servers and compositors are way beyond me. But I'd love to participate in testing if/when we get there.

This is me. I've wanted to use Sway and Hyprland but they just don't work the way I want. Also someone mentioned not being able to add features to Leftwm if not moving to wayland. I don't think that's true, but also, what features is it missing? I agree with the person who wanted to focus on bug fixes and code organization, which would make eventual adoption of wayland support easier.

stevensonmt commented 1 year ago

Is there a bird's eye view of the architecture (current and anticipated) of leftwm documented anywhere? If not it might be worth putting something together so that implementation of alternative backends could be easier to reason about.

Eskaan commented 1 year ago

I don't think there is anything like that atm, but this is the basic crate layout:

              +-< <any display server> <-+
              +--< xlib-display-server <-+
              |                          |
leftwm-core <-+------------<<------------+-< leftwm
                                         |
                                lefthk <-+

The display servers are already separated by a crate from leftwm-core, and where currently one display server is, there can of course be more added and switched to by a feature (or similar).

stevensonmt commented 1 year ago

Correct me if I am wrong, but as far as I understood wayland last time I dug into this topic, lots of the functionality that in X11 the WM handles is treated as display server territory in Wayland. So I guess we need to bisect the leftwm-core crate and move such things to the displayserver crate.

Is this necessarily the best approach if X11 is still going to be not only supported but the default? If X11 doesn't consider it displayserver stuff maybe there needs to be a trait for those functionalities that are assumed into Wayland as displayserver and then have the leftway (or whatever backend, maybe even leftx11) implement both displayserver and "other window managery stuff" traits? Leaving core as mostly the integration of the two?

TH3-S4LM0N commented 1 year ago

This is me. I've wanted to use Sway and Hyprland but they just don't work the way I want.

And that's why LeftWM needs Wayland (or the other way around). For your average user coming from say GNOME that was shipped by default on their distro, Sway is i3 (hardcore wm stuff) and not especially approachable (i still find i3 intimidating). Sway is really the only "stable" Wayland wm currently but it isn't approachable so people end up w/ something like awesome on X or just go back to GNOME.

sfrique commented 1 year ago

This is me. I've wanted to use Sway and Hyprland but they just don't work the way I want.

And that's why LeftWM needs Wayland (or the other way around). For your average user coming from say GNOME that was shipped by default on their distro, Sway is i3 (hardcore wm stuff) and not especially approachable (i still find i3 intimidating). Sway is really the only "stable" Wayland wm currently but it isn't approachable so people end up w/ something like awesome on X or just go back to GNOME.

hyprland is quite stable for a while.

I would like to see leftwm support wayland as well!

FelixSchausberger commented 10 months ago

Is there any update on this matter?

Eskaan commented 10 months ago

You can look at #1073 for the current state of the Wayland implementation. Any help is greatly appreciated.