"Wayland" support of awesome about awesome HOT 83 CLOSED

X wont be discarded for at least 15 years. It will be supported as an alternate protocol in Wayland and Mir just as it is on OS X.

Awesome doesn't have the heavy handed abstraction layers some other WM may have. It is a lean XCB based WM. The Awesome core probably cannot be extended to support Wayland (let alone Mir). A rewrite is AFAIK the only viable option. The lua layer could probably be re-used with some changes. There is currently no plan to do that.

Wayland support is going to happen. We built those abstractions,

from awesome.

Posted about this on IRC but I'm thinking I should encode this somewhere more permanent...

Yesterday I decided to try to get this version of awesome working in Way Cooler by commenting out the window management specific parts. I got something that was actually very usable in about 10 min, much more so than the current Rust rewrite I'm doing.

For those wanting to play at home install way-cooler and my patched Awesome and run way-cooler -c awesome in a TTY to see a basic setup.

I'm thinking that instead of rewriting the client to use Wayland in Rust it would be much simpler to add optional Wayland support to the existing codebase. It would still use large parts of the X11 API that can eventually be deprecated and phased out when Wayland is enabled. That also solves the issue of switching to Wayland vs staying on X11: you can run Awesome as before and if it detects WAYLAND_DISPLAY it will try run in Wayland mode.

The Way Cooler repo would just be the compositor that's designed to work with the Wayland version of Awesome. It wouldn't have the client or anything else. You would need way-cooler to use Awesome in Wayland mode as it can't work with any other compositor.

Thoughts? I'm thinking if we want to go this path we would want to restructure the logic of the C code so the X11 logic is in its own explicit code path and the Wayland is in another. Otherwise it will just be a lot of if (wayland) { /* Fancy new Wayland logic */ } else { /* Old X11 logic */ } everywhere. As well it would probably be good to get these changes in piece meal instead of all at once.

from awesome.

Hey, owner of Way Cooler here. Just found this thread.

Although Way Cooler isn't designed to be an exact successor for Awesome on Wayland, we definitely will try to support the same level of customization that Awesome has using a similar mechanism (i.e: Lua).

Most of the work so far has been to make it usable and to use my favourite type of tiling scheme (i3-style), though I have plans to have add a tiling system that works like Lua by defining the placement of windows using user-defined Lua code.

Feel free to make suggestions or pull requests on the project. I'm open to adding any of the features you might want to bring over from Awesome.

from awesome.

Looks like Way Cooler just died: http://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html

from awesome.

"2018: The Year of Awesome... The goal of 2018 is for Way Cooler to be a fully compatible AwesomeWM clone."

http://way-cooler.org/blog/2017/12/24/way-cooler-2017.html

from awesome.

So does this mean awesome dies with X?

from awesome.

Rewrite of AwwesomeWM as separated display server + it's own compositor is too hard because devs would need to rewrite whole Xorg as display server for wayland because awesome is too much integrated with xorg-related libs etc.
Way-cooler project is deprecated (actually repo is archived) because of some really big problems and incompatibilies like that rewrite of Xorg described above.

First of all, never use raw libweston or libwayland both are not worth, good alternative would be wlroots (based on libwayland) because actually every wayland related projects (compositors and clients) are based on it except that KDE and GNOME are using own implementations of libwayland/weston.

Wlroots library provide a lot of great and useful protocols like layershell which gives you 4 base layers on screen for backgrounds, windows, widgets, overlays etc. for example user can specify geometry and anchor where widget should be "pined" and on which layer should be displayed.

from other useful protocols we have screencopy, idle inhibitor, output power management and gamma control . Screencopy allow user to record screen, take screenshots and save them to files or client buffer. Idle inhibitor watch compositor state and e.g. activate lockscreen. Output power management protocol manage your outputs configured through compositor which sends info to display server and turn off selected monitor or change refresrate. Gamma control allow compositor to edit gamma tables for selected outputs.

from awesome.

@awesomeWM It's 2021, X is starting to die, and I don't want awesome to die with it. We need wayland support for awesome to live. I don't have the skills to port awesome to wayland, but I would if I could.

from awesome.

I believe that Awesome will get unofficial PoC backend next year:tm: (I have discussed it with Elv13 on Disord) I have already developed (private) Herbstluftwm clone as Vulkan Compositor with libwayland++ (32k loc, no wlroots), so creating Awesome as compositor with Smithay (Rust) shouldn't be that much problem but there are some Wayland limitations since it will be whole new Display Server, there will be no "Xresources" in API and some stuff might not be working properly (widget backed will be fully rewritten) and other things might be added to be exclusive Wayland features like built-in Shadows, Shaders, Animation APIs and more, I see it more like actual rewrite which sadly will require rewriting most parts of your config.

PS. I really don't want to create way-cooler clone, it was done in bad way imo, author tried to support everything which possible at once, I want to build it in "stages", starting from functional compositor, including stable input/output API (keyboard, monitors) and then actually start working on widgets, shadows, shaders and other fancy stuff.

from awesome.

No

from awesome.

Just saw this, might be worth looking at:
https://lists.freedesktop.org/archives/wayland-devel/2020-May/041458.html

https://github.com/taiwins/taiwins

from awesome.

Yep, that's the goal! Hopefully it's achievable this year.

from awesome.

found in the news one more interesting project related to the topic
https://github.com/Immington-Industries/way-cooler

from awesome.

@Elv13
you are right that X will not discarded in that sense. But once wayland becomes mainstream, then the X apps will run on X; and that X will itself run on XWayland , which will then run on Wayland.

HENCE, X which was running directly on machine, will then run on top of wayland (using XWayland).
So, awesomeWM which prides in fast execution , will become inefficient as "awesomeWM->X->XWayland->Wayland" when compared" with itself as the situation today is just "awesomeWM->X".
This four layer situation ( "awesomeWM->X->XWayland->Wayland" ) may or may not make it a CPU hog, but it will definitely make it a laptop battery draining hog compared to today's situation :-(

from awesome.

from awesome.

@Timidger

Floating windows per workspace

Not enough coffee, I have the dumb, and I cannot brain. Apologies for the noise.

from awesome.

from awesome.

There is only Taiwins

It looks like Taiwins has also been discontinued as of a week ago.

from awesome.

MayTODO:
[ ] Pixman backend
[ ] FB backend
[ ] Wayland backend

The FB and PixMap backends would be quite useful, one less layer of abstraction. I guess it will stay a "wait and see" approach for some time (and well, patches welcome).

from awesome.

@zaxebo1 I don't have any write up comparing them feature by feature, whether planned or not, but here's a quick run down of how I envisioned the influences come from:

