The Problem

Logitech Options+ locks advanced mouse and keyboard features behind a cloud-dependent client with limited Linux support and no native remapping flexibility. Users wanting button remapping, per-application profiles, or gesture support on any physical button must accept telemetry, account requirements, and platform restrictions.

What This Does

OpenLogi is a native, local-first alternative to Logitech Options+ written in Rust (482 Rust files across 584 crate files). It exposes full Logitech device capabilities over HID++ and UVC without accounts or telemetry. Key capabilities visible in the codebase:

  • Button remapping via OS input hook (crates/openlogi-agent-core/src/runtime/button.rs) with a built-in action catalog and custom keyboard shortcuts authored in TOML config (crates/openlogi-core/src/config/settings.rs)
  • DPI control through HID interface (crates/openlogi-core/src/hid/dpi.rs) and smartshift handling (crates/openlogi-core/src/hid/smartshift.rs)
  • Litra light control with brightness and color temperature (crates/openlogi-core/src/hid/light.rs)
  • Per-application profile overlays that auto-switch on focus (crates/openlogi-agent/src/overlay.rs), supporting macOS + Windows; Linux via X11/XWayland
  • Gestures assignable to any physical button or disableable entirely (crates/openlogi-agent-core/src/watchers/gesture/)
  • Plain-text TOML config (crates/openlogi-core/src/config/file.rs) for syncing between machines

The crate architecture separates concerns: openlogi-agent-core handles core logic and watchers, openlogi-agent is the GUI/tray application, openlogi-camera manages UVC webcam integration, and openlogi-cli provides command-line control.

How It Is Wired

Execution starts at crates/openlogi-agent/src/main.rs, which initializes the tray application and loads configuration. The agent-core orchestrator (crates/openlogi-agent-core/src/orchestrator.rs) sits at the center of the call graph, receiving events from system watchers and dispatching actions through runtime components.

The event flow traces as: foreground app watcher (crates/openlogi-agent-core/src/watchers/foreground_app.rs) → orchestrator → runtime button handler (crates/openlogi-agent-core/src/runtime/button.rs) or runtime scroll handler (crates/openlogi-agent-core/src/runtime/scroll/worker.rs) → HID interface (crates/openlogi-core/src/hid.rs) → device-specific implementation. The watchers module (crates/openlogi-agent-core/src/watchers/mod.rs) aggregates keyboard, gesture, input monitoring, and pairing watchers.

The HID hub (crates/openlogi-core/src/hid.rs) is the single point through which all device communication passes: dpi changes, smartshift toggles, light controls, and pairing all route through this module. The orchestrator carries the widest blast radius—modifying its action routing affects all remapped inputs across all connected devices.

Configuration lives in TOML format, with the settings file (crates/openlogi-core/src/config/settings.rs) defining action bindings, per-application overlays, and device-specific overrides. The config file watcher monitors changes and reloads without restart.

How To Use It

Setup: Clone the repository verbatim:

git clone https://github.com/moses-y/OpenLogi

Build with cargo from the root:

cargo build --release

Configuration: The application reads crates/openlogi-core/src/config/settings.rs on startup. No environment variables are required for basic operation; the TOML config file handles all bindings and profile settings.

Running it: Start the GUI application:

cargo run -p openlogi-agent

The CLI is available via openlogi-cli crate for scripted operations.

Real-World Use

A user connects a Logitech MX Master 3S over Bolt receiver. OpenLogi detects the device and reports battery state. The user configures the thumbwheel as a per-application volume control for VS Code only: the TOML config assigns the wheel role to application_target com.microsoft.VSCode. When VS Code gains focus, the overlay auto-switches (crates/openlogi-agent/src/overlay.rs), remapping the wheel exclusively to that app. All other apps retain the default scroll behavior. The same user assigns a gesture to the side button for push-to-talk in Discord, with the gesture role bound to any physical button via the action catalog.

Code Health & Issues

Measured static analysis findings:

  • 57 test files present across crates, including integration tests for gesture dispatch and button handling
  • 31 documentation files covering API surfaces and configuration
  • No structural red flags detected: CI (/.github/workflows/ci.yml), license (LICENSE-APACHE, LICENSE-MIT), and lockfile (Cargo.lock) are all present
  • The .cargo/deny.toml indicates dependency management and licensing enforcement is configured

SDLC observations from the file structure:

  • .github/scripts/release-notes/generate.ts and associated package.json suggest automated release-note generation, but the repo is under active development with version-dependent config changes noted in the README warning
  • macOS permissions handling has dedicated skill docs (.claude/skills/openlogi-macos-permissions/SKILL.md) and a diagnose script, indicating platform permission surfaces are an acknowledged integration point
  • No evidence of secrets committed; .gitignore is present at root

The Bottom Line

OpenLogi delivers a functional, local-first Logitech feature set without telemetry or account requirements, with Rust ensuring cross-platform performance including native Linux support—a notable gap in the Options+ ecosystem. The TOML-based config and per-application overlays are well-executed for power users who want syncable, granular control. The active-development status means config schemas may shift, and the X11-limited Linux gesture support constrains full replacement on Wayland desktops today. Engineers seeking to remap Logitech devices across macOS, Linux, and Windows without cloud dependencies will find this the most viable open alternative; others should wait for stabilization or pin to a known-good release.