This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Xinerama/Xrandr resolution change patch (Xinerama2.diff, text/plain, 2012-09-28 16:01:47 +0000, 13172 bytes)
• Xinerama/Xrandr resolution change patch v2 (Xinerama2.diff, text/plain, 2012-09-29 12:19:30 +0000, 15814 bytes)
• Xinerama/Xrandr resolution change patch v3 (Xinerama2.diff, text/plain, 2012-10-01 06:45:24 +0000, 16376 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-08-14 22:50:42 +0000, Sik wrote:

I just implemented fullscreen support in my game and I'm having an issue when quitting. Basically, the original desktop resolution is not restored when the fullscreen window is destroyed, leaving the game resolution even after the program quits (e.g. if the game was running at 640×480, on exit the desktop will remain at 640×480, regardless of the resolution before running the game). I'm expecting the resolution to be restored when a fullscreen window is destroyed.

My game explicitly calls SDL_DestroyWindow when quitting, if that matters.

Using Ubuntu 11.04 with the proprietary Nvidia drivers. Using the latest snapshot from the site (SDL-2.0.0-6394 as of writing). This issue seems to have been there for quite a while by now.

On 2012-08-14 22:55:10 +0000, Sik wrote:

Actually thinking about it more carefully, just changing the resolution when destroying the fullscreen window (as-is) would be a bad idea, since there could be other fullscreen windows opened at the same time (possibly?).

I suppose the correct behavior is that the window resolution is used when that fullscreen window gets focus, and the desktop resolution is restored when no fullscreen windows have focus. This matters when the user wants to press alt+tab or similar to switch windows. Destroying a fullscreen window implicitly makes it lose focus, thereby restoring the resolution as needed.

In either case the fullscreen window resolution shouldn't be kept when said window is destroyed, which is the original bug report.

On 2012-09-23 19:27:56 +0000, Edward Rudd wrote:

I can confirm this issue occurring.. It seems to be an issue with how Xinerama & XRandR is handled. Disabling Xinerama seems to somewhat fix the screen restoration process. I have to ensure I position the window & 0x0 or it will most of the time pop back out of fullscreen immediately and the window will minimize or do other "odd" stuff.

Also in a related issue with a dual-monitor setup (nvidia twinview 304+ driver). the "Desktop resolution" is kept per-screen when xinerama is enabled. Thus on window destroy the resolution is attempted to restore to a SINGLE screen size (1600x1200) instead of the FULL size (3520x1200). However it still fails to restore regardless and the user is left with a 640x480 desktop.

On 2012-09-27 16:10:51 +0000, Gabriel Jacobo wrote:

I'm leaving this as reference: http://cgit.freedesktop.org/xorg/app/xrandr/tree/xrandr.c?id=xrandr-1.3.5

It appears we are faced with a two part problem...first, we need to store the current video mode (and rotation?) so we are able to restore it, but also, when Xinerama is in use, we need to alter resolution only on the desired screen like Xrandr does (that is preserving the other monitor's resolution and rotation).I believe most of what is required is inside crtc_apply, crtc_revert, screen_apply and screen_revert. An additional required step (not present in xrandr's code) would be doing a mapping from Xinerama screen/SDL video display to Xrandr output, which I'm not sure how it can be done (i.e., which Xrandr output, DVI-1, CRT, etc, belongs to what Xinerama refers to "Screen 0")

On 2012-09-27 16:22:04 +0000, Sik wrote:

I would like to remark I'm having this issue with a single monitor setup, not a multimonitor one. No idea if Xinerama is in use (how can I check?), Xrandr most likely is (the resolution list bug is there - nothing SDL can do about, it's the Nvidia drivers at fault).

Not saying it isn't Xinerama (it could be), just saying the bug doesn't require multiple monitors.

On 2012-09-28 02:18:51 +0000, Sam Lantinga wrote:

This should be fixed in the latest snapshot. Thanks!

On 2012-09-28 02:42:33 +0000, Sik wrote:

I can confirm it's fixed in the latest snapshot, at least for my system.

Another bug seems to have been introduced (refresh rate is not restored so in my case it returns to 1024×768@60Hz instead of 1024×768@85Hz), but I'll fill another bug report for that.

On 2012-09-28 06:10:21 +0000, Gabriel Jacobo wrote:

I'm afraid this is not fixed in my system, the behaviour is exactly as before. If I set select a display and use the desktop resolution, everything's fine. But if I choose a resolution different than the current one, on restore SDL restores one monitor only. This is because of what I mentioned in my previous comment, and seeing what xrandr does, I think it's not going to be a trivial solution.

Also, here http://hg.libsdl.org/SDL/rev/94e3643928ed you removed a special case I added for Xinerama:

-#if SDL_VIDEO_DRIVER_X11_XINERAMA
1.40 - if (w == real_w && h == real_h && (data->use_xinerama || !rate || rate == real_rate)) {
1.41 + if (w == real_w && h == real_h && (!rate || !real_rate || rate == real_rate)) {

Under Xinerama I think the refresh rate loses meaning, as you can have two monitors at different settings, that's why I had added that.

On 2012-09-28 16:01:47 +0000, Gabriel Jacobo wrote:

Created attachment 960
Xinerama/Xrandr resolution change patch

With the current code, asking SDL2 to go full screen on both either display, has the effect of going full screen always on the same display (the first one), while the second one remains disabled.
If I request the first display, when I close the app I get the original desktop resolution back (on both monitors), however, if I choose the second display, I get the app fullscreen on the first display, and when I exit the second display is never activated (the first display is correctly restored).

This patch I'm attaching solves the issue for me as far as I can tell, it sets the app fullscreen on the expected display and leaves the other one untouched (as it happens with Windows games), can you evaluate it and let me know how it goes?

On 2012-09-29 12:19:30 +0000, Gabriel Jacobo wrote:

Created attachment 961
Xinerama/Xrandr resolution change patch v2

Updated patch, a few clean ups and bug fixes.

On 2012-10-01 06:45:24 +0000, Gabriel Jacobo wrote:

Created attachment 963
Xinerama/Xrandr resolution change patch v3

Attaching third pass, this should be final...unless it's not.

On 2012-10-03 11:32:04 +0000, Sam Lantinga wrote:

Okay, I added a variant of your patch for Xinerama support. It doesn't work correctly for rotated monitors, but that will come later.

On 2012-10-03 11:48:11 +0000, Edward Rudd wrote:

I have to say I am happily impressed with the progress and patches flowing through this bug:) This and the fullscreen (for unity/compiz) patch I submitted in # 1153 are really getting SDL2 more usable on linux!. As it stands right now I am planning on continuing to use SDL2 in future game ports and incorporating these patches after they get "dusted" some more into the SDL2 build in Torchlight for linux.

On 2012-10-03 12:11:29 +0000, Gabriel Jacobo wrote:

I just checked this and it appears to be working, closing the ticket but if anyone feels this is still failing feel free to reopen.