Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[sniper] libsdl3 3.4.14: relative mouse becomes delta-of-deltas under Xwayland (SDL#16163, fixed in 3.4.18), TF2 mouselook stalls

Open
  • Is something wrong?
#857 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
infrastructure, operating-systems

Research direction

Start by inspecting the sniper package version and debian/patches/series, then compare src/video/x11/SDL_x11xinput2.c with SDL 3.4.18 and the referenced upstream fix. Done means shipping libsdl3 3.4.18 or later, or a backport, and confirming the supplied Xwayland ctypes/uinput reproduction delivers the expected relative deltas.

Written by the indexing model from the issue text.

Description

Your system information
  • Steam Runtime Version: steam-runtime_1.0.20260714.251828
  • Distribution (e.g. Ubuntu 18.04): NixOS 26.05 (kernel 6.18.54), Hyprland 0.55.4, Xwayland 24.1.13
  • Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: available on request; the bug is a deterministic library issue, details below
  • Have you checked for system updates?: Yes
  • What compatibility tool are you using?: Steam Linux Runtime 3.0 (sniper), native Linux game (Team Fortress 2, 64-bit)
  • What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt? 1.0.20260618.246542
  • What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt? 2.0.20260805.254767
  • What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt? 3.0.20260805.254768 (pressure-vessel 0.20260805.0)
  • What versions are listed in steamapps/common/SteamLinuxRuntime_4/VERSIONS.txt? 4.0.20260805.254769
Please describe your issue in as much detail as possible:

In Team Fortress 2 (64-bit, running in sniper, SDL2 API through sdl2-compat 2.32.70 on top of libsdl3-0 3.4.14+ds-1+steamrt3.1+bsrt3.1), mouselook intermittently stalls: the view turns a few degrees and stops while the mouse keeps moving. Keyboard, clicks and menus keep working. Whether a session is affected is decided at launch: some launches are fine, others are broken until the game is closed, and nothing in-game recovers it (m_rawinput, mat_setvideomode, alt-tab).

This is the SDL bug libsdl-org/SDL#16163, fixed upstream by libsdl-org/SDL#16267 (first released in SDL 3.4.18):

  • The X11 backend selects raw events on XIAllMasterDevices and caches the valuator mode (relative or absolute) of rawev->deviceid, which is the master "Virtual core pointer", once, on the first raw event.
  • Under Xwayland the master's classes follow the last slave used: xwayland-pointer (Abs X/Y, absolute) or xwayland-relative-pointer (Rel X/Y, relative).
  • If the master was following the absolute slave at that moment, every relative raw delta is afterwards converted as if it were an absolute position (current - previous). The game receives a delta of deltas, so constant-speed motion becomes zero.

Because of the steamrt patch video-Always-prefer-Wayland-over-X11-unless-configured-ot.patch, SDL3 games in sniper use X11 through Xwayland on Wayland desktops, so every one of them goes through this code path.

The newest package I can find in the apt pool, libsdl3 3.4.16+ds-1+steamrt3.1, does not contain the fix either: upstream 3.4.16 still has //case XI_DeviceChanged: commented out in src/video/x11/SDL_x11xinput2.c, and the package's debian/patches/series does not backport it.

ValveSoftware/csgo-osx-linux#4354 and ValveSoftware/csgo-osx-linux#4310 are linked from the upstream PRs and describe the same symptom in CS2.

Steps for reproducing this issue:

This reproduces deterministically without a game. I loaded the runtime's own libSDL3.so.0.4.14 with Python ctypes, opened an X11 window (SDL_VIDEO_DRIVER=x11, under Xwayland) and injected motion through a uinput device with ydotool:

  1. Create the SDL window. Before SDL processes any raw motion, focus an X11 window that does not confine the pointer (the test window before relative mode, or the Steam client) and move the pointer with an absolute-axis device: ydotool mousemove --absolute .... xinput list --long 2 now reports Abs X / Abs Y for the master, and that is what SDL caches.
  2. Enable relative mode with SDL_SetWindowRelativeMouseMode.
  3. Inject three bursts of ten relative events: +60 ten times, +60 ten times again, then -60 ten times. Sum the xrel that SDL delivers.
burst runtime SDL 3.4.14 expected
10 x (+60) -1660 (a single event: 60 - 1720, the absolute X from step 1) +600
10 x (+60) again 0 (no events) +600
10 x (-60) -120 -600

The same harness gives +600 / +600 / -600 with a build that keys the device cache by rawev->sourceid (the approach of libsdl-org/SDL#16259), also when that build is loaded into the runtime's SDL through SDL3_DYNAMIC_API. The numbers I measured in-game in a broken TF2 session match the delta-of-deltas model exactly: ten +60 events after ten -60 events turned the view by exactly 120 units, and ten +60 events after ten +60 events did not turn it at all.

Request: please update libsdl3 in sniper to 3.4.18 or later, or backport libsdl-org/SDL#16267 into the 3.4.x package.

Workaround until then: launch options SDL3_DYNAMIC_API=/path/to/libSDL3.so.0 %command%, pointing at an SDL3 that has the fix and runs inside sniper. The path must be a regular file in a location pressure-vessel shares, such as $HOME. I use Valve's own 3.4.14 binary with a one-byte change that makes the device-info lookup use rawev->sourceid, equivalent to libsdl-org/SDL#16259.

Dominant language
Shell
Stars
1.5k
Forks
97
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ValveSoftware/steam-runtime

All issues in ValveSoftware/steam-runtime

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.