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

Investigate OpenRGB startup device rescan reliability #51

New issue
Closed
opened 2026-05-12 00:51:12 -04:00 by JackFrostbyte · 3 comments
JackFrostbyte commented 2026-05-12 00:51:12 -04:00
Owner
Copy link

Context

After an OS update, RGB Aura failed to start from the systemd user service because OpenRGB did not detect the GPU at boot.

Manual recovery worked:

  1. Open OpenRGB GUI.
  2. Rescan devices.
  3. GPU appears.
  4. RGB Aura service starts successfully on the next retry.

This suggests RGB Aura is working correctly, but OpenRGB sometimes starts with an incomplete device list.

Goal

Investigate whether RGB Aura or the systemd user service can improve startup reliability when OpenRGB initially exposes an incomplete device list.

Scope

Research and test possible approaches:

  • Delay RGB Aura startup until OpenRGB is fully ready.
  • Restart OpenRGB before starting RGB Aura.
  • Trigger an OpenRGB rescan if the SDK/API supports it.
  • Extend retry behavior when expected mapped devices are missing.
  • Document manual recovery if automatic rescan is not reliable.

Out of scope

  • Ignoring missing required devices silently.
  • Writing to partially matched or ambiguous devices.
  • Weakening device mapping safety.

Acceptance criteria

  • We understand whether OpenRGB SDK/device rescan can be automated.
  • If possible, startup reliability is improved.
  • If not possible, documentation explains the manual recovery path.
  • RGB Aura still refuses unsafe or mismatched device mappings.
  • ruff format passes where applicable.
  • ruff check passes where applicable.
  • Tests pass where applicable.

Branch workflow

Base branch:

develop

Suggested work branch:

fix/issue-51-openrgb-startup-device-rescan

Pull request target:

develop

Do not merge directly into main. main should only receive tested release-ready changes from develop.

## Context After an OS update, RGB Aura failed to start from the systemd user service because OpenRGB did not detect the GPU at boot. Manual recovery worked: 1. Open OpenRGB GUI. 2. Rescan devices. 3. GPU appears. 4. RGB Aura service starts successfully on the next retry. This suggests RGB Aura is working correctly, but OpenRGB sometimes starts with an incomplete device list. ## Goal Investigate whether RGB Aura or the systemd user service can improve startup reliability when OpenRGB initially exposes an incomplete device list. ## Scope Research and test possible approaches: - Delay RGB Aura startup until OpenRGB is fully ready. - Restart OpenRGB before starting RGB Aura. - Trigger an OpenRGB rescan if the SDK/API supports it. - Extend retry behavior when expected mapped devices are missing. - Document manual recovery if automatic rescan is not reliable. ## Out of scope - Ignoring missing required devices silently. - Writing to partially matched or ambiguous devices. - Weakening device mapping safety. ## Acceptance criteria - We understand whether OpenRGB SDK/device rescan can be automated. - If possible, startup reliability is improved. - If not possible, documentation explains the manual recovery path. - RGB Aura still refuses unsafe or mismatched device mappings. - `ruff format` passes where applicable. - `ruff check` passes where applicable. - Tests pass where applicable. ## Branch workflow Base branch: `develop` Suggested work branch: `fix/issue-51-openrgb-startup-device-rescan` Pull request target: `develop` Do not merge directly into `main`. `main` should only receive tested release-ready changes from `develop`.
JackFrostbyte commented 2026-05-12 02:05:42 -04:00
Author
Owner
Copy link

Investigation notes — OpenRGB startup device rescan reliability

Current issue being investigated:

  • Issue: #51
  • Branch: fix/issue-51-openrgb-startup-device-rescan
  • Problem: after OS update or reboot, OpenRGB sometimes starts without detecting the GPU. RGB Aura then correctly refuses to start because the expected mapped GPU device is missing.
  • Manual recovery works by opening the OpenRGB GUI, using device rescan, and then letting RGB Aura start again on the next systemd retry.

Safety conclusion

RGB Aura behaved correctly from a device-mapping safety perspective.

When OpenRGB only reported the motherboard, RGB Aura refused to continue because the GPU was missing.

Observed failure:

Expected: ASUS TUF GeForce RTX 5080 Gaming OC
Detected devices: ['ASUS ROG STRIX B650E-E GAMING WIFI']

This behavior must not be weakened.

RGB Aura should not:

  • silently ignore missing required devices;
  • write to partially matched devices;
  • continue with ambiguous mappings;
  • continue when required OpenRGB devices are missing.

A separate cleanup bug was also observed:

UnboundLocalError: cannot access local variable 'previous_sigterm_handler'

That bug is already covered by issue #45, so it should not be fixed inside issue #51.

Systemd / startup evidence

OpenRGB currently starts from the generated XDG autostart user service:

app-OpenRGB@autostart.service

That generated service comes from:

~/.config/autostart/OpenRGB.desktop

Current OpenRGB autostart command:

/usr/bin/openrgb --server --server-host 127.0.0.1 --server-port 6742

The generated OpenRGB service has:

After=graphical-session.target
Restart=no
TimeoutStopSec=5s

RGB Aura currently has:

After=app-OpenRGB@autostart.service
Wants=app-OpenRGB@autostart.service
Restart=on-failure
RestartSec=10

This means RGB Aura is ordered after OpenRGB starts, but it does not guarantee that OpenRGB has finished hardware discovery or that the GPU was available when OpenRGB scanned devices.

OpenRGB / I2C findings

During failed startup, OpenRGB logged this warning:

Some internal devices may not be detected:
One or more I2C or SMBus interfaces failed to initialize.
RGB DRAM modules, some motherboards' onboard RGB lighting, and RGB Graphics Cards,
will not be available in OpenRGB without I2C or SMBus.

This matches the observed missing GPU.

When working, OpenRGB reports the GPU as:

ASUS TUF GeForce RTX 5080 Gaming OC
Type: GPU
Description: ENE SMBus Device
Version: I2C: NVIDIA i2c adapter 1 at 1:00.0 (/dev/i2c-1), address 0x67

Current system evidence shows the required NVIDIA I2C adapter exists after boot:

/sys/class/i2c-dev/i2c-1/name
NVIDIA i2c adapter 1 at 1:00.0

Other NVIDIA I2C adapters are also present:

NVIDIA i2c adapter 2 at 1:00.0
NVIDIA i2c adapter 3 at 1:00.0
NVIDIA i2c adapter 4 at 1:00.0
NVIDIA i2c adapter 5 at 1:00.0
NVIDIA i2c adapter 6 at 1:00.0
NVIDIA i2c adapter 7 at 1:00.0

Working theory:

OpenRGB may start and scan devices before the GPU I2C path is fully ready. Once OpenRGB has scanned too early, RGB Aura can retry forever and still see the incomplete OpenRGB device list until OpenRGB is manually rescanned or restarted.

OpenRGB CLI / SDK rescan investigation

OpenRGB CLI help was checked.

It exposes options such as:

--server
--server-host
--server-port
--list-devices
--device
--zone
--profile
--nodetect
--noautoconnect

No documented --rescan or --scan-devices CLI option was found.

Packet captures were taken on loopback port 127.0.0.1:6742 while clicking OpenRGB GUI rescan-related buttons.

A clean capture with RGB Aura stopped showed this packet:

4f524742000000008c00000000000000

Decoded:

magic:       ORGB
device_id:   0
packet_type: 140 / 0x8c
payload_len: 0

After this packet, the GUI requested controller count and controller data. The controller count went from 0 to 2, then OpenRGB returned full device data for:

ASUS TUF GeForce RTX 5080 Gaming OC
ASUS ROG STRIX B650E-E GAMING WIFI

Upstream OpenRGB source confirms packet type 140 is:

NET_PACKET_ID_REQUEST_RESCAN_DEVICES = 140

The server handles it through:

ProcessRequest_RescanDevices()
ResourceManager::get()->RescanDevices()

However, the Python SDK currently used by RGB Aura is:

openrgb-python 0.3.6

Its exposed packet types do not include request rescan devices.

Current exposed packet types include:

REQUEST_CONTROLLER_COUNT = 0
REQUEST_CONTROLLER_DATA = 1
REQUEST_PROTOCOL_VERSION = 40
SET_CLIENT_NAME = 50
DEVICE_LIST_UPDATED = 100
REQUEST_PROFILE_LIST = 150

Conclusion:

The rescan command exists in OpenRGB upstream, but is not currently exposed by openrgb-python 0.3.6.

Decision for now:

Do not hardcode raw packet 140 directly inside RGB Aura runtime. It is real, but it is not exposed by the SDK dependency and should be treated as a future/experimental path unless implemented cleanly or added upstream to openrgb-python.

Chosen next avenue

The best immediate workaround is to own the OpenRGB SDK server startup sequence instead of relying on the GUI/XDG autostart service.

Planned approach:

  1. Disable OpenRGB GUI autostart.

  2. Add a repo-owned user service: systemd/user/openrgb-sdk.service

  3. Add a startup wait helper: scripts/wait_for_openrgb_i2c.py

  4. The helper should wait for the required NVIDIA I2C adapter to appear under /sys/class/i2c-dev/i2c-*/name, matching something like NVIDIA i2c adapter.

  5. The new OpenRGB SDK service should start OpenRGB only after that adapter is visible:

    /usr/bin/openrgb --server --server-host 127.0.0.1 --server-port 6742

  6. Update rgb-aura.service to depend on the repo-owned OpenRGB SDK service instead of the generated XDG autostart unit:

    After=openrgb-sdk.service
Wants=openrgb-sdk.service

  7. Update docs/systemd-user-service.md to document:

  • OpenRGB startup ordering does not guarantee hardware detection readiness.
  • GPU RGB depends on NVIDIA I2C/SMBus readiness.
  • OpenRGB CLI has no documented rescan option.
  • SDK packet 140 exists upstream but is not exposed by openrgb-python 0.3.6.
  • Current recommended workaround is to start OpenRGB SDK through a controlled user service that waits for NVIDIA I2C.
  • Manual recovery remains: open OpenRGB GUI, rescan devices, then restart or let RGB Aura retry.

Next session starting point

Continue from branch:

cd ~/Projects/rgb-aura
source .venv/bin/activate
git branch --show-current
git status --short

Expected branch:

fix/issue-51-openrgb-startup-device-rescan

Next practical local step:

openrgb --autostart-disable
openrgb --autostart-check || true

Then add:

  • scripts/wait_for_openrgb_i2c.py
  • systemd/user/openrgb-sdk.service

And update:

  • systemd/user/rgb-aura.service
  • docs/systemd-user-service.md

Keep issue #45 separate for the previous_sigterm_handler cleanup bug.

