[GH-ISSUE #500] Activating a save-state hotkey kills all input to the Dolphin emulator #306

New issue

Open

opened 2026-10-15 12:59:30 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:59:30 +00:00

Owner

Originally created by @Aodhagan on GitHub (Sep 7, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/500

In the Pegasus container, activating Dolphin's save-state hotkey stops all input
reaching the emulator. The game keeps running — video and audio continue normally —
but no further gamepad or keyboard input is delivered. Recovery requires ending the
session; the container has to be restarted.

PCSX2, running in the same container on the same virtual pad, is unaffected. Its
save/load-state hotkeys work correctly from the gamepad.

Environment

Wolf: ghcr.io/games-on-whales/wolf:stable, built 2026-03-30, revision
f492ab632c6109619bdf0209262ce95691378b54
(digest sha256:da96c3240d4b208143bca77739f8d3205fe4470d9862d978d2fe5fbeb7835441)
App: ghcr.io/games-on-whales/pegasus:edge, Dolphin 2603a
Host: Ubuntu 24.04.4 LTS, kernel 7.0.0-30-generic
- Intel AlderLake-S GT1 [8086:4680] — /dev/dri/renderD128, Wolf compositor + encode
- AMD [1002:7590] — /dev/dri/renderD129, app rendering (RADV)
Client: Steam Deck, Moonlight launched from Steam UI as a non-Steam game
Pad: Wolf X-Box One (virtual) pad (inputtino), event20 / js0

Steps to reproduce

Launch Pegasus, start any GameCube title in Dolphin.
Confirm the pad works in game.
Trigger save state by any of the routes marked BREAKS below.
Game continues running; no further input reaches Dolphin.

Observations

Route to save state	Result
Key on a USB keyboard, nothing else touched	works
Same keyboard key, while holding L3 on the pad	breaks
Dolphin menubar, via Deck trackpad as mouse	works
Steam Input keystroke on a back paddle, no gamepad binding	breaks
Hotkey bound to a controller button in Dolphin (evdev backend)	breaks
Hotkey bound to a controller button in Dolphin (SDL backend)	breaks

The common factor is the gamepad's involvement, not the input type. A pure keyboard
press works; the same press with a pad button held breaks. A Steam Input keystroke
from a paddle breaks even with no pad button held and no gamepad binding on that
paddle.

What this rules out

Not keyboard vs. gamepad — a keyboard press breaks it if a pad button is held.
Not Dolphin's input backend — evdev and SDL both break.
Not Dolphin's save-state code in general — the same action from the menubar works.
Not the virtual pad or the container — PCSX2 in the same container on the same pad
handles gamepad-triggered save states without issue.

Recovery

Ending the session is the only way out. I exit Wolf from the Steam UI, log back in,
and end the Pegasus session from there. Re-entering Pegasus immediately after that
returns "Lobby full", and the Wolf log shows mknod: File exists. It clears after
a while / a Wolf restart.

Logs

Captured a full reproduction with WOLF_LOG_LEVEL=DEBUG and RUST_LOG=DEBUG
(22,760 lines). Nothing is logged at the moment input stops.

21:35:20.071 DEBUG | [DOCKER] Executing command: mkdir -p /dev/input &&
  mknod /dev/input/event20 c 13 84 && chmod 777 /dev/input/event20 && fake-udev ...
21:35:20.103 DEBUG | [DOCKER] Executing command: mkdir -p /dev/input &&
  mknod /dev/input/js0 c 13 0 && chmod 777 /dev/input/js0 && fake-udev ...

Every one of the ~19,000 lines after that is the same per-frame message:

DEBUG waylanddisplaycore::utils::allocator: Failed to convert fourcc to video
format: DrmFourcc(AR24)

Nothing else is emitted through the game running, the hotkey press, or input dying.
Happy to attach the full log or grep it for anything specific.

Also visible at session start, on every launch (not specific to this bug, but it
shows how the pad is handled): the Wolf-UI session's pad is torn down with
ACTION=remove plus rm /dev/input/event20 and rm /dev/input/js0, then recreated
~150ms later with the same minor numbers (13:84 and 13:0) and the same
DEVPATH=/devices/virtual/input/input93.

Incidental: that fourcc message is logged once per frame at DEBUG, which makes
DEBUG-level capture fairly unwieldy — may be worth demoting to trace.

Note on version

I'm pinned to this older build because the newer one's embedded PulseAudio exits
repeatedly on my host and Wolf then blocks waiting for the socket — so my audio path
is the older sidecar PulseAudio container. Happy to retest on latest if that's
likely to be relevant here.

Originally created by @Aodhagan on GitHub (Sep 7, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/500 In the Pegasus container, activating Dolphin's save-state hotkey stops all input reaching the emulator. The game keeps running — video and audio continue normally — but no further gamepad or keyboard input is delivered. Recovery requires ending the session; the container has to be restarted. PCSX2, running in the same container on the same virtual pad, is unaffected. Its save/load-state hotkeys work correctly from the gamepad. ### Environment - Wolf: `ghcr.io/games-on-whales/wolf:stable`, built 2026-03-30, revision `f492ab632c6109619bdf0209262ce95691378b54` (digest `sha256:da96c3240d4b208143bca77739f8d3205fe4470d9862d978d2fe5fbeb7835441`) - App: `ghcr.io/games-on-whales/pegasus:edge`, Dolphin 2603a - Host: Ubuntu 24.04.4 LTS, kernel 7.0.0-30-generic - Intel AlderLake-S GT1 [8086:4680] — `/dev/dri/renderD128`, Wolf compositor + encode - AMD [1002:7590] — `/dev/dri/renderD129`, app rendering (RADV) - Client: Steam Deck, Moonlight launched from Steam UI as a non-Steam game - Pad: `Wolf X-Box One (virtual) pad` (inputtino), `event20` / `js0` ### Steps to reproduce 1. Launch Pegasus, start any GameCube title in Dolphin. 2. Confirm the pad works in game. 3. Trigger save state by any of the routes marked BREAKS below. 4. Game continues running; no further input reaches Dolphin. ### Observations | Route to save state | Result | |---|---| | Key on a USB keyboard, nothing else touched | works | | Same keyboard key, while holding L3 on the pad | **breaks** | | Dolphin menubar, via Deck trackpad as mouse | works | | Steam Input keystroke on a back paddle, no gamepad binding | **breaks** | | Hotkey bound to a controller button in Dolphin (evdev backend) | **breaks** | | Hotkey bound to a controller button in Dolphin (SDL backend) | **breaks** | The common factor is the gamepad's involvement, not the input type. A pure keyboard press works; the same press with a pad button held breaks. A Steam Input keystroke from a paddle breaks even with no pad button held and no gamepad binding on that paddle. ### What this rules out - Not keyboard vs. gamepad — a keyboard press breaks it if a pad button is held. - Not Dolphin's input backend — evdev and SDL both break. - Not Dolphin's save-state code in general — the same action from the menubar works. - Not the virtual pad or the container — PCSX2 in the same container on the same pad handles gamepad-triggered save states without issue. ### Recovery Ending the session is the only way out. I exit Wolf from the Steam UI, log back in, and end the Pegasus session from there. Re-entering Pegasus immediately after that returns "Lobby full", and the Wolf log shows `mknod: File exists`. It clears after a while / a Wolf restart. ### Logs Captured a full reproduction with `WOLF_LOG_LEVEL=DEBUG` and `RUST_LOG=DEBUG` (22,760 lines). Nothing is logged at the moment input stops. The last line matching `input|pad|joypad|evdev|uinput|inputtino|error|warn` is the session-start device creation at 21:35:20: 21:35:20.071 DEBUG | [DOCKER] Executing command: mkdir -p /dev/input && mknod /dev/input/event20 c 13 84 && chmod 777 /dev/input/event20 && fake-udev ... 21:35:20.103 DEBUG | [DOCKER] Executing command: mkdir -p /dev/input && mknod /dev/input/js0 c 13 0 && chmod 777 /dev/input/js0 && fake-udev ... Every one of the ~19,000 lines after that is the same per-frame message: DEBUG waylanddisplaycore::utils::allocator: Failed to convert fourcc to video format: DrmFourcc(AR24) Nothing else is emitted through the game running, the hotkey press, or input dying. Happy to attach the full log or grep it for anything specific. Also visible at session start, on every launch (not specific to this bug, but it shows how the pad is handled): the Wolf-UI session's pad is torn down with `ACTION=remove` plus `rm /dev/input/event20` and `rm /dev/input/js0`, then recreated ~150ms later with the same minor numbers (13:84 and 13:0) and the same `DEVPATH=/devices/virtual/input/input93`. Incidental: that fourcc message is logged once per frame at DEBUG, which makes DEBUG-level capture fairly unwieldy — may be worth demoting to trace. ### Note on version I'm pinned to this older build because the newer one's embedded PulseAudio exits repeatedly on my host and Wolf then blocks waiting for the socket — so my audio path is the older sidecar PulseAudio container. Happy to retest on latest if that's likely to be relevant here.