Repository navigation
docs: Bosun profile concepts and G13 input-path research - #6
Conversation
…ot, master-prompt Co-authored-by: RaapTechllc <RaapTechllc@users.noreply.github.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 66ec6ea46c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - LWN “hid Logitech G13 Driver 0.0.5” (2010): device identifies as HID but **“does not support standard HID input messages”**; a custom input device was synthesized in-driver. https://lwn.net/Articles/376851/ | ||
| - Modern mainline work extending `hid-lg-g15` for G13 (LKML / lore, 2025–2026): looks for application collection `0xff000000`, connects **hidraw**, exposes synthetic “Gaming Keypad” + “Thumbstick” input devices — i.e. **kernel translation of vendor reports**, not a stock Keyboard Page hardware interface. (Kernel sources are GPL; Bosun must not copy them — PRD R6 / AC-12.) |
There was a problem hiding this comment.
Remove conclusions drawn from banned GPL G13 sources
These lines explicitly quote a historical G13 driver discussion and summarize implementation details from GPL kernel work, despite the repository's clean-room rule forbidding consultation of GPL G13 sources and requiring protocol facts to come only from docs/BOSUN-PLAN.md. Calling the material “corroboration” rather than an implementation source does not remove the provenance problem; delete these derived facts and support the conclusion exclusively with the in-repo measurements.
AGENTS.md reference: AGENTS.md:L14-L14
Useful? React with 👍 / 👎.
|
|
||
| | Listening path | Can distinguish G1 vs keypad “1”? | Notes | | ||
| |----------------|-----------------------------------|--------| | ||
| | OS keyboard / Raw Input on **Keyboard/Keypad Page `0x07`** | **No** | Same Usage ID (e.g. Keypad 1 = `0x59`) whether produced by a real keypad or by LGS injection. | |
There was a problem hiding this comment.
Preserve device provenance in the keyboard-path analysis
When LGS exposes mapped keys through a distinct virtual HID device, Windows Raw Input retains the source in RAWINPUTHEADER.hDevice, so equal 0x59 usage values do not by themselves make the LGS stream indistinguishable from a physical keypad. The note itself proposes checking for a different device node at line 195; declaring this path definitively unusable before that measurement can discard a viable fallback while vendor-report reads remain blocked.
Useful? React with 👍 / 👎.
|
|
||
| | G-key | Action | | ||
| |-------|--------| | ||
| | G22 (or user-chosen) | Insert / paste master project-start prompt | |
There was a problem hiding this comment.
Keep G22 reserved for stop-all
If this illustrative mapping is promoted into a profile, binding a prompt to G22 overrides the repository's documented emergency action: docs/BOSUN-PLAN.md states that G22 broadcasts stop-all, is bound in every layer, and cannot be overridden. Use a different key so the master-prompt concept does not remove the only globally reserved interrupt.
Useful? React with 👍 / 👎.
|
|
||
| ## Decisions for Kyle | ||
|
|
||
| 1. **Which profiles ship in M2?** Candidates: Grokbot/agent (core), Omarchy and/or Windows-Omarchy (key-emitter), Codex, master-prompt. Recommend: agent profile first if AC-R1 is unblocked; at most one key-emitter profile in M2. |
There was a problem hiding this comment.
Schedule profiles after their prerequisite milestones
The current PRD assigns M2 exclusively to bosun-lcd; the profile schema arrives in M3, inject actions in M4, and agent adapters in M5. Consequently none of the listed profiles can ship in M2 as described, so asking Kyle to select M2 profiles creates an impossible milestone target and conflicts with the authoritative sequencing; phrase this as a later milestone or v1 decision instead.
Useful? React with 👍 / 👎.
Docs-only capture of Kyle’s post-M1 profile brainstorm and the 2026-09-23 G13 input-path research note. No product code, no HID changes, and no edits to
docs/PRD.mdordocs/BOSUN-PLAN.md.What landed
docs/PROFILE-CONCEPTS.md— Windows-Omarchy, Omarchy, Codex, Grokbot/agent, and master-prompt concepts. Related section points at the in-repo research note.docs/research/ADR-BOSUN-g13-input-paths-2026-09-23.md— research lock on vendor0xFF00vs LGS-injected keystrokes vs an Omarchy key-emitter profile.README.md— one sentence in the existing “See AGENTS.md…” paragraph linking the brainstorm.Brainstorm only. M1 scope is unchanged.