WIP: feat(input): share Keyboard Auto/On/Off policy with menu navigation #152

Draft
omgitsgela wants to merge 1 commit from omgitsgela/Longshot:restore-keyboard-policy-longshot into main
First-time contributor

Why

Steam Input's Desktop layout can deliver keyboard events alongside native controller input, so walking moves the camera or a controller action also reaches a menu as Escape/Enter. This reconstructs https://github.com/NotRexed/Hookshot/pull/2530 with the unpublished shared menu/gameplay policy rather than restoring its gameplay-only gap.

What changed

  • Controls Keyboard row: Auto, On, Off, persisted in keyboard.
  • host/nn_hid.c: Auto rejects keyboard bindings while a controller is connected, even idle; On enables mixed input, Off suppresses keys. Mouse buttons remain independent.
  • gpu/vk/vk_menu.cpp: apply the shared policy to queued/polled menu navigation and held-key repeats. Drain queued events and retain edge tracking while suppressed; preserve F1 and the enabled Insert shortcut.
  • gpu/vk/vk_api.h and host/rx_backend.c: register the shared host callback; bump interface 21 to 22; allocate option 54, avoiding reserved Walk IDs and frame-rate cap 53.
  • Add production-policy/menu-poll regressions, callback/repeat wiring guards and documentation. Update source-extracted fixtures without weakening them.

Flags and settings

Setting What it does Default now Recommendation Helps on Doesn't help on Untested on
Controls Keyboard / keyboard=0,1,2 Auto accepts keyboard bindings and menu navigation only without a connected controller; On/Off force acceptance Auto Keep WIP until this exact port is hardware-tested Historical Steam Deck direct Desktop launch with Steam keyboard translation GPU performance; use On for a physical keyboard alongside a connected controller Exact latest-main runtime; Windows

No environment switch added. README option table and docs/development.md are updated.

Measurements

main: 39647e1a71e5ceabf3ed8fd60dbfe494f63bb3fe
this PR: restore-keyboard-policy-longshot @ ad5fdacf17737abee0c407934ab62189d8785d37
Method: Linux game-free production-function extraction, compiled policy/menu tests and full-source suite. No FPS claim.

Check main @ 39647e1a this PR @ ad5fdacf
Keyboard option regression No Keyboard row 10 policy cases pass
Menu intake after gameplay gating Auto with controller accepts injected Escape Polled and queued menu paths obey policy; explicit shortcuts remain
Full suite 455 passed, 1 failed, 82 skipped 457 passed, 1 failed, 82 skipped

The common full-suite failure is test_bake_portability.py: local interpreter lacks zstandard. Optional-tool skips are not passes. Latest selected input/menu run: 31 passed, 0 failed, 0 skipped. Two initial test-path references were corrected for Longshot naming before the final full run.

Testing

Tested: Original feature plus shared-menu follow-up on an older matched Hookshot build, Steam Deck VanGogh/RADV, SteamOS 3.8.28: the user confirmed controls/menu actions worked. This is historical validation of the design, not an exact-head Longshot runtime test. Current tests compile the real keyboard policy and menu poll with isolated device/window adapters, test queued-event draining, idle-pad suppression, explicit menu access, callback registration and suppressed-repeat wiring. Inline diff/security review and whitespace check completed.

Not tested: This exact Longshot head has not been built or run in the game; no current-build menu screenshot; no native Windows build/runtime. No latest-head hardware acceptance is claimed.

Needs other testers:

  • Exact-head matched host/renderer on Steam Deck: direct Desktop and Steam/Game Mode, all keyboard modes, connect/disconnect, idle connected pad, held/queued keys and mouse buttons (request to open after authenticated publication).
  • Windows/XInput mixed physical keyboard/controller validation (request to open after authenticated publication).

Screenshots

Pending current-build screenshot of the new menu row. No screenshot from an older revision is labeled as this PR. Remains WIP.

Risk and rollback

Auto deliberately suppresses physical keyboard gameplay/menu bindings while a controller is connected: select Keyboard On for mixed input. Revert the commit to remove the feature. The host/renderer interface changes and must be built as a matched pair; header/shader stamps can invalidate translated programs, so budget visible first-launch preparation. Nothing has been installed on the user's game by preparing this PR.

Reviewer notes

