Weird behavior on multiple screens

[gunar]

Hi, thank you for this awesome plugin to awesome wm 🚀

Steps to reproduce:

1. Have multiple screens (each with its tags)
2. Call revelation
3. Choose one client
4. Weird behavior: all clients are attached to all tags.

[blueyed]

Do you see an error in awesome's log/output?

[guotsuan]

Hi,

If this bug will depend on some specific client? or general any client?

If may happen, if you just restart awesomeWM, and there are clients pre-exist before restart of the awesome, which are now not managed by new awesomeWM after restart? And more log/output will help debug the error as @blueyed suggested

[gunar]

Thanks for following up!

The only error I'm getting is this unrelated error multiple times:

2017-03-15 11:19:00 W: awesome: xerror:989: X error: request=GrabKey (major 33, minor 0), error=BadAccess (10)

The problem seems to happen when I am on one screen and I select (through keyboard) a window in the other screen. It is as if, after showing all clients for the preview, revelation won't put them back where they belong.

[gunar]

• Confirmed it the bug does not happen when I have a single screen configured.
• Confirmed problem happens with clients that existed before restarting awesomeWM, but also with clients created after restarting awesomeWM.

[blueyed]

Which awesomeWM version are you using?
If it's v4.0, please try with Git master - there might be fixes in Awesome itself regarding this.

[guotsuan]

Thanks @gunar for the test. I'm wondering too what is you awesomeWM, and if you use the git version, you can try to update to latest version. I use two screen too, but I have no similar problem. revelation use API function provided by awesomeWM to collect and return all the clients. For now I cannot reproduce the problem? Let me know if you find any new clues.

[gunar]

Sorry for the delay.
I waited for my distro (Manjaro) to update awesome (lazy, I know)
The unintended behavior persists on

awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.4 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.1

[guotsuan]

Hi @gunar， I'm sorry that I may not be able work on this issue in the next month. I just re-located back to China. My beloved Arch linux desktop computer was dismantled into components and waiting to be woke up...

[blueyed]

@gunar
btw: there are https://aur.archlinux.org/packages/awesome-luajit-git/ and https://aur.archlinux.org/packages/awesome-git/

[landauclassic]

@gunar i had similar problem with community/awesome, two days ago switched to awesome-luajit-git as @blueyed suggested, git version fixed my issues with revelation, plus other problems with fullscreen and mpv

[sim590]

I experience a weird behavior too. When I have a second monitor connected, many windows opened (with fewer, the bug doesn't occur) and at least one window present in the secondary screen, all of my windows in the primary screen will get stuck on a single tag, i.e. the windows on the primary screen are not put back where they were initially. This means that revelation may be crashing or something. I have made of video to illustrate the issue.

Version

I use the debian package produced with the awesome's Makefile.

awesome v4.2-116-g790a6690 (Human after all)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.1

[sim590]

Also, the windows in the secondary screen will suffer from the same problem actually.

It's even possible to call revelation from the primary screen and everything will work OKAY on the primary screen, but on the secondary screen, all windows will suffer from the same bug.

[guotsuan]

I have watched your video. I may run into the same bug sometimes. As you said it happen for the case that you have slightly more window clients. However Revelation itself have no direct control where to put back the window clients. It just call the system (awesome) API. In theory, it is the same for Revelation to put back a few or more window clients. I'm puzzled by this too. But I will look into it.

[L0uac]

Hi, thank you for the plugin :-)

but exactly the same problem here:

awesome v4.2 (Human after all)
• Compiled against Lua 5.3.4 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.5
• LGI version: 0.9.2

[offray]

I have the same problem reported by @sim590, running awesome-luajit-git 4.2.521.g820094c3-1 with awesome-revelation-git 2017.01.30.gaa05fce-1. After running the revelation shortcut all clients in the primary monitor get attached to the tag where I was located when running it.

Revelation is an important piece of an ergonomic experience using Awesome. Let me know if there is any other way I can help fixing the issues with it.

[stanzahk]

Hi there,

i am struggling with this issue too. I managed to resolve it this way.

index eca7dc6..a9c8adc 100644
--- a/init.lua
+++ b/init.lua
@@ -218,11 +218,15 @@ end
 
 
 function revelation.restore(t, zt)
-    for scr=1, capi.screen.count() do
-        awful.tag.history.restore(scr)
-        t[scr].screen = nil
+    for s in screen do
+        awful.tag.history.restore(s)
     end
 
+--    for scr=1, capi.screen.count() do
+--        awful.tag.history.restore(scr)
+--        t[scr].screen = nil
+--    end
+
     capi.keygrabber.stop()
     capi.mousegrabber.stop()

t[scr].screen = nil is the line that seems to prevent stuff to wok correctly, but i do not know the purpose of that code.

[ryanthomas-org]

I'm replicating sim590's issue consistently.

Neither stanzahk nor thiru's proposed solutions work for me on v4.3 - I looked at sim590's commit on the rc.lua end but he seems to just be disabling revelation whenever more than 1 screen is in use. Has anyone found a workaround for stable version of awesome?

Sorry for the pings, I was editing the an old init file. The patch to comment out t[scr].screen = nil worked for me.

EDIT EDIT: To add some value to this post, I'll note that replacing t[scr].screen = nil with t[scr]:delete() seems to work just as well as deleting it. This had been proposed as a workaround for another issue here: #36 Just in case that would make a better pull request for some reason