• The layout is primarily i3-based (e.g, there's a tree consisting of Outputs, Workspaces, Containers, and Views). This was chosen because the awesome layout's can be considered a subset of i3 (it's just a special way to layout the children of a container). This was also chosen because I personally like i3-style tiling more, but I want to incorporate the awesome-style by allowing containers to defer to Lua for tiling
• Heavy focus on using D-Bus clients to extend the window manager. I know Awesome uses D-Bus, though I'm not sure how it compares to Way Cooler's. In Way Cooler, it's designed so that core functionality, such as the lock screen, notification system, and top bar are all swap-able client programs. For example, we don't currently have a top bar but I envision at least two being made by me: one simpler that uses a static configuration file, and a more dynamic one that will use the Lua thread.
  • I made this design decision because while I like Lua, I found it difficult to use conflicting extensions for Awesome because they didn't play nicely with each other. As well, because many X-utilities no longer work it serves to help replace some of the functionality that is lost.
• Lua is the main configuration language right now. It has a very tight integration with Way Cooler, being able to do everything a D-Bus client can do (but much faster!) and more (e.g it will eventually be the way clients are given permissions to access D-Bus. You can think of the Lua API exposed by Way Cooler as a super-set of the D-Bus commands we expose). But right now it's serving as a mostly glorified init file that doesn't do much after starting the window manager.This should change in the future, though it's very reliant on what the users want built into it. At the very least I think I will have a way to import a Lua library that can define how the user want's the Lua-controlled top bar to behave, but beyond that I haven't planned for the Lua thread to do anything else during runtime. Really would love user feed-back for what functionality I should implement to make the Lua thread more useful outside of the initialization (e.g timeouts calling functions, or maybe event-based callbacks or something).

This main design is fairly set in stone (though anything can change before 1.0), it's more the specifics that need ironing out. I've been focused on the tiling and other "core" features lately (e.g server-side borders, tabbed/stacked tiling, and other features that the compositor needs to implement), but hopefully I can start working on the customization aspects more (I have some ideas kicking around, like themes defined as yaml files that can be loaded dynamically from Lua)

from awesome.

I am bumping this issue as I stumbled upon a thread at the Puppy Linux forum that might provide a solution for awesome as well: They are experimenting with running JWM (their WM) on top of a fullscreen Xwayland session under a patched Cage. Here is the link for more info: Puppy Linux on Wayland

from awesome.

I am bumping this issue as I stumbled upon a thread at the Puppy Linux forum that might provide a solution for awesome as well: They are experimenting with running JWM (their WM) on top of a fullscreen Xwayland session under a patched Cage. Here is the link for more info: Puppy Linux on Wayland

I'm sorry but thats incredibely stupid idea... thats not how Wayland Support works.

You need to run Cage first, inside it you have to open Xephyr, inside Xephyr you open Xorg and then inside Xorg you open actual windows... 3 different programs to open windows handled in awesome.
Cage inside ot it nested Xorg (xwayland) then inside of it another nested Xorg (xephyr) and then actual awesome to handle windows under Wayland session...

EDIT: forgot about more than 1 monitor, hardware access and many more features for either Wayland and X11 since cage cannot handle multi monitor as well as nested Xorg also you still have to run picom to get rid of tearing.

from awesome.

Getting awesome to work on wayland is possible only if you reinwent all libs to behave the same or be even better than now but reintwenting stuff from X11 on Wayland kills the purpose of completely new and fully extensible Display Protocol. Recently Qtile added wayland backend for their lib and thar mivht be new good source of reference since they're using custom bar etc.

On a side: What is the purpose of adding Xephyr into the mix?

You can't run Xorg under wayland, only from tty. So you need Xephyr for that. Wayland compositors are having special backends which allows nesting without any external programs

from awesome.

I forgot to post it here, but to improve the usage of sway on a multi-monitor setup, and have a feeling much more similar to what I had on Awesome, I made swaysome, which plugs on the sway socket to better manage workspace, outputs, and windows.
Here is my navigation configuration, with most of the shortcuts inherited from my previous Awesome configuration, which was not far from the default.

With all that, I've been able to make the switch to the wonderful Wayland world without much hassle, and don't regret it a single day! :-)

from awesome.

What about widgets though? This is the thing that sets awesome apart for me. You can actually draw on the screen and create whatever you want with wiboxes and such. Are there any wayland window manager that support creating custom elements like widgets without external programs ?

There is only Taiwins (through Nuklear) like I said before but there is also external widgets system called eww (GTK3) which works with compositors which are having implemented proper support for layershell protocol (screen layers).

from awesome.

we can not avoid wayland issue, one way or other - it is going to meet us very soon:

Fedora 20 with Wayland preview (post of year 2013)
http://www.phoronix.com/scan.php?page=article&item=fedora20_wayland_preview&num=1

roadmap of Wayland and Fedora (post of year 2013)
https://lists.fedoraproject.org/pipermail/devel/2013-March/180546.html

Fedora 22 even more emphasis on Wayland (post of year 2015)
http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Workstation-22-Features

from awesome.

also, related ticket: #2635

from awesome.

Best Wayland-compatible Awesome alternative so far?

from awesome.

with F36 it looks like Awesome will no longer be able to run

If there are bugs, we can fix them. I don't think Fedora is dropping X11, it's just not defaulting to it anymore.

from awesome.

I believe that Awesome will get unofficial PoC backend next year

Let me know when/if there is a place to follow progress, I'd be really interested in this. I have not been able to find any replacement for what awesome can do and it would be a pity if such a great project dies due to deprecation of X11 at some time. Even today wayland is something I would like to try, but loosing my awesome config is not really an option.

I would find any distro that deprecates Xorg to be promoting lock-in... I'm happy with X + Awesome for now.

from awesome.

What's the current state of this?

Hard to say, because there are small problems related to APIs for writing compositors, one of them isn't any nice to use and spread hate related to Nvidia and doesn't provide ANY HELP for users with closed source drivers (any vendor) as well as everyone in it's ecosystem do the same. Second one, implemented in rust is under rework and will need few months to fully stabilize new abstractions and features. On the other hand I can see awesome as cross compositor shell which can be injected into any compositor and provide proper UI side of awesome instead of being slowly ported which will take years to be side-by-side compatible with X11 version and due to Wayland APIs being under heavy and active development it's currently too hard to maintain full compositor as rewrite of awesome.

from awesome.

I'd offer time to code as well but having twins, I have no time to even sleep.

Ha. I can really empathise with you :-D

from awesome.

I took a look too. It is based on https://github.com/Cloudef/wlc. If we had to port Awesome, this would be the way to go too. It is a WM core just like Awesome own CAPI. It has most of the base APIs we need to create the CAPI lua interface Awesome awful/wibox/gears depends on. We can steal some of https://github.com/SirCmpwn/sway code to get the wiboxes showing properly. They mostly do that same as us (cairo surfaces + events). The third step is to port Awesome events to libinput (for both X11 and Wayland). After those 3 steps, 80% of Awesome features should work properly in Wayland. It isn't that much work, but I don't have the time or motivation to do it myself for the foreseeable future.

WLC is dead, long live wlroot-rs

from awesome.

talking about rewriting -- can it be just a lua wrapper for an already existing library like https://github.com/Cloudef/wlc or https://github.com/michaelforney/swc ?

from awesome.

"patches" welcome

from awesome.

okk :-)

