WIP: feat(input): share Keyboard Auto/On/Off policy with menu navigation #152
No reviewers
Labels
No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Longshot!152
Loading…
Reference in a new issue
No description provided.
Delete branch "omgitsgela/Longshot:restore-keyboard-policy-longshot"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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.handhost/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.Flags and settings
keyboard=0,1,2No environment switch added. README option table and docs/development.md are updated.
Measurements
main:
39647e1a71e5ceabf3ed8fd60dbfe494f63bb3fethis PR:
restore-keyboard-policy-longshot @ ad5fdacf17737abee0c407934ab62189d8785d37Method: Linux game-free production-function extraction, compiled policy/menu tests and full-source suite. No FPS claim.
39647e1aad5fdacfThe common full-suite failure is
test_bake_portability.py: local interpreter lackszstandard. 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:
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
type(scope): description).main(frozen fetched revision39647e1a).python -I -B tests/run_all.pyrun and passing (any failure that also fails onmainis named above).third_party/untouched (a new folder with aPROVENANCE.mdinstead).If applicable
Assisted-by:/Co-Authored-By:trailers.MKWVK_API_VERSIONbumped (gpu/vk/vk_api.h'sMkwVkHostorMkwVkRendererchanged).mainand passing here.tests/that reads changed source updated in this PR, not weakened.Thanks for porting https://github.com/NotRexed/Hookshot/pull/2530 together with its menu follow-up. The plumbing is careful:
take_key_press) are still drained, andheld[]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.key().keyboard_countsis added at the end ofMkwVkHostwith the version bump, and the option persists askeyboard=throughini_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
Auto takes the keyboard away from every player who has a controller connected. It decides by
pad_count_now == 0(host/nn_hid.ckeyboard_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: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:
hDevice == NULLforSendInput-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.SteamDeck=1) running outside Steam's game launch.Whichever you choose, log once when Auto first drops a key, so bug reports show it.
"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 ingpu/vk/vk_menu.cpp(the Controls rows) andREADME.md(the option table) with "Mouse camera Off" (#178), which changed the Mouse camera row to0, 2/ "As the stick, Native, Off". Please rebase, keep its row, and update the box.Should change
The window code still acts on Esc when the policy suppresses it.
host/display.c(WM_KEYDOWN) andhost/posix/display_sdl.c(scancode 41) still release the mouse capture on every Esc and setesc_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.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.
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 22is also taken by #196 and #51. Whichever merges second has to renumber. #51's text fields read typed keys through its owntake_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 needspress[7]). Please say which way that should go.Smaller points:
optioncomment invk_api.hthat lists the option ids doesn't mention 54.docs/development.mdputs 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:
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 };Id 54 is also
HOS_OPT_HOLD_TOGGLEin #137 andHOS_OPT_SPRINTin #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.@ -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,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 against39647e1a, 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]));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.cWM_KEYDOWN andhost/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;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'shDevice == NULLforSendInput; 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.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.