## Investigation notes — OpenRGB startup device rescan reliability Current issue being investigated: * Issue: #51 * Branch: `fix/issue-51-openrgb-startup-device-rescan` * Problem: after OS update or reboot, OpenRGB sometimes starts without detecting the GPU. RGB Aura then correctly refuses to start because the expected mapped GPU device is missing. * Manual recovery works by opening the OpenRGB GUI, using device rescan, and then letting RGB Aura start again on the next systemd retry. --- ## Safety conclusion RGB Aura behaved correctly from a device-mapping safety perspective. When OpenRGB only reported the motherboard, RGB Aura refused to continue because the GPU was missing. Observed failure: ``` Expected: ASUS TUF GeForce RTX 5080 Gaming OC Detected devices: ['ASUS ROG STRIX B650E-E GAMING WIFI'] ``` This behavior must not be weakened. RGB Aura should not: * silently ignore missing required devices; * write to partially matched devices; * continue with ambiguous mappings; * continue when required OpenRGB devices are missing. A separate cleanup bug was also observed: ``` UnboundLocalError: cannot access local variable 'previous_sigterm_handler' ``` That bug is already covered by issue #45, so it should not be fixed inside issue #51. --- ## Systemd / startup evidence OpenRGB currently starts from the generated XDG autostart user service: ``` app-OpenRGB@autostart.service ``` That generated service comes from: ``` ~/.config/autostart/OpenRGB.desktop ``` Current OpenRGB autostart command: ``` /usr/bin/openrgb --server --server-host 127.0.0.1 --server-port 6742 ``` The generated OpenRGB service has: ``` After=graphical-session.target Restart=no TimeoutStopSec=5s ``` RGB Aura currently has: ``` After=app-OpenRGB@autostart.service Wants=app-OpenRGB@autostart.service Restart=on-failure RestartSec=10 ``` This means RGB Aura is ordered after OpenRGB starts, but it does not guarantee that OpenRGB has finished hardware discovery or that the GPU was available when OpenRGB scanned devices. --- ## OpenRGB / I2C findings During failed startup, OpenRGB logged this warning: ``` Some internal devices may not be detected: One or more I2C or SMBus interfaces failed to initialize. RGB DRAM modules, some motherboards' onboard RGB lighting, and RGB Graphics Cards, will not be available in OpenRGB without I2C or SMBus. ``` This matches the observed missing GPU. When working, OpenRGB reports the GPU as: ``` ASUS TUF GeForce RTX 5080 Gaming OC Type: GPU Description: ENE SMBus Device Version: I2C: NVIDIA i2c adapter 1 at 1:00.0 (/dev/i2c-1), address 0x67 ``` Current system evidence shows the required NVIDIA I2C adapter exists after boot: ``` /sys/class/i2c-dev/i2c-1/name NVIDIA i2c adapter 1 at 1:00.0 ``` Other NVIDIA I2C adapters are also present: ``` NVIDIA i2c adapter 2 at 1:00.0 NVIDIA i2c adapter 3 at 1:00.0 NVIDIA i2c adapter 4 at 1:00.0 NVIDIA i2c adapter 5 at 1:00.0 NVIDIA i2c adapter 6 at 1:00.0 NVIDIA i2c adapter 7 at 1:00.0 ``` Working theory: OpenRGB may start and scan devices before the GPU I2C path is fully ready. Once OpenRGB has scanned too early, RGB Aura can retry forever and still see the incomplete OpenRGB device list until OpenRGB is manually rescanned or restarted. --- ## OpenRGB CLI / SDK rescan investigation OpenRGB CLI help was checked. It exposes options such as: ``` --server --server-host --server-port --list-devices --device --zone --profile --nodetect --noautoconnect ``` No documented `--rescan` or `--scan-devices` CLI option was found. Packet captures were taken on loopback port `127.0.0.1:6742` while clicking OpenRGB GUI rescan-related buttons. A clean capture with RGB Aura stopped showed this packet: ``` 4f524742000000008c00000000000000 ``` Decoded: ``` magic: ORGB device_id: 0 packet_type: 140 / 0x8c payload_len: 0 ``` After this packet, the GUI requested controller count and controller data. The controller count went from 0 to 2, then OpenRGB returned full device data for: ``` ASUS TUF GeForce RTX 5080 Gaming OC ASUS ROG STRIX B650E-E GAMING WIFI ``` Upstream OpenRGB source confirms packet type 140 is: ``` NET_PACKET_ID_REQUEST_RESCAN_DEVICES = 140 ``` The server handles it through: ``` ProcessRequest_RescanDevices() ResourceManager::get()->RescanDevices() ``` However, the Python SDK currently used by RGB Aura is: ``` openrgb-python 0.3.6 ``` Its exposed packet types do not include request rescan devices. Current exposed packet types include: ``` REQUEST_CONTROLLER_COUNT = 0 REQUEST_CONTROLLER_DATA = 1 REQUEST_PROTOCOL_VERSION = 40 SET_CLIENT_NAME = 50 DEVICE_LIST_UPDATED = 100 REQUEST_PROFILE_LIST = 150 ``` Conclusion: The rescan command exists in OpenRGB upstream, but is not currently exposed by `openrgb-python 0.3.6`. Decision for now: Do not hardcode raw packet 140 directly inside RGB Aura runtime. It is real, but it is not exposed by the SDK dependency and should be treated as a future/experimental path unless implemented cleanly or added upstream to `openrgb-python`. --- ## Chosen next avenue The best immediate workaround is to own the OpenRGB SDK server startup sequence instead of relying on the GUI/XDG autostart service. Planned approach: 1. Disable OpenRGB GUI autostart. 2. Add a repo-owned user service: `systemd/user/openrgb-sdk.service` 3. Add a startup wait helper: `scripts/wait_for_openrgb_i2c.py` 4. The helper should wait for the required NVIDIA I2C adapter to appear under `/sys/class/i2c-dev/i2c-*/name`, matching something like `NVIDIA i2c adapter`. 5. The new OpenRGB SDK service should start OpenRGB only after that adapter is visible: ``` /usr/bin/openrgb --server --server-host 127.0.0.1 --server-port 6742 ``` 6. Update `rgb-aura.service` to depend on the repo-owned OpenRGB SDK service instead of the generated XDG autostart unit: ``` After=openrgb-sdk.service Wants=openrgb-sdk.service ``` 7. Update `docs/systemd-user-service.md` to document: * OpenRGB startup ordering does not guarantee hardware detection readiness. * GPU RGB depends on NVIDIA I2C/SMBus readiness. * OpenRGB CLI has no documented rescan option. * SDK packet 140 exists upstream but is not exposed by `openrgb-python 0.3.6`. * Current recommended workaround is to start OpenRGB SDK through a controlled user service that waits for NVIDIA I2C. * Manual recovery remains: open OpenRGB GUI, rescan devices, then restart or let RGB Aura retry. --- ## Next session starting point Continue from branch: ``` cd ~/Projects/rgb-aura source .venv/bin/activate git branch --show-current git status --short ``` Expected branch: ``` fix/issue-51-openrgb-startup-device-rescan ``` Next practical local step: ``` openrgb --autostart-disable openrgb --autostart-check || true ``` Then add: * `scripts/wait_for_openrgb_i2c.py` * `systemd/user/openrgb-sdk.service` And update: * `systemd/user/rgb-aura.service` * `docs/systemd-user-service.md` Keep issue #45 separate for the `previous_sigterm_handler` cleanup bug.
McJuniorstein commented 2026-05-12 10:43:28 -04:00
Collaborator
Copy link