from awesome.

AFAIK XWayland is only used when running a legacy X application in a wayland powered environment. So for asesome nothing will change: it will just run directly on X as it did before, no XWayland involved.

from awesome.

@ff2000 : as of now Awesome window manager uses XCB (X protocol C-language binding), which is client of X11 display server protocol.
==> So yes, awesomeWM is X application
===>So, awesomeWM is a legacy X application in wayland powrred environment
===>So, Xwayland will be involved

from awesome.

Awesome is a special application - it's a window manager, so it IS the "environment". wayland is used in the compositor, but awesome DOES NOT composite. For compositing you need special applications like compton (and AFAIK they also don't have a wayland roadmap). It is the WM/compositor who decides if it can run wayland or not. And as long as the login manager is not entirely stupid it won't force wayland on legacy X sessions.
XWayland is something the compositor has to deal with - run X applications in an embedded X server.

In short: I really don't see a reason that you should be worried about performance issues because awesome won't run inside XWayland.

from awesome.

Just a thought... would it be possible to use the upcoming libweston, which from what I understand could be used as a compositing library?

from awesome.

Code is code, so I guess with unlimited effort and respect for the laws of physics and economics, everything is possible. It would still take monumental effort and a full rewrite of the C code.

from awesome.

+1 for Wayland support. I would hate to go look for another WM. I can offer some time to test and report bugs if that helps. I'd offer time to code as well but having twins, I have no time to even sleep.

from awesome.

@Timidger : saw "Way Cooler" which you referred, just now. Thanks for the link. It seems really a great project, esp as it is written in rust and supports wayland. I hope it as good as i3 and awesome. Is there some quick comparison somewhere?

from awesome.

@Timidger Any chance of Way Cooler implementing floating windows? I know, I am a freak using a tilling window manager in floating mode. ☺

from awesome.

@Elv13 I saw your edits, does that mean that wayland support will happen and this issue should be opened again?

@Timidger This is still planned?

from awesome.

@aviau Hi/Salut

There was some progress eariler this year, but then I threw a wrench into that by pointing out the original single process design wasn't going to work with async I/O used by some APIs and had unsolvable performance limitations that Gnome devs currently have and consider a dead-end issue. Then @Timidger had an intership and no time/right(!?!) to work on this. This is the current state. So at some point it got rather close to be useful, but regressed a fair bit when the design changes were implemented. Patches welcome

from awesome.

http://way-cooler.org/blog/2018/07/27/prehibernate-update.html

from awesome.

@aviau

As @psychon pointed out by linking my blog post, I'm still in hibernation until November 2nd when my internship is over. Since it's starting to slowly wrap up I'm waking up and taking stock of what needs to be done on Way Cooler. Another update might come this year.

