Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL: erroneously uses xrandr-style mode switching #596

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

SDL: erroneously uses xrandr-style mode switching #596

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.14
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2010-09-23 17:02:37 +0000, Jan Engelhardt wrote:

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.

On 2011-04-12 20:13:51 +0000, Jen Spradlin wrote:

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!

On 2011-05-08 15:58:32 +0000, Jonas Thiem wrote:

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.

On 2011-12-30 01:20:11 +0000, Ryan C. Gordon wrote:

fwiw, we should really disable the XRandR codepath by default, if we haven't already.

--ryan.

On 2011-12-30 01:25:49 +0000, Ryan C. Gordon wrote:

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.

On 2011-12-30 11:40:10 +0000, Sam Lantinga wrote:

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant