This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.9
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2019-03-01 11:09:58 +0000, Matej Smid wrote:

A trivial sdl app https://github.com/Twinklebear/TwinklebearDev-Lessons/blob/master/Lesson0/src/main.cpp

outputs following and terminates:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  69
  Current serial number in output stream:  70

I'm running the executable over ssh with remote X, but this works flawless on a similar machine with the same $HOME mounted. The following system info is the same on both machines. On the machine where the executable fails are multiple GPUs, on the machine where executable works is none. I can debug when I'd be directed.

Debian GNU/Linux 9

~> ldd .../TwinklebearDev-Lessons/_build/bin/Lesson0                                                                                                                    
        linux-vdso.so.1 (0x00007fff8ddee000)
        libSDL2-2.0.so.0 => /mnt/home.dokt/smidm/local/miniconda2/envs/idtrackerai-env/lib/libSDL2-2.0.so.0 (0x00007f5de474f000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5de422d000)
        libstdc++.so.6 => /mnt/home.dokt/smidm/local/miniconda2/envs/idtrackerai-env/lib/libstdc++.so.6 (0x00007f5de40ec000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5de3de8000)
        libgcc_s.so.1 => /mnt/home.dokt/smidm/local/miniconda2/envs/idtrackerai-env/lib/libgcc_s.so.1 (0x00007f5de470b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5de3a49000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5de3845000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5de363d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5de464d000)

apt-cache show xserver-xorg | grep Version                                                                                                                                         
Version: 1:7.7+19

On 2019-03-04 12:04:31 +0000, Matej Smid wrote:

when building SDL with ../configure --enable-video-opengl=no there is no X protocol error on GPU machines, but SDL complains with:

SDL_CreateRenderer Error: Couldn't find matching render driver

on machines without GPUs I got the SDL window and message:

libEGL warning: DRI3: failed to query the version

On 2019-04-09 23:40:58 +0000, Charles P wrote:

Arch Linux, SDL2 2.0.9, nvidia proprietary drivers, kernel 5.0.0

I've also gotten this error:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  109
  Current serial number in output stream:  110

A gdb backtrace:

(gdb) bt
# 0  0x00007ffff35bc410 in _XError () from /usr/lib/libX11.so.6
# 1  0x00007ffff35b93f8 in ?? () from /usr/lib/libX11.so.6
# 2  0x00007ffff35b94a5 in ?? () from /usr/lib/libX11.so.6
# 3  0x00007ffff35ba410 in _XReply () from /usr/lib/libX11.so.6
# 4  0x00007ffff35b5cbf in XSync () from /usr/lib/libX11.so.6
# 5  0x00007ffff276ece8 in ?? () from /usr/lib/libGLX_nvidia.so.0
# 6  0x00007ffff2760db1 in glXCreateContext () from /usr/lib/libGLX_nvidia.so.0
# 7  0x00007ffff2b70474 in glXCreateContext () from /usr/lib/libGLX.so.0
# 8  0x00007ffff7f01541 in X11_GL_InitExtensions (_this=0x5555572241d0) at /usr/src/debug/SDL2-2.0.9/src/video/x11/SDL_x11opengl.c:366
# 9  X11_GL_LoadLibrary (_this=0x5555572241d0, path=<optimized out>) at /usr/src/debug/SDL2-2.0.9/src/video/x11/SDL_x11opengl.c:235
# 10 0x00007ffff7eccb56 in SDL_GL_LoadLibrary_REAL (path=path@entry=0x0) at /usr/src/debug/SDL2-2.0.9/src/video/SDL_video.c:2869
# 11 0x00007ffff7ecee16 in SDL_CreateWindow_REAL (title=title@entry=0x7ffff7f281ff "OpenGL test", x=x@entry=-32, y=y@entry=-32, w=w@entry=32, h=h@entry=32, 
    flags=flags@entry=10) at /usr/src/debug/SDL2-2.0.9/src/video/SDL_video.c:1451
# 12 0x00007ffff7ecf5b9 in ShouldUseTextureFramebuffer () at /usr/src/debug/SDL2-2.0.9/src/video/SDL_video.c:220
# 13 SDL_VideoInit_REAL (driver_name=<optimized out>, driver_name@entry=0x0) at /usr/src/debug/SDL2-2.0.9/src/video/SDL_video.c:544
# 14 0x00007ffff7e4b300 in SDL_InitSubSystem_REAL (flags=16416) at /usr/src/debug/SDL2-2.0.9/src/SDL.c:171

I feel like ShouldUseTextureFramebuffer should return false, rather than erroring when creating its test window...

However, this does have the caveat of my OpenGL is currently "broken" - Arch has a tendency to upgrade the kernel & graphics driver in place, and I've not rebooted my machine yet so the (running) graphics driver is having issues. However, many other programs are able to fallback to a software renderer, e.g. mpv:

[vo/gpu/x11] X11 error: BadValue (integer parameter out of range for operation)
[vo/gpu/x11] Type: 0, display: 0x7f841824d580, resourceid: 0, serial: 6e
[vo/gpu/x11] Error code: 2, request code: 97, minor code: 3
[vo/gpu] Could not create GLX context!
libEGL warning: DRI2: failed to authenticate
[vo/gpu/opengl] Suspected software renderer or indirect context.
[vo/gpu/x11] X11 error: BadValue (integer parameter out of range for operation)
[vo/gpu/x11] Type: 0, display: 0x7f841859f530, resourceid: 0, serial: 6e
[vo/gpu/x11] Error code: 2, request code: 97, minor code: 3
[vo/gpu] Could not create GLX context!
[vo/gpu/vulkan] vkEnumeratePhysicalDevices(vk->inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED
[vo/vdpau] Error when calling vdp_device_create_x11: 1
[vo/xv] Warning: this legacy VO has bad quality and performance, and will in particular result in blurry OSD and subtitles. You should fix your graphics drivers, or not force the xv VO.

It may well be that SDL should error in this case, but the current behaviour is that it's not erroring "cleanly" - instead hard exiting with an X11 error, which seems to me to be an issue. It would be especially nice if SDL could fallback to a software renderer more cleanly