EDIT: Forgot to mention I'll be meeting with @Elv13 since we are both in Montreal to discuss Way Cooler.

from awesome.

Any news on this?

from awesome.

@awesomeWM It's 2021, X is starting to die, and I don't want awesome to die with it. We need wayland support for awesome to live. I don't have the skills to port awesome to wayland, but I would if I could.

Well, the taiwins mentioned here is a LUA-scripted Wayland compositor, supporting both tiling and floating layouts. I think given the demise of way-cooler it's the project worth focusing on. It may not be compatible with Awesome, but given amount of efforts required to write a new full-blown compositor, the backward incompatibility looks to me like a minor problem.

from awesome.

any progress? i really would like this since i use fedora as my main and im not moving to X11 any time soon

from awesome.

any progress? i really would like this since i use fedora as my main and im not moving to X11 any time soon

I use Fedora 34 with awesome (awesome-4.3-9.fc34.x86_64) just fine. Since I user the Nvidia drivers, I am stuck on X11 for now.

from awesome.

@Elv13 according to your comment from this closed issue above, there is chance for awesome to get widgets and other stuff without rewriting whole backend for wayland.

Recently there is new library libtaiwins made by taiwins compositor authors and built around wlroots which provide advanced widgets but through nuklear, it's possible to fork library and replace nuklear with Gobejcts (or whatever awesome uses) with minimal effort since they already provide lua configuration in backend

Taiwins itself is already advanced and in general functionalites pretty close to awesome but a bit more advanced on case of widgets, since you are able to create whole graphical programs like video/media player which belongs to your compositor config (already made by authors or community).

Cairo graphics works natively for long time, same for pango as font backend (I know it from my experience after writting custom bar for wayland).

from awesome.

Wow! Taiwins wasn't that advanced last time I checked on it. That's impressive to see.

from awesome.

Wow! Taiwins wasn't that advanced last time I checked on it. That's impressive to see.

here is screenshot from their screenshots showcase, this provide mentioned video player

from awesome.

even-cooler, though it is archived

from awesome.

Best Wayland-compatible Awesome alternative so far?

I heard taiwins had all the widgets, but I have not get it to start on my distro.

from awesome.

taiwins is really broken though

from awesome.

taiwins is really broken though

@pjalsGit Which of the issues on https://github.com/taiwins/taiwins/issues you have on your mind?

from awesome.

taiwins/taiwins#130 this one

from awesome.

@heavyrain266 I do appreciate your honesty, and I see your point. I do admit that it's a hack, but "proper" Wayland support for awesome seems to be really hard as it's (as far as I understand the post mortems of the previous attempts) tightly coupled to the Xorg server-client model. The Puppy solution (cage+xwayland) could also actually be lighter than plain "legacy" X.

On a side: What is the purpose of adding Xephyr into the mix?

from awesome.

Sway a "tiling Wayland compositor and a drop-in replacement for the i3 window manager[…]" has a back-end called wlroots which might or might not be useful. I like what I saw of Sway as a tiling WM but that's not how I use awesome so not ideal for me weird needs.

from awesome.

It looks like Taiwins has also been discontinued as of a week ago.

Do you have some link to at least semi-official announcement?

from awesome.

It looks like Taiwins has also been discontinued as of a week ago.

Do you have some link to at least semi-official announcement?

Author has a blog, and the latest current entry goes over, basically, lack of motivation to work on some "massive project", which I presume from the context is Taiwins.

from awesome.

from awesome.

It seems there are plenty of Lua-based compositors around but none with widgets besides taiwins, right?

Yes, but actually taiwins is unmaintained because of personal reasons.

from awesome.

It seems there are plenty of Lua-based compositors around but none with widgets besides taiwins, right?

Yes, but actually taiwins is unmaintained because of private reasons.

I presume you probably meant "personal reasons"? "Private reasons" sort of implies they're unknown which is not really true.

from awesome.

Hikari seems promising as well: Stacking/Tiling hybrid view management with a minimalistic look & feel. I have not tried it at all since I am using the Nvidia drivers on Fedora 35 for now. However, with F36 it looks like Awesome will no longer be able to run so… ¯\_(ツ)_/¯

from awesome.

with F36 it looks like Awesome will no longer be able to run

