Repository navigation
Keep the requested mode after set_mode() - #96
Merged
Merged
Conversation
OpenRGB 1.0 applies SDK writes on a per-controller thread but answers REQUEST_CONTROLLER_DATA right away, so the update() in set_mode() can return the previous mode. set_color() and set_colors() then dispatch on that stale mode, and when it has no colors (e.g. Off) they send nothing. Home Assistant hits this every time it turns a light on from Off. See https://gitlab.com/CalcProgrammer1/OpenRGB/-/work_items/5924 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bs25H1VRVY917EZg6GxZhr
jath03
force-pushed
the
set-mode-tracks-requested-mode
branch
from
October 8, 2026 04:50
7d7e44c to
ab0fe5e
Compare
jath03
force-pushed
the
set-mode-tracks-requested-mode
branch
from
October 8, 2026 04:53
ab0fe5e to
19996ab
Compare
Removed comments about OpenRGB 1.0+ behavior and server response.
TRusselo
commented
Oct 8, 2026
TRusselo
left a comment
TRusselo
left a comment
Contributor
Author
There was a problem hiding this comment.
sorry for the comments. fixed
jath03
force-pushed
the
set-mode-tracks-requested-mode
branch
from
October 8, 2026 04:59
e39f0f8 to
50f7b82
Compare
Owner
|
This is an ugly problem. Your original fix would be invalid if the server rejected the UPDATEMODE request, so I added a short retry loop to catch the race. I still manually set it in the timeout case, as that may occur during rescans, but I added a warning. The correct solution is to finally implement v6, but this should work for the moment. |
10 of 21 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Device.set_mode()sendsUPDATEMODEand then callsupdate(). OpenRGB 1.0 applies SDK writes on a per-controller thread but answersREQUEST_CONTROLLER_DATAright away, so thatupdate()can return the previous mode.set_color()andset_colors()then dispatch on the staleactive_mode, and when it has no colors (e.g.Off) they send nothing, without an error.Home Assistant's OpenRGB integration hits this every time it turns a light on from Off:
set_mode("Direct")followed byset_color(color, fast=True)leaves the device in Direct with its old color.This keeps
active_modeat the mode that was just sent. Against servers that apply writes in order the re-read already matches, so nothing changes there.The server side is reported as https://gitlab.com/CalcProgrammer1/OpenRGB/-/work_items/5924.
Testing
Off →
set_mode("Direct")→ randomset_color(..., fast=True), 20 rounds, each result checked from a second client (script in the OpenRGB issue), on a Razer Goliathus:0b02dc62(protocol 6)1e1fb09(protocol 5)flake8 and mypy output is unchanged.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Bs25H1VRVY917EZg6GxZhr