Controllers behind other windows: a menu row and HOS_INPUT_BACKGROUND #359

Merged

hckrman101 merged 1 commit from input-background into main

2026-11-07 23:46:13 +00:00

hckrman101 commented

2026-11-07 22:17:07 +00:00

(Migrated from github.com)

The pads only count while the game's window is in front (game_in_front() in host/nn_hid.c). That breaks streaming: with Sunshine putting the game on a screen of its own and Moonlight on a TV, the controller stops working as soon as anything on the desktop takes the focus. The same happens with the game left running behind another window.

This adds an opt-in:

Insert menu: a "Controller in background" row (Off by default), saved in hookshot_options.ini like the others. The host reads it through the renderer's existing option() callback as id 4.
HOS_INPUT_BACKGROUND=1 / =0: overrides the menu, for scripts and launchers.
Only the pads are read behind other windows. The keyboard and mouse still need the window in front, so typing elsewhere never reaches the game. SDL already reads pads in the background (SDL_JOYSTICK_ALLOW_BACKGROUND_EVENTS), so nothing changes there.

tests/test_input_background.py compiles the decision on its own and checks the menu row and the option wiring (python -I -B tests/test_input_background.py). It isn't in .github/workflows/source-regressions.yml yet: this account can't push workflow changes, so it would need a step there next to "Check controller rumble keeps going" (Linux, needs gcc), with host/nn_hid.c and the test added to the path filters.

Tested on Linux (Sway, Sunshine to Moonlight): with the row On and another window focused, a Switch Pro Controller keeps playing; the log still notes hid: input paused: the game window is not in front for the keyboard. With it Off, behaviour is unchanged.

The pads only count while the game's window is in front (`game_in_front()` in `host/nn_hid.c`). That breaks streaming: with Sunshine putting the game on a screen of its own and Moonlight on a TV, the controller stops working as soon as anything on the desktop takes the focus. The same happens with the game left running behind another window. This adds an opt-in: - **Insert menu:** a "Controller in background" row (Off by default), saved in `hookshot_options.ini` like the others. The host reads it through the renderer's existing `option()` callback as id 4. - **`HOS_INPUT_BACKGROUND=1` / `=0`:** overrides the menu, for scripts and launchers. - **Only the pads** are read behind other windows. The keyboard and mouse still need the window in front, so typing elsewhere never reaches the game. SDL already reads pads in the background (`SDL_JOYSTICK_ALLOW_BACKGROUND_EVENTS`), so nothing changes there. `tests/test_input_background.py` compiles the decision on its own and checks the menu row and the option wiring (`python -I -B tests/test_input_background.py`). It isn't in `.github/workflows/source-regressions.yml` yet: this account can't push workflow changes, so it would need a step there next to "Check controller rumble keeps going" (Linux, needs gcc), with `host/nn_hid.c` and the test added to the path filters. Tested on Linux (Sway, Sunshine to Moonlight): with the row On and another window focused, a Switch Pro Controller keeps playing; the log still notes `hid: input paused: the game window is not in front` for the keyboard. With it Off, behaviour is unchanged.

Commenting is not possible because the repository is archived.

No reviewers