[Bug Report] flatpak with sdlcompat update breaks Super key

[SjoerdV]

Describe the bug
Latest flatpak with sdlcompat update breaks Super key in stream, reverting to previous commit fixed issue
Running xev -event keyboard inside the stream gives no output when Super key is pressed.

Steps to reproduce
Upgrade to this commit

        ID: com.moonlight_stream.Moonlight
       Ref: app/com.moonlight_stream.Moonlight/x86_64/stable
      Arch: x86_64
    Branch: stable
   Version: 6.1.0
   License: GPL-3.0+
Collection: org.flathub.Stable
  Download: 8.0 MB
 Installed: 19.1 MB
   Runtime: org.kde.Platform/x86_64/6.10
       Sdk: org.kde.Sdk/x86_64/6.10

    Commit: 61da768f1d637268fdc4212046609e83d2a153b949f84cf80fd0e47093aa97c4
    Parent: 292c3be7f1845d5c47b1d63f405cb94503ee8764f3d559b7591ff6ae366a6cb5
   Subject: Merge pull request #67 from flathub/sdl2compat (12f4804557eb)
      Date: 2026-01-01 05:34:16 +0000
   History: 

Client PC details (please complete the following information)

• OS: debian forky
• Moonlight Version: 6.1.0
• GPU: Intel UHD Graphics 630
• Linux package type (if applicable): Flatpak

Server PC details (please complete the following information)

• OS: debian forky
• Sunshine or GeForce Experience version: Sunshine
• GPU: nvidia 4000 series
• GPU driver: 580

[cgutman]

Thanks for the report. It's working okay for me here on the GNOME 49 Wayland session in Fedora 43. I tested with both modes of system keyboard shortcut capture (always and fullscreen only) and both Wayland and XWayland. I also tried both the Super key alone and in a Super+Tab key combo.

Could you provide a little more info like:

• Which desktop environment are you running?
• Are you using X11 or Wayland?
• For the capture system keyboard shortcuts option, are you using "always" or "in fullscreen"?
• Is it broken both when used by itself and with another key?

[Fritnes]

Hi everyone,
I’m also seeing some issues with keyboard shortcuts and wanted to share my setup.

Which desktop environment are you running?
Client flatpak
Arch Linux + KDE Plasma

Server
Windows 11

Are you using X11 or Wayland?
Wayland

For the capture system keyboard shortcuts option, are you using "always" or "in fullscreen"?
Always

Is it broken both when used by itself and with another key?
Yes, it seems that all combinations using Alt / Ctrl / Shift + Q/S don’t work for me.
When I switch back to an older commit, the shortcuts start working again, so this might be a regression in recent changes, possibly related to Wayland handling.

Thanks for looking into this, and let me know if I can provide any additional detail

[SjoerdV]

Could you provide a little more info like:

• Which desktop environment are you running?

labwc 0.9.3 on wlroots 0.19.1

• Are you using X11 or Wayland?

wayland (Xwayland is still available)

• For the capture system keyboard shortcuts option, are you using "always" or "in fullscreen"?

fullscreen only

• Is it broken both when used by itself and with another key?

the entire key does nothing (in stream)

[cgutman]

I tried Arch Linux + KDE Plasma Wayland here and still can't reproduce the issue.

Any chance you have some IMEs installed that might be interfering?

Can you try to run Moonlight with flatpak run --env=SDL_EVENT_LOGGING=1 --env=SDL2_EVENT_LOGGING=1 com.moonlight_stream.Moonlight and see if you see SDL key events when you press those buttons?

[SjoerdV]

So the scenario below is:

1. connecting with host
2. press SUPER+R
3. PRESS C-A-S-x (to exit fullscreen)
4. PRESS C-A-S-z (to release mouse)
5. copy the log

working SDLcompat (previous flatpak)

00:02:11 - SDL Info (0): SDL EVENT: SDL_MOUSEBUTTONDOWN (timestamp=131419 windowid=2 which=0 button=1 state=pressed clicks=1 x=1843 y=439)
00:02:11 - SDL Info (0): SDL EVENT: SDL_MOUSEBUTTONUP (timestamp=131497 windowid=2 which=0 button=1 state=released clicks=1 x=1843 y=439)
00:02:12 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=132826 windowid=2 state=pressed repeat=false scancode=227 keycode=1073742051 mod=5120)
00:02:14 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=134369 windowid=2 state=pressed repeat=false scancode=21 keycode=114 mod=5120)
00:02:14 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=134441 windowid=2 state=released repeat=false scancode=21 keycode=114 mod=5120)
00:02:14 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=134554 windowid=2 state=released repeat=false scancode=227 keycode=1073742051 mod=4096)
00:02:16 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=136561 windowid=2 state=pressed repeat=false scancode=41 keycode=27 mod=4096)
00:02:16 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=136601 windowid=2 state=released repeat=false scancode=41 keycode=27 mod=4096)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=137257 windowid=2 state=pressed repeat=false scancode=224 keycode=1073742048 mod=4160)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=137305 windowid=2 state=pressed repeat=false scancode=226 keycode=1073742050 mod=4416)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=137497 windowid=2 state=pressed repeat=false scancode=225 keycode=1073742049 mod=4417)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=137641 windowid=2 state=pressed repeat=false scancode=27 keycode=120 mod=4417)
00:02:17 - SDL Info (0): Detected full-screen toggle combo
00:02:17 - SDL Info (0): SDL EVENT: SDL_WINDOWEVENT (timestamp=137643 windowid=2 event=SDL_WINDOWEVENT_SIZE_CHANGED data1=1536 data2=864)
00:02:17 - SDL Info (0): SDL EVENT: SDL_WINDOWEVENT (timestamp=137643 windowid=2 event=SDL_WINDOWEVENT_RESIZED data1=1536 data2=864)
00:02:17 - SDL Info (0): SDL EVENT: SDL_WINDOWEVENT (timestamp=137643 windowid=2 event=SDL_WINDOWEVENT_EXPOSED data1=0 data2=0)
00:02:17 - SDL Info (0): SDL EVENT: SDL_WINDOWEVENT (timestamp=137643 windowid=2 event=SDL_WINDOWEVENT_RESIZED data1=1536 data2=864)
00:02:17 - SDL Info (0): SDL EVENT: SDL_WINDOWEVENT (timestamp=137643 windowid=2 event=SDL_WINDOWEVENT_SIZE_CHANGED data1=1536 data2=864)
00:02:17 - SDL Info (0): Raising 3 keys
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=137721 windowid=2 state=released repeat=false scancode=27 keycode=120 mod=4417)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYDOWN (timestamp=137809 windowid=2 state=pressed repeat=false scancode=29 keycode=122 mod=4417)
00:02:17 - SDL Info (0): Detected mouse capture toggle combo
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=137873 windowid=2 state=released repeat=false scancode=29 keycode=122 mod=4417)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=137971 windowid=2 state=released repeat=false scancode=224 keycode=1073742048 mod=4353)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=137971 windowid=2 state=released repeat=false scancode=225 keycode=1073742049 mod=4352)
00:02:17 - SDL Info (0): SDL EVENT: SDL_KEYUP (timestamp=137971 windowid=2 state=released repeat=false scancode=226 keycode=1073742050 mod=4096)
00:02:18 - SDL Info (0): SDL EVENT: SDL_WINDOWEVENT (timestamp=138665 windowid=2 event=SDL_WINDOWEVENT_LEAVE data1=0 data2=0)
00:02:19 - SDL Info (0): SDL EVENT: SDL_WINDOWEVENT (timestamp=139466 windowid=2 event=SDL_WINDOWEVENT_FOCUS_LOST data1=0 data2=0)

broken SDLcompat (current flatpak)

