[Feature]: Support Logitech gaming devices — become a full G Hub alternative

[erek303]

Pre-flight checklist

• I searched existing issues and the Roadmap, and this isn't already tracked.

Problem / motivation

OpenLogi is a great local-first replacement for Logi Options+, but Logitech's gaming peripherals are managed by a separate app: G Hub. Users who own both productivity and gaming gear (e.g., an MX Master for work plus a G502 X / G Pro X Superlight 2 for gaming) still have to keep G Hub installed alongside OpenLogi.

That partially defeats OpenLogi's core promise: G Hub requires a Logitech account for some features, runs a heavy Electron app plus multiple background services, and pushes cloud profile sync — exactly the things OpenLogi frees us from on the Options+ side.

Receiver-level detection for several Lightspeed receivers already works (#512), but the feature surface on top is still Options+-oriented, so gaming mice are recognized without exposing their gaming capabilities.

Proposed solution

Extend OpenLogi's gaming-device feature set so it can fully replace G Hub, the same way it replaces Options+. Roughly in priority order:

1. Gaming mouse basics — remapping for all G-buttons (including G-Shift), multi-stage DPI (per-stage DPI value, e.g. 5 stages, with optional on-device color indication), and report/polling rate switching.
2. Onboard memory profiles — read/write on-device profiles so settings persist on other machines without any daemon (on top of feat: onboard profiles (0x8100) support for G-series mice #459).
3. LIGHTSYNC RGB — per-zone colors and effects, per-profile (on top of feat(hid): support LIGHTSPEED receivers and RGB effects #351).
4. Remaining Lightspeed receivers — tracked in [Tracking]: Lightspeed receiver support #512.
5. Later: G-series keyboards (G-keys/macros) and headsets.

It would also help to have a single "Gaming devices" roadmap/tracking item so the scattered gaming-related PRs and issues (#351, #369, #459, #730, #392, #877) have one home.

Alternatives considered

• G Hub itself — what we're trying to avoid (account, telemetry, resource usage).
• Logitech Onboard Memory Manager — Windows-only, limited device coverage, no longer actively extended.
• piper/ratbag (Linux) — partial gaming-mouse support (DPI, buttons), Linux-only, no per-app profiles or richer features.

Related area(s)

• GUI
• CLI
• Button actions / remapping
• DPI
• SmartShift
• Per-application profiles
• Configuration (TOML)
• Auto-update
• Other (RGB / LIGHTSYNC, onboard profiles, polling rate)

Additional context

Cross-references: #512 (Lightspeed receiver tracking), #351 (RGB effects PR), #369 (G305 + gaming features PR), #459 (onboard profiles PR), #730 / #392 / #877 (individual gaming-device reports).

For context, there is prior open-source work on talking to gaming devices over HID++ (e.g., ratbag's Logitech gaming protocol support, and the g-hub-configurator project for G502-style onboard profiles), which may be useful references for the protocol side.

[yuzi-co]

Partly addressed by #949, which gives G-series mice a working Buttons panel:
Capabilities::buttons now covers 0x8100/0x8110, and the mouse model can read
gaming asset depots — they key the side render device_side rather than
device_buttons_image, identify slots by slotId (g502wireless_g4_m1) rather
than slotName, and place markers in absolute pixels rather than percentages. On a
G502 LIGHTSPEED that yields working back/forward through the OS input hook.

It stops well short of item 1 on this list. G6+ are handled in firmware and emit no
HID event, so the hook cannot reach them at all — those need the onboard-profile
work in #459. Middle click is also still unreachable on these mice, for an unrelated
reason: its marker lives on the front render while the panel draws one view. Filed
separately as #950.

Two things worth flagging between #949 and #459, since both touch Capabilities
and the wire:

• fix(core,gui,ipc,assets): give G-series mice a working Buttons panel #949 adds Capabilities::hook_only_buttons, documented as "the OS input hook is
  the only thing that can remap this device's buttons". That stops being true once
  onboard profiles work — a G502 would then carry both hook_only_buttons: true and
  onboard_profiles: true, which contradict each other. The flag probably wants
  renaming to something diversion-specific (it exists to answer "can controls beyond
  middle/back/forward be diverted over 0x1b04"), or the panel logic needs to
  consider both.
• feat: onboard profiles (0x8100) support for G-series mice #459 currently targets PROTOCOL_VERSION = 24 against a master already at 27, so
  it needs a rebase and a renumber independently of fix(core,gui,ipc,assets): give G-series mice a working Buttons panel #949. The two field additions
  don't collide on the wire — fix(core,gui,ipc,assets): give G-series mice a working Buttons panel #949 inserts after buttons, feat: onboard profiles (0x8100) support for G-series mice #459 appends after
  haptic_panel — but whichever rebases second regenerates the golden in
  wire_format.rs.