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 3062

Summary: XRandR display detection doesn't work
Product: SDL Reporter: Ryan C. Gordon <icculus>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: HG 2.0   
Hardware: x86_64   
OS: Linux   
Attachments: Patch to fix XRandR code and favor it over Xinerama.

Description Ryan C. Gordon 2015-07-15 03:28:24 UTC 
Right now on X11, if SDL or the X server doesn't support Xinerama, multi-display support is broken, even though XRandR should be able to carry the weight alone.

Here's what the new test/testdisplayinfo.c reports on my machine (two different generations of 23" Apple Cinema Displays and an Oculus Rift DK2 plugged in...) if I force it to only use Xinerama...

SDL_VIDEO_X11_XINERAMA=1 SDL_VIDEO_X11_XVIDMODE=0 SDL_VIDEO_XRANDR=0 ./testdisplayinfo 
INFO: Using video target 'x11'.
INFO: See 3 displays.
INFO: 0: "play 23"" (1920x1200, (0, 0)), 1 modes.
INFO: CURRENT: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO: 
INFO: 1: "Rift DK2 6"" (1080x1920, (3840, 0)), 4 modes.
INFO: CURRENT: fmt=SDL_PIXELFORMAT_RGB888 w=1080 h=1920 refresh=74
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_RGB888 w=1080 h=1920 refresh=74
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_RGB888 w=1080 h=1920 refresh=74
INFO:     MODE 1: fmt=SDL_PIXELFORMAT_RGB888 w=1080 h=1920 refresh=71
INFO:     MODE 2: fmt=SDL_PIXELFORMAT_RGB888 w=1080 h=1920 refresh=59
INFO:     MODE 3: fmt=SDL_PIXELFORMAT_RGB888 w=1080 h=948 refresh=119
INFO: 
INFO: 2: "HD Display 23"" (1920x1200, (1920, 0)), 1 modes.
INFO: CURRENT: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59


...here is what XVidMode reports...


SDL_VIDEO_X11_XINERAMA=0 SDL_VIDEO_X11_XVIDMODE=1 SDL_VIDEO_XRANDR=0 ./testdisplayinfo 
INFO: Using video target 'x11'.
INFO: See 1 displays.
INFO: 0: "0" (4920x1920, (0, 0)), 13 modes.
INFO: CURRENT: fmt=SDL_PIXELFORMAT_RGB888 w=4920 h=1920 refresh=0
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_RGB888 w=4920 h=1920 refresh=0
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_RGB888 w=4920 h=1920 refresh=59
INFO:     MODE 1: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1200 refresh=59
INFO:     MODE 2: fmt=SDL_PIXELFORMAT_RGB888 w=1920 h=1080 refresh=59
INFO:     MODE 3: fmt=SDL_PIXELFORMAT_RGB888 w=1680 h=1050 refresh=59
INFO:     MODE 4: fmt=SDL_PIXELFORMAT_RGB888 w=1600 h=1200 refresh=59
INFO:     MODE 5: fmt=SDL_PIXELFORMAT_RGB888 w=1440 h=900 refresh=59
INFO:     MODE 6: fmt=SDL_PIXELFORMAT_RGB888 w=1366 h=768 refresh=59
INFO:     MODE 7: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=1024 refresh=59
INFO:     MODE 8: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=800 refresh=59
INFO:     MODE 9: fmt=SDL_PIXELFORMAT_RGB888 w=1280 h=720 refresh=59
INFO:     MODE 10: fmt=SDL_PIXELFORMAT_RGB888 w=1024 h=768 refresh=59
INFO:     MODE 11: fmt=SDL_PIXELFORMAT_RGB888 w=800 h=600 refresh=59
INFO:     MODE 12: fmt=SDL_PIXELFORMAT_RGB888 w=640 h=480 refresh=59

(I don't know why XVidMode can see more legit resolutions here, but I don't think that's an SDL bug. I think...?)


Here's XRandR...

SDL_VIDEO_X11_XINERAMA=0 SDL_VIDEO_X11_XVIDMODE=0 SDL_VIDEO_XRANDR=1 ./testdisplayinfo 
INFO: Using video target 'x11'.
INFO: See 1 displays.
INFO: 0: "0" (4920x1920, (0, 0)), 1 modes.
INFO: CURRENT: fmt=SDL_PIXELFORMAT_RGB888 w=4920 h=1920 refresh=0
INFO: DESKTOP: fmt=SDL_PIXELFORMAT_RGB888 w=4920 h=1920 refresh=0
INFO:     MODE 0: fmt=SDL_PIXELFORMAT_RGB888 w=4920 h=1920 refresh=0


So even if SDL chooses to use XRandR, it'll still rely on the Xinerama codepath for crucial information, even though XRandR supplies that information too.


Part of the problem is that X11_InitModes() wants to iterate through X11 "screens" but this particular setup has one "screen" and three XRandR "outputs" on that screen. Also, it currently relies on Xinerama to fill in screen positions, even though that information is listed with the XRandR outputs data.

It's likely 100% common for an X server to provide both extensions, and SDL to be built with support for both, but that still doesn't make the existing code correct and robust.

--ryan.
Comment 1 Ryan C. Gordon 2015-08-07 05:20:23 UTC 
> [...] if I force it to only use Xinerama...
> 
> SDL_VIDEO_X11_XINERAMA=1 SDL_VIDEO_X11_XVIDMODE=0 SDL_VIDEO_XRANDR=0

Whoops, that XRANDR disable was the wrong environment variable; the Xinerama codepath leans on the XRandR one and vice versa at the moment. Without XRandR, the Xinerama codepath is only good for correctly identifying current monitor dimensions and placing windows appropriately on them, but can't enumerate modes or change resolutions.

--ryan.
Comment 2 Ryan C. Gordon 2015-08-07 05:26:48 UTC 
Created attachment 2235 [details]
Patch to fix XRandR code and favor it over Xinerama.


This patch fixes the XRandR code and makes it so we won't use Xinerama at all if XRandR is available to us.

Side effect: fixes people with the Nvidia drivers with broken Xinerama support, and also now correctly identifies and handles the primary display.

--ryan.
Comment 3 Ryan C. Gordon 2015-08-07 15:59:47 UTC 
This patch is now https://hg.libsdl.org/SDL/rev/d3fa6d0d3793 ...marking this FIXED until we hear it broke everything.  :)

--ryan.