Awesome: multi-monitors: Disabling/enabling screens using xrandr causes some clients to become unraisable

[liquiddandruff]

Output of awesome --version:

$ awesome -v
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

$ xrandr --version
xrandr program vzzzzzersion       1.5.0
Server reports RandR version 1.5

Tested with /etc/xdg/awesome/rc.lua.

How to reproduce the issue:

1. Acquire 2 monitors. In my case: HDMI1 (external), and VDS1 (laptop).
2. Enable HDMI1 with xrandr --output HDMI1 --primary --mode 1920x1080 --output LVDS1 --auto --below HDMI1
3. Start several clients on both screens
4. Disable HDMI1 with xrandr --output HDMI1 --off --output LVDS1 --primary --auto

Actual result:

Clients that were on HDMI1 at the moment of being disabled are never moved back to LVDS1 (i.e, does not even appear on LVDS1's menubar, minimized or otherwise).

Clients that have been moved back manually to the primary screen prior to disabling the display it came from (e.g, HDMI1) are however shown in a minimized state on the primary screen, but trying to raise them (restore unminized) has no effect--they remain minimized, and therefore unusable.

(this seemed to have happened with my custom rc.lua, but is not exactly the same scenario anymore with /etc/xdg/awesome/rc.lua).

After fiddling with this more I've realized this issue only ever occurs to some types of clients. For example, I found that chromium and ccstudio (Code Composer Studio, an eclipse IDE) always becomes unraisable whenever any xrandr event occurs. I.e., these clients will become unraisable on both enable and disable of HDMI1. However, other clients like all of my urxvtc terminals and logic (a logic analyzer program; it's the only other non-terminal program I tested, there are likely others out there that work) will always remain functional.

When clients become unraisable due to HDMI1 enable events, I've noticed that the only way to make them usable again aside from forcibly restarting awesome is to focus them using super+k/j and moving them to HDMI1 with super+o. This will then successfully raise the client. When a client is in an unraisable state, I could still close it, but all other manners of client operations such as maximizing, unminimizing, etc, has no effect.

When clients become unraisable due to HDMI1 disable events, the only fix to make them usable again would be to restart awesome; super+o would have fixed them, but it won't work since there's no other screen to move the client to.

No errors have ever been displayed during these tests.

Expected result:

All clients should remain functional and moved appropriately back to enabled screens on xrandr/screen events.

The only complete fix I've found is to forcibly restart awesome. This then fixes every client and makes them usable again.

I originally reported this issue in awesome-copycats. Also, I am pretty sure an update to some other package in the pipeline (outside of awesomewm's control) likely introduced this "regression", since I am positive I did not encounter this issue before. This issue became apparent to me a few months ago after using my laptop more both as a workstation and on-the-go.

[psychon]

In the last few days I thought a bit and... no idea. So: Is there anything on awesome's stdout or stderr? If you don't know where awesome's output goes to, the following might help (or not, it depends): ls -l /proc/$(pidof awesome)/fd/1 /proc/$(pidof awesome)/fd/2

[liquiddandruff]

I took a quick glance earlier but didn't find anything of note. I'll take a closer look once I'm free.

[thanhnl]

I have same problem. After disabled external display, all client moved to LVDS, and some couldn't raise. I pressed super+m, it raised with these errors:

2017-11-27 23:37:06 W: awesome: luaA_dofunction:77: error while running function!
stack traceback:
        [C]: in metamethod '__index'
        /usr/share/awesome/lib/awful/placement.lua:102: in upvalue 'get_screen'
        /usr/share/awesome/lib/awful/placement.lua:1437: in function </usr/share/awesome/lib/awful/placement.lua:1421>
        (...tail calls...)
        /usr/share/awesome/lib/awful/ewmh.lua:279: in function 'awful.ewmh.geometry'
        [C]: in metamethod '__newindex'
        /home/thanh/.config/awesome/rc.lua:387: in upvalue 'press'
        /usr/share/awesome/lib/awful/key.lua:91: in function </usr/share/awesome/lib/awful/key.lua:91>
error: /usr/share/awesome/lib/awful/placement.lua:102: invalid object

[psychon]

@thanhnl What is /home/thanh/.config/awesome/rc.lua:387? Is that function(c) c.maximized = not c.maximized c:raise() end (with some line break around it, line 387 is the assignment to c.maximized)?
Also, what's your awesome version? /usr/share/awesome/lib/awful/placement.lua:1437 makes no sense (it's in the middle of a comment here, aka "not code").
This code is accessing some screen that was already deleted. I guess that for some reason these clients are still assigned to the already-removed screen. That should not really happen. Something like awesome-client 'for _, c in pairs(client.get()) do c.screen = 1 end' could work around this and get things working again. But the bug here is: Why weren't the clients (properly) moved to another screen when their screen was removed!? Is there anything "special" in your config that could interfere?

[thanhnl]

@psychon
I'm using Funtoo, x11-wm/awesome-4.2:

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

/home/thanh/.config/awesome/rc.lua:387

    awful.key({ modkey,           }, "m",
        function (c)
            c.maximized = not c.maximized   -- line 387
            c:raise()
        end ,
        {description = "maximize", group = "client"}),

/usr/share/awesome/lib/awful/placement.lua:1437

https://github.com/awesomeWM/awesome/blob/20dfff373dbf6f9055f9d40ab9f294cf9f38cf0f/lib/awful/placement.lua#L1437

I have 2 monitor, DP1 + LVDS. I maximized some clients in tile layout. After turn off DP1, all clients moved to LVDS, those maximized clients appeared in tasklist on remain monitor, but I can't raise it. After focused on it, press super + m, it raised and awesome showed errors as above post.

[psychon]

Ahhh... Sorry for messing up my line numbers earlier.
@Elv13 The memento that awful.placement creates/manages contains the screen for which it is valid. That seems to be the problem here (memento.screen.valid seems to be false). I could just fix this by adding a check for .valid, but this leaves another problem:

• Maximise a client
• Use xrandr to move the client's screen (e.g. --left-of instead of --right-of)
• Unmaximise the client
  The client will be unmaximised at the old position of the screen. Basically, the check get_screen(memento.screen) ~= get_screen(d.screen) that causes the problem here is broken beyond the obvious use of an invalid screen.

Can we get rid of memento.screen and use memento.sgeo exclusively?

Also:
https://github.com/awesomeWM/awesome/blob/73b70d34faae9d34f805d2be25ea75f25c82f292/lib/awful/placement.lua#L1436-L1438
In the above scenario (s.geometry changed since the memento was created), what should happen? I guess that this here is the "someone complains"-case that the comment waits for. (Otherwise, only unmaximisation will do the right thing while other cases would still continue using the screen's old geometry)
(Or should "client moved to another screen" and "screen moved" be treated differently?)