Welcome to awesome bug tracking system.

FS#717 - SDL fullscreen apps handled bad

Attached to Project: awesome
Opened by Dunric (dunric) - Friday, 08 January 2010, 03:18 GMT
Last edited by Julien Danjou (jd) - Friday, 10 September 2010, 13:06 GMT
Task Type Bug Report
Category Core
Status Closed
Assigned To No-one
Operating System Linux
Severity High
Priority Normal
Reported Version 3.4.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


It seems fullscreen applications (mostly games) based on Simple Direct Media library ( Awesome does not handle well.

Steps to reproduce:
1. Run SDL-based application like Xmoto or Battle for Wesnoth in windowed mode
2. Set application's resolution to any but _different_ from your current desktop screen resolution
3. Switch to fullscreen mode _by application_ , not by Mod+f !
4. Awesome switches to the 1st tag and any attempts to switch back to a tag where app is running throws you back to the 1st tag. If app is originaly run from the 1st tag, screen gets blank and Awesome does not respond to any key or mouse input. Only terminating of X-server does help. Whereas app is still running.

On the same system running the same app under other window manager like Xmonad or Xfwm (Xfce) does not experience any similar problem.
This task depends upon

Closed by  Julien Danjou (jd)
Friday, 10 September 2010, 13:06 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Probably a bug of nVidia and ATI(AMD) drivers.
Comment by Uli Schlachter (psychon) - Friday, 08 January 2010, 15:25 GMT
When the resolution is changed, a Xrandr notification is sent out by the X server. Awesome doesnt handle these currently at all, it just restarts to pick up the new screen configuration.

Now here is what I think happened:
- Game grabs mouse and keyboard input, any input is now only sent to the game
- Game changes resolution
- awesome restarts, after a restart you are on tag 1 by default (that's what rc.lua sets)

Since the game grabbed the input, awesome doesnt receive anything. However this is only a guess.

Here is the bad news:

Battle of Wesnoth works (more or less) fine here. No problems in windowed mode, in fullscreen it disables my primary monitor (WTF?) and is only displayed on the secondary one. This causes awesome to restart, but input and everything is working as expected.

Sorry, but this bug is not reproducible for me and I think FS#687 might be closely related to this.j
Comment by Dunric (dunric) - Saturday, 09 January 2010, 00:51 GMT
Thanks for the quick reply.

Your explanation sounds logical and i'd bet that is the reason of mentioned issue. But if Awesome currently does not handle XRandr events, is such feature even planned to be implemented ?

I'm currently using only one monitor so I cann't comment behaviour described in your post.
Comment by Uli Schlachter (psychon) - Saturday, 09 January 2010, 09:43 GMT
The FS#687 I mentioned above is "Stop restarting on XRandR events", so it is planned.

Also, I can't explain why starting the game on tag 1 fails badly. :(
Comment by antoine beaupré (anarcat) - Tuesday, 30 March 2010, 03:18 GMT
I must say I have the same problem here with mplayer. The workaround is to use the "-vo xv" option to change the mplayer video driver, but then mplayer is in a fixed-size window that is floating and cannot be unfloated. At least then fullscreen works.

I have seen similar problems with the openarena game.
Comment by antoine beaupré (anarcat) - Tuesday, 30 March 2010, 03:37 GMT
So I must also mention that I use awesome from Debian unstable at home, and I do not have this problem with mplayer, which I use all the time.

It *could* therefore just be a driver issue, or a problem with the video output driver chosen by mplayer...

This is on an Aspire One D250-1821, which features a Intel mobile 943/940GML Express Integrated Graphics Controller:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device [1025:022f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 58280000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at 60f0 [size=8]
Region 2: Memory at 40000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at 58300000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915

This is with xorg 7.5 and the "intel" driver. I have the composite extension enabled.
Comment by Gregor Best (farhaven) - Tuesday, 30 March 2010, 18:08 GMT
I have seen a similar bug before on the suckless mailing list for the DWM window manager. It seems that the newest SDL version breaks compatibility with non-reparenting window managers such as awesome and DWM. Does reverting to an older SDL version fix the bug?
Comment by Gregor Best (farhaven) - Friday, 07 May 2010, 08:26 GMT
I recently had a try with some games (like Sauerbraten, Q3A, RTCW) which also change the screen resolution. If one sets the screen geometry the game wants (i.e. 1024x768) _before_ starting the game with xrandr like so: xrandr --output LVDS1 --mode 1024x768, the game works fine. It's just a workaround though.
Comment by Igor S. (ciphr) - Saturday, 31 July 2010, 13:11 GMT
I confirm this one. Running Openarena 0.8.1 on FreeBSD 8.1-STABLE with awesome 3.4.6 causes:

1. App changes screen settings (for me resolution is unchanged but I set brightness to a very high value)
2. awesome switches to second tag (it might be the first if counting from zero)
3. I select tag with the game, see app window under a terminal window (from which a launched OpenArena). The game seems to render properly (see the blue background with effects and openarena logo for a while)
4. goto 2. :) i.e. I cannot switch to game

This is really bad thing, because I even played OpenArena on Musca WM ;)
Comment by Igor S. (ciphr) - Saturday, 31 July 2010, 13:15 GMT
Wanted to add that OpenArena doesn't grab neither keyboard nor mouse input. They're still usable, so I can kill the app.
Comment by Nick Gladstone (Cosmonaut) - Friday, 13 August 2010, 21:51 GMT
I have noticed a fullscreen problem with virtualbox which uses sdl.

Switching to fullscreen with a virtualbox machine causes the screen to become somewhat garbled and certainly not truly fullscreen. I am fortunately able to switch out of it which returns things to acting normal. However.. I use this for designing in Solidworks and fullscreen would be very useful.

I'm using awesome 3.4.6
kernel 2.6.34
xorg 1.8.1 with proprietary nvidia drivers.

I have included a screenshot of what the whole monitor looks like using fullscreen...
Comment by Uli Schlachter (psychon) - Saturday, 14 August 2010, 11:30 GMT
As a work-around, can't you just resize the window to cover the whole screen without using any special "fullscreen" magic keycombo?...
Comment by Nick Gladstone (Cosmonaut) - Saturday, 14 August 2010, 18:36 GMT
I can maximize (via awesome) the Virtualbox screen just fine. However, that includes all of its toolbars and such, so the resolution of the guest OS has to be set a bit smaller than the physical monitor in order to fit all of it on the screen. So it's not a complete workaround although it's close. The special 'fullscreen magic keycombo' (of Virtualbox) should hide all of the virtualbox junk and just show the guest OS occupying the full space of the monitor.

Comment by David Demelier (markand) - Wednesday, 25 August 2010, 18:20 GMT
I can confirm this.
Comment by Dunric (dunric) - Thursday, 02 September 2010, 20:56 GMT
Unfortunately nothing has changed for 9 moths. I did tested the current Awesome version and the issue remains:

1. you are running awesome in screen resolution 1400x1050 for example
2. you launch an application like a game that switches to _other_ resolution like 800x600
3. awesome can not handle this situation and becomes unusable (gets in an infinite loop and switches between a game and the 1st tag)
4. you have to kill awesome (from virtual text-mode terminal or remotely from ssh session) or do a hard reset

It's sad it sill miss such basic funcionality or nobody else plays OpenGL fullscreen games ?!
Comment by Uli Schlachter (psychon) - Friday, 03 September 2010, 07:33 GMT
I guess instead of "nobody else" the problem is rather "none of the devs". No idea why restarting the WM would cause an endless loop. I'll guess I'll have to bite the apple and actually test this myself. :(
Comment by Uli Schlachter (psychon) - Friday, 03 September 2010, 15:09 GMT
Not reproducable.

I started "Battle of wesnoth" with --fullscreen and it used a resolution of 1024x768. That's what my left monitor already had, so I tried something else (exiting wesnoth caused my second screen to be turned off?!).
"wesnoth --fullscreen --resolution 800x600". Now the screen resolution changes and wesnoth went into an endless loop. So... uhm... dunno, nothing we can do about that, it's not awesome's fault.

Suggestions what I do to make this break?
Comment by Dunric (dunric) - Saturday, 04 September 2010, 00:25 GMT
Only can add I did tested it with quite different hardware configurations (ATI FireGL, Nvidia GF 230) and Linux distributions (Debian Squeeze i386, Slackware 13.1 x86_64 with newer Xorg version) and reproduced mentioned issue every time.

I'm sorry I cann't help more here, because my lack of knowledge in XRandr, XCB and other areas of XOrg.
It's worth mentioning, although you dislaim Awesome's fault, I didn't EVER experienced the same behaviour with other window managers. Tested with Xmonad, wmii, Metacity, xfwm (from Xfce), Window Maker and Blackbox.

I like tiling window managers and find interesting that Awesome configuration is solved in Lua (my preferred language), but it's not usable for me in its current state.
Comment by Uli Schlachter (psychon) - Saturday, 04 September 2010, 07:43 GMT
What's the easiest way to reproduce this? "wesnoth --fullscreen --resolution 800x600" just worked fine for me when I started it on tag 3.
Comment by Dunric (dunric) - Sunday, 05 September 2010, 00:24 GMT
Uli Schlachter> "What's the easiest way to reproduce this? "wesnoth --fullscreen --resolution 800x600" just worked fine for me when I started it on tag 3."

I did exactly as you described. Launching wesnoth on tag3 caused Awesome to switch to tag1. Any attempt to switch back to tag3 with the running game (modkey-3) immediately returns back to tag1. If I execute wesnoth on tag1, it gets in an infinite loop as described above: title screen of Wesnoth in 800x600 -> awesome's screen of tag1 -> title screen of Wesnoth in 800x600 -> awesome's screen of tag1 -> etc. Cycling is fast (less then second before switch) and any key or mouse input is ignored or not handled. Only aborting X with Ctrl+Alt+Backspace does work.

Comment by Dunric (dunric) - Sunday, 05 September 2010, 00:30 GMT
Just curious what version of Xorg are you running on ?
My xorg server version is 1.7.7
Comment by Uli Schlachter (psychon) - Sunday, 05 September 2010, 08:26 GMT
1.7.5, why would the server make a difference?
Comment by Dunric (dunric) - Sunday, 05 September 2010, 12:27 GMT
Uli Schlachter> "1.7.5, why would the server make a difference?"
Because Xorg devs may fixed some bug in the newer minor version. Supposing it's not an Awesomes fault ...
Comment by Dunric (dunric) - Friday, 10 September 2010, 12:03 GMT
I've had the possibility to test Awesome on PC with Intel chipset based graphics card and it did worked as expected. So it may be a bug in implementation of Xrandr events in binary nVidia and AMD's drivers ?

It seems it's really not an issue of Awesome WM.