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 3185

Summary: XRandR multiple screen code fails if there is no primary screen
Product: SDL Reporter: Edward Rudd <urkle>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: critical    
Priority: P2 CC: cedega.git, galtgendo, icculus, winterknight
Version: HG 2.0   
Hardware: x86_64   
OS: Linux   
Attachments: Xrandr keep searching for non-primary outputs on default screen

Description Edward Rudd 2015-11-20 20:47:06 UTC 
The multiple screen handling code added in changeset 9920 breaks when there is no primary screen in the XRandR setup.  

In debugging the RROutput primary variable is set to 0 when no primary display is configured.  Due to this the code never finds a display and yields the "No available displays" or "No available video device".

Recreated on my Fedora 21 x64 desktop.

To recreate simply undefine the primary XRandR display

$ xrandr --noprimary

run any SDL2 test app that initializes the video subsystem. They will fail.

use

$ xrandr --output DVI-I-1 --primary

to re-establish a primary output and re-run the SDL2 test apps. They will now work.
Comment 1 winterknight 2015-12-05 06:21:56 UTC 
Created attachment 2329 [details]
Xrandr keep searching for non-primary outputs on default screen
Comment 2 winterknight 2015-12-05 06:22:33 UTC 
I have also run across this, in a slightly different circumstance, in hg 9943. Basically, X11_InitModes_XRandR logic will not find any outputs on the default screen, except for the primary output, if available. This can lead to funky behavior if the default screen has no primary output, but another screen does.

The culprit is this section here:

            if ((looking_for_primary && (screen != default_screen)) ||
                (!looking_for_primary && (screen == default_screen))) {
                continue;
            }

Why do you abort if you're not looking for primary outputs and the screen == default_screen? There are non-primary outputs on the default screen you want to find. The patch I propose just simplifies this line so that SDL will continue looking for outputs even if looking for non primary outputs on the default screen.

I also suggest simplifying the line on 424-425. You already aborted the loop on line 379 if looking_for_primary & screen != default_screen, so you don't have to check for that again. It makes the logic more complicated and easier to make mistakes.
Comment 3 cedega.git 2015-12-21 22:56:55 UTC 
*** Bug 3209 has been marked as a duplicate of this bug. ***
Comment 4 Ryan C. Gordon 2015-12-29 07:03:52 UTC 
(In reply to winterknight from comment #2)
> Why do you abort if you're not looking for primary outputs and the screen ==
> default_screen?

Because that loop is trying to find the primary output on the default screen first, so it'll be first in our list of SDL displays. So on the first time through the outer loop, we only run our code for the default screen. After that, we run it for every screen except the default.

--ryan.
Comment 5 Ryan C. Gordon 2015-12-29 07:05:27 UTC 
(In reply to Ryan C. Gordon from comment #4)
> (In reply to winterknight from comment #2)
> > Why do you abort if you're not looking for primary outputs and the screen ==
> > default_screen?
> 
> Because that loop is trying to find the primary output on the default screen
> first, so it'll be first in our list of SDL displays. So on the first time
> through the outer loop, we only run our code for the default screen. After
> that, we run it for every screen except the default.

Oh, wait, I get what you're saying. Yeah, that's a bug.

--ryan.
Comment 6 Ryan C. Gordon 2015-12-29 07:18:17 UTC 
(In reply to Ryan C. Gordon from comment #5)
> Oh, wait, I get what you're saying. Yeah, that's a bug.

So, yes, your patch looks good, and should fix Edward's problem, too, so I've applied it to revision control as https://hg.libsdl.org/SDL/rev/df034dc2f547, thanks!

--ryan.