ValveSoftware
Gamescope + Big Picture Overlay mouse recapture bug on stretched resolutions (native res workaround exists; conflicts with multi-Xwayland)
Is there an existing issue for this?
- [x] I have searched the existing issues
Are you using any gamescope patches or a forked version of gamescope?
- [x] The issue occurs on upstream gamescope without any modifications
Current Behavior
Description: On stretched resolutions using gamescope (-S stretch with -W/-H != -w/-h), closing the Steam Big Picture overlay does not reliably return the game to a working relative/raw mouse state. After closing the overlay, the game’s camera mouse input becomes unresponsive until the user physically moves the mouse (a tiny “jiggle”). In some games, mouse/camera input becomes constrained to a small box region; in others it appears fully locked/unresponsive. The same jiggle restores normal camera input.
On native resolutions (no stretch; -W/-H == -w/-h), I can avoid the issue by using multiple Xwayland instances (STEAM_MULTIPLE_XWAYLANDS=1 with --xwayland-count 2). However, enabling that workaround causes stretched mode to stop working on my system: -S stretch is ignored or the output is no longer stretched (scaler behavior changes).
Expected behavior:
- Closing the Steam Big Picture overlay should immediately restore normal relative/raw mouse capture for camera input.
- Stretched scaling (-S stretch) should continue working regardless of whether multiple Xwayland instances are used.
Actual behavior (stretched mode):
- Open Steam overlay (Shift+Tab).
- Close Steam overlay (Shift+Tab).
- If the mouse is NOT moved immediately after closing overlay, camera input is unresponsive (no mouselook) OR constrained to a small box region.
- Moving the mouse even slightly (1–2 px) after closing overlay immediately restores normal camera input.
Games observed:
- ARC Raiders: often constrained to a small “box” region until jiggle.
- THE FINALS: similar “box” constraint until jiggle.
- Other titles: sometimes fully unresponsive until jiggle.
Steps To Reproduce
Steps to reproduce:
- Launch a game with gamescope stretched scaling and forced cursor grab: PIPEWIRE_DEBUG=0 gamescope -f -W 1920 -H 1080 -w 1440 -h 1080 -r 400 -S stretch --force-grab-cursor -- steam -gamepadui
- In-game, open Steam overlay (Shift+Tab).
- Close Steam overlay (Shift+Tab).
- Do NOT move the mouse.
- Observe camera input is broken (unresponsive or boxed).
- Move mouse slightly (“jiggle”).
- Observe camera input immediately returns to normal.
Workaround for native (works, but breaks stretch on my system): This fixes the overlay/mouse recapture issue at native resolution, but conflicts with stretched scaling.
- Native (no stretch) example command: STEAM_MULTIPLE_XWAYLANDS=1 PIPEWIRE_DEBUG=0 gamescope -f -W 1920 -H 1080 -w 1920 -h 1080 -r 400 --xwayland-count 2 --force-grab-cursor -- steam -gamepadui
Conflict / regression detail:
- If I keep my stretched sizes (W/H 1920x1080, w/h 1440x1080) and add multi-Xwayland: STEAM_MULTIPLE_XWAYLANDS=1 PIPEWIRE_DEBUG=0 gamescope -f -W 1920 -H 1080 -w 1440 -h 1080 -r 400 -S stretch --xwayland-count 2 --force-grab-cursor -- steam -gamepadui Result: stretched behavior stops working (on my system). The scale behavior changes and the output is no longer stretched as expected.
Hardware information
System / software info
- Distro: Arch Linux (vanilla)
- Kernel: 6.17.8-273-tkg-eevdf
- CPU: AMD Ryzen 7 7700
- GPU: AMD Radeon RX 6800 XT
- Graphics stack:
- mesa 1:25.3.1-2
- libdrm 2.4.131-1
- llvm 21.1.6-1
- Steam:
- Client channel: Stable Client (not beta)
- Steam version/build: 1763795278
- Monitor: Zowie XL2566X+
Software information
* Desktop environment: Bare Metal TTY & Hyprland
* Session type: tty & wayland
* Gamescope version: 3.16.18
Issue with:
* Gamescope launch command(s): `PIPEWIRE_DEBUG=0 gamescope -f -W 1920 -H 1080 -w 1440 -h 1080 -r 400 -S stretch --force-grab-cursor -- steam -gamepadui`
Resolves issue, but using `STEAM_MULTIPLE_XWAYLANDS=1` and `--xwayland-count 2` causes stretched (-S stretch) to not work anymore.
* Gamescope launch command(s): `STEAM_MULTIPLE_XWAYLANDS=1 PIPEWIRE_DEBUG=0 gamescope -f -W 1920 -H 1080 -w 1440 -h 1080 -r 400 -S stretch --xwayland-count 2 --force-grab-cursor -- steam -gamepadui`
Which gamescope backends have the issue you are reporting?
- [x] Wayland (default for nested gamescope)
- [x] DRM (default for embedded gamescope, i.e. gamescope-session)
- [ ] SDL
- [ ] OpenVR
Logging, screenshots, or anything else
Notes:
- The bug presents as “overlay visually closes, but relative mouse grab/capture is not restored until the first post-overlay mouse motion event.”
- The “boxed” behavior and “fully unresponsive” behavior appear to be the same underlying failure mode across different games.
I switched the examples from -- %command% (per-game launch options) to -- steam -gamepadui to match how I’m reproducing this issue.
I'm experiencing this issue again on a new kernel..
6.18.2-3-cachyos
the solution would be to allow STEAM_MULTIPLE_XWAYLANDS=1 and --xwayland-count 2 to allow stretched resolutions with steam -gamepadui but that still doesn't work.
I'm running very similar hardware and also cs2 with a stretched resolution. For me, this problem never happens while shift-tabbing out of the game - only when I open the game through big picture mode and not moving the mouse immeaditly. The cursor works in the menu of the game, but after loading into a game the crosshair only moves like 1-2 pixel to a side and then moves back again for some reason. I have to relaunch big picture mode in order to fix it. The issue does not occur without big picture mode.
I'm running very similar hardware and also cs2 with a stretched resolution. For me, this problem never happens while shift-tabbing out of the game - only when I open the game through big picture mode and not moving the mouse immeaditly. The cursor works in the menu of the game, but after loading into a game the crosshair only moves like 1-2 pixel to a side and then moves back again for some reason. I have to relaunch big picture mode in order to fix it. The issue does not occur without big picture mode.
Yes the issue is in direct relation when big picture is used. If you close the big picture overlay and are jiggling/moving your mouse while closing you can gain full input to the game back.. Without big picture of course this is a non-issue.
If you close the big picture overlay and are jiggling/moving your mouse while closing you can gain full input to the game back
doesn't work for me, but anyways I just stopped using BPM for now
doesn't work for me, but anyways I just stopped using BPM for now
You're using the latest commit version?