Bug 99052

I managed to wrench my daughter way from her pure Intel Ironlake laptop long enough to discover that this is not amdgpu-specific. I didn't test Alien Isolation but the rest was the same.

Now I understand that the --panning argument is also needed to prevent the mouse from being locked. Not entirely intuitive but okay. The games are still the same though.

I've looked at how SDL2 picks up the current mode in SetXRandRModeInfo and enabled X11MODES_DEBUG. It reports that the current mode is 1920x1080. The xrandr utility also puts a * against 1920x1080 but of course this is still the real mode in use by the monitor. Perhaps SDL2 should look at the screen as a whole instead of individual modes but that would screw up on multihead configurations. I am using Zaphod mode so there are two distinct screens. What is the right way to do this?

Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384
HDMI-A-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 527mm x 296mm panning 3840x2160+0+0
   1920x1080     60.00*+  50.00    59.94  
   1680x1050     59.88  
   1280x1024     60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      70.07    60.00  
   800x600       60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       66.67    60.00    59.95    59.94  
   720x400       70.08  
   3840x2160     59.98

I just managed to get unigine valley and Xonotic-glx to work on R9285 + fluxbox using -

xrandr --output DVI-D-0 --fb 3840x2160 --panning 3840x2160
xrandr --output DVI-D-0 --mode 1920x1080 --scale-from 3840x2160

TODO work out how to get back to normal, quit X being current method :-)

Should have read extra info before posting (I only saw first posts that went to ati list). I don't even have sdl2 and only a single screen - so not much use other than it seems to work without adding a fake mode.

Thanks for your help. Multihead isn't really a factor in my tests as Zaphod mode allocates an entirely separate screen for each CRTC. I only meant that any fix would need to take multihead into account.

I now believe this is entirely an SDL2 issue. If I comment out the call to SetXRandRModeInfo in X11_InitModes_XRandR then everything works. I don't even have to add a new mode. Neverball correctly reports 3840x2160. Alien shows 1920x1080 in the options but it is actually rendering at 3840x2160 while in fullscreen.

SetXRandRModeInfo's main purpose in this context seems to be to deal with rotation and yet I get the exact same result while rotated when the call is commented out. I wanted to try --rotate and --scale-from at the same time but I couldn't get them to play well together.

I'll therefore file an SDL bug. Sorry for the noise here, it was the mouse locking that threw me off. If anything useful could come from this report, it would be an improvement to the xrandr documentation. It says you typically use --fb with --panning but I didn't use --fb at all. If you don't use --panning with --rotate or --scale-from then you can get some very odd results. When I tried it on my Intel desktop at work, mouse locking wasn't the only strange thing I observed. How about instead of this:

> You typically have to set the screen size with --fb simultaneously.

We have something like this:

> This option is typically used in conjunction with --fb, --scale-from, or --rotate.

That xrandr --panning needs to be specified explicitly for this is arguably a bug, see bug 39949.

(In reply to Michel Dänzer from comment #7)
> That xrandr --panning needs to be specified explicitly for this is arguably
> a bug, see bug 39949.

That bug report is a little incoherent but that does seem to be one aspect of it. I agree that you shouldn't need to give --panning as changing mode in a game while rotated preserves the original --panning value, leading to weird results.