feat: onboard profiles (0x8100) support for G-series mice

[Stanley5249]

Summary

Adds support for HID++ 2.0 Onboard Profiles (feature 0x8100), the flash profile memory G-series gaming mice use to decide whether they run host software settings or their own stored profiles. Until now 0x8100 was a name-only row in the feature registry, so OpenLogi could neither report which mode a mouse was in nor let the user choose one.

This is a read and mode-control slice: read the memory description, mode, active profile and profile directory; switch between host and onboard mode; and select the active onboard profile. It deliberately does not write flash, so profile editing (functions 6 to 8) is out of scope.

The mode lives in device RAM, so a mouse left in host mode is back in onboard mode after a power cycle. The agent therefore re-applies a configured mode on every reconnect. A device with no configured mode is left in whatever mode it powered on in, and OpenLogi never switches it on the user's behalf.

Scope, and what still needs work

This PR is the wiring: the protocol wrapper, the I/O verbs, the config key, a panel to toggle the mode and pick a profile, and enough receiver support to reach these mice at all. It is not a finished onboard-profiles feature:

• Profile contents are untouched. Key bindings, DPI stages and report rate stored inside a profile are neither read nor written. Selecting a profile activates whatever the device already has in that slot.
• The UI is functional, not designed. The Profiles tab is a source toggle and a row of pills. It needs real design work before it is something to ship proudly.
• Flash writes are out of scope, so OpenLogi cannot create, edit or reset a profile.

Worth reviewing as the foundation, not as the finished surface.

Changes

• hidpp: new feature/onboard_profiles with getDescription, get/set onboard mode, get/set current profile, memoryRead, and directory parsing over sector 0. Offsets are reverse-engineered against Solaar and libratbag and marked as such; unknown mode and enabled bytes surface as UnsupportedResponse rather than silent fallbacks. The directory read is bounded by profile_count + profile_count_oob, so a device that lists its read-only profiles is not truncated. No flash-write session.
• hid: IPC-facing ProfilesMode / ProfileEntry / OnboardProfilesInfo and the read/apply verbs; apply_profiles_config skips writes the device already matches. Recognises Lightspeed receivers (0xc53f, 0xc547) so a G502 X LIGHTSPEED is reachable at all. Adds the exchange() lock described below.
• core: per-device [devices."…".onboard_profiles] (mode, profile), config-file only and now documented in docs/CONFIGURATION.md; Capabilities::onboard_profiles from a 0x8100 feature probe.
• ipc: set_onboard_profiles / read_onboard_profiles agent methods and the reconnect re-apply. PROTOCOL_VERSION 10 → 11, wire-format goldens regenerated.
• gui: a Profiles tab gated on Capabilities::onboard_profiles, with a settings source (OpenLogi settings / onboard memory) and the active-profile selector. The selector offers user slots only: a device's read-only profiles are factory templates a slot is reset from, and the firmware rejects setCurrentProfile on one, so offering them would be an action that cannot succeed. diag profiles still prints them, since showing raw device state is its job.
• cli: openlogi diag profiles prints the state and runs a mode/profile round-trip (--read-only, --leave-onboard).

Things worth a careful look

PROTOCOL_VERSION 10 → 11. ProfilesMode and ProfileEntry cross the agent↔GUI IPC, so their variant and field order are wire format.

The global lock is a stopgap, not the fix. send_v20 matches a reply to its request by comparing HID++ headers, and the channel is built with rotate_software_id: false, so two concurrent requests to one device carry byte-identical headers and can take each other's replies. Bench-observed on a G502 X: a DPI write racing a mode write fails InvalidArgument 3/3 with the DPI payload landing on 0x8100's feature index, and get_dpi racing a mode write returns Ok(0), silently wrong with no error. write::exchange() serializes verbs to stop it, but the root fix is HidppChannel::set_rotating_sw_id(true). The lock is global rather than per-device and is held across open_route_channel(), so it serializes enumeration for unrelated devices too, which is heavier than the problem warrants. Rotating the software id is left out of this PR deliberately: it changes the vendored channel for every device and every feature, so it wants the bench cases re-run on hardware rather than riding along here. Note also that gesture.rs::run_capture_session opens a channel outside the lock.

Lightspeed receivers route as DeviceRoute::Unifying. They speak the same HID++ 1.0 register protocol, so they are enumerated, routed and paired through the Unifying path, and only receiver_display_name tells them apart. A dedicated route variant would fork every match arm for what is currently a cosmetic difference, so it seems worth revisiting only if their pairing register semantics turn out to diverge.

Three new UI strings are English placeholders in all 19 non-English locales, for Crowdin to fill.

