awesomeWM / awesome Dismiss Join GitHub today GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together. Sign up "Wayland" or Mir support of awesome #159 New issue Closed zaxebo1 opened this issue Mar 6, 2015 · 23 comments zaxebo1 commented Mar 6, 2015 Assignees No one assigned 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 Labels supports wayland. enhancement Is there any plan /roadmap for awesome for porting to wayland need info wontfix 3 Projects Elv13 commented Mar 6, 2015 • edited Member None yet X wont be discarded for at least 15 years. It will be supported as an alternate protocol in Wayland and Mir Milestone just as it is on OS X. No milestone 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 10 participants 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, 3 actionless commented Mar 6, 2015 Member 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 commented Mar 6, 2015 Member 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). 1 zaxebo1 commented Mar 6, 2015 @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 :-( 1 2 zaxebo1 commented Mar 6, 2015 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 commented Mar 6, 2015 Member "patches" welcome zaxebo1 commented Mar 7, 2015 okk :-) ff2000 commented Mar 16, 2015 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 commented Mar 16, 2015 @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 commented Mar 16, 2015 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. blueyed added the enhancement label Mar 17, 2015 aignas commented May 20, 2015 Contributor 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 commented May 20, 2015 Member 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 commented Nov 26, 2015 +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 commented Nov 26, 2015 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 psychon added wontfix need info labels Feb 10, 2016 psychon closed this Jul 4, 2016 actionless commented Aug 19, 2016 Member found in the news one more interesting project related to the topic https://github.com/Immington-Industries/way-cooler 6 Elv13 commented Aug 20, 2016 • edited Member 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 1 Timidger commented Apr 14, 2017 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. 3 8 ❤ 7 zaxebo1 commented Apr 14, 2017 @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 commented Apr 14, 2017 @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).