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 3714

Summary: [patch] Windows: SDL_WINDOW_FULLSCREEN_DESKTOP broken on 3 monitor setup w/ DPI scaling
Product: SDL Reporter: Eric Wasylishen <ewasylishen>
Component: videoAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: sezeroz
Version: HG 2.1   
Hardware: x86_64   
OS: Windows 10   
Attachments: Possible patch

Description Eric Wasylishen 2017-07-26 18:42:58 UTC 
I set up an (admittedly exotic) 3-monitor setup, and when I enter fullscreen-desktop on the middle display (#2), the SDL window is off center. (covers half of monitor #2 and most of monitor #3). 

The displays are arranged from left to right:

Display #1 (main): 2880x1800, 200% scaling
Display #2: 1920x1200, 150% scaling
Display #3: 1920x1080, 100% scaling

SDL display bounds:
INFO: Bounds: 1440x900 at 0,0
INFO: Bounds: 1281x801 at 1921,0  (these are incorrect)
INFO: Bounds: 1920x1080 at 4800,0

Correct bounds reported by calling EnumDisplayMonitors and printing the LPRECT param of the callback:
1440x900 at (0, 0)
1280x800 at (2880, 0)
1920x1080 at (4800, 0) 

It seems like you need 3 displays to reproduce this, and the left two need DPI scaling, and the 3rd display needs to have a different scale factor than the others.

Related: https://bugzilla.libsdl.org/show_bug.cgi?id=3709

SDL: current hg (11235:43c7baa53681)
Windows 10, Version 10.0.15063 Build 15063
Tested with testdraw2 and testgl2, and pressing alt+enter to enter fullscreen desktop.
Comment 1 Eric Wasylishen 2017-08-11 07:18:13 UTC 
Created attachment 2826 [details]
Possible patch

This patch reworks SDL_windowsmodes.c to use EnumDisplayMonitors instead of EnumDisplayDevices, so we always have an HMONITOR for each SDL display.

With access to an HMONITOR, we can get the monitor bounds in virtual screen coordinates the proper way, by calling GetMonitorInfo. (whereas the original code was doing some calculations - e.g. "data->DeviceMode.dmPosition.x * data->ScaleX" - to try to get virtual screen coordinates. These worked in simple cases, but failed in more complex cases like this bug)

The one potential problem with my patch is, the ChangeDisplaySettingsEx docs say that you're supposed to get the display name from EnumDisplayDevices, but I'm getting the display name from GetMonitorInfo now.
Comment 2 Sam Lantinga 2017-08-11 17:19:01 UTC 
Fixed, thanks!
https://hg.libsdl.org/SDL/rev/0060bcf673e8