Awesome: "Wayland" support of awesome

[zaxebo1]

As X will be discarded in a short time by Fedora and Ubuntu etc. GNOME, KDE etc are being directly compatible with Wayland (or Mir ). Even with e19 release the enlightment window manager also directly supports wayland.
Is there any plan /roadmap for awesome for porting to wayland

[Elv13]

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,

[actionless]

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 ?

[Elv13]

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).

[zaxebo1]

@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 :-(

[zaxebo1]

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

[Elv13]

"patches" welcome

[zaxebo1]

okk :-)

[ff2000]

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.

[zaxebo1]

@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

[ff2000]

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.

[aignas]

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

[Elv13]

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.

[kierun]

+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.

[zaxebo1]

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

[actionless]

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

[Elv13]

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

[Timidger]

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.

[zaxebo1]

@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?

[Timidger]

@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)

[kierun]

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

[kierun]

@Timidger

Floating windows per workspace

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

[charwhee]

"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

[Timidger]

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

[aviau]

@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?

[Elv13]

@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

[psychon]

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

[Timidger]

@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.

[Timidger]

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.

[ghost]

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

[legion151]

So does this mean awesome dies with X?

[ashpieboop]

Any news on this?

[psychon]

No

[exzombie]

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

https://github.com/taiwins/taiwins

[actionless]

also, related ticket: https://github.com/awesomeWM/awesome/issues/2635

[reesericci]

@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.

[Hi-Angel]

@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.

[branwright1]

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.