VirtualBox 5.X with "Auto-resize Guest Display" moves the window to first monitor

[NickeZ]

Output of awesome --version:

$ awesome --version
awesome v3.5.9 (Mighty Ravendark)
• Build: Mar 20 2016 11:06:36 for x86_64 by gcc version 5.3.1 (buildd@lgw01-10)
• Compiled against Lua 5.1.5 (running with Lua 5.1)
• D-Bus support: ✔

How to reproduce the issue:

• Start VirtualBox 5.0 or 5.1.
• Start any virtual machine.
• Enable "View" -> "Auto-resize Guest Display".
• Move window to monitor with different resolution (modkey + 'O').

Actual result:

When the window decides to resize the guest it jumps to the first monitor instead of staying on the current monitor.

Expected result:

It should stay on the same monitor like it did with awesome 3.4.

More info
Running Ubuntu 16.04 on a thinkpad t440s with a GeForce GT 730M. Also using nouveau.

Screen 0: minimum 8 x 8, current 6528 x 1440, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm
   1920x1080     60.01*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1368x768      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
DP1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     59.95*+
   1920x1200     59.88  
   1920x1080     60.00    60.00    50.00    59.94    24.00    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DP2 connected 2048x1152+4480+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2048x1152     59.91*+
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1152x864      75.00  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   640x480       75.00    60.00  
   720x400       70.08  

[NickeZ]

Related? #769

[psychon]

• Enable "View" -> "Auto-resize Guest Display".

Is this important? If this issue does not occur with this setting, then I highly suspect that something is wrong in VirtualBox. I cannot try myself since I'm allergic to downloading random programs from the internet and running them (and Fedora doesn't seem to have a VirtualBox package).

Does the floating status of virtualbox have any influence? (E.g. "issue does not occur when VirtualBox is made floating)

Could you add the following to the end of your config and provide the output (and explain it a bit, if you can; like which line corresponds to which thing that you did):

client.connect_signal("property::geometry", function(c)
    local g = c.geometry
    print(os.date(), c.name, "x=" .. g.x, "y=" .. g.y, "width=" .. g.width, "height=" .. g.height)
end)

I'm asking for this last thing since I suspect that VirtualBox is first moved to the other monitor (=> a line would be printed by the above) and then VirtualBox moves itself somehow around (=> a line is printed) and then Awesome's normal layout code kicks in and moves the window back into a "proper position" (=> a line is printed).

[NickeZ]

Is this important?

It seems to also occur when I use "View" -> "Virtual Screen 1" -> "1024x768". Which seems to be the way to manually select the guest resolution.

I cannot try myself since I'm allergic to downloading random programs from the internet and running them (and Fedora doesn't seem to have a VirtualBox package).

The free version is packaged in ubuntu AFAIK. (I'm using the oracle version if it matters..)

Does the floating status of virtualbox have any influence?

If I make it floating it does not jump to another screen. =)

There seems to be two ways to resize the guest. Either with the "auto-resize" or manually setting different resolutions. When the window is floating it stays on the same screen. But:

• If I enable auto-resize and resize the window with "alt+ right mouse click" the window is moved to the upper left corner and is resized to some other size.
• If I disable auto-resize and manually set a resolution it seems to work for small-ish resolutions.

Could you add the following to the end of your config and provide the output (and explain it a bit, if you can; like which line corresponds to which thing that you did):

I added it and I'm getting a bunch of errors as red notifications:

attempt to index local 'g' (a function value)

I also don't know where the output of the print function would end up. Could you tell me?

[NickeZ]

I seem to have found a "works for me" fix. With "auto-resize" enabled, if I have it floating and then maximize it (Ctrl+Alt+Space, Alt+M), it actually does what I want. Thanks!

I'm still happy to give you more logs if you want.

[psychon]

attempt to index local 'g' (a function value)

Whoops, sorry. It should be local g = c:geometry() (with ()).

I also don't know where the output of the print function would end up. Could you tell me?

Assuming you have lsof:

$ lsof -c awesome
[Lots of output]
awesome 1112 psychon    2w      REG               0,47   425722 4036595 /home/psychon/.xsession-errors
[Lots of output]

The line with the value "2" in the fourth column is where awesome's stderr goes to. The last column hopefully has a file name. (Other values mean more complicated things)

Where this goes to depends on how you start awesome. For example, with gdm the output should end up in /var/log/gdm.log.

I have a debian machine. I will try to reproduce this there, but it might take a while until I have the time to do that.

Edit by Elv13: c.geometry() to c:geometry(), once screen.geometry exists (btw, any good idea how to change this without breaking the API)

[NickeZ]

How to reproduce:

• Auto-resize enabled
• Virtualbox is neither maximised nor floating on laptop screen.
• Use Ctrl+O to move it to second screen

Result:
Virtualbox jumps back to laptop screen.

jul 26 10:06:17 niklas-tp gnome-session[3805]: Tue Jul 26 10:06:17 2016        Development-2.2.3 [Running] - Oracle VM VirtualBox        x=1920        y=20        width=2556        height=1416
jul 26 10:06:17 niklas-tp gnome-session[3805]: Tue Jul 26 10:06:17 2016        Development-2.2.3 [Running] - Oracle VM VirtualBox        x=1920        y=20        width=2556        height=1416
jul 26 10:06:19 niklas-tp gnome-session[3805]: Tue Jul 26 10:06:19 2016        Development-2.2.3 [Running] - Oracle VM VirtualBox        x=1920        y=20        width=2556        height=1416
jul 26 10:06:19 niklas-tp gnome-session[3805]: Tue Jul 26 10:06:19 2016        Development-2.2.3 [Running] - Oracle VM VirtualBox        x=1920        y=20        width=2556        height=1416
jul 26 10:06:19 niklas-tp gnome-session[3805]: Tue Jul 26 10:06:19 2016        Development-2.2.3 [Running] - Oracle VM VirtualBox        x=0        y=20        width=1916        height=1056

btw, I'm running awesome in a gnome session and I'm using systemd. Therefore I found the output in journalctl -b -u session-c2.scope -f. Session can be found with systemctl -t scope.

I also had to add the client c as an argument to the function call:

client.connect_signal("property::geometry", function(c)
   local g = c.geometry(c)
       print(os.date(), c.name, "x=" .. g.x, "y=" .. g.y, "width=" .. g.width, "height=" .. g.height)
   end)

[subbyte]

Same issue here. I am using Archlinux with awesome 3.5.9 and Virtualbox 5.1.4. I am in pure awesome, no gnome or other desktop environment running. Monitor control via xrandr.

1. If I disable "Auto-resize Guest Display" in VBox, there is no issue moving the guest OS to monitor 2.
2. If I use float mode for the guest OS window, there is no issue moving it to monitor 2.
   Otherwise, it will go back to monitor 1 after Alt+o.

[subbyte]

@psychon I add your debug code into my rc.lua, but I am not sure where to read the printed information. Please let me know if you need me to generate some logs, and where I can retrieve the logs (generated by the print function in lua).

[psychon]

VirtualBox (5.0.24-dfsg-2, the version from debian testing) just managed to basically freeze my WM issue by getting into a fight. Its main window (not the one for a particular machine) started jumping around by single pixels (or was it its border width changing?). This busy loop meant that other commands weren't interpreted and I SIGKILL'd awesome.
Oh and I didn't manage to reproduce this. VirtualBox's VM window was jumping between screens, but not in the way specified here.
I lost interest in trying to debug this and I guess VirtualBox is (accidentally?) moving its window around.

Edit: Oh and my /tmp is full due to awesome's stderr being filled with things like this:

2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'
2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'
2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'
2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'
2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'
2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'
2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'
2016-08-30 16:42:07 W: awesome: luaA_class_call_handler:385: [string "return debug.traceback("error while running f..."]:1: too many C levels (limit is 200) in main function near 'return'

Edit: Ok, I tried looking into the VBox source code a bit, but after the following I can conclude that they don't know what they are doing:

VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c-        /*
VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c-         * This is ugly, but it seems to be the only thing that works.
VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c:         * Basically, XResizeWindow() doesn't seem to always take effect
VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c-         * immediately.
VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c-         * Even after an XSync(), the GetWindowAttributes() call will sometimes
VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c-         * return the old window size.  So, we use a loop to repeat the window
VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c-         * resize until it seems to take effect.
VirtualBox-5.1.4/src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c-         */

[Elv13]

@psychon If you can't reproduce on master, can we close this?

[Knaldgas]

I have had similar problems.

Using:

• Debian stretch/sid (testing).
• VirtualBox from debian repos: 5.1.4-dfsg-1+b1
• Windows XP guest with newest guest additions installed.
• Awesome: 3.5.9-1
• Laptop 1440x900 with external monitor 1920x1200 above (xrandr)

Launching VirtualBox with Windows XP client on external monitor:
VirtualBox starts then does a couple of resizes, and settles on (estimated) 640x480 top left corner (probably Windows XP startup resolution) with start-up splash, then after boot resizes to 1438x879 (windows Display properties). To me it seems like perfect auto-size for the laptop monitor, although it's actually on the external monitor.

Launching from the laptop monitor, same sequence, but ends up in continuously swapping between laptop and external monitor. This can be stopped with "Meta-O" (change to other monitor).

In both cases I can get the VirtualBox on to the external monitor by having it on an empty laptop screen, pressing Meta-O, and then immediately press Meta-O again (sometimes requires a couple of tries), then I get VirtualBox to stay on the external monitor in the right size. But if I start another application up that requires VB to resize, it starts jumping forth and back until caught by Meta-O.

I have no idea what is causing it Awesome or VirtualBox, but they obviously do not like each other very much right now...

[NickeZ]

I started trying out I3 after using awesome 3.4 for many years. So far I'm very happy with how it handles multiple monitors.

[Airblader]

FYI, I think this issue is related or even the same as this ticket over at VirtualBox: https://www.virtualbox.org/ticket/15863

[NickeZ]

Inspired by the virtualbox ticket I did an xtrace of virtualbox. I attached the log file.

What I did:

1. Start VM (VM starts on screen 1)
2. Move VM to second screen (Ctrl+O)
3. VM jumps back to screen 1.
4. Exit VM with (Ctrl+Shift+C, Enter)

xtrace.awesomwm.virtualbox.txt

[Elv13]

This issues has apparently been fixed upstream