Terminal windows disappear after disabling external monitor

[phipse]

Hi, I am using an external monitor via VGA or HDMI and xrandr to enable/disable it. When disabling, sometimes a terminal window disappears. That's especially annoying, when vim instances are running in that terminal. I can confirm it's still running, but it is not displayed on any tab, nor in any task bar. Unfortunately, this doesn't happen each time I disable the external monitor and sometimes the window reappears, when I enable/disable the monitor again. I am using Konsole with zsh.

Setup: Fedora 22 KDE spin with login to awesomeWM awesome v3.5.6 (For Those About To Rock) • Build: Jan 17 2015 02:26:27 for x86_64 by gcc version 4.9.2 (mockbuild@) • Compiled against Lua 5.3.0 (running with Lua 5.3) • D-Bus support: ✔

[psychon]

After this happens the next time, could you run the following and see if your terminal is listed (and perhaps even reappears)?

echo 'local t = require("awful.tag") local res = {} for k, c in pairs(client.get()) do res[c.name] = c:tags() t.withcurrent(c) end return require("gears.debug").dump_return(res)' | awesome-client

In any case I'd be interested in the output from this command. It might be that this issue was already fixed in git master and needs to be cherry picked to the 3.5 branch...

Edit: What the code does: Go through all clients that awesome knows about and build a table with client name -> list of tags that the client is on. Then it also calls a function that will tag the client if it doesn't have any tags currently. Finally it returns a string representation of the table that it build (and I just noticed that if two clients have the same name, only one of them will be listed...)

[phipse]

% echo 'local t = require("awful.tag") local res = {} for k, c in pairs(client.get()) do res[c.name] = c:tags() t.withcurrent(c) end return require("gears.debug").dump_return(res)' | awesome-client

string " Signal : 1 : tag: 0x1e3db78 (tag) ~/Uni/diplom/thesis : zsh — Konsole : 1 : tag: 0x1d02a08 (tag) Re: [awesome] Terminal windows disappear after disabling external monitor (#600) - github - philipp@eppelt.de - Mozilla Thunderbird : 1 : tag: 0x1d0ed38 (tag) Buddy List : 1 : tag: 0x1d2c718 (tag) Terminal windows disappear after disabling external monitor · Issue #600 · awesomeWM/awesome - Mozilla Firefox : 1 : tag: 0x1d06338 (tag) ~ : beet — Konsole : 1 : tag: 0x1cacca8 (tag) 30_design.tex (~/Uni/diplom/thesis/content) - GVIM : 1 : tag: 0x1d7dd68 (tag)"

All windows accounted for, but my vim instance is still running somewhere and not mentioned here.

[psychon]

None of those konsole windows is the one with your vim? Does your vim modify the window title?

Ok, this is weird. So awesome really doesn't know about the window, it is not just not tagged with any tag. No idea what this has to do with external monitors...

Can you find your Konsole vim window in the output of xwininfo -root -tree? It should be one of the direct children of the root window, without anything intermediate (I'd be interested in the output of the command and your explanation for what which window is). When you have the window id of the konsole window (something like 0x2200008), could you run xwininfo -id 0x2200008 ; xdotool windowunmap 0x2200008 ; sleep 1 ; xdotool windowmap 0x2200008? This displays some information about the window (I'm curious about its position and size) and then unmaps and maps the window. Now this really ought to make the window re-appear...

[phipse]

Actually, there are 100children of the root window, I'm not going to list them all.

% xwininfo -root -tree

xwininfo: Window id: 0x99 (the root window) "LG3D"

  Root window id: 0x99 (the root window) "LG3D"
  Parent window id: 0x0 (none)
     100 children:
...

There are a lot of windows with status "has no name" and a couple of windows, which I don't even remember vanishing in the last 6 days. If the "Map State" displayed was IsUnMapped I maped it as you recommended. And it appeared. Yay! For example:

% xwininfo -id 0x1000154

xwininfo: Window id: 0x1000154 "~/Uni/diplom/git_tudos/l4re/build : lua — Konsole"

  Absolute upper-left X:  1
  Absolute upper-left Y:  1100
  Relative upper-left X:  1
  Relative upper-left Y:  1100
  Width: 638
  Height: 779
  Depth: 24
  Visual: 0x86
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1000152 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: no
  Corners:  +1+1100  -961+1100  -961-121  +1-121
  -geometry 638x779+1+1100

% xdotool windowmap 0x1000154

What makes me curious is the presence of many windows, that are already closed. E.g. a Thunderbird composing window. Ca. 29 Windows tagged with Thunderbird, 24 tagged with Firefox. I did find one window named 'vim':

     0xa00091 (has no name): ()  1278x779+0+1219  +0+1219
        1 child:
        0x2200001 "Vim": ("gvim" "Gvim")  1278x779+0+0  +1+1220
           1 child:
           0x2200002 (has no name): ()  1x1+-1+-1  +0+1219

Mapping this lead to the appearance of a black window with no interaction capabilities, not even mod+shift+c works. xwininfo -id output for all three IDs follows the first two calls are before and after mapping the window. Is there a way to connect the window IDs to the ProcessID?

 xwininfo -id 0x2200001     

xwininfo: Window id: 0x2200001 "Vim"

  Absolute upper-left X:  10
  Absolute upper-left Y:  10
  Relative upper-left X:  10
  Relative upper-left Y:  10
  Width: 10
  Height: 10
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: no
  Corners:  +10+10  -1580+10  -1580-1980  +10-1980
  -geometry 10x10+10+10

 % xdotool windowmap 0x2200001
 % xwininfo -id 0x2200001     

xwininfo: Window id: 0x2200001 "Vim"

  Absolute upper-left X:  1
  Absolute upper-left Y:  1220
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1278
  Height: 779
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnviewable
  Override Redirect State: no
  Corners:  +1+1220  -321+1220  -321-1  +1-1
  -geometry 1278x779+0-0

 % xwininfo -id 0xa00091