Look first at the common keyboard policy, queued event draining and held-arrow repeat gate. This includes the menu follow-up missing from the original PR. Cross-contribution: https://github.com/NotRexed/Hookshot/pull/3050 . Original closed PR: https://github.com/NotRexed/Hookshot/pull/2530 . No deleted Steam Deck fork is recreated.

Issues

See the two fully linked GitHub PRs above; no Longshot issue is claimed closed.

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main (frozen fetched revision 39647e1a).
  • python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
  • Tested in the game, or what wasn't is named under Testing.
  • Testing filled in: what was tested, what wasn't, and what needs other testers (with pending requests explicitly named).
  • Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. Exact-head game validation pending; stays WIP.
  • No game files, dumps, build output or generated files.
  • third_party/ untouched (a new folder with a PROVENANCE.md instead).
  • The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. Own prior contribution and direct adaptations of repository source only.

If applicable

  • AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
  • Flags noted, and the switch reference updated (docs/development.md, the README).
  • Screenshots for a change that shows on screen. Exact-head screenshot pending.
  • MKWVK_API_VERSION bumped (gpu/vk/vk_api.h's MkwVkHost or MkwVkRenderer changed).
  • A game-free test added for the fix, failing on main and passing here.
  • A check under tests/ that reads changed source updated in this PR, not weakened.
  • Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Native full builds pending; extracted-path tests pass on Linux.
  • Docs updated.
## Why Steam Input's Desktop layout can deliver keyboard events alongside native controller input, so walking moves the camera or a controller action also reaches a menu as Escape/Enter. This reconstructs https://github.com/NotRexed/Hookshot/pull/2530 with the unpublished shared menu/gameplay policy rather than restoring its gameplay-only gap. ## What changed - Controls Keyboard row: Auto, On, Off, persisted in `keyboard`. - `host/nn_hid.c`: Auto rejects keyboard bindings while a controller is connected, even idle; On enables mixed input, Off suppresses keys. Mouse buttons remain independent. - `gpu/vk/vk_menu.cpp`: apply the shared policy to queued/polled menu navigation and held-key repeats. Drain queued events and retain edge tracking while suppressed; preserve F1 and the enabled Insert shortcut. - `gpu/vk/vk_api.h` and `host/rx_backend.c`: register the shared host callback; bump interface 21 to 22; allocate option 54, avoiding reserved Walk IDs and frame-rate cap 53. - Add production-policy/menu-poll regressions, callback/repeat wiring guards and documentation. Update source-extracted fixtures without weakening them. ## Flags and settings | Setting | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | Controls Keyboard / `keyboard=0,1,2` | Auto accepts keyboard bindings and menu navigation only without a connected controller; On/Off force acceptance | Auto | Keep WIP until this exact port is hardware-tested | Historical Steam Deck direct Desktop launch with Steam keyboard translation | GPU performance; use On for a physical keyboard alongside a connected controller | Exact latest-main runtime; Windows | No environment switch added. README option table and docs/development.md are updated. ## Measurements main: `39647e1a71e5ceabf3ed8fd60dbfe494f63bb3fe` this PR: `restore-keyboard-policy-longshot @ ad5fdacf17737abee0c407934ab62189d8785d37` Method: Linux game-free production-function extraction, compiled policy/menu tests and full-source suite. No FPS claim. | Check | main @ 39647e1a | this PR @ ad5fdacf | |---|---|---| | Keyboard option regression | No Keyboard row | 10 policy cases pass | | Menu intake after gameplay gating | Auto with controller accepts injected Escape | Polled and queued menu paths obey policy; explicit shortcuts remain | | Full suite | 455 passed, 1 failed, 82 skipped | 457 passed, 1 failed, 82 skipped | The common full-suite failure is `test_bake_portability.py`: local interpreter lacks `zstandard`. Optional-tool skips are not passes. Latest selected input/menu run: 31 passed, 0 failed, 0 skipped. Two initial test-path references were corrected for Longshot naming before the final full run. ## Testing **Tested:** Original feature plus shared-menu follow-up on an older matched Hookshot build, Steam Deck VanGogh/RADV, SteamOS 3.8.28: the user confirmed controls/menu actions worked. This is historical validation of the design, not an exact-head Longshot runtime test. Current tests compile the real keyboard policy and menu poll with isolated device/window adapters, test queued-event draining, idle-pad suppression, explicit menu access, callback registration and suppressed-repeat wiring. Inline diff/security review and whitespace check completed. **Not tested:** This exact Longshot head has not been built or run in the game; no current-build menu screenshot; no native Windows build/runtime. No latest-head hardware acceptance is claimed. **Needs other testers:** - Exact-head matched host/renderer on Steam Deck: direct Desktop and Steam/Game Mode, all keyboard modes, connect/disconnect, idle connected pad, held/queued keys and mouse buttons (request to open after authenticated publication). - Windows/XInput mixed physical keyboard/controller validation (request to open after authenticated publication). ## Screenshots Pending current-build screenshot of the new menu row. No screenshot from an older revision is labeled as this PR. Remains WIP. ## Risk and rollback Auto deliberately suppresses physical keyboard gameplay/menu bindings while a controller is connected: select Keyboard On for mixed input. Revert the commit to remove the feature. The host/renderer interface changes and must be built as a matched pair; header/shader stamps can invalidate translated programs, so budget visible first-launch preparation. Nothing has been installed on the user's game by preparing this PR. ## Reviewer notes Look first at the common keyboard policy, queued event draining and held-arrow repeat gate. This includes the menu follow-up missing from the original PR. Cross-contribution: https://github.com/NotRexed/Hookshot/pull/3050 . Original closed PR: https://github.com/NotRexed/Hookshot/pull/2530 . No deleted Steam Deck fork is recreated. ## Issues See the two fully linked GitHub PRs above; no Longshot issue is claimed closed. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main` (frozen fetched revision 39647e1a). - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with pending requests explicitly named). - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. Exact-head game validation pending; stays WIP. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. Own prior contribution and direct adaptations of repository source only. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] Flags noted, and the switch reference updated (docs/development.md, the README). - [ ] Screenshots for a change that shows on screen. Exact-head screenshot pending. - [x] `MKWVK_API_VERSION` bumped (`gpu/vk/vk_api.h`'s `MkwVkHost` or `MkwVkRenderer` changed). - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Native full builds pending; extracted-path tests pass on Linux. - [x] Docs updated.
feat(input): share Keyboard Auto/On/Off policy with menu navigation
Some checks are pending
CI / Conventional Commit title (pull_request) Blocked by required conditions
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions
CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions
Third-party parts / As their notes say (pull_request) Blocked by required conditions
Third-party parts / The same as upstream (pull_request) Blocked by required conditions
PR description / Description follows the template (pull_request_target) Successful in 4s
Website / Website on Cloudflare (pull_request_target) Has been skipped
ad5fdacf17
Reconstruct https://github.com/NotRexed/Hookshot/pull/2530 with the locally validated menu-intake follow-up. Preserve explicit F1/Insert access, mouse bindings and queued event draining. Reserve option 54 and bump renderer interface 21 to 22.

Assisted-by: OpenAI GPT-6.1 via Hermes Agent
HumanBean added this to the v3.0.0 milestone 2026-11-13 17:51:44 +00:00
HumanBean left a comment

Thanks for porting https://github.com/NotRexed/Hookshot/pull/2530 together with its menu follow-up. The plumbing is careful:

  • Queued presses (take_key_press) are still drained, and held[] is still tracked while the policy suppresses a key. A press made while the keyboard was off can't fire later, and on Linux re-enabling the keyboard creates no false edge.
  • Mouse buttons stay independent in key().
  • F1 and Insert stay as ways out.
  • keyboard_counts is added at the end of MkwVkHost with the version bump, and the option persists as keyboard= through ini_key.

The new tests compile the real keyboard_counts/key() and the menu poll, not copies. Gameplay keys are polled level by level, so changing the policy can't leave a key stuck down.

I reviewed the code only. I didn't build it or run any checks.

Must change

  1. Auto takes the keyboard away from every player who has a controller connected. It decides by pad_count_now == 0 (host/nn_hid.c keyboard_counts), and the menu now uses the same rule. This is the default, so a desktop player with an Xbox or DualSense controller plugged in (including one that is idle or only charging) loses:

    • the keyboard in play;
    • Esc opening and closing the menu (the default Menu shortcut, "Insert, F1 or Esc");
    • the arrow keys, Enter, Q/E/Tab, Page Up/Down and Home/End in the menu.

    F1 and Insert still open the menu, but then the keyboard can't move through it. Nothing on screen or in the log says why the keys stopped working. The same happens on a docked Steam Deck in Game Mode with a USB keyboard, where Steam's gamepad template sends no key presses at all. A real keyboard alongside a controller has to keep working by default. Some options:

    • Make Auto detect injected keys, not the presence of a pad. On Windows, Raw Input reports hDevice == NULL for SendInput-injected keys, which is how Steam's Desktop layout sends them. On Linux, Steam's keys come from its own uinput keyboard, which SDL can name.
    • Make Auto apply only where the problem exists: a Valve controller (VID 0x28DE) or a Steam Deck (SteamDeck=1) running outside Steam's game launch.
    • Keep the default at On and leave Auto as an opt-in.

    Whichever you choose, log once when Auto first drops a key, so bug reports show it.

  2. "Rebased on current main" is ticked but no longer true. The PR is based on 39647e1a, and main has 40 commits since. It now conflicts in gpu/vk/vk_menu.cpp (the Controls rows) and README.md (the option table) with "Mouse camera Off" (#178), which changed the Mouse camera row to 0, 2 / "As the stick, Native, Off". Please rebase, keep its row, and update the box.

Should change

  1. The window code still acts on Esc when the policy suppresses it. host/display.c (WM_KEYDOWN) and host/posix/display_sdl.c (scancode 41) still release the mouse capture on every Esc and set esc_had_capture, because Esc "may open the Insert menu". With Auto and a controller connected, the menu now doesn't open, so the capture is lost and nothing gives it back. This affects both a keyboard player with an idle pad and a Deck in Desktop layout, where the Menu button sends Esc. Either gate that Esc on the same policy, or don't suppress Esc's opening of the menu.

  2. Keyboard Off leaves a player with no mouse unable to recover. F1 or Insert opens the menu, but the arrows and Enter do nothing, so only a mouse or a pad can set the row back to On. Consider still counting the menu's navigation keys while no controller is connected, even in Off.

  3. Coordinate the numbering with the open input PRs. Option id 54 is also taken by #137 (HOS_OPT_HOLD_TOGGLE) and #196 (HOS_OPT_SPRINT). MKWVK_API_VERSION 22 is also taken by #196 and #51. Whichever merges second has to renumber. #51's text fields read typed keys through its own take_text, which this policy doesn't gate. That is right for typing, but in Auto with a controller, the keyboard's Enter can no longer start editing a field (that needs press[7]). Please say which way that should go.

  4. Smaller points:

    • The row's hint has no translations; the "Keyboard" title already has them.
    • The option comment in vk_api.h that lists the option ids doesn't mention 54.
    • docs/development.md puts the new paragraph above the section's existing intro, followed by two blank lines.

Evidence

As the description says, this head hasn't been built or run. Steam Input has not been tried on this code:

  • The Steam Deck run was on an older Hookshot build.
  • There is no Windows run or build.
  • There is no screenshot.

Before it leaves WIP, it needs an exact-head run on a Deck, in Desktop Mode launched outside Steam and in Game Mode. It also needs a Windows run with a real keyboard and a controller connected, covering hot-plugging a controller while the menu is open and an idle connected pad.

Thanks for porting https://github.com/NotRexed/Hookshot/pull/2530 together with its menu follow-up. The plumbing is careful: - Queued presses (`take_key_press`) are still drained, and `held[]` is still tracked while the policy suppresses a key. A press made while the keyboard was off can't fire later, and on Linux re-enabling the keyboard creates no false edge. - Mouse buttons stay independent in `key()`. - F1 and Insert stay as ways out. - `keyboard_counts` is added at the end of `MkwVkHost` with the version bump, and the option persists as `keyboard=` through `ini_key`. The new tests compile the real `keyboard_counts`/`key()` and the menu poll, not copies. Gameplay keys are polled level by level, so changing the policy can't leave a key stuck down. I reviewed the code only. I didn't build it or run any checks. ### Must change 1. **Auto takes the keyboard away from every player who has a controller connected.** It decides by `pad_count_now == 0` (`host/nn_hid.c` `keyboard_counts`), and the menu now uses the same rule. This is the default, so a desktop player with an Xbox or DualSense controller plugged in (including one that is idle or only charging) loses: - the keyboard in play; - Esc opening and closing the menu (the default Menu shortcut, "Insert, F1 or Esc"); - the arrow keys, Enter, Q/E/Tab, Page Up/Down and Home/End in the menu. F1 and Insert still open the menu, but then the keyboard can't move through it. Nothing on screen or in the log says why the keys stopped working. The same happens on a docked Steam Deck in Game Mode with a USB keyboard, where Steam's gamepad template sends no key presses at all. A real keyboard alongside a controller has to keep working by default. Some options: - Make Auto detect injected keys, not the presence of a pad. On Windows, Raw Input reports `hDevice == NULL` for `SendInput`-injected keys, which is how Steam's Desktop layout sends them. On Linux, Steam's keys come from its own uinput keyboard, which SDL can name. - Make Auto apply only where the problem exists: a Valve controller (VID 0x28DE) or a Steam Deck (`SteamDeck=1`) running outside Steam's game launch. - Keep the default at On and leave Auto as an opt-in. Whichever you choose, log once when Auto first drops a key, so bug reports show it. 2. **"Rebased on current main" is ticked but no longer true.** The PR is based on 39647e1a, and main has 40 commits since. It now conflicts in `gpu/vk/vk_menu.cpp` (the Controls rows) and `README.md` (the option table) with "Mouse camera Off" (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/178), which changed the Mouse camera row to `0, 2` / "As the stick, Native, Off". Please rebase, keep its row, and update the box. ### Should change 3. **The window code still acts on Esc when the policy suppresses it.** `host/display.c` (WM_KEYDOWN) and `host/posix/display_sdl.c` (scancode 41) still release the mouse capture on every Esc and set `esc_had_capture`, because Esc "may open the Insert menu". With Auto and a controller connected, the menu now doesn't open, so the capture is lost and nothing gives it back. This affects both a keyboard player with an idle pad and a Deck in Desktop layout, where the Menu button sends Esc. Either gate that Esc on the same policy, or don't suppress Esc's opening of the menu. 4. **Keyboard Off leaves a player with no mouse unable to recover.** F1 or Insert opens the menu, but the arrows and Enter do nothing, so only a mouse or a pad can set the row back to On. Consider still counting the menu's navigation keys while no controller is connected, even in Off. 5. **Coordinate the numbering with the open input PRs.** Option id 54 is also taken by https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/137 (`HOS_OPT_HOLD_TOGGLE`) and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/196 (`HOS_OPT_SPRINT`). `MKWVK_API_VERSION 22` is also taken by https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/196 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/51. Whichever merges second has to renumber. https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/51's text fields read typed keys through its own `take_text`, which this policy doesn't gate. That is right for typing, but in Auto with a controller, the keyboard's Enter can no longer start editing a field (that needs `press[7]`). Please say which way that should go. 6. **Smaller points:** - The row's hint has no translations; the "Keyboard" title already has them. - The `option` comment in `vk_api.h` that lists the option ids doesn't mention 54. - `docs/development.md` puts the new paragraph above the section's existing intro, followed by two blank lines. ### Evidence As the description says, this head hasn't been built or run. Steam Input has not been tried on this code: - The Steam Deck run was on an older Hookshot build. - There is no Windows run or build. - There is no screenshot. Before it leaves WIP, it needs an exact-head run on a Deck, in Desktop Mode launched outside Steam and in Game Mode. It also needs a Windows run with a real keyboard and a controller connected, covering hot-plugging a controller while the menu is open and an idle connected pad.
@ -48,2 +48,4 @@
/* 49 and 50 are reserved for Walk mode and Walk speed (#2345). */
enum { HOS_OPT_FOV = 51 };
/* Controls Keyboard: 0 Auto (no controller connected), 1 On, 2 Off. */
enum { HOS_OPT_KEYBOARD = 54 };
Owner

Id 54 is also HOS_OPT_HOLD_TOGGLE in #137 and HOS_OPT_SPRINT in #196, and API version 22 is also used by #196 and #51. Whichever merges second has to renumber. It may be worth agreeing on the numbers in the team chat now.

Id 54 is also `HOS_OPT_HOLD_TOGGLE` in https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/137 and `HOS_OPT_SPRINT` in https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/196, and API version 22 is also used by https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/196 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/51. Whichever merges second has to renumber. It may be worth agreeing on the numbers in the team chat now.
@ -1297,2 +1300,4 @@
// Controls (13 rows; Motion opens the 6 TAB_MOTION rows, Controls its page with the 2 TAB_PAGE rows)
{TAB_CONTROLS, "Controller in background", &opts.pad_background, 0, 1, 1, tx_onoff,
"Whether the controller plays the game while another window has the focus.", hn_background, false, true},
{TAB_CONTROLS, "Keyboard", &opts.keyboard, 0, 2, 1, tx_keyboard,
Owner

This conflicts with main: #178 changed the next row to &opts.mouse_native, 0, 2, 1 (Mouse camera Off), and README.md's table conflicts the same way. "Rebased on current main" is ticked against 39647e1a, 40 commits behind. Please rebase and keep its row.

This conflicts with main: https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/178 changed the next row to `&opts.mouse_native, 0, 2, 1` (Mouse camera Off), and README.md's table conflicts the same way. "Rebased on current main" is ticked against 39647e1a, 40 commits behind. Please rebase and keep its row.
@ -4705,0 +4713,4 @@
// Drain queued events and track key edges even when the keyboard policy suppresses them.
const bool emergency = keys[i] == VK_INSERT || keys[i] == VK_F1;
const bool enabled = (keys[i] != VK_INSERT || opts.menu_shortcut != 1) &&
(emergency || !host || !host->keyboard_counts || host->keyboard_counts(keys[i]));
Owner

With Auto and a controller connected, this suppresses Esc, so Esc no longer opens the menu (the default "Insert, F1 or Esc" shortcut). But host/display.c WM_KEYDOWN and host/posix/display_sdl.c (scancode 41) still release the mouse capture on every Esc, expecting the menu to open and take the capture back. Now the capture is lost and the menu doesn't open. The window code's Esc handling needs the same policy.

With Auto and a controller connected, this suppresses Esc, so Esc no longer opens the menu (the default "Insert, F1 or Esc" shortcut). But `host/display.c` WM_KEYDOWN and `host/posix/display_sdl.c` (scancode 41) still release the mouse capture on every Esc, expecting the menu to open and take the capture back. Now the capture is lost and the menu doesn't open. The window code's Esc handling needs the same policy.
@ -54,0 +61,4 @@
static int keyboard_counts(int vk) {
if (vk >= 0x01 && vk <= 0x06 && vk != 0x03) return 1; /* (VK_LBUTTON to VK_XBUTTON2 but VK_CANCEL: the mouse's buttons) */
const int mode = rx_option(HOS_OPT_KEYBOARD, 0);
return mode == 1 ? 1 : mode == 2 ? 0 : pad_count_now == 0;
Owner

This is Auto's whole test: any connected controller, idle or only charging, turns off the keyboard in play and (through hos_keyboard_counts) in the Insert menu. A desktop player who has a pad plugged in loses WASD, Esc-to-open and the menu's arrow keys/Enter by default, and nothing tells them why. Could Auto detect injected keys instead (on Windows, Raw Input's hDevice == NULL for SendInput; on Linux, Steam's uinput keyboard), or apply only for a Valve/Steam Deck controller? Either way, log once when it first drops a key.

This is Auto's whole test: any connected controller, idle or only charging, turns off the keyboard in play and (through `hos_keyboard_counts`) in the Insert menu. A desktop player who has a pad plugged in loses WASD, Esc-to-open and the menu's arrow keys/Enter by default, and nothing tells them why. Could Auto detect injected keys instead (on Windows, Raw Input's `hDevice == NULL` for `SendInput`; on Linux, Steam's uinput keyboard), or apply only for a Valve/Steam Deck controller? Either way, log once when it first drops a key.
Some checks are pending
CI / Conventional Commit title (pull_request) Blocked by required conditions
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions
CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions
Third-party parts / As their notes say (pull_request) Blocked by required conditions
Third-party parts / The same as upstream (pull_request) Blocked by required conditions
PR description / Description follows the template (pull_request_target) Successful in 4s
Website / Website on Cloudflare (pull_request_target) Has been skipped
This pull request has changes conflicting with the target branch.
  • README.md
  • gpu/vk/vk_menu.cpp
Some workflows are waiting to be reviewed.
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u 'restore-keyboard-policy-longshot:omgitsgela-restore-keyboard-policy-longshot'
git switch 'omgitsgela-restore-keyboard-policy-longshot'
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Longshot!152
No description provided.