Welcome to awesome bug tracking system.

FS#835 - Mplayer in fullscreen - titlebar still displayed

Attached to Project: awesome
Opened by TiP-X (TiP-X) - Thursday, 14 October 2010, 21:13 GMT
Last edited by Uli Schlachter (psychon) - Monday, 12 September 2011, 20:26 GMT
Task Type Bug Report
Category Core
Status Closed
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version 3.4.8
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


When using Mplayer in fullscreen mode, the awesome titlebar is still displayed on top of the video (which is a bit annoying).

To reproduce:
mplayer <file>
press key "f"

I'm using awesome 3.4.8 and this was not happening before (I don't know which version I was using before, but I can test older versions if that can help).
The problem doesn't appear on Ion3.
I'm using a dual screen setup
Gentoo distribution
Nvidia video card
MPlayer SVN-r29796-4.3.4

Screenshot attached.
This task depends upon

Closed by  Uli Schlachter (psychon)
Monday, 12 September 2011, 20:26 GMT
Reason for closing:  Fixed
Additional comments about closing:  commit 8a04ce9c97e71cd5ce8057d984c1e98d6fdfef16
Author: Uli Schlachter <>
Date: Mon Sep 12 22:19:59 2011 +0200

Fix restacking with zaphod mode ( FS#835 )

Boy was this code broken. It tried to stack windows ontop of each other which
were on different screens. However, since they didn't have the same parent, they
obviously couldn't be ontop of each other. The X server just reacted with a "wtf
are you doing?"-kind of error which means the restacking was ignored.

The fix is to restack each screen on its own, completely ignoring any windows
from other screens.

A big thanks goes to Siarhei Siamashka who bisected this issue and helped me
debugging it which took quite a while. Finally, he noticed that my first patch
was broken and also figured out the fix. Thanks!

v2: Move the check on "client_need_stack_refresh" from
client_stack_refresh_screen() into client_stack_refresh(), so that all screens
are restacked instead of just the first one.

Signed-off-by: Uli Schlachter <>
Comment by TiP-X (TiP-X) - Thursday, 14 October 2010, 21:16 GMT
=> screenshot
Comment by TiP-X (TiP-X) - Thursday, 14 October 2010, 21:19 GMT
Note: I'm using the default config
Comment by rawoul (rawoul) - Monday, 06 December 2010, 01:04 GMT
Same thing here, looks like bug #606 is back
Comment by Nikolaj Sjujskij (krigstask) - Monday, 06 December 2010, 14:04 GMT
Works all right for me. Gentoo ~amd64, nouveau, two screens set up with XRandr.
Comment by mikankun (mikankun) - Saturday, 15 January 2011, 19:45 GMT
I'm also having the same issue. I've had to switch 3.4.6 which works correctly. I'm running Gentoo amd64, radeon drivers, and dual-screens (zaphod).
Comment by Uli Schlachter (psychon) - Saturday, 15 January 2011, 21:07 GMT
It might help mentioning which version you switched away from.
Comment by mikankun (mikankun) - Sunday, 16 January 2011, 02:26 GMT
Same version this bug is filed against, 3.4.8.
Comment by Mattias Fliesberg (inty) - Sunday, 13 February 2011, 14:39 GMT
I have the same issue, it works in 3.4.6 but not in >3.4.6. I have a dual-screen setup and it works fine if I only have one of the screens connected but with both connected it doesn't want to cover the titlebar for whatever reason.
Comment by tomboy (tomboy64) - Friday, 18 February 2011, 20:48 GMT
I have the same issue.
Since I use awesome as wm for my HTPC i consider this a blocker.
Last working version for me is 3.4.4; in 3.4.7 and 3.4.8 it doesn't work. Other versions are not available in my distribution (Gentoo).
I am using a dual-monitor setup, with a recent Nvidia card (GT218 / Ion2).

Suggestions are welcome.
Comment by Siarhei Siamashka (ssvb) - Sunday, 11 September 2011, 14:40 GMT
bisecting shows that

d7d70714d7943ac4201072b0605fb923ba1f29a0 is the first bad commit
commit d7d70714d7943ac4201072b0605fb923ba1f29a0
Author: Uli Schlachter <>
Date: Sun Jul 18 09:54:30 2010 +0200

Kick out the systray when wiping a wibox

When a wibox is destroyed or detached from a screen, it is wiped to clean up its
resources. This also includes destroying the window which is associated with the

The problem here is that if the wibox contains the systray, the systray window
would automatically be destroyed since all childs of a window are destroyed when
said window is destroyed. To fix this, we kick out the systray window before
destroying the wibox' window.

Signed-off-by: Uli Schlachter <>

:100644 100644 e72690fd48634c9f4ef215cd7abd84426e462c64 c6becc5b6e7de837c2ab0911034f7012e1c007da M wibox.c
Comment by Siarhei Siamashka (ssvb) - Sunday, 11 September 2011, 15:15 GMT
Sorry, missed by one commit when bisecting. The problematic one is actually;a=commit;h=312094ace3ad540f9793cf5b114c0cc0db0ee7a2

And reverting it in 3.4.10 solves the titlebar on top of the video problem for me.
Comment by Uli Schlachter (psychon) - Sunday, 11 September 2011, 15:57 GMT
Weird, that commit shouldn't have any permanent effects since the next restack should reorder stuff correctly. Also, I still can't reproduce this with my own config nor with git/master's default config (and I still can't build 3.4). Sadly, the stacking code is quite different between 3.4 and master :(.

@ssvb: Could you test another change? In client.c, function client_stack_refresh(), remove the "if (!globalconf.client_need_stack_refresh) return;". If this fixes the problem, something is messing with the stacking order without setting client_need_stack_refresh.
Comment by Uli Schlachter (psychon) - Sunday, 11 September 2011, 16:00 GMT
Actually, wtf? The commit ssvb found only changes code when a new window appears, but when pressing "f" in mplayer, no new window appears, but only an existing one is made fullscreen, so this code shouldn't even be executed? Perhaps add puts("foo"); fflush(stdout); after the xcb_configure_window() to check if that code is executed when fullscreening mplayer?
Comment by Siarhei Siamashka (ssvb) - Sunday, 11 September 2011, 19:02 GMT
> Could you test another change? In client.c, function client_stack_refresh(), remove the "if (!globalconf.client_need_stack_refresh) return;".

Tried that, it has no effect.

> Actually, wtf?

I have a feeling that windows stacking is messed up a bit and not only mplayer is affected. For example, when I was trying to start midori browser (in maximized state), it was occasionally showing up partially overlapped by the other windows. This all happens in "zaphod" dual monitor mode (which apparently had lots of similar bugs in the past and is not the best recommended option).
Comment by Uli Schlachter (psychon) - Sunday, 11 September 2011, 21:35 GMT
Thanks to ssvb for wasting some time to test random stuff!
We figured out that awesome's stacking code is broken with zaphod mode. Instead of restacking windows, it just causes X11 error when it tries to stack windows across monitors. (Which is a terribly stupid idea anyway)


Edit: (Meh, wrong button)
Attached is a patch which fixes this, but I need some sleep now and won't have time tomorrow, but at least we figured out the issue.
   patch (2.3 KiB)
Comment by Siarhei Siamashka (ssvb) - Monday, 12 September 2011, 05:15 GMT
After giving it a bit more testing, the Uli's attached patch seems to fix problems only for the first monitor, but makes windows stacking totally broken for the second monitor.
Comment by Siarhei Siamashka (ssvb) - Monday, 12 September 2011, 19:32 GMT
I'm currently testing this patch modification applied to awesome 3.4.10, with the following part

+ if (!globalconf.client_need_stack_refresh)
+ return;
+ globalconf.client_need_stack_refresh = false;

moved from 'client_stack_refresh_screen(int screen)' to 'client_stack_refresh()'

Both monitors seem to be fine so far.