Is there an existing issue for this?
Are you using any gamescope patches or a forked version of gamescope?
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?
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.
Is there an existing issue for this?
Are you using any gamescope patches or a forked version of gamescope?
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:
Actual behavior (stretched mode):
Games observed:
Steps To Reproduce
Steps to reproduce:
PIPEWIRE_DEBUG=0 gamescope -f -W 1920 -H 1080 -w 1440 -h 1080 -r 400 -S stretch --force-grab-cursor -- steam -gamepadui
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.
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:
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
Software information
Which gamescope backends have the issue you are reporting?
Logging, screenshots, or anything else
Notes: