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.

Bug 1058

Summary: SDL: erroneously uses xrandr-style mode switching
Product: SDL Reporter: Jan Engelhardt <ej+bko>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P1 CC: contact, jspradlin, ludwig.nussel
Version: 1.2.14   
Hardware: x86   
OS: Linux   

Description Jan Engelhardt 2010-09-23 17:02:37 UTC 
Problem:

SDL-1.2.14.

When SDL switches to fullscreen 640x480 - for example, because the game is
configured to run in such resolution - or back, it changes the desktop size too
by means of xrandr or something along the lines of that.

Actual results:

Windows on my desktop are reordered, which is usually a result of the WM being
forced to do so because the desktop size (virtualsize) changed.

Resolution switching also takes significantly longer than it did before — this
is another sign that it switches desktop size (too), not just resolution.

First the screen goes black-with-backlight and after roughly 500ms, the TFT
screen finally gets the new 640x480 mode signal (I use VGA), which is evidenced
by the backlight going briefly off.

Expected results:

Previous behavior. In other worsd, leave desktop size as-is (and subsequently
keep my windows where they are) and _only_ change the resolution. The old
switching style is also way faster in that there is no black-with-backlight
delay.

Additional information:

Overriding the system SDL 1.2.14 libraries and using LD_LIBRARY_PATH to point
to SDL-1.2.13 libraries brings back the desired behavior.

hg bisecting...
The first bad revision is:
changeset:   4313:8ec3036098df
branch:      SDL-1.2
user:        Sam Lantinga <slouken@libsdl.org>
date:        Sat Oct 10 10:14:01 2009 +0000
summary:     Adapted from Debian patch: 320_activate_xrandr_on_default.diff

I am aware of the existence of the SDL_VIDEO_X11_XRANDR environment variable, but that only looks like a temporary workaround to me.
Comment 1 Jen Spradlin 2011-04-12 20:13:51 UTC 
Thank you for your bug report!

We're busy working on getting SDL 1.3 ready for a high quality release, and want to make sure as many things are fixed there as possible.
Could you check to see if your bug is resolved by the latest SDL 1.3 snapshot?
http://www.libsdl.org/tmp/SDL-1.3.zip

Thanks!
Comment 2 Jonas Thiem 2011-05-08 15:58:32 UTC 
While I cannot confirm anything more, I can confirm that with a very recent hg (~two weeks), the screen resolution change takes way longer than in old 1.2 on this Linux system (Fedora 14).

So something in the screen resolution switch is definitely taking longer than in 1.2 and should be probably removed if possible.
Comment 3 Ryan C. Gordon 2011-12-30 01:20:11 UTC 
fwiw, we should really disable the XRandR codepath by default, if we haven't already.

--ryan.
Comment 4 Ryan C. Gordon 2011-12-30 01:25:49 UTC 
Bumping priority on a few bugs that I would like examined more closely before 1.2.15 is finalized. This is not a promise that a bug will be fixed. We may close it with WONTFIX or WORKSFORME or something, but I just want to make sure attention is paid.

--ryan.
Comment 5 Sam Lantinga 2011-12-30 11:40:10 UTC 
Okay, that patch has been reverted.
http://hg.libsdl.org/SDL/rev/804c6c62c55f

I discussed this with Ryan:
Ryan:  XRandR is for configuring screens.
it happens to "work" for choosing a fullscreen resolution, but it's really meant for like, a "display" section of a System Preferences app.
Unlike XVidMode, apps notice that XRandR changed the resolution and reconfigure themselves.
So icons move around the desktop, windows resize, etc.
---

Thanks!