Xonotic does not work with the latest sdl3/sdl2-compat library

[janp20]

I am using Xonotic (fps online game) on Arch Linux, after upgrading to sdl3-3.2.12/sdl2-compat-2.32.56 it stopped working (only the splash screen is displayed with music). I had to downgrade to the previous version.
Unfortunately I cannot supply further information.

Thanks

[Kontrabant]

The window isn't appearing on Wayland because eglSwapBuffers() always fails with EGL_BAD_DISPLAY. The EGL display and surface passed to the function appear to be valid, and there are no other errors during initialization or before swapping, so I'm not sure what is going on here.

[slouken]

Can we git bisect to see where it broke?

[Kontrabant]

On my system with the Nvidia proprietary drivers, Xonotic doesn't work with Wayland with the current release version, the old 3.2.10/2.32.54 version, or with the real SDL2 either.

If I take the Nvidia drivers out of the equation and force lavapipe + Zink it works though:
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json MESA_LOADER_DRIVER_OVERRIDE=zink ./xonotic-linux64-sdl

This is probably an Nvidia driver bug.

[Kontrabant]

Just forcing Zink with Nvidia's Vulkan implementation works too: __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json MESA_LOADER_DRIVER_OVERRIDE=zink ./xonotic-linux64-sdl

This is definitely an Nvidia GL driver bug.

[janp20]

Hi, but I am using Xonotic-SDL on AMD Radeon hardware (RX 5600 XT) and plain X11 (no Wayland and no Vulkan AFAIK).

[wks]

I am having the same issue. I am using ArchLinux and the nvidia-open driver. My computer has an Intel CPU and an NVidia 4070 mobile graphics card. I can launch Xonotic with xonotic-sdl (which uses the integrated Intel GPU) or prime-run xonotic-sdl (which uses the NVidia discrete GPU), and the problem can be reproduced in both cases. xonotic-glx does not have this issue.

An interesting detail is that if I

1. Launch Xonotic with xonotic-sdl
2. Quickly tap the backtick key and then some random letter keys
3. Wait until the "Singleplayer", "Multiplayer" and "Settings" windows appear, and the BGM starts.

Then the console will open and contain those random keys I typed. But if I press more letter keys after step 3, they won't appear in the console.

Another interesting detail: If I press the enter key, it behaves as if I pressed the enter key twice. The same is true for arrow keys. If I press the "up" key once, it will go back two commands in history in quick succession.

And this problem seems to be related to FCITX 5 (the input method framework for inputting Chinese, Japanese and other languages). I am using Wayland + KDE Plasma, and I am setting the "virtual keyboard" in System Settings to the Fcitx virtual keyboard (which is the expected way to use Fcitx). If I turn off the virtual keyboard, the problem will go away. I think it may be related to some interaction between SDL and input methods.

[wks]

I created a minimalist test program

#include <stdio.h>

#include <SDL.h>

int main() {
    if (SDL_Init(SDL_INIT_VIDEO) < 0) {
        printf("Error initializing SDL: %s\n", SDL_GetError());
        return -1;
    }

    SDL_Window *window = SDL_CreateWindow("Keyboard events test",
                                          SDL_WINDOWPOS_UNDEFINED,
                                          SDL_WINDOWPOS_UNDEFINED,
                                          800, 600,
                                          SDL_WINDOW_SHOWN);
    if(!window) {
        printf("Error creating window: %s\n", SDL_GetError());
        return -2;
    }

    bool quit = false;

    while (!quit) {
        SDL_Event e;
        SDL_WaitEvent(&e);

        switch (e.type) {
            case SDL_QUIT:
                quit = true;
                break;
            case SDL_KEYDOWN:
                printf("Key down: %d\n", e.key.keysym.sym);
                break;
            case SDL_KEYUP:
                printf("Key up: %d\n", e.key.keysym.sym);
                break;
            case SDL_TEXTINPUT:
                printf("Text input: [%s]\n", e.text.text);
                break;
            default:
                printf("Event: %d\n", e.type);
        }
    }

    SDL_DestroyWindow(window);
    SDL_Quit();
    return 0;
}

Save it as main.c and compile it with

gcc -I/usr/include/SDL2 -D_GNU_SOURCE=1 -D_REENTRANT -L/usr/lib -lSDL2 main.c -o main

I first go to KDE System Setting -> Input & Output -> Virtual Keyboard and select "None". I launch the program and press A B C D E ALT+F4 in that order. It prints:

Event: 512
Event: 514
Event: 512
Event: 526
Event: 512
Event: 516
Event: 512
Event: 524
Event: 1024
Event: 519
Event: 532
Event: 533
Event: 2304
Event: 512
Event: 517
Key down: 97
Text input: [a]
Key up: 97
Key down: 98
Text input: [b]
Key up: 98
Key down: 99
Text input: [c]
Key up: 99
Key down: 100
Text input: [d]
Key up: 100
Key down: 101
Text input: [e]
Key up: 101
Key down: 1073742050
Event: 512
Event: 528

