hover input dies in nested gamescope (RUN_GAMESCOPE) #104

New issue

Open

opened 2026-10-15 12:49:02 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:49:02 +00:00

Owner

Originally created by @TrafficDemotion on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/games-on-whales/gow/issues/360

Environment: Wolf + ghcr.io/games-on-whales/steam:edge (RUN_GAMESCOPE=true, GAMESCOPE_MODE="-b -C 99999999", i.e. gamescope nested inside the session's wayland-display), clients in absolute-mouse mode (Moonlight "optimize mouse for remote desktop").

Symptom: as soon as a controller is connected (USB, a virtual uinput pad, or a Moonlight-forwarded gamepad), Steam's controller activation writes the X property STEAM_TOUCH_CLICK_MODE=4 (its own log then shows Touchscreen DefaultMode 4) and all absolute mouse motion into the Steam UI stops being delivered — hover dead, cursor stops, clicks still work. Unplugging the controller does not restore it.

Root cause (verified in-container): gamescope's wlserver_touchmotion() branches on that property. Mode 4 = "passthrough" delivers the input as wl_touch events, and in nested mode the wl_touch path is unimplemented upstream (ValveSoftware/gamescope#1606; fix PR #2104 still unmerged), so the events are swallowed. Modes 0..3 (hover/left/right/middle) take the warp path and keep working. Direct capture: inserting the pad → Steam writes 4 → motion stops within the same second; changing the mode back → motion resumes instantly.

Verified workaround (two forms):

set the property to 0..3 (works, but Steam reads it back and can re-assert 4 → brief write fights), or
set gamescope's convar directly: gamescopectl touch_click_mode 0 (invisible to Steam; no property writes).

We ship the latter as a tiny /etc/cont-init.d script inside the image (mounted through the wolf app config) that watches the property and re-asserts the convar. Happy to provide the script and the raw evidence (per-second captures, hook logs).

Ask: consider making the steam image immune by default — e.g. carry the wl_touch patch, force a sane touch mode when nested, or at least document this pitfall.

Related observation (possibly separate): in some sessions an intermittent input freeze occurs ~2-3 min after start (preceded by a burst of synthetic mousemove events), where pointer input stops regardless of the touch mode. Looks like a pointer-focus/enter race in the nested path. Can instrument further if useful.

Originally created by @TrafficDemotion on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/games-on-whales/gow/issues/360 **Environment**: Wolf + `ghcr.io/games-on-whales/steam:edge` (`RUN_GAMESCOPE=true`, `GAMESCOPE_MODE="-b -C 99999999"`, i.e. gamescope nested inside the session's wayland-display), clients in absolute-mouse mode (Moonlight "optimize mouse for remote desktop"). **Symptom**: as soon as a controller is connected (USB, a virtual uinput pad, or a Moonlight-forwarded gamepad), Steam's controller activation writes the X property `STEAM_TOUCH_CLICK_MODE=4` (its own log then shows `Touchscreen DefaultMode 4`) and **all absolute mouse motion into the Steam UI stops being delivered** — hover dead, cursor stops, clicks still work. Unplugging the controller does not restore it. **Root cause (verified in-container)**: gamescope's `wlserver_touchmotion()` branches on that property. Mode 4 = "passthrough" delivers the input as **wl_touch** events, and in nested mode the wl_touch path is unimplemented upstream (ValveSoftware/gamescope#1606; fix PR #2104 still unmerged), so the events are swallowed. Modes 0..3 (hover/left/right/middle) take the warp path and keep working. Direct capture: inserting the pad → Steam writes 4 → motion stops within the same second; changing the mode back → motion resumes instantly. **Verified workaround** (two forms): - set the property to 0..3 (works, but Steam reads it back and can re-assert 4 → brief write fights), or - set gamescope's convar directly: `gamescopectl touch_click_mode 0` (invisible to Steam; no property writes). We ship the latter as a tiny `/etc/cont-init.d` script inside the image (mounted through the wolf app config) that watches the property and re-asserts the convar. Happy to provide the script and the raw evidence (per-second captures, hook logs). **Ask**: consider making the steam image immune by default — e.g. carry the wl_touch patch, force a sane touch mode when nested, or at least document this pitfall. **Related observation** (possibly separate): in some sessions an intermittent input freeze occurs ~2-3 min after start (preceded by a burst of synthetic mousemove events), where pointer input stops regardless of the touch mode. Looks like a pointer-focus/enter race in the nested path. Can instrument further if useful.

bsakaguchi referenced this issue

2026-10-15 12:49:31 +00:00

[PR #104] [MERGED] use the official sunshine image instead of building ourselves #153

bsakaguchi referenced this issue

2026-10-15 12:49:48 +00:00

[PR #144] [CLOSED] udev #185