JackFrostbyte/rgb-aura
1
2
Fork 0
Code Issues 25 Pull requests Projects Releases 2 Packages Wiki Activity Actions

Fix OpenRGB 1.0 compatibility and resilient device discovery #98

Merged
JackFrostbyte merged 10 commits from feature/issue-97-openrgb-resilience into develop 2026-09-21 01:16:26 -04:00
Conversation 0 Commits 10 Files changed 16 +1469 -62
JackFrostbyte commented 2026-09-21 01:14:17 -04:00
Owner
Copy link

Closes #97

Summary

Improve RGB Aura compatibility with OpenRGB 1.0 and make device discovery/recovery more resilient without weakening strict hardware mapping safety.

The OpenRGB 1.0 upgrade exposed several separate problems: renamed motherboard zones, intermittent GPU discovery, an unstable plugin-list SDK request, OpenRGB process restarts, and the ASUS RTX 5080 returning in a hardware Rainbow mode instead of the Direct mode required for per-LED control.

Changes

  • Add explicit allow-listed zone-name aliases for OpenRGB 1.0 renamed motherboard ARGB headers.
  • Keep strict device, type, zone index, LED count, and usable-LED validation.
  • Add required mapping support so explicitly optional devices may be absent without disabling the remaining validated zones.
  • Mark the RTX 5080 mapping as optional/recoverable.
  • Add validated runtime refresh for missing optional devices.
  • Drain active scheduler events before replacing refreshed runtime-zone objects.
  • Wait for the NVIDIA I2C adapter set to remain stable before starting OpenRGB.
  • Add a repository helper for safely synchronizing systemd user service definitions.
  • Pin openrgb-python==0.3.7.
  • Add an RGB Aura OpenRGB client wrapper that skips unused plugin enumeration, avoiding the OpenRGB 1.0 plugin-list path observed crashing the SDK server.
  • Use systemd for full OpenRGB process-level recovery rather than duplicating process supervision inside RGB Aura.
  • Add opt-in ensure_direct_mode mapping behavior.
  • Configure the ASUS RTX 5080 to restore exact Direct mode before per-LED animation writes.
  • Update systemd, failure-mode, and usage documentation to describe the implemented recovery model.

Validation

The changes were validated against the actual OpenRGB 1.0 installation and production hardware.

OpenRGB successfully detected the ASUS TUF GeForce RTX 5080 Gaming OC and ASUS ROG STRIX B650E-E GAMING WIFI with all expected zones.

The OpenRGB process was deliberately killed with SIGKILL. openrgb-sdk.service restarted it after the stable-I2C gate, RGB Aura detected the SDK disconnect and exited non-zero, and rgb-aura.service restarted and revalidated the hardware successfully.

The RTX 5080 recovery issue was reproduced separately: OpenRGB exposed the GPU in Rainbow mode while RGB Aura's per-LED writes require Direct. The new runtime preparation was hardware-tested by deliberately placing the GPU in Rainbow; RGB Aura detected the state, switched the validated GPU to Direct, verified the transition, and normal GPU animation resumed.

The complete test suite passes, including coverage for zone aliases, malformed mappings, optional-device absence, recovered-device validation, runtime refresh, OpenRGB client compatibility, scheduler refresh behavior, and Direct-mode preparation.

Design notes

Optional status relaxes only complete device absence. A present device with an unexpected identity still fails mapping validation.

Zone compatibility remains explicit rather than fuzzy: only configured aliases are accepted.

Full OpenRGB process failure recovery remains owned by systemd. RGB Aura handles the disconnect safely, exits non-zero, and performs fresh enumeration and mapping validation after systemd restarts it.

The portable v1.1 device-profile work is intentionally not wired into the current runtime as part of this issue.

Closes #97 ## Summary Improve RGB Aura compatibility with OpenRGB 1.0 and make device discovery/recovery more resilient without weakening strict hardware mapping safety. The OpenRGB 1.0 upgrade exposed several separate problems: renamed motherboard zones, intermittent GPU discovery, an unstable plugin-list SDK request, OpenRGB process restarts, and the ASUS RTX 5080 returning in a hardware `Rainbow` mode instead of the `Direct` mode required for per-LED control. ## Changes * Add explicit allow-listed zone-name aliases for OpenRGB 1.0 renamed motherboard ARGB headers. * Keep strict device, type, zone index, LED count, and usable-LED validation. * Add `required` mapping support so explicitly optional devices may be absent without disabling the remaining validated zones. * Mark the RTX 5080 mapping as optional/recoverable. * Add validated runtime refresh for missing optional devices. * Drain active scheduler events before replacing refreshed runtime-zone objects. * Wait for the NVIDIA I2C adapter set to remain stable before starting OpenRGB. * Add a repository helper for safely synchronizing systemd user service definitions. * Pin `openrgb-python==0.3.7`. * Add an RGB Aura OpenRGB client wrapper that skips unused plugin enumeration, avoiding the OpenRGB 1.0 plugin-list path observed crashing the SDK server. * Use systemd for full OpenRGB process-level recovery rather than duplicating process supervision inside RGB Aura. * Add opt-in `ensure_direct_mode` mapping behavior. * Configure the ASUS RTX 5080 to restore exact `Direct` mode before per-LED animation writes. * Update systemd, failure-mode, and usage documentation to describe the implemented recovery model. ## Validation The changes were validated against the actual OpenRGB 1.0 installation and production hardware. OpenRGB successfully detected the ASUS TUF GeForce RTX 5080 Gaming OC and ASUS ROG STRIX B650E-E GAMING WIFI with all expected zones. The OpenRGB process was deliberately killed with `SIGKILL`. `openrgb-sdk.service` restarted it after the stable-I2C gate, RGB Aura detected the SDK disconnect and exited non-zero, and `rgb-aura.service` restarted and revalidated the hardware successfully. The RTX 5080 recovery issue was reproduced separately: OpenRGB exposed the GPU in `Rainbow` mode while RGB Aura's per-LED writes require `Direct`. The new runtime preparation was hardware-tested by deliberately placing the GPU in `Rainbow`; RGB Aura detected the state, switched the validated GPU to `Direct`, verified the transition, and normal GPU animation resumed. The complete test suite passes, including coverage for zone aliases, malformed mappings, optional-device absence, recovered-device validation, runtime refresh, OpenRGB client compatibility, scheduler refresh behavior, and Direct-mode preparation. ## Design notes Optional status relaxes only complete device absence. A present device with an unexpected identity still fails mapping validation. Zone compatibility remains explicit rather than fuzzy: only configured aliases are accepted. Full OpenRGB process failure recovery remains owned by systemd. RGB Aura handles the disconnect safely, exits non-zero, and performs fresh enumeration and mapping validation after systemd restarts it. The portable v1.1 device-profile work is intentionally not wired into the current runtime as part of this issue.
JackFrostbyte deleted branch feature/issue-97-openrgb-resilience 2026-09-21 01:16:26 -04:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
JackFrostbyte/rgb-aura!98
No description provided.