Why is that? Is there any problem with awesome and nvidia drivers? I use awesome as my daily driver, this would really be bad news. Hikari looks nice, but I don't see it having widgets or similar.

from awesome.

Why is that? Is there any problem with awesome and nvidia drivers?

No problem whatsoever. I use it daily! However, F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change) so it might be a good time to move to Wayland at this point. Although, I am pretty sure that X11 will remain in Fedora for some time… But who knows?

from awesome.

I believe that Awesome will get unofficial PoC backend next year

Let me know when/if there is a place to follow progress, I'd be really interested in this. I have not been able to find any replacement for what awesome can do and it would be a pity if such a great project dies due to deprecation of X11 at some time. Even today wayland is something I would like to try, but loosing my awesome config is not really an option.

from awesome.

there will be no "Xresources" in API

i think it could be just replaced to simple lua-based text parser for compatibility reasons until wayland ecosystem will come up with something similar

from awesome.

there will be no "Xresources" in API

i think it could be just replaced to simple lua-based text parser for compatibility reasons until wayland ecosystem will come up with something similar

There will never be something similiar, every compositor has it's own ecosystem since you write Display Server like Xorg, Xresources alternative will be useless unless you create protocol which client can implement to sync compositor theme with i.e terminal.

from awesome.

alternative will be useless unless you create protocol which client can implement to sync compositor theme with i.e terminal.

true, i think we need to follow/invite to such sort of conversation developers of wayland terminals, as such sort of mechanism is nice in X

from awesome.

alternative will be useless unless you create protocol which client can implement to sync compositor theme with i.e terminal.

true, i think we need to follow/invite to such sort of conversation developers of wayland terminals, as such sort of mechanism is nice in X

Most terminals are cross-protocol like Alacritty but I don't think that those developers would like to impelement wayland specific features other than being displayed natively, from standalone (not tied to kde or gnome) terminals there is Foot (hosted on codeberg), author is open for new features and sometimes contributes to various compositors to add future parity with his terminal like xdg_activation protocol which adds "urgent" state to windows, so you can implement additional theme variable for that in your compositor but there aren't many apps which support it just yet.

from awesome.

ok, let's just get back to the topic later when most of more important things be in place :)

from awesome.

I believe that Awesome will get unofficial PoC backend next year

Let me know when/if there is a place to follow progress, I'd be really interested in this. I have not been able to find any replacement for what awesome can do and it would be a pity if such a great project dies due to deprecation of X11 at some time. Even today wayland is something I would like to try, but loosing my awesome config is not really an option.

There was awesome-rs repo, but I'd deleted it (had forks so can't restore) but actually I need better name for this project since it's not gonna be same thing as we talked with Elv13, he wanted it to run on glib event loop just like awesome, but I want it to be implemented completely from scratch with config converter due to huge changes in API, widgets will also be implemented from the ground because it's not really possible to integrate protocols like layershell (native wallpaper API, z-indexed layers and possibility to implement overlays for i.e games) to existing implementation, doesn't matter if would it be in C/C++, Rust or even Go.

from awesome.

What's the current state of this?

from awesome.

one of them isn't any nice to use and spread hate related to Nvidia and doesn't provide ANY HELP for users with closed source drivers (any vendor)

We all know who, let's just not talk about them.

from awesome.

After more research and reading this thread, I decided I'm happy with AwesomeWM + X - and probably wouldn't switch to Wayland + Awesome if it did exist:
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

from awesome.

https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

"Let's list a bunch of resolved issues and claim that everything is broken with that new software and will surely never get fixed"...

from awesome.

@cherti Wayland has been around since 2008, and peace-be-upon anyone who wants to use & contribute to it. I think a lot of people were just moving off of X because of the implication it would be deprecated/useless/unsupported in the near future - but I think that is simply untrue and almost the opposite of the truth.

from awesome.

Okay, I've had enough.

• AwesomeWM will not magically turn into a wayland compositor, so closing this issue as wontfix again. (I already did so six years ago.)
• This issue seems to attract "any news on this?"-comments. Sorry, but that's just noise.
• I didn't count how many "here is a small project which tries to reimplement AwesomeWM as a wayland compositor"-comments we had, but there were too many.
• Now we even got into FUD territory.

I'll also lock this thread due to that last point.

from awesome.