Then I go to KDE System Setting -> Input & Output -> Virtual Keyboard and select "Fcitx 5" or "Fcitx 5 Wayland Launcher (experimental)" (the results are the same). I launch the program and press A B C D E ALT+F4 in that order. It prints:

Event: 512
Event: 514
Event: 512
Event: 526
Event: 512
Event: 516
Event: 512
Event: 524
Event: 1024
Event: 519
Event: 532
Event: 533
Event: 2304
Event: 512
Event: 517
Key down: 97
Key down: 97
Text input: [a]
Key up: 97
Key down: 98
Key down: 98
Text input: [b]
Key up: 98
Key down: 99
Key down: 99
Text input: [c]
Key up: 99
Key down: 100
Key down: 100
Text input: [d]
Key up: 100
Key down: 101
Key down: 101
Text input: [e]
Key up: 101
Key down: 1073742050
Key down: 1073742050
Event: 512
Event: 528

Notice that all key-down events are duplicated.

Some package versions:

sdl2-compat 2.32.56-1
sdl3 3.2.12-1
gcc 15.1.1+r7+gf36ec88aa85a-1
kwin 6.3.5-1
plasma-desktop 6.3.5-1
nvidia-open 570.144-4

[wks]

Well, the duplicated key-down event was caused by 2a9b84e

However, that was an independent problem. I built the revision before that, and used LD_PRELOAD=/path/to/my/built/libSDL2-2.0.so.0 xonotic-sdl to run Xonotic, and the problem that one ENTER key or ARROW key behaves like two disappeared. But I still can't type in any letters into the Xonotic console.

[wks]

I also tried downgrading my ArchLinux packages to the previous versions. The following combination does not have the problem:

sdl3 3.2.10-1
sdl2-compat 2.32.54-2

Because the commit 2a9b84e was between 2.30.50 and 2.30.51, but the package sdl2-compat-2.32.54-2 works, I guess something happened in sdl3 between 3.2.10 and 3.2.12 changed the behavior.

[Kontrabant]

The X11 IME double key issue is fixed in upstream SDL3, which also seems to solves the Xonotic text input issue from my testing.

[wks]

I bisected the SDL repo and found the culprit is libsdl-org/SDL@e42071a It was related to X11 and IME.

The X11 IME double key issue is fixed in upstream SDL3, which also seems to solves the Xonotic text input issue from my testing.

@Kontrabant Thank you. I have just seen your message. I confirm that the current main branch of SDL does not have the problem. I built the main branch of SDL, and used LD_LIBRARY_PATH=/path/to/install/dir/lib xonotic-sdl to run Xonotic, and I can type letters into the console. And the ENTER key and ARROW keys do not repeat.

But if I do so, Xonotic will crash on exit with an error message

Assertion failure at SDL_UnlockMutex_REAL (/home/wks/tocompile/SDL/src/thread/pthread/SDL_sysmutex.c:150), triggered 1 time:
  'rc == 0'

And whenever I open the console by pressing BACKTICK, it opens the console, but the BACKTICK character is also typed into the console, which shouldn't happen.

Anyway those are other problems that needs solution. I think what I can do as an ArchLinux user is just temporarily pin the version of sdl3 and sdl2-compat to a working combination and wait for the SDL3-side fix to be released.

[Kontrabant]

The assertion failures are due to compiling in debug mode, and the game not completely cleaning up its threads on exit. This is not unique to Xonotic, as it happens with others as well.

And whenever I open the console by pressing BACKTICK, it opens the console, but the BACKTICK character is also typed into the console, which shouldn't happen.

This might be a legit game bug, as the engine seems to make an assumption about internal X and SDL workings in that a text event will always immediately follow the associated key down event in the event queue, which doesn't always happen with the updated SDL3 IME code and passing dead keys while text input is enabled, as X may not send the text event immediately following the key down event. In short:

• Xonotic gets a key down event to open the console in the event loop
• It immediately calls SDL_PollEvent to see if the next event in the queue is a text event
• X hasn't delivered the text event to SDL yet, so SDL_PollEvent() returns nothing
• The text event arrives at some later time
• Xonotic thinks that these two events are separate and adds the character of the key used to open the console to the working command line

[andreymal]

Not sure if this is the same issue, but in my case, I have a black Xonotic window with all three drivers (nvidia, nouveau and nouveau+zink) _{(and I have no idea how to run nvidia+zink, the commands mentioned above don't work)}

Downgrading to 2.32.54 fixes this (both sdl3 3.2.10 and 3.2.12 work well after downgrading sdl2-compat)

UPD: the black screen seems to be caused by libsdl-org/SDL#12986

[Kontrabant]

Ah, my system defaults to Pipewire for audio, so that's why I couldn't reproduce this. Forcing it to Pulseaudio breaks GL rendering on my setup as well, on both X and Wayland.

[slouken]

SDL 3.2.14 with the fix for the bug is now available!