Upstream openrgb-python rescan support — research findings

Parallel research into the upstream openrgb-python angle you flagged as a future path. Posting in case it helps shape the long-term plan for this issue. Does not replace the I2C-wait + systemd-controlled SDK service approach you've outlined — that's still the right primary fix for boot-time readiness. This is about complementary runtime tooling.

Headline finding: PR already exists

PR #85 "Add rescan function" by ThanhCN0 — opened 2025-10-20, still open, status mergeable=clean. Verified directly against GitHub today. Does exactly what RGB Aura would need:

  • Adds PacketType.REQUEST_RESCAN_DEVICES = 140 to openrgb/utils.py
  • Adds requestRescanDevices() helper to openrgb/network.py
  • Adds OpenRGBClient.rescan() to openrgb/orgb.py (with docstring warning about state-breaking behavior)
  • Total: 3 files, +15 lines, 2 commits, head sha 8657459

Two important caveats from the PR thread

  1. Rescan requires OpenRGB server 1.0+. Per the PR author's own testing: "On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan." OpenRGB servers older than 1.0 ignore packet 140 entirely. RGB Aura would need to confirm the user's OpenRGB server version before relying on this.
  2. Rescan requires client protocol_version=5. openrgb-python currently defaults to protocol 4. Maintainer's reasoning: other v5 features aren't implemented yet, and forcing protocol 5 can produce ValueError: 655360 is not a valid ZoneType errors in some setups. So even after PR #85 merges, the calling code has to opt into protocol 5 explicitly (OpenRGBClient(protocol_version=5)) and accept the v5-incomplete caveats. Not free.

Project health (verified 2026-05-12)

  • Last commit on master: 2025-11-23. Master branch is essentially the same as when PR #85 was opened — only one unrelated commit landed since (touches an example script, not the network protocol code).
  • Last PyPI release: 0.3.6 (2025-10-16). What RGB Aura pins to. No newer release.
  • Release cadence: 0.3.4, 0.3.5, 0.3.6 all shipped Aug-Oct 2025. Healthy.
  • Maintainer activity: jath03 commented on issues/PRs as recently as 2026-03-27. Still around.
  • PR #85 itself: mergeable=clean, no conflicts. Stalled because the author (ThanhCN0) went silent right after committing the requested docstring change. Maintainer is on record saying he'd merge: "Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in."

No viable alternative SDK

Surveyed PyPI and GitHub for other Python OpenRGB clients:

  • OpenRGB-PyClient (bahorn) — MIT, but effectively abandoned since 2023. Author's own README points users to openrgb-python. Also missing packet 140.
  • Nothing else viable. openrgb-python has ~40,000 monthly downloads vs ~30 for the alternative.

