We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

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.

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.

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")

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.

This should be fixed in the latest snapshot.  Thanks!

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.

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.

Created attachment 960 [details]
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?

Created attachment 961 [details]
Xinerama/Xrandr resolution change patch v2

Updated patch, a few clean ups and bug fixes.

Created attachment 963 [details]
Xinerama/Xrandr resolution change patch v3

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

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

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.

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.