xwininfo: Window id: 0xa00091 (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  1219
  Relative upper-left X:  0
  Relative upper-left Y:  1219
  Width: 1278
  Height: 779
  Depth: 32
  Visual: 0x5e
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0xa00000 (not installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: yes
  Corners:  +0+1219  -320+1219  -320-0  +0-0
  -geometry 1278x779+0-0

% xwininfo -id 0x2200002

xwininfo: Window id: 0x2200002 (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  1219
  Relative upper-left X:  -1
  Relative upper-left Y:  -1
  Width: 1
  Height: 1
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnviewable
  Override Redirect State: no
  Corners:  +0+1219  -1599+1219  -1599-780  +0-780
  -geometry 1x1+0-0

[psychon]

X11 uses windows for lots of things besides showing stuff. E.g. EWMH makes us create a window just so that applications can get the name and capabilities of the running window manager. You likely got such a window and made it visible (which would also explain why nothing draws to it and it is simply black). This could also explain the thunderbird composite windows: When sending a mail, the window is just made invisible and re-used the next time that you write a mail. Edit: You can get rid of such a window via windowunmap. Also, the size of 1x1 is a big hint that this is such a window.

For getting the process id of a window: xprop -id 0xFOO gets you all its properties, one of them is _NET_WM_PID. You can also just ask for the pid via xprop -id 0xFOO _NET_WM_PID.

Thanks for debugging this so far. I thought I once fixed something like this, but I can't find it in the git history. Currently I do not know why these windows end up being unmapped across a restart.

[phipse]

Not a restart: I use this mit VGA1/HDMI1 as parameter to disable the external monitor: xrandr --output $1 --off --output $1 --auto

The PID told me, this was part of the gvim window, which was shown under another ID by xwininfo, too. I extracted all IDs from xwininfo -root -tree and checked their PID via xrprop -id $ID _NET_WM_PID: wininfo -root -tree | g --color=never -o -E "0x[[:xdigit:]]{5,7}" >> all_window_ids while read p; do xprop -id $p _NET_WM_PID done <all_window_ids >> all_window_pids

Then I inspected the output of the 164 PIDs (not all windows had one) and didn't find the PID of the vim instance still running. Where did it go? Is there a way to deduce the windowId, from the processId?

[psychon]

Well, vim doesn't open a window. You are looking for a window with konsole's PID. You should be able to find this one by getting the parent process id (PPID) of vim.

@"not a restart": Awesome doesn't RandR changes that nicely. What it does when something in your monitor configuration changes is a restart. This is also why so much state is lost when some monitor is activated/deactivated.

[phipse]

Right. I will list the steps taken to get the Konsole PID:

% ps -o ppid= -p 20785
28454 << zsh

% ps -o ppid= -p 28454
11593 << Konsole

% gr -n 11593 all_window_pids
9:_NET_WM_PID(CARDINAL) = 11593
12:_NET_WM_PID(CARDINAL) = 11593
28:_NET_WM_PID(CARDINAL) = 11593
30:_NET_WM_PID(CARDINAL) = 11593
32:_NET_WM_PID(CARDINAL) = 11593
37:_NET_WM_PID(CARDINAL) = 11593
63:_NET_WM_PID(CARDINAL) = 11593
112:_NET_WM_PID(CARDINAL) = 11593
137:_NET_WM_PID(CARDINAL) = 11593

>> line 9 contains ID 0x100036d

% xwininfo -id 0x100036d

xwininfo: Window id: 0x100036d "Konsole"

  Absolute upper-left X:  282
  Absolute upper-left Y:  1559
  Relative upper-left X:  282
  Relative upper-left Y:  1559
  Width: 365
  Height: 226
  Depth: 24
  Visual: 0x86
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1000356 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: yes
  Map State: IsUnMapped
  Override Redirect State: yes
  Corners:  +282+1559  -953+1559  -953-215  +282-215
  -geometry 365x226+282+1559

% xdotool windowmap 0x100036d
% xwininfo -id 0x100036d     

xwininfo: Window id: 0x100036d "Konsole"

  Absolute upper-left X:  282
  Absolute upper-left Y:  1559
  Relative upper-left X:  282
  Relative upper-left Y:  1559
  Width: 365
  Height: 226
  Depth: 24
  Visual: 0x86
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1000356 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: yes
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +282+1559  -953+1559  -953-215  +282-215
  -geometry 365x226+282+1559

After mapping the window I had a rectangle on each screen, displaying the content of the window that was there before mapping. I got rid of it while selecting the console text and invoking the context menu with a right click. xdotool windowunmap 0x100036d should have done the same, I guess. New status:

xwininfo -id 0x100036d

xwininfo: Window id: 0x100036d "Konsole"

  Absolute upper-left X:  461
  Absolute upper-left Y:  1684
  Relative upper-left X:  461
  Relative upper-left Y:  1684
  Width: 344
  Height: 226
  Depth: 24
  Visual: 0x86
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1000356 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: yes
  Map State: IsUnMapped
  Override Redirect State: yes
  Corners:  +461+1684  -795+1684  -795-90  +461-90
  -geometry 344x226+461-90

I went through all the windowIds, but none show this vim instance. htop: 20785 phipse vim -p ../resume.tex ../awesome-cv.cls

[psychon]

If a context menu gets rid of the window, perhaps that was the window for the context menu? I don't know. And the "displays what was there before" likely just means that nothing at all was drawn to it and the window doesn't have a background color. :-)

Sorry, but I have no idea for that missing vim. You already know how to get to these lost windows, so perhaps konsole somehow lost vim? No idea how it would do that.

[phipse]

Well, it copied the content of the window below and even if I changed screens, this window kept the content and position and was displayed above everything else.

Thanks, for your help. I learned a lot about debugging awesome and X. If I find a clue I let you know.

[psychon]

So what this issue is actually about: During restart awesome somehow loses windows. I have no idea how this is related to your other monitor. Perhaps some minimized windows...? (And yeah, the server will happily move the contents of a window together with that window, even if the window wasn't actually painted to and just contains whatever was there before; for that "above everything else": I just noticed Override Redirect State: yes in the xwininfo output. Such windows are ignored by the WM. They are e.g. menus or tooltips (any kind of window that the window manager doesn't know about at all). You can just ignore those when looking for a lost vim.)

[Elv13]

Is this solved?