00:00:14 - SDL Info (0): SDL2 EVENT: SDL_KEYUP (timestamp=14015 windowid=13 state=released repeat=false scancode=27 keycode=120 mod=4417)
00:00:14 - SDL Info (0): SDL EVENT: SDL_EVENT_KEY_UP (timestamp=14015427638 windowid=13 which=8 state=released repeat=false scancode=27 keycode=120 mod=0x1141)
00:00:15 - SDL Info (0): SDL2 EVENT: SDL_KEYDOWN (timestamp=15151 windowid=13 state=pressed repeat=false scancode=29 keycode=122 mod=4417)
00:00:15 - SDL Info (0): SDL EVENT: SDL_EVENT_KEY_DOWN (timestamp=15151427638 windowid=13 which=8 state=pressed repeat=false scancode=29 keycode=122 mod=0x1141)
00:00:15 - SDL Info (0): Detected mouse capture toggle combo
00:00:15 - SDL Info (0): SDL2 EVENT: SDL_KEYUP (timestamp=15223 windowid=13 state=released repeat=false scancode=29 keycode=122 mod=4417)
00:00:15 - SDL Info (0): SDL EVENT: SDL_EVENT_KEY_UP (timestamp=15223427638 windowid=13 which=8 state=released repeat=false scancode=29 keycode=122 mod=0x1141)
00:00:15 - SDL Info (0): SDL2 EVENT: SDL_KEYUP (timestamp=15423 windowid=13 state=released repeat=false scancode=225 keycode=1073742049 mod=4416)
00:00:15 - SDL Info (0): SDL EVENT: SDL_EVENT_KEY_UP (timestamp=15423427638 windowid=13 which=8 state=released repeat=false scancode=225 keycode=1073742049 mod=0x1140)
00:00:15 - SDL Info (0): SDL2 EVENT: SDL_KEYUP (timestamp=15423 windowid=13 state=released repeat=false scancode=226 keycode=1073742050 mod=4160)
00:00:15 - SDL Info (0): SDL EVENT: SDL_EVENT_KEY_UP (timestamp=15423427638 windowid=13 which=8 state=released repeat=false scancode=226 keycode=1073742050 mod=0x1040)
00:00:15 - SDL Info (0): SDL2 EVENT: SDL_KEYUP (timestamp=15431 windowid=13 state=released repeat=false scancode=224 keycode=1073742048 mod=4096)
00:00:15 - SDL Info (0): SDL EVENT: SDL_EVENT_KEY_UP (timestamp=15431427638 windowid=13 which=8 state=released repeat=false scancode=224 keycode=1073742048 mod=0x1000)
00:00:17 - SDL Info (0): SDL2 EVENT: SDL_WINDOWEVENT (timestamp=17550 windowid=13 event=SDL_WINDOWEVENT_LEAVE data1=0 data2=0)
00:00:17 - SDL Info (0): SDL EVENT: UNKNOWN 0x200
00:00:18 - SDL Info (0): SDL2 EVENT: SDL_WINDOWEVENT (timestamp=18879 windowid=13 event=SDL_WINDOWEVENT_FOCUS_LOST data1=0 data2=0)
00:00:18 - SDL Info (0): SDL EVENT: UNKNOWN 0x200

[SjoerdV]

I know for certain keybinds of the client WM are not interfering with the ones Moonlight sets/uses because the client WM has disabled the OS keybinds with the ToggleKeybinds option of labwc.

#1525 (comment)

[cgutman]

For a little background, the change in that Flatpak commit that introduced the breakage is switching from SDL2 to SDL2-compat+SDL3, because SDL2 is end of life now and not receiving new releases. Many distros are doing the same thing (Arch, Fedora, and Debian Forky already use SDL2-compat instead of SDL2). The fact that I haven't gotten complaints from Arch users using its native moonlight-qt package makes me wonder if it's actually a new regression in SDL 3.4.0.

Your logs indicate that it's most likely a bug in SDL3. In the working log, we see the expected scancode=227 which corresponds to the left super key, but I don't see that (or even the R which is scancode=21) in the SDL3 events.

One last thing you can try is forcing it to run under XWayland, which can be done by WAYLAND_DISPLAY= flatpak run com.moonlight_stream.Moonlight. That may or may not work depending on whether your WM lets XWayland apps grab the keyboard. It would be an interesting data point if it's specific to SDL's Wayland video driver.

I know for certain keybinds of the client WM are not interfering with the ones Moonlight sets/uses because the client WM has disabled the OS keybinds with the ToggleKeybinds option of labwc.

So just to confirm, neither the host nor the client WM is reacting to the Super key?

[SjoerdV]

For a little background, the change in that Flatpak commit that introduced the breakage is switching from SDL2 to SDL2-compat+SDL3, because SDL2 is end of life now and not receiving new releases. Many distros are doing the same thing (Arch, Fedora, and Debian Forky already use SDL2-compat instead of SDL2). The fact that I haven't gotten complaints from Arch users using its native moonlight-qt package makes me wonder if it's actually a new regression in SDL 3.4.0.

My forky has these versions (btw. wasn't the whole idea of flatpak to have these dependencies inside the flatpak itself?):

• SDL2: 2.32.10+dfsg-6
• SDL3: 3.2.28+ds-1
• SDL2Compat: 2.32.60+ds-1

I did see today that an update is available, maybe this 3.4 update fixes the issue? (Didn't yet update, to not polute this case)

libsdl3-0:
  Installed: 3.2.28+ds-1
  Candidate: 3.4.0+ds-1
  Version table:
     3.4.0+ds-1 500
        500 https://deb.debian.org/debian forky/main amd64 Packages
         50 https://deb.debian.org/debian unstable/main amd64 Packages
 *** 3.2.28+ds-1 100
        100 /var/lib/dpkg/status
     3.2.10+ds-1 50
         50 https://deb.debian.org/debian stable/main amd64 Packages

Your logs indicate that it's most likely a bug in SDL3. In the working log, we see the expected scancode=227 which corresponds to the left super key, but I don't see that (or even the R which is scancode=21) in the SDL3 events.

Yeah it's weird

One last thing you can try is forcing it to run under XWayland, which can be done by WAYLAND_DISPLAY= flatpak run com.moonlight_stream.Moonlight. That may or may not work depending on whether your WM lets XWayland apps grab the keyboard. It would be an interesting data point if it's specific to SDL's Wayland video driver.

This made it worse, none of the shortcuts worked, but fullscreen mode was bugged so I had access to my client system thankfully. Also screenflicker observed... Wayland is obviously the only way.

I know for certain keybinds of the client WM are not interfering with the ones Moonlight sets/uses because the client WM has disabled the OS keybinds with the ToggleKeybinds option of labwc.

So just to confirm, neither the host nor the client WM is reacting to the Super key?

No, the client WM is configured to not impose it's keybinds to the Moonlight window (in this case), leaving the app to have full reign over shortcuts when focused and fullscreen. Even with this configuration the stream did not react to the Super key.

[cgutman]

My forky has these versions (btw. wasn't the whole idea of flatpak to have these dependencies inside the flatpak itself?):

Yes, the versions on the host have no impact on the Flatpak. My point was that there are official downstream moonlight-qt packages for distros like Arch, and nobody has complained about this issue even though they have been running SDL2-compat+SDL3 for almost a year at this point (and they did quickly complain after the SDL2-compat transition initially in #1525). That makes me wonder if it's a new regression in SDL 3.4.0 (which is not released in Arch yet) and that's why nobody else has reported it yet.

[SjoerdV]

Yes, the versions on the host have no impact on the Flatpak. My point was that there are official downstream moonlight-qt packages for distros like Arch, and nobody has complained about this issue even though they have been running SDL2-compat+SDL3 for almost a year at this point (and they did quickly complain after the SDL2-compat transition initially in #1525). That makes me wonder if it's a new regression in SDL 3.4.0 (which is not released in Arch yet) and that's why nobody else has reported it yet.

Ah Ok so how do I find the version of the libs inside the flatpak? (Just so I know how to check)

[cgutman]

For SDL2-compat and SDL3, we build them ourselves as part of the Flatpak, so the versions are defined in https://github.com/flathub/com.moonlight_stream.Moonlight/blob/master/com.moonlight_stream.Moonlight.json

It would be interesting if you tried an older version of SDL3 to see if that changes anything.

You can git clone https://github.com/flathub/com.moonlight_stream.Moonlight.git and then in com.moonlight_stream.Moonlight.json just modify release-3.4.0 to release-3.2.28 and a962f40bbba175e9716557a25d5d7965f134a3d3 to 7f3ae3d57459e59943a4ecfefc8f6277ec6bf540.

Then you can build and install your build with:

flatpak install flathub org.kde.Sdk//6.10
flatpak-builder --install --user --force-clean build/ com.moonlight_stream.Moonlight.json

and that should install it where you can run it with flatpak run com.moonlight_stream.Moonlight//master.

[SjoerdV]

OK thanks, I tried the older libSDL3.so.0.2.28 on the newest flatpak, that had exact the same issue.

I did notice that you are using libSDL2-2.0.so.0.3200.62 in the newest build but the previous build had libSDL2-2.0.so.0.3300.0. So was there a reason to do a downgrade of this package maybe?

In any case, I did test it again with the new version of Moonlight but with the libSDL2-2.0.so.0.3300.0 libraries+sym/hardlinks and that fixed it! Probably something goes wrong in the 3200.62 version of the SDL2 libary. Hope it helps.

[cgutman]

So was there a reason to do a downgrade of this package maybe?

They're actually completely different implementations. SDL2-compat (using SDL3 under the hood) masquerades as SDL 2.32.50+ while the "real" SDL2 development branch reports version 2.33.0, so those version numbers are consistent with the expected change of moving from SDL2 to SDL2-compat.

Even though SDL2 reports 2.33.0 and SDL2-compat reports 2.32.62, the latter is actually newer since it's using the very latest SDL3 code under the hood, while the former is using the SDL2 branch which hasn't seem significant development work since 2024.

[SjoerdV]

So was there a reason to do a downgrade of this package maybe?

They're actually completely different implementations. SDL2-compat (using SDL3 under the hood) masquerades as SDL 2.32.50+ while the "real" SDL2 development branch reports version 2.33.0, so those version numbers are consistent with the expected change of moving from SDL2 to SDL2-compat.

Hmm, bit opaque form of package management imho. Why not create a new package for compat and leave the old sdl2 package out all together when sure it’s not needed anymore, use environment variables for switching between versions in this transition phase to have some fallback if things break. (At least in my case sdl3 seems not entirely well tested at this point, so I’d like to fallback to sdl2).

Btw my Debian system does have this separated (so 3 libs are doing work and coexist: libsdl2, sdl2-compat and libsdl3)

Any course of action you want to propose because of this super key thing? Can I help?