-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Discussion - Device Addition and Removal #360
Comments
I like the idea of supporting hotplugging/reconnect scenarios in general (and discussed that a while back with @Aytackydln) but the way RGB.NET works causes some problems in that regard and adds a lot of complexity and potential issues, which make a feature like this quite hard to implement in the lower levels. (Even on device-provider level is a lot that can break stuff for user). |
I've been using my changes on a fork on Aurora since I made the PRs. Though it only works when manually refreshing the devices and on start of OpenRGB, I've seen no reports of any weird behaviour. Though as you've mentioned Aurora just uses rgb.net as an interface to send color data and not for the surfaces it provides Edit: also testing with the latest hotplug fork of OpenRGB. So far good. |
I'm making this issue mostly because of OpenRGB's hotplug support. It will listen for changes and detect devices as they are plugged in. This is useful for some wireless devices that will be turned on and off whislt OpenRGB is expected to stay running.
The OpenRGB SDK implements this by sending a device update packet through the socket:
My question is: does any other device provider implement something like this? Do we even want to handle this on the RGB.NET level? I could have artemis start up a new OpenRGB SDK connection and restart the plugin when one of these events is received if that's better. Opinions?
The text was updated successfully, but these errors were encountered: