Windows: logon-autostarted agent never arms OS-hook button bindings until restarted (G502 over receiver)
- Dominant language
- Rust
- Stars
- 21k
- Forks
- 675
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 172
Description
## Summary
On Windows, the agent instance that autostarts at logon (HKCU `Run` → `OpenLogiAgent`) installs the OS input hook and reaches the device, but never arms the configured OS-hook button bindings. Physical presses of `Back`/`Forward` pass through as native XBUTTON1/2 for the entire lifetime of that instance. Restarting the agent by any means (GUI respawn after kill, manual start, with or without debug env, GUI open or closed) arms the same bindings within ~3 s, and they keep working afterwards.
## Environment
- Windows 11 (10.0.26200), OpenLogi v0.8.1 MSI (Aug 26 build: `openlogi-agent.exe` dated 2026-08-26 13:31)
- G502 LIGHTSPEED over its Lightspeed receiver (USB Receiver vid=046d pid=c539, wpid 407f, unit id d87c11b4)
- The mouse exposes no HID++ 0x1b04 over this link (`openlogi diag controls` → `device does not expose HID++ feature 0x1b04`), so `Back`/`Forward`/`MiddleClick` remapping goes through the OS input hook — the affected path.
Config (`%USERPROFILE%\.config\openlogi\config.toml`, schema 6):
```toml
[app_settings]
capture_mouse_events = true
[devices."unit:d87c11b4".bindings]
Forward = { CustomShortcut = "Ctrl+W" }
```
## Timeline (all times UTC, from the default-info-level built-in log)
Log: `~/.local/state/openlogi/agent.2026-08-28.log`.
- **00:32:39** — logon-autostarted agent starts. `OS input hook installed` appears immediately; tray, overlay and IPC all healthy. No errors/warnings at any point.
- **00:33:49** — first device session line, `control capture active index=1 gesture_sources=0 dpi_buttons=0 buttons=0 thumbwheel=false`, **70 s after agent start**. The mouse was asleep during logon and woke when first moved. For comparison, every manually started instance reaches this line within ~3 s because the device is already warm.
- **00:56:54** — GUI connects (launched from the agent tray icon).
- **00:32:39 → 01:01:46** (entire lifetime of the boot instance): **zero** `button → handling binding` lines, although the bound buttons were pressed repeatedly (native forward/back observed). A SendInput XBUTTON probe in this window also produced no handling line. A later GUI connect with the device long online did not heal the instance either.
- **01:01:46** — the GUI respawns the agent after a kill. Armed within ~2 s; from then on every press logs `button → handling binding button=Forward action=Ctrl+W`, including with the GUI open, relaunched, etc.
## What I ruled out with controlled experiments
- The config file was never modified (mtime unchanged, no GUI backups created) — not a persistence problem.
- Opening the GUI does not break an already-armed agent (verified in both directions).
- A bare manual start — no env vars, no output redirection, GUI running — arms correctly, so it is not a start-method or logging-timing artifact.
- Key resolution looks correct in the v0.8.1 source (`Config::resolve_device_key` resolves the asleep device to its `unit:` key via the persisted `links` index), and this file has no later commits, so the installed build matches master here.
## Suspicion
The device arrives ~70 s after the boot instance starts, and that late arrival never produces the arming that a fresh start performs. The continuous re-probe loop is active the whole time (`inventory::probe` cycles every ~2.5 s with `drained device-arrival events events=1`), which may be related — cf. #1041, where inventory probing retires a live channel on Linux.
Side note that makes this class of failure easy to miss: the mouse's onboard memory keeps DPI/lighting values, so a boot instance that silently skips all device settings still *looks* correctly configured apart from button bindings.
## Workaround
Restart the agent after logon (kill `openlogi-agent.exe`; the GUI respawns it, or start it manually).
`OPENLOGI_LOG=openlogi=debug,info` is now set user-wide on this machine, so the next cold-boot occurrence will produce a full debug trace in the rotating log — happy to attach it here when it happens.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the cold-boot timeline and the default-info-level agent log at ~/.local/state/openlogi/agent.2026-08-28.log, then trace inventory::probe and the drained device-arrival events around control capture activation. Compare a late-arriving sleeping device with a manually started instance; done means OS-hook bindings arm without restarting and Forward/Back presses produce handling-binding log lines.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100