[mooki000]

What this is for: keyboard players can walk. A Walk key (Caps Lock by default, held or toggled) makes the movement
keys tilt the stick part of the way, set by a new Walk speed row; today the keys only run. What is measured: on
Arch Linux with an RTX 4090 (NVIDIA 615.78.08), on main 49f75dc, in headless runs in Kokiri Forest: how fast Link
moves and whether he walks or runs at each share of the stick (1.03 m/s at 15%, 1.47 m/s at 45% to 50%, 4.50 m/s at
100%), which set the row's default (45%) and range (15% to 90%); the key path itself with keys held in the key table
by a test-only probe (Caps Lock with W or S: 1.47 m/s, without: 4.50 m/s), Hold and Toggle; the two menu rows and the
Controls page row in pictures; a new game-free test that fails on main. Not measured: Windows game runtime, a real keyboard
(the game ran headless), controllers (unchanged), first-person aiming while walking, places other than Kokiri Forest.

Closes #2344.

Problem

On the keyboard Link can only run: the movement keys push the stick all the way (host/nn_hid.c, * 32767), so a
player without a controller has no way to walk (narrow ledges, sneaking past guards, a slower pace on a path).

What changed

• A Walk control on the Controls page, keys only, after Camera right (HOS_KEY_WALK; ini key_walk). Its default
  key is Caps Lock, which no other control has and which sits beside A and Shift, so it can be held with WASD. It is
  rebound, cleared and reset like Move forward, takes a second key, and can be a mouse button (while the mouse is
  captured, as the other bindings).
• Walk mode (Controls tab, walk_mode): Hold (the default: Link walks while the key is held) or Toggle (one press
  walks, the next runs again). A press counts only while the keys are the game's: not while the Insert menu is open or
  the window is behind another one, and a key still held when they come back counts after its release.
• Walk speed (Controls tab, walk_speed): how far the movement keys tilt the stick while Link walks, 15% to 90% in
  steps of 5, default 45%. A diagonal is scaled by its length (W+A walks too). The numbers come from the measurement
  below: 15% is Link's slowest walk (10% is no slower), 45% the lowest share at his walk's top speed, and from 55% he
  speeds up into a jog; the rows above 55% are there for a player who wants a slower run.
• Nothing else is scaled: the camera keys, the mouse (both Mouse camera modes), controllers and scripted input
  (HOS_INPUT_SCRIPT, HOS_INPUT_LIVE) keep their tilt, and so does running (the diagonal included).
• An options file from before this change that gives Caps Lock to another control keeps it there alone: Walk then has
  no key until one is bound (hid: no Walk key: ... in the log).
• Log lines: hid: walking: the movement keys tilt the left stick to 45% (0, 14745) (the first tilt at each share) and
  hid: walking on / off (Walk mode Toggle).
• Option ids 52 and 53 (gpu/vk/vk_api.h), answered in vk_replay.cpp's option lambda; the host reads them live.
  Updated 2026-11-11 after review: the scripted survey checked all 134 open PRs, fetched the 13 heads that change
  vk_api.h, and found neither ID in main nor those heads. The refreshed inventory now puts feat(camera): add adjustable gameplay field of view #2357's FOV 51 on main;
  feat(input): a Keyboard row: Auto, On or Off #2530 uses 49 for Keyboard and feat: an optional item wheel for the R/L item row, Twilight Princess style #2261 uses 60 for Item wheel. Saved walk_mode/walk_speed keys are unchanged.
• Docs: the readme's menu table and notes, its Controls section and the ini's key names; the options file table in
  docs/development.md.
• Tests: tests/test_walk_key.py (new) compiles read_input, the binding table and the walk helpers from
  host/nn_hid.c against fake keys, window, pad, mouse and options files. All original source-text wiring/doc
  checks are restored, updated to 52/53. The compiled fixture includes the actual header and statically checks both
  allocations; its behavior checks exercise the host's reads using those constants.
  tests/test_bound_keys.py (its prelude needs VK_CAPITAL) and tests/test_input_background.py (cuts the new
  helpers read_input calls) are updated. All four unrelated background wiring checks are restored verbatim;
  no check from main is removed. The merged tests/test_option_ids.py keeps all five negative cases and every
  assertion, with its two Walk collision values and reservations updated from 49/50 to 52/53.

How it was tested

Checks.

Latest refresh, 2026-11-11: head 5ab213a6 on 8fcc8c22. After #2357 merged, I rebased again and kept both FOV and
Walk formatters. The feature remains the first commit; review repairs are folded into the second. All four background
wiring checks and the original Walk wiring/doc checks are restored, not removed. Main's two-slot pad-binding fixture
locks and its five option-ID collision cases are retained, with the Walk values updated. No new game run or Windows
run is claimed for this refresh; the older
Source-regression CI passed on 796b1bdf, not this new head.

• On 5ab213a6, test_walk_key.py, test_bound_keys.py and test_input_background.py pass with GCC 16.2.1 and
  Clang 23.1.3. The merged option-ID check passes with both: 43 unique IDs, all five collision variants rejected.
• A compiled variant with the final Walk tilt multiplied by zero fails at runtime with 26 CHECK failures with each
  compiler. Before the last rebase, the restored wiring guards and compiled fixture rejected 32 mutations per
  compiler on cb984dc3; wrong host mode/speed IDs caused five/six runtime CHECK failures respectively.
• The final-header control-socket scenario matches all 13 asserted stick/button states: the socket's tilt is
  preserved, exclusive input suppresses the keyboard, and Walk returns afterwards. This is a compiled input fixture,
  not a new game or real socket session.
• Full suites ran serially through hs-idle.sh, with the dependency Python and 32 checks at once. Load is the
  wrapper's before/after reading, not a quiet-machine performance measurement:

Tree	Passed	Failed	Skipped	Suite time	Wrapper load before → after
Walk 5ab213a6 on 8fcc8c22	446	3	20	601 s	186.12 → 181.69
Clean main 8fcc8c22	446	2	20	591 s	181.69 → 72.79

The raw failure sets differ. Both fail test_env_on.py at main's HOS_FPS_LOG use in host/oot_high_fps.c:15.
Walk also had a compiler killed by SIGKILL in test_depth_sample_types.py and a 600.1 s timeout in
test_recorder_sync.py; both passed on main (recorder took 590.8 s there). Main alone failed
test_appimage_package_retry.py on an extra enrollment/retry; it passed in Walk's full run. These test files and
the high-fps/appimage sources are unchanged by Walk. No raw full-suite parity is claimed.

The three differing checks were then run serially on 5ab213a6 through the same test gate:

Check	Walk full suite	Main full suite	Isolated rerun on Walk
test_depth_sample_types.py	Compiler SIGKILL	Pass	Pass, 8.2 s
test_recorder_sync.py	Timeout at 600.1 s	Pass, 590.8 s	Pass, 240.0 s
test_appimage_package_retry.py	Pass	Enrollment/retry assertion	Pass, 16.7 s

That serial run ended 3 passed, 0 failed, 0 skipped in 265 s, wrapper load 111.79 → 77.18. The original
failures remain recorded above; the common base failure is test_env_on.py, not changed by this PR.
The final core-dump check reported No coredumps found.

Added 2026-11-11: tests/test_walk_key.py passes in Windows part 1/2 on 37687e2f. That shard fails only on main’s ASTC scanf fixture, whose fix is #2397. This proves the compiled input check on Windows, not physical input or gameplay.

• Updated 2026-11-11: head 37687e2f on 7759a6f3, including test: test_vcore_fs_open and test_vcore_video_acquire build again with env_on #2380. test_walk_key.py, test_bound_keys.py and test_input_background.py pass with GCC and Clang. A throwaway variant that suppresses the Walk tilt fails the compiled behavioral checks with both compilers. The earlier test against main 49f75dc failed because the Walk helper was absent.
• Full suite on the earlier 37687e2f: 386 passed, 1 failed, 10 skipped in 144 s; only test_updater_asset_digest.py fails because this machine has no .NET 8 reference packs. The two vcore tests fixed by test: test_vcore_fs_open and test_vcore_video_acquire build again with env_on #2380 now pass. A compiled header check reports walk_mode=49 walk_speed=50 camera_speed=48.
• The control-socket scenario was rerun: its own stick tilt is preserved, exclusive socket input suppresses keyboard movement while active, and keyboard Walk returns afterwards. No new game run after this rebase/renumber.
• Earlier python -I -B tests/run_all.py on the original branch (Linux, clang 23): 363 passed, 2 failed, 10 skipped. The two fail on
  main on this machine as well and do not touch this change: test_updater_asset_digest.py (no .NET 8 reference
  packs installed) and test_wayland_libdecor_hint.py (clang 23's -Wunused-but-set-global under -Werror).

In the game: Arch Linux (kernel 7.2.15), i9-13900K, RTX 4090, NVIDIA 615.78.08, base main 49f75dc, head
78af2f7, 2026-11-11, headless runs (no window) with 1280x720 pictures, load average 2 to 4 for the speed and key
runs, my save in Kokiri Forest. The build was this branch plus a local probe that is not part of this pull request: it lets the input
script hold the left stick at a share of the way, logs Link's position and the forward speed the game sets on him every
250 ms together with the stick that GetNpadStates handed the game, and holds key codes in the key table that SDL's
keyboard fills on Linux, so the keyboard's own path (bound_down, walk_held, move_keys_stick) ran although no key
can reach a headless game. Speeds are medians of 9 or 10 readings per 2.6 s hold, forward and back, the first reading of
each hold (the turn) left out:

Left stick	Speed the game set (m/s)	Speed from his position (m/s)	Pose
10%	1.03	1.02	walk
15%	1.03	1.03	walk
20%	1.11	1.11	walk
30%	1.28	1.28 to 1.30	walk
40%	1.45	1.44	walk
45%	1.47	1.46 to 1.47	walk
50%	1.47	1.45 to 1.47	walk
55%	1.65	1.64	walk, faster
60%	1.85	1.84	arms start to bend
70%	2.37	2.34 to 2.35	jog
80%	2.97	2.94 to 2.96	run
100%	4.50	4.27 to 4.39	run

• Keys, Walk speed at 45%: W or S with Caps Lock gave the game the stick (0, ±14745), 45% of the way, and Link walked
  at 1.47 m/s; W or S alone gave (0, ±32767) and he ran at 4.50 m/s; W+A and S+D with Caps Lock gave (∓10426, ±10426),
  45% along the diagonal, and he walked at 1.47 m/s. The log showed hid: walking: the movement keys tilt the left stick to 45% (0, 14745).
• Toggle, set through the menu's keys: a Caps Lock press logged hid: walking on and W then walked (stick 14745,
  1.47 m/s), the next press hid: walking off and W ran (32767, 4.50 m/s), the next on again and S+D walked along the
  diagonal, the last off. The options file afterwards held walk_mode=1, walk_speed=45, key_walk=20,0 (Caps
  Lock, no second key).
• The table and the key holds were measured on this branch's first version, whose walking code is the same (only the
  row's lower bound has changed since); the Toggle run and the menu pictures were taken again on this version
  (78af2f7 plus the probe), while other work loaded the machine (load average 129 at its start; it gives log lines
  and pictures, no timing).

The runs, as the harness printed them (exit 124 is the run's own time limit; nvrm=1 is one
NVRM: memMap_IMPL: CPU mapping not supported line in the kernel log, which the game's start usually draws from
this driver and which is no fault):

hs-run walk-probe1 exit=124 wall=240.7s start=2026-11-11 02:14:41 shots=231 fatal/crash/devlost=0 kernel=0 nvrm=1 dev=vk:_device_0:_NVIDIA_GeForce_RTX_4090  load 2.38 3.12 3.96 -> 4.00 3.97 4.13
hs-run walk-menu1 exit=124 wall=200.7s start=2026-11-11 02:18:42 shots=385 fatal/crash/devlost=0 kernel=0 nvrm=1 dev=vk:_device_0:_NVIDIA_GeForce_RTX_4090  load 4.00 3.97 4.13 -> 4.48 4.11 4.14
hs-run walk-menu2 exit=124 wall=201.0s start=2026-11-11 09:00:54 shots=307 fatal/crash/devlost=0 kernel=0 nvrm=1 dev=vk:_device_0:_NVIDIA_GeForce_RTX_4090  load 129.26 74.03 42.96 -> 19.30 52.27 41.06

Run	Build	What it did	Result
walk-probe1	first version + probe	the stick at 10% to 100%, then the key holds	the speed table above; keys walk at 1.47 m/s, run at 4.50 m/s
walk-menu1	first version + probe	the menu's rows, then Toggle with keys	Toggle sequence as expected; the Controls page's list did not scroll in headless pictures, so no picture from it is used
walk-menu2	this version + probe	the same, the page's list scrolled by the probe	Toggle sequence as expected (below); the two menu pictures

The Toggle sequence of walk-menu2, from its log (the script that reads it asserts the order and the stick values):

walking on
hold stick      0, 14745 presents 6668-6813 lines 11 set 1.468 m/s
walking off
hold stick      0, 32767 presents 6943-7076 lines 10 set 4.500 m/s
walking on
hold stick  10426,-10426 presents 7201-7353 lines 11 set 1.469 m/s
walking off
OK: the sequence is as expected

Pictures (1280x720 headless shots, cropped to the game and to the menu's rows):

Left: S held with Caps Lock, Link walks towards the camera with his arms hanging. Right: S alone, he runs, leaning
forward with his arms pumping.

The two new rows sit between Motion and Controls. Panel 1: Walk mode selected with Toggle chosen (Hold is the
default) and its help text. Panel 2: Walk speed selected at 45% and its help text.

The new last row of the Controls page, after Camera right: Walk, no gamepad button, Caps Lock as its key.

Not tested

• Windows game runtime, and a real keyboard and mouse: the game here only runs headless, where no key reaches it. The keys were held
  in the game's key table by the test-only probe described above; the press itself (SDL's scancode 57 on Linux,
  VK_CAPITAL on Windows) was not exercised.
• Controllers: not run, and not changed (the walk scaling applies only to the movement keys' tilt).
• Caps Lock with a keyboard layout or a tool that remaps it; places other than Kokiri Forest's paths (slopes, water).

Risks

• First-person aiming with the movement keys while walking: the game may read the left stick to aim, which would then
  be slower by the same share. Aiming with the camera keys or the mouse is not changed. Not tried in the game.
• Caps Lock still switches capitals on and off in other programs at each press (said in the readme, with the advice to
  bind another key).
• vk_api.h is part of the shader caches' stamp (nx2/build.py 907-912), so, as with any change to that header, the
  first start of a build with this translates the shaders once more.
• MKWVK_API_VERSION stays at the base's 18; this change adds option/key identifiers, not host/renderer table entries. Build the host and renderer together; mixing binaries from different versions was not tested.
• Walk now uses 52/53, free in the open-head survey at 2026-11-11 22:34:34 UTC. The survey includes API-version bumps and the indexed achievement namespace starting at 8192 in feat: add local achievement tracking and toasts #2307. Future changes must still avoid reusing an assigned ID.

Overlaps

Updated 2026-11-11 after the FOV merge: 79 open PRs touch one of this branch's eleven files; six have additional
text conflicts (nine hunks). Each reported hunk was read; no combined game run was made.

• feat: add separate button mappings for the ocarina notes #1930 (ocarina bindings): keep both ordered control-name additions and both fixture helper sets; Walk stays keyboard-only.
• feat(enhancement): item assignable buttons, items on A, B, X and Y used with a shoulder hotkey #2151 (item buttons): keep both option-lambda additions and the controls documentation. Its numeric 12/13 IDs do not
  collide with Walk's 52/53; keep all input wiring checks.
• feat(input): support the Switch 2 Pro Controller over USB, with HD rumble #2252 (Switch 2 controller): preserve its documentation paragraph and the controls sentence that includes Walk.
• feat(paths): saves and settings in a per-user data folder, caches and logs in the game folder's cache/ and logs/ #2317 (data folder): keep its updated options-file location and the Walk control in the host comment.
• feat(audio): the microphone heard on audio interfaces, with a volume, a channel and a test on the Audio tab #2459 (microphone controls): keep both header additions; its gain/channel IDs 29/30 are separate from Walk's 52/53.
• feat(input): a Keyboard row: Auto, On or Off #2530 (Keyboard row): update the combined Controls-row count; its Keyboard ID 49 is separate from Walk's 52/53.
• feat(input): add a second gamepad binding in Controls #1990 (second pad binding), feat(menu): the Aspect ratio row (was Ultrawide), at the monitor's shape by default #2119 (Aspect ratio), feat(camera): add adjustable gameplay field of view #2357 (FOV), feat(prompts): a new face or new controls show while the game runs, no restart #2366 (live prompts) and feat: Save my pipeline list, the zip and filled-in report for the "Submit your pipelines" issue in one click #2447 (pipeline-list export)
  are now on the base. Their code and checks are retained; FOV's Walk collision cases now test 52/53.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

Assisted-by: GPT-6 Astra
Co-Authored-By: GPT-6 Astra noreply@openai.com

[mooki000]

Rebased onto main b744b1ec. It merged without a conflict, but its test would not have built there: the read_input that tests/test_walk_key.py cuts out of host/nn_hid.c now calls hos_control_input() (#926) and reads HOS_INPUT_EXCLUSIVE with env_on() (#2042). The test now gets gpu/vk/compat/hookshot_env.h with -include and stubs the control bridge as off, as tests/test_input_background.py does on main. The source lines of this pull request are unchanged.

With the control socket: its input keeps its own stick tilt, like scripted input, and an exclusive socket input keeps the keyboard out while it lasts, Walk included.

Rerun on the new head (8a14b300): the branch's three tests pass with gcc 16 and clang 23, and test_walk_key.py still fails against main's source. tests/run_all.py: 374 passed, 4 failed, 10 skipped. All four fail on main too on this machine; two of them are main's test_vcore_fs_open.py and test_vcore_video_acquire.py, which #2380 fixes, so expect those two red here until it is merged. The game runs in the description are from the old base (49f75dc8) and were not repeated.

[hckrman101]

Nice, well measured and the test is a good one (it fails on main, passes here). I read the code and found nothing wrong in it: walk_held resets properly while the keys are not the game's, the diagonal scaling is right, Caps Lock is VK_CAPITAL read with the 0x8000 bit on Windows and mapped to scancode 57 on Linux, and no other control uses it. The stick dead zone (option 11) is applied only to pads, so it does not touch the keyboard's tilt, and #2286 is merged and #1600 touches the pad path only, so I see no interaction with either. The menu rows are plain Row entries and I see nothing in the diff that the tests which cut code out of vk_menu.cpp would trip on (you updated test_bound_keys and test_input_background for the new prelude and helpers).

One real problem: option id 46 collides with #2366 (open, "a new face or new controls show while the game runs"), which defines HOS_OPT_PROMPTS = 46 in vk_api.h and answers it in the same option lambda. This one takes 46 and 47. On main, 45 and 48 (Camera speed) are now taken, so the free ids are 49 and up, except #2261 (60). Whichever of the two lands second has to renumber. Easiest is to move Walk to ids that nobody has claimed (49 and 50 are free as far as I can see, #1945's 48 is already on main) so this can merge independently.

CI: the Python source checks fail only on test_vcore_fs_open.py and test_vcore_video_acquire.py, which you noted fail on main and #2380 fixes; the appimage job died on an Ubuntu mirror 504 (infrastructure); Windows Vulkan back end build passes. Not for this PR to fix, but it will need a rerun once #2380 is in.

Minor, not blocking: the first-person aiming risk you list is real for keyboard players who aim with WASD, worth a line in the readme if you try it in game.

[hckrman101]

46 is also taken by #2366 (HOS_OPT_PROMPTS = 46). Please pick ids that are free, e.g. 49 and 50 (main has 45 and 48 now, #2261 has 60), and update the comment lines in vk_menu.h that name 46 and 47.

[mooki000]

Moved Walk mode/speed to 49/50 and updated both vk_menu.h comments in 37687e2f. The host and renderer use the same constants; a compiled header check reports walk_mode=49 walk_speed=50 camera_speed=48. Saved named keys are unchanged. #2366 can keep 46; its remaining overlaps are text conflicts, not shared IDs.

Also rebased onto 7759a6f3, including #2380. The three input checks pass with GCC and Clang. The full suite is 386 passed, 1 failed, 10 skipped; only the missing .NET 8 reference packs fail here. I removed the source-text wiring assertions rather than repinning the IDs; the compiled behavior check still rejects a variant with Walk tilt suppressed, with both compilers.

No new game run after this rebase/renumber; first-person aiming remains explicitly untested.

[mooki000]

tests/test_walk_key.py passes on Windows on 37687e2f. Windows part 1/2 fails only on tests/test_native_astc_texture_count.py (the known scanf CRT deprecation); #2397 contains that fix. The description now records this Windows game-free coverage. Physical keyboard input and Windows gameplay remain untested.

[pmwork-personal]

I think i prefer Alt as walk. its consistent with many other default control schemes in other implementations with walk keys.

[mooki000]

@pmwork-personal thanks. Walk is rebindable on the Controls page. This CI refresh keeps Caps Lock; the default choice can be settled separately. The readme already calls out its effect on capitals.

Rebased onto 47ed9f14, now 796b1bdf, including the merged #2397 repair and #2366 live prompts. The latter exposed a fixture bug: the test selected an earlier hos_bind declaration instead of its definition. The range search is fixed, and all three input checks pass with GCC and Clang. Walk still uses 49/50. No new gameplay, physical-input or first-person-aiming proof is claimed.

Update 2026-11-11: the refreshed source-regression workflow is green on 796b1bdf: both Windows and both Ubuntu shards pass. This is game-free CI evidence, not a new game run.

[Joey-Magnus]

The code is sound (Caps Lock is scancode 57, a conflicting old ini leaves Walk unbound with a log line, and no API bump is needed). Two things before merge:

1. tests/test_input_background.py drops four checks unrelated to this feature: the background block reads pads but not keyboard or mouse, t.option maps 4 to pad_background, and the "Controller in background" row exists. All four still pass on this branch, so they can simply go back in. AGENTS.md asks for checks to be updated, not removed.
2. Option ID collision: HOS_OPT_WALK_MODE = 49 matches #2357's HOS_OPT_FOV = 49. The two PRs touch different hunks, so git won't flag it. Your if (id == HOS_OPT_WALK_MODE) comes first, so the game would read Walk mode (0/1) as the FOV percentage, which oot_fov.c then rejects. Whichever lands second has to renumber; please coordinate with @polaco1782.

There's also an open question from a commenter about Alt instead of Caps Lock as the default.

[hckrman101]

This now conflicts with main in gpu/vk/vk_menu.cpp, host/nn_hid.c, readme.md. Could you merge main into the branch (or rebase) when you get a chance? I'll take another look once it's up to date.

[mooki000]

I fixed both points in 5ab213a6:

1. I restored all four background checks verbatim and every original Walk wiring/doc check. The background test only adds to main. After feat(camera): add adjustable gameplay field of view #2357 merged, I updated its two Walk collision cases and reservations to 52/53, keeping all five cases and every assertion.
2. I moved Walk mode/speed to 52/53 after scripting a survey of all 134 open PRs and fetching the 13 heads that changed vk_api.h. Neither ID was claimed; the refreshed table now puts FOV 51 on main and still finds 52/53 free. feat(input): a Keyboard row: Auto, On or Off #2530 claims 49 for Keyboard. The real header is compiled with the host's reads, and the renderer, menu comments and wiring checks agree.

The three input checks and the 43-ID guard pass with GCC and Clang; suppressed Walk tilt fails at runtime, and all 13 socket-fixture states pass. The updated description keeps both unequal raw suite results with their loads; the three differing depth/recorder/appimage checks all pass when run serially.

I kept Caps Lock for now: Walk is rebindable on the Controls page, and I can change the default if the maintainers prefer another key.

I rebased onto 8fcc8c22 after the FOV merge, keeping both formatters, main's two-slot pad bindings and its documentation additions. No new game run, physical-input or first-person-aiming proof is claimed.

[mooki000]

Rebased the pushed 5ab213a6 onto current main 87991bc8 as c3c7d19e, keeping both commits and their complete authors/messages/trailers. The resolutions retain all five ocarina-note controls, keyboard prompts, camera handover, upscaler reset and current translated hints beside Walk's unchanged Hold/Caps Lock/45% defaults, 15–90% range and IDs 52/53. Fixtures retain all assertions; the new note-layer integration also asserts that an inactive note layer consumes no controller input. GCC passed all 122 selected checks; Clang passed 121 with main's inherited background-input warning. The suite was 469 passed / 2 inherited failures / 20 skipped: that warning and the known release-script race. The last rebase adds only #2671 and changes no PR file blob; Walk/ocarina/wiring checks, final-main negatives, #2671's offline check and Windows-target syntax ran again. The final PR gate passes. No second full suite, game run or native Windows execution is claimed. Sources: the #2345 evidence and final-handoff ledger above.

[Joey-Magnus]

Both of my points are fixed at c3c7d19. tests/test_input_background.py now only adds to main's checks, with the four I asked about back unchanged, and Walk uses option ids 52 and 53 (gpu/vk/vk_api.h:34), which nothing on main uses (main has 45 to 48, and #2357's FOV took 51). The bind table grows by one entry at its end, saved by name as key_walk, options_version is untouched and no API bump is needed.

I merged it into current main and ran test_walk_key.py, test_bound_keys.py, test_input_background.py, test_ocarina_note_bindings.py, test_ocarina_notes.py, test_option_ids.py, test_menu_i18n.py and test_env_on.py: all pass, and CI is green on this head. Leaving Walk unbound with a log line when an older ini already gives Caps Lock to another control (binds_load) is the right upgrade path.

Caps Lock versus Alt as the default is the maintainers' call, and it's rebindable either way. First-person aiming while walking is still untested, as you say.