The device renders as a silhouette. The pinned asset catalog has no G502 X or X-generation entry (#461), so the panel shows generic art and hotspots.

Testing

Hardware: G502 X LIGHTSPEED over a Lightspeed receiver, on Windows.

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
cargo run -p openlogi -- diag profiles      # read + round-trip
cargo run -p openlogi -- diag dpi           # in both modes
cargo run -p openlogi-gui                   # Profiles tab, toggle + re-read

Verified on hardware:

• diag profiles reads the description (5 user + 2 read-only profiles, 11 buttons, 16 × 255 B sectors), the mode, the active profile and the directory. The strict 0/1 enabled parse holds on real flash, and the unit fixture carries this captured payload.
• Mode and active-profile round-trips succeed, including across an agent restart honouring a GUI-set mode = onboard, profile = 2.
• setCurrentProfile is onboard-mode only. Host mode answers InvalidArgument and reports the active profile as 0x0000, since it parks the flash profile.
• The mode is volatile: a device left in host mode came back onboard, with sector 0x0002 active, after a power cycle.
• DPI writes are accepted in both modes. 1600 → 1650 → 1600 round-trips while onboard, while in host mode, and immediately after a mode write.
• The concurrency pairs above, before and after the lock.

Not verified:

• Any device other than a G502 X LIGHTSPEED. Everything above generalises from one mouse.
• The read-only-profile paths. The G502 X reports 2 of them alongside its 5 user slots, yet the sector-0 directory terminates after the 5 user entries and setCurrentProfile rejects 0x0101 to 0x0103, so nothing here exercises them. A device that does list them would be the first real test.
• macOS and Linux GUI builds and i18n parity are CI's job; not built on macOS locally.

Notes

Depends on #388 (Lightspeed receiver recognition). Its commit is carried here so the branch builds and the hardware test runs; the patch-ids match, so it drops out on rebase once #388 merges.

Screenshots

[greptile-apps]

Greptile Summary

This PR adds full read-and-mode-control support for HID++ 2.0 0x8100 OnboardProfiles on G-series gaming mice, along with Lightspeed receiver recognition (0xc53f, 0xc547) that makes devices like the G502 X LIGHTSPEED reachable at all. The implementation spans the full stack: a new openlogi-hidpp feature wrapper, HID-layer verbs, agent IPC (PROTOCOL_VERSION → 11), a reconnect reapply path that sequences before DPI writes (to prevent flash-reload clobber), and a GUI Profiles tab with source toggle and profile pills.

• Protocol layer (openlogi-hidpp): strict enabled-byte validation, total-profile directory reads (user + ROM), and a global EXCHANGE mutex to serialize concurrent HID++ verbs — acknowledged as a stopgap pending rotating software IDs.
• Reconnect sequencing (orchestrator.rs): apply_onboard_profiles_in_background runs first with a RunOnDrop continuation; DPI/SmartShift writes land only after the mode settles, preventing a flash-profile reload from discarding them.
• GUI (profiles_panel.rs): ROM profiles are correctly excluded from the user-facing selector; optimistic write + confirming re-read pattern mirrors the SmartShift panel; keep_profile_for carries the current sector through a mode switch so switching back to onboard restores the same profile.

Confidence Score: 4/5

Safe to merge after fixing the ROM-sector omission in the diag command; all other paths are well-guarded and hardware-tested.

The diag command's profile_round_trip selects a target profile without filtering ROM sectors, while the GUI and config-apply paths both do. Now that get_onboard_profiles passes the total entry count (user + OOB), a device that lists enabled ROM entries in sector 0 would have set_active_profile called on a ROM sector, which the firmware rejects. The rest of the PR is solid.

Files Needing Attention: crates/openlogi-cli/src/cmd/diag/profiles.rs — profile_round_trip target selection needs !e.is_rom() to match the GUI guard.

Important Files Changed

Filename	Overview
crates/openlogi-cli/src/cmd/diag/profiles.rs	New diag command reads description/mode/profile/directory and does mode and profile round-trips. profile_round_trip is missing !e.is_rom() filter, so a device with enabled ROM entries in its directory would cause a firmware-rejected InvalidArgument on set_active_profile.
crates/openlogi-hid/src/write/onboard_profiles.rs	HID-layer verbs for 0x8100: get_onboard_profiles correctly passes total_profiles (user+OOB) to read_profile_directory; apply_profiles_config_on_channel skips writes when already matching; read-back warnings are non-fatal.
crates/openlogi-hidpp/src/feature/onboard_profiles/mod.rs	New 0x8100 feature impl: get_description, mode get/set, profile get/set, memory_read, directory parse. Loop termination and bounds are correct; doc comment on read_profile_directory is stale after the total-profiles fix.
crates/openlogi-hidpp/src/feature/onboard_profiles/types.rs	Domain types for 0x8100: OnboardMode, ProfilesDescription, ProfileDirectoryEntry, parse_directory. Wire layout matches libratbag; strict enabled-byte validation is correct; tests cover all edge cases.
crates/openlogi-agent-core/src/orchestrator.rs	Reconnect reapply now calls apply_onboard_profiles_in_background before the DPI/SmartShift continuation; configured_onboard_profiles correctly gates on capabilities.onboard_profiles; sequencing prevents flash-profile reload from clobbering a DPI write.
crates/openlogi-agent-core/src/hardware.rs	apply_onboard_profiles_in_background uses RunOnDrop to guarantee the continuation fires on panic/early-return; integrates with shared-channel fast path correctly.
crates/openlogi-hid/src/write.rs	Introduces global EXCHANGE mutex to serialize HID++ verbs; acknowledged as a stopgap (per-device would be better, and gesture.rs bypasses the lock); all *_on shared-channel helpers now take the lock before delegating.
crates/openlogi-gui/src/components/profiles_panel.rs	New profiles tab: source toggle and profile pills. ROM entries are correctly excluded from the selector; optimistic write + confirming re-read pattern matches smartshift_panel; keep_profile_for handles host-mode 0x0000 correctly.
crates/openlogi-gui/src/state.rs	LazyDeviceData wiring for profiles follows the established smartshift pattern; commit_onboard_profiles correctly gates the profile write on mode==Onboard in apply_profiles_config_on_channel.
crates/openlogi-agent-core/tests/wire_format.rs	PROTOCOL_VERSION bumped to 11; golden bytes for new request variants (SetOnboardProfiles, ReadOnboardProfiles), ProfilesMode, OnboardProfilesInfo, and HidppOperation indices are all pinned.

Sequence Diagram

sequenceDiagram
    participant GUI as GUI (profiles_panel)
    participant State as AppState
    participant IPC as Agent IPC
    participant HW as hardware.rs
    participant HID as write/onboard_profiles.rs
    participant Dev as Device (0x8100)

    GUI->>State: commit_onboard_profiles(mode, profile)
    State->>State: optimistic update (Ready to new mode)
    State->>IPC: SetOnboardProfiles(route, mode, profile)
    State->>State: persist to config.toml
    State->>State: profiles_pending_confirm.insert(key)

    IPC->>HW: apply_onboard_profiles(capture, route, mode, profile)
    HW->>HID: apply_profiles_config_on_channel(channel, index, mode, profile)
    HID->>Dev: get_onboard_mode() [read current]
    Dev-->>HID: current mode
    HID->>Dev: set_onboard_mode(mode) [if changed]
    HID->>Dev: get_onboard_mode() [read-back]
    HID->>Dev: set_current_profile(sector) [if onboard and profile changed]
    HID->>Dev: get_current_profile() [read-back]
    HID-->>IPC: Ok(written)

    Note over GUI,State: On next render
    GUI->>State: ensure_profiles_confirm()
    State->>IPC: ReadOnboardProfiles(route)
    IPC->>HW: read_onboard_profiles(route)
    HW->>HID: get_onboard_profiles(route)
    HID->>Dev: get_description() + get_onboard_mode() + get_current_profile() + read_profile_directory(total)
    Dev-->>HID: OnboardProfilesInfo
    HID-->>State: store_profiles_info(key, route, Ok(info))
    State->>GUI: notify (render with real state)

Loading

_{Reviews (10): Last reviewed commit: "feat(hid,hidpp): recognize Lightspeed re..." | Re-trigger Greptile}

[davidbudnick]

@Stanley5249 Looks as you have issues, with your pipeline running for the following change, can you fix issues and re-push?

[Stanley5249]

@davidbudnick CI is green now, and I've updated the PR body. A few things could use a closer look: the protocol version bump, the translations, and the temporary global lock. Details on each are at the top. Thanks.

[davidbudnick]

@davidbudnick CI is green now, and I've updated the PR body. A few things could use a closer look: the protocol version bump, the translations, and the temporary global lock. Details on each are at the top. Thanks.

Perfect thanks for updating it, looks as you have a few merge conflicts which need to be resolved before a merge can take place.

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Start a greploop in Codex and it will work through the open comments and keep going until this PR reviews clean.

[Stanley5249]

@davidbudnick Done. Maybe close #388 as well, its commit is carried here with kiwimaker credited.