Switching SDKs is not a shortcut.

Server-side semantics

Packet 140 is fire-and-forget. Server handler is a one-liner: ResourceManager::get()->RescanDevices(). No reply is sent.

Completion notification is indirect: if the rescan changes the device list (devices added or removed), the server broadcasts packet 100 (DEVICE_LIST_UPDATED) to all connected clients. openrgb-python already handles that broadcast at orgb.py:410-411 by auto-running requestDeviceNum().

Critical edge case for this issue: if a rescan happens but the device list doesn't actually change (e.g., GPU still missing because I2C still isn't ready), no broadcast is sent. So a client wanting to confirm "rescan completed and devices recheckable" has to either wait for the broadcast or poll REQUEST_CONTROLLER_COUNT after a brief delay. Fire-and-forget means there's no blocking primitive.

Implications for #51

The systemd + wait_for_openrgb_i2c.py approach you've outlined remains the correct primary fix. The underlying problem is OpenRGB scanning before I2C readiness, and rescan-after-startup is a band-aid for that, not a substitute.

If/when PR #85 lands in openrgb-python AND the user is on OpenRGB server 1.0+ AND the calling code opts into protocol 5, RGB Aura gains a runtime tool: on mapping-validation failure due to a missing expected device, try a rescan + retry once before giving up. Smaller incremental defense than the systemd reordering, complements it.

Suggested action (low-effort, high-leverage)

Option A: ping PR #85 noting interest in the feature. Project-neutral wording would be appropriate — no need to name RGB Aura specifically. That nudges the maintainer to revisit.

Option B: if ThanhCN0 stays silent for a few more weeks, open a follow-up PR cherry-picking their two commits with Co-authored-by: ThanhCN0 <...> attribution. Cheap, faster than clean-room re-implementation, and respects the original author's work. Maintainer is on record with the merge bar already.

License note (pre-existing)

openrgb-python is GPL-3.0. RGB Aura is MIT (per LICENSE). This is the existing dependency posture, unchanged by upstreaming rescan support — flagging only because it shows up any time we discuss upstream changes.

Sources

## Upstream `openrgb-python` rescan support — research findings Parallel research into the upstream `openrgb-python` angle you flagged as a future path. Posting in case it helps shape the long-term plan for this issue. **Does not replace the I2C-wait + systemd-controlled SDK service approach you've outlined** — that's still the right primary fix for boot-time readiness. This is about complementary runtime tooling. ### Headline finding: PR already exists [PR #85 "Add rescan function"](https://github.com/jath03/openrgb-python/pull/85) by ThanhCN0 — opened 2025-10-20, still open, status `mergeable=clean`. Verified directly against GitHub today. Does exactly what RGB Aura would need: - Adds `PacketType.REQUEST_RESCAN_DEVICES = 140` to `openrgb/utils.py` - Adds `requestRescanDevices()` helper to `openrgb/network.py` - Adds `OpenRGBClient.rescan()` to `openrgb/orgb.py` (with docstring warning about state-breaking behavior) - Total: 3 files, +15 lines, 2 commits, head sha `8657459` ### Two important caveats from the PR thread 1. **Rescan requires OpenRGB *server* 1.0+.** Per the PR author's own testing: *"On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan."* OpenRGB servers older than 1.0 ignore packet 140 entirely. RGB Aura would need to confirm the user's OpenRGB server version before relying on this. 2. **Rescan requires client `protocol_version=5`.** `openrgb-python` currently defaults to protocol 4. Maintainer's reasoning: other v5 features aren't implemented yet, and forcing protocol 5 can produce `ValueError: 655360 is not a valid ZoneType` errors in some setups. So even after PR #85 merges, the calling code has to opt into protocol 5 explicitly (`OpenRGBClient(protocol_version=5)`) and accept the v5-incomplete caveats. Not free. ### Project health (verified 2026-05-12) - Last commit on master: 2025-11-23. Master branch is essentially the same as when PR #85 was opened — only one unrelated commit landed since (touches an example script, not the network protocol code). - Last PyPI release: `0.3.6` (2025-10-16). What RGB Aura pins to. No newer release. - Release cadence: 0.3.4, 0.3.5, 0.3.6 all shipped Aug-Oct 2025. Healthy. - Maintainer activity: jath03 commented on issues/PRs as recently as 2026-03-27. Still around. - PR #85 itself: mergeable=clean, no conflicts. Stalled because the author (ThanhCN0) went silent right after committing the requested docstring change. Maintainer is on record saying he'd merge: *"Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in."* ### No viable alternative SDK Surveyed PyPI and GitHub for other Python OpenRGB clients: - `OpenRGB-PyClient` (bahorn) — MIT, but effectively abandoned since 2023. Author's own README points users to `openrgb-python`. Also missing packet 140. - Nothing else viable. `openrgb-python` has ~40,000 monthly downloads vs ~30 for the alternative. Switching SDKs is not a shortcut. ### Server-side semantics Packet 140 is **fire-and-forget**. Server handler is a one-liner: `ResourceManager::get()->RescanDevices()`. No reply is sent. **Completion notification is indirect:** if the rescan changes the device list (devices added or removed), the server broadcasts packet 100 (`DEVICE_LIST_UPDATED`) to all connected clients. `openrgb-python` already handles that broadcast at `orgb.py:410-411` by auto-running `requestDeviceNum()`. **Critical edge case for this issue:** if a rescan happens but the device list doesn't actually change (e.g., GPU still missing because I2C still isn't ready), no broadcast is sent. So a client wanting to confirm "rescan completed and devices recheckable" has to either wait for the broadcast *or* poll `REQUEST_CONTROLLER_COUNT` after a brief delay. Fire-and-forget means there's no blocking primitive. ### Implications for #51 The systemd + `wait_for_openrgb_i2c.py` approach you've outlined remains the correct primary fix. The underlying problem is OpenRGB scanning before I2C readiness, and rescan-after-startup is a band-aid for that, not a substitute. If/when PR #85 lands in `openrgb-python` AND the user is on OpenRGB server 1.0+ AND the calling code opts into protocol 5, RGB Aura gains a runtime tool: on mapping-validation failure due to a missing expected device, try a rescan + retry once before giving up. Smaller incremental defense than the systemd reordering, complements it. ### Suggested action (low-effort, high-leverage) Option A: ping PR #85 noting interest in the feature. Project-neutral wording would be appropriate — no need to name RGB Aura specifically. That nudges the maintainer to revisit. Option B: if ThanhCN0 stays silent for a few more weeks, open a follow-up PR cherry-picking their two commits with `Co-authored-by: ThanhCN0 <...>` attribution. Cheap, faster than clean-room re-implementation, and respects the original author's work. Maintainer is on record with the merge bar already. ### License note (pre-existing) `openrgb-python` is GPL-3.0. RGB Aura is MIT (per `LICENSE`). This is the existing dependency posture, unchanged by upstreaming rescan support — flagging only because it shows up any time we discuss upstream changes. ### Sources - [PR #85 on jath03/openrgb-python](https://github.com/jath03/openrgb-python/pull/85) - [jath03/openrgb-python repo](https://github.com/jath03/openrgb-python) - [openrgb-python on PyPI](https://pypi.org/project/openrgb-python/) - [OpenRGB SDK documentation](https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md) - Upstream packet handling references: `NetworkServer.cpp ~620, ~1020-1022`; `ResourceManager.cpp ~369, ~410-424`; `NetworkClient.cpp 651-659` in [CalcProgrammer1/OpenRGB on GitLab](https://gitlab.com/CalcProgrammer1/OpenRGB) - Current `openrgb-python` patch shape: `openrgb/utils.py:102-124` (PacketType enum), `openrgb/network.py:187-188,213-228` (send pattern), `openrgb/orgb.py:389-426,461-469` (callback + update)
JackFrostbyte commented 2026-05-13 01:35:34 -04:00
Author
Owner
Copy link

Perfect, I updated my issue chat with the new info. I'll continue that this weekend.

Perfect, I updated my issue chat with the new info. I'll continue that this weekend.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
docs/issue-72-animation-pack-architecture
develop
v1.0.1
v1.0
Labels
Clear labels
No items
No labels
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
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#51
No description provided.