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 1854

Summary: Linux: Fullscreen creates scrollable virtual desktop scrolled to random position by default
Product: SDL Reporter: Gerry JJ <trick>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: ASSIGNED --- QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: akeithw, boris.gjenero, deveee, icculus, wick.sebastian
Version: HG 2.0   
Hardware: x86_64   
OS: Linux   

Description Gerry JJ 2013-05-18 22:36:13 UTC 
Ubuntu 13.04 64-bit, Unity desktop, nvidia binary driver

Creating a fullscreen window either by passing SDL_WINDOW_FULLSCREEN to SDL_CreateWindow or switching with SDL_SetWindowFullscreen creates a desktop-sized scrollable virtual desktop with the actual "fullscreen" window content area in the top left, scaled so that the window content would fill the screen if aligned right (ignoring aspect ratio). Moving the mouse cursor to a screen edge scrolls the view in that direction within the larger area. The area not covered by the top-left window content displays a scaled still image of the desktop instead, usually corrupted (like an uninited texture). Sometimes, the initial position of the scrolled view isn't at the top left where the window content is, so it's possible for the fullscreen switch to just display a screen filled with random garbage even if the cursor never moved near a screen edge at all. If the mouse is grabbed, the view can be scrolled to the window area but stays within it once there. Clicking in the "desktop" area has different effects, ranging from nothing at all happening to the window minimizing to crashing compiz. Very rarely, none of this will happen and the view will actually be locked to the window content from the start, but that's very rare.

This can be reproduced with the SDL test programs (start with --fullscreen flag or hit ctrl-enter).

Also, there's erratic behavior after returning to windowed mode from fullscreen, even after exiting the SDL program. The cursor is usually drawn offset from its real position until it would go offscreen (then it snaps to the real position). A few times, compiz has crashed even without provoking it by clicking in the virtual desktop area. Once, although compiz didn't crash, windowed mode wasn't restored at all and left the desktop at 640x480 pixels, resized all other windows, and moved them all to different workspaces. (I can't reproduce most of those last ones (at least not reliably), but the cursor offset thing happens more often than not.)

None of this happens with SDL 1.2, or when using SDL_WINDOW_FULLSCREEN_DESKTOP in SDL 2.
Comment 1 Gerry JJ 2013-05-18 22:38:52 UTC 
By the way, there's no SDL_GetWindowFullscreen function. Shouldn't there be?
Comment 2 Gerry JJ 2013-05-19 14:51:59 UTC 
Er, never mind comment #1. I missed the SDL_GetWindowFlags function somehow.
Comment 3 Sebastian Wick 2013-07-26 17:06:34 UTC 
I have the same problem but only in specific cases:
1. This only happens if the fullscreen is not in the native resolution
2. Using only SDL_CreateWindow with SDL_WINDOW_FULLSCREEN
3. Does *NOT* occur if turning fullscreen off and on again with SDL_SetWindowFullscreen
Comment 4 akeithw 2015-05-08 03:58:39 UTC 
Ubuntu 14.04 LTS 64-bit, Unity desktop, nvidia binary driver.

This still happens even with the latest code in hg.  It is exactly like comment #3 describes and does not happen in SDL 1.2.
Comment 5 akeithw 2015-05-08 04:14:26 UTC 
(In reply to akeithw from comment #4)
> Ubuntu 14.04 LTS 64-bit, Unity desktop, nvidia binary driver.
> 
> This still happens even with the latest code in hg.  It is exactly like
> comment #3 describes and does not happen in SDL 1.2.

After further testing for my setup this only appears to happen when moving from window mode to fullscreen if the resolution is not the native desktop resolution.  Once you center the veiw with the mouse then there doesn't appear to be a problem
Comment 6 akeithw 2015-05-09 02:50:32 UTC 
I have done further testing.  If I am going to full screen to a resolution of 800x600 from 1280x1024 and my mouse curser is not within the upper 800x600 region of my display at launch then my application "window" is not centered on the screen.  So, I think it has to do with the warping of the mouse in Ubuntu.
Comment 7 Boris Gjenero 2017-03-11 01:41:27 UTC 
Using SDL 2.0.5 with 340.101-0ubuntu0.16.10.1 driver, SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN) results in a mode where the displayed area is larger than the resolution, and you can scroll around the video with the mouse. The view always starts off at the top left, cutting off the bottom and right part. I can view all SDL output properly by scrolling around, and there is no extra junk anywhere, but this is not a nice way to use an application.

Then, if I'm not scrolled all the way up and all the way left, SDL_SetWindowFullscreen(window, 0) does not change the resolution. I'm returned to the desktop and with the SDL application in a window, but at the same low resolution that was used in full screen mode. Then I need to use xrandr to set the proper resolution. If the full screen display was scrolled all the way up and all the way left, then I don't get this problem.

If I use the open source nouveau driver instead of the proprietary nvidia driver, none of these problems happen.
Comment 8 Deve 2018-05-09 10:11:37 UTC 
It is how it works with nvidia and it's still broken for me on ubuntu 18.04...

I was trying to disable panning with XRRSetPanning after setting crtc config, but the panning remains enabled.

Actually XRRSetScreenSize works for me, but it may break multi-monitor configurations (I didn't test it yet).

And anyway setting resolution with xrandr application works properly, so it should be possible to make a workaround.
Comment 9 Ryan C. Gordon 2018-05-09 16:31:02 UTC 
In SDL2, almost all cases where this happens are because the copy of SDL in use was built without XRandR support (or is being run on an Xserver that doesn't support XRandR, but that's significantly less likely). SDL uses XVidMode as a fallback in this case and tends to produce this result, and, eventually, I want to remove that codepath from SDL2 entirely.

But for now: please make sure your SDL built correctly. It'll disable XRandR if you don't have the headers installed for it, which come from the libxrandr-dev package on Debian/Ubunty (and probably somewhere else on Fedora, etc...ymmv).

(Note that in 2013, in Gerry's original bug report, this was probably just legitimately broken in SDL2, but this shouldn't be the case in modern times.)

--ryan.
Comment 10 Deve 2018-05-09 18:40:31 UTC 
Tbh. I didn't look that carefully at SDL2 code, but I have this problem with all SDL2-based games and actually I'm trying to fix it in Supertuxkart that uses xrandr with XRRSetCrtcConfig too.

Other people have such issues too, for example:
https://devtalk.nvidia.com/default/topic/951192/linux/panning-enabled-when-turning-fullscreen-with-xrrsetcrtcconfig/

I suppose that screen size must be manually set to correct value before crtc config is changed. Anyway I will make some tests...
Comment 11 Deve 2018-05-09 22:03:34 UTC 
Here is a quick patch that works for me in STK:
https://github.com/supertuxkart/stk-code/commit/26e7af3c23816bc056063fea9330468af03b9e30

Basically I turn off crtc, set screen size and then eventually set crtc mode.

I'm not sure if computed screen size will be correct for some exotic configurations though (if someone has enabled panning/scaling/etc).

And actually if someone has low resolution in system and wants to choose higher resolution in SDL, then you have to change screen size anyway, because they say:

"The entire area of the CRTC must fit within the screen size, else a Match error results."

And ideally I would like to find a way to disable panning, because it's much more simple. But XRRSetPanning just doesn't work...