`KEY_DOWN`/`KEY_UP` were the last two nampower events left unfired, and the blocker was never
effort: it was the client's numeric `KEY_*` enum. The DLL's own strings publish four values
(`KEY_NONE=-1`, `KEY_SHIFT=0`, `KEY_A=65`, `KEY_ESCAPE=512`, `KEY_F1=768`) — enough to see three
banks and not enough to name a key past the first in any of them, and a guessed code is worse than
no event, since an addon switching on `arg1` would silently never match.
It is in the binary, in the name parser `SetBinding` resolves a key string through (`0x4886f0`),
and the arithmetic is in the instructions rather than inferred:
- **ASCII, bank 0** — a printable key is its own byte (`movsbl (%esi)`), which is why `KEY_A` is 65.
- **Numpad, `0x100`** — the digit character plus `0xd0` (`add $0xd0,%edi` at `0x48875b`), so
`NUMPAD0 = 0x100`..`NUMPAD9 = 0x109`, then `+ - * / .` at `0x10a`..`0x10e`, each reached by its
own character compare.
- **Specials, `0x200`** — contiguous from `ESCAPE = 0x200` through `PAGEDOWN = 0x20d`, then a hole,
`NUMLOCK = 0x20f`, two more holes, `PRINTSCREEN = 0x212`. Every one is a `mov $imm,%edi` in the
chain at `0x4888a0`..`0x488a20`; the holes are codes this parser assigns to no name.
- **Function keys, `0x300`** — `0x2ff + n` (`add $0x2ff,%edi`), so `F1 = 768` as published, and
`NUMPADEQUALS` sits past them at `0x30c`, from the parser's own `=` arm.
Transcribed into `bindings::chord::key_code`, which composes with the existing `key_token`, with a
test per bank and the three published values as its anchors. `CAPSLOCK`, `SPACE` and the
mouse-wheel names are in the client's name table at `0x846c20` but take no code from this parser,
so they answer `None` rather than a number nobody can check — and a second test walks every token
`key_token` can produce and fails on any that has neither a code nor a written-down reason.
No caller yet, and that is the honest state: what is left for the events is a **producer** on the
keyboard path, which is nampower's hook and the same hook the press-interception queue uses, so it
belongs with that decision rather than ahead of it. `docs/ADDON_COMPAT.md` now says so instead of
naming the enum as the blocker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
9df4b6abd8