Welcome to awesome bug tracking system.

FS#996 - Borders are drawn on VirtualBox guest in fullscreen

Attached to Project: awesome
Opened by Arvydas Sidorenko (Asido) - Saturday, 12 May 2012, 18:31 GMT
Last edited by Uli Schlachter (psychon) - Wednesday, 16 May 2012, 21:07 GMT
Task Type Bug Report
Category Core
Status Closed
Assigned To No-one
Operating System Linux
Severity Medium
Priority Normal
Reported Version git/master
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


With multihead setup very often I use one screen specifically for running OS in virtualization in fullscreen mode. So just by hitting ctrl+i I can toggle between the host and guest. The problem in VirtualBox is that whenever guest is focused, the top and left borders show up and right and bottom goes offscreen. That means Awesome sees the guest client as a non-fullscreen window. In vmware everything works fine. I have attached both window xprop's, maybe someone can see something not right.
This task depends upon

Closed by  Uli Schlachter (psychon)
Wednesday, 16 May 2012, 21:07 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with commit 3cbb59b0dcadc9e2894aad6b252e81a1c0c6ed9e
Comment by Uli Schlachter (psychon) - Saturday, 12 May 2012, 18:37 GMT
Please tell me that you did a mistake when creating those files:

$ grep -i fullscreen vbox.xprop vmware.xprop

The first one is correct, the second one is impossible.

Also, could you attach your rc.lua?
Comment by Arvydas Sidorenko (Asido) - Saturday, 12 May 2012, 18:48 GMT
Huh, the beginning `_NET_WM_S` got cut.
   rc.lua (20.1 KiB)
Comment by Arvydas Sidorenko (Asido) - Wednesday, 16 May 2012, 00:35 GMT
So that happens because vbox becomes fullscreen before making it visible and vmware the other way around, so as the last touch when a client becomes visible Awesome applies default rules - focus, keys, buttons, and borders.
My proposed solution at first was to get rid of global rules and apply default setings at client_manage, which does xcb_create_window and sounds like a logical place for that. But since EWMH specifications are implemented in Lua, this will be overwritten. So the only option I could think of atm is to connect to the signal inside ewmh.lua which client_manage at the end emits and use that callback to apply the default settings. That sounds more flexible way which can act based on situation and EWMH specification. I attached a patch how it **could** look like (it fixes the issue for the moment). Any better ideas?