Questions: using RGB.NET as a service + OpenRGB provider + device discovery reliability

[TheAuthorsGrimm]

Hi! I’m working on a Rust/Tauri desktop app (PrismForge) and I’m evaluating RGB.NET as a potential “device coverage layer.”

I noticed RGB.NET includes many device providers and also an RGB.NET.Devices.OpenRGB provider, and the core usage model with RGBSurface + TimerUpdateTrigger looks clean.

A few questions:

1. What’s the recommended way to use RGB.NET purely as a “device discovery + direct LED write” library (no rendering engine), especially when combining OpenRGB + vendor SDK providers?

2. Do you have guidance/examples for running RGB.NET as a long-lived service/daemon (IPC boundary) rather than embedding it into a UI app? (For example: a local TCP/NamedPipe service that a UI talks to.)

3. Are there known limitations for keyboards (HID) vs ARGB controllers in terms of reliability/hotplug?

Thanks for building this — it looks like a great abstraction layer.

[DarthAffe]

Hey, while RGB.NET tries to abstract over all the different types and vendors of devices it still relies on their SDKS underneath where each brings in it's own limitations and quirks. Also system-specific setups can cause issues/behavior changes. This is something that always should be kept in mind.

As for the question:

1. I don't recommend skipping RGB.NET rendering at all. You can set the Color-Property on the Leds itself, but this does not really offer any benefit over using a custom brush that assigns these colors using a lookup or whatever fits best in your design. (this would save you from some potential issues like partial renders that could occur otherwise.)

2. For RGB.NET this does not really change anything I'd say. There is nothing UI related in RGB.NET.
   I use something like this myself where I can change my room light using a REST-API.
   The complexity of this is all up to the requirments of your IPC-Protocol. (Refering to 1., a simple solution could be to just replicate the state of the brush used to render, or changing brushes based on some profile hint and so on)

3. I'd say reliability is generally quite good, but it highly depends on the device and the use case. Especially things like waking up from sleep on windows causing some of vendor SDKs to behave weird.
   Hotpluggin is currently not supported by RGB.NET and would need to be worked around by handling device connects/disconnects yourself.

I hope this helps :)

[Aytackydln]

https://github.com/Aurora-RGB/Aurora uses RGB.NET like you mention it

[Aytackydln]

I'd say integrating your idea on ArtemisRGB or Aurora-RGB would be better

[TheAuthorsGrimm]

I’m looking more into live musical RGB and ARGB would be nice to have real time music, and Thanks I appreciate the Replies and suggestion I am looking into those as OpenRGB is using them so I’m on right track to end goal, and Dynamic Lights All in One Direction Microsoft trying to make happen. Honestly bit disappointed and surprised can’t do this at hardware signal level, SDK for each Company So why I was curious to see if what you had would assist me, thanks again for and Happy New Year!

…

On Thu, Jan 1, 2026 at 6:12 PM Aytaç Kayadelen ***@***.***> wrote: *Aytackydln* left a comment (DarthAffe/RGB.NET#437) <#437 (comment)> I'd say integrating your idea on ArtemisRGB or Aurora-RGB would be better — Reply to this email directly, view it on GitHub <#437 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUDCKBCTAWKLBBZALMQKNDT4EWLTBAVCNFSM6AAAAACQGMXGNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMBUGE3DGNJYGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>