How it works

Architecture

The tray sends user choices to a local service, which validates and applies supported hardware changes.

Control path

WinUI tray
User intent

Typed named pipe
Versioned contracts

LocalSystem service
Policy and serialization

Protocol + HID
Exact-device I/O

Status and results return to the tray.

Project	Responsibility	Trust boundary
`OpenBlade.Contracts`	Defines versioned IPC messages for profiles, state, capabilities, and results.	Contains no platform or HID code.
`OpenBlade.Protocol`	Validates reports, admits exact devices, stores sanitized fixtures, provides typed HID operations, and renders lighting.	Only typed operations allowed by the exact model and its validated or experimental authority reach HID.
`OpenBlade.Service`	Owns the control handle, serializes operations, runs automation, confirms state, and handles drift and diagnostics.	Runs as the privileged LocalSystem IPC server.
`OpenBlade.Tray.Core`	Stores presentation state, commands, profiles, telemetry choices, and service client behavior without depending on WinUI.	Runs in the unelevated user process.
`OpenBlade.Tray`	Handles the WinUI 3 window, Mica styling, tray icon, startup preference, and user interaction.	Runs as the unelevated current-user UI.
`OpenBlade.Display`	Finds displays and applies Windows refresh rate, HDR, and color profile settings.	Uses APIs from the current interactive session.
`OpenBlade.Platform`	Reads Windows NVIDIA GPU activity counters, lists and closes the apps holding the GPU awake, and applies processor efficiency policy.	Contains no HID code. Acts only on the current user's own processes.
`OpenBlade.Deployment`	Parses manifests and verifies signatures for enrolled local-development deployments.	Checks manifests and installer hashes against local deployment trust policy; installation is handled by the broker.
`OpenBlade.Session` / `SessionAgent`	Handles current-user display, input, audio, and streamed-lighting work. Profile automation, configured keys, and interactive lighting continue when the tray exits.	Runs once per signed-in user. The service accepts hardware changes only from the active console session.
`OpenBlade.Capture`	Provides typed capture, query, and reversible validation tools for developers.	The production installer does not ship this tool and rejects payloads containing it.
`OpenBlade.FirmwareSmoke`	Runs reversible firmware checks against a connected Blade and restores the original state.	This developer tool does not ship in the production installer.
`OpenBlade.DeploymentBroker` / `DeploymentClient`	Installs locally built OpenBlade payloads without repeated permission prompts, with first-install rollback.	For local development only, and only after an explicit, machine-authorized enrollment. Does not ship in the production installer.
`OpenBlade.Setup`	Installs or removes the app, manages the service and session component, and preserves profiles.	Requests elevation only for machine changes. It refuses to replace a newer installed version.

State and precedence

The service resolves settings in this order: manual override, temporary power-source override, active profile, then confirmed firmware state. It writes only values that changed.

Firmware behavior varies by model. RZ09-0581 reports one manual thermal state for Fixed, Manual curve, and Maximum. Its adapter remembers the selected mode while confirming the generic firmware state.

Ownership and conflicts

The service serializes all hardware operations through one gate.
Before a control session, the service checks the target model, VID/PID, and feature-report geometry. Validated backends pin usage tuples; experimental admission selects a unique responding interface using read-only performance queries.
OpenBlade checks for competing Razer controllers. A verified Synapse Blade Blocker installation lets Synapse handle peripherals alongside OpenBlade. OpenBlade does not uninstall them. Its Troubleshooting action can stop a fixed list of known Synapse and Chroma services when you request it and approve administrator access. It reports each service's Windows status and leaves its startup type unchanged.
After its safety checks, OpenBlade can restore a performance mode or fan setting changed by another app. Choose Notify me to report the change and leave it in place. Profiles upgraded from an older version wait for one acknowledgment before restoration starts. OpenBlade never enables HyperBoost automatically. A user-enabled lighting policy can restore lighting the same way.
The service keeps animated keyboard effects running. Static and firmware-backed settings use one write where supported.

Experimental authority

The five experimental profiles use a separate upstream-derived backend. Exact host identity, current state, power, and competing-controller checks still gate writes. These profiles do not inherit the validated lighting oracle, Driver-mode ownership, manual fan controls, or full-power adapter classification.

A possibly submitted, unconfirmed command pauses experimental writes. Resume drains the old session and performs fresh read-only admission and state checks. It never replays the uncertain command. Lighting remains held until a new effective lighting choice. Diagnostics retain a bounded local history.

Failure model

Not applied

No command was accepted. Keep the last confirmed state and report the failed control.

Result unknown

A write may have reached the laptop, but confirmation failed. Stop writing and reconcile the current state. Experimental controls require the explicit read-only Resume action before another request.

Changed elsewhere

Report the change, then restore the confirmed setting or leave it in place, depending on your choice. Never replay a write whose outcome is unknown.

Data unavailable

Show unavailable data as unavailable. If temperature data is lost while a manual fan curve is active, the curve requests the maximum supported fan speed; hardware writes still require the normal device and controller checks.