Bug 7277 - SDL2 applications sometimes change resolutions in strange ways
: SDL2 applications sometimes change resolutions in strange ways
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
Depends on:
  Show dependency treegraph
Reported: 2016-08-12 09:40 MSD by Zombie Ryushu
Modified: 2016-08-13 00:17 MSD (History)
1 user (show)

See Also:
RPM Package: SDL2
Bad POT generating:


Note You need to log in before you can comment on or make changes to this bug.
Description Zombie Ryushu 2016-08-12 09:40:54 MSD
Some applications trigger a metamode change in the video drivers rather than actually changing the screen resolution. Particularly if nVidia Drivers are used. 

I have it set to change the screen resolution
to 640x480, or 800x600 from my fault of 1920x1080, it appears to do this
correctly at first, then, if you move the screen too far to the left or the
right the screen scrolls away. SDL2 applications sometimes don't call xrandr
to really change the screen and instead change a metamode.
Comment 1 Andrey Bondrov 2016-08-12 13:14:57 MSD
Likely related to this upstream bug? https://bugzilla.libsdl.org/show_bug.cgi?id=3387
Comment 2 Zombie Ryushu 2016-08-12 13:32:15 MSD
That sounds about right. because nvidia-settings said that the xrandr mode wasn't changing.
Comment 3 Zombie Ryushu 2016-08-12 13:54:28 MSD
I checked ldd, and its not linking against xrandr.

$ ldd /usr/lib64/libSDL2-2.0.so.0.4.0
        linux-vdso.so.1 =>  (0x00007ffec72bc000)                                                                                                                       
        libm.so.6 => /lib64/libm.so.6 (0x0000003a59600000)                                                                                                             
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003a59200000)                                                                                                           
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003a59a00000)                                                                                                 
        libc.so.6 => /lib64/libc.so.6 (0x0000003a58e00000)                                                                                                             
        /lib64/ld-linux-x86-64.so.2 (0x0000003a58a00000)
Comment 4 Andrey Bondrov 2016-08-12 14:03:21 MSD
(In reply to comment #3)
> I checked ldd, and its not linking against xrandr.

Yes, it seems to use dlopen() instead of linking:


-- dynamic libX11 -> libX11.so.6
-- dynamic libXext -> libXext.so.6
-- dynamic libXcursor -> libXcursor.so.1
-- dynamic libXinerama -> libXinerama.so.1
-- dynamic libXi -> libXi.so.6
-- dynamic libXrandr -> libXrandr.so.2
-- dynamic libXrender -> libXrender.so.1
-- dynamic libXss -> libXss.so.1
-- dynamic libXxf86vm -> libXxf86vm.so.1
Comment 5 Zombie Ryushu 2016-08-13 00:10:32 MSD
It was suggested to try the the --with-backend=qt arguement in Building 3.2.x
Comment 6 Zombie Ryushu 2016-08-13 00:17:33 MSD
Would you attempt to build an instance of 3.1.5 or whatever the latest is using 3.1.2 as a basis and putting it in a testing repo?