You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
privateasync Task ReadLoop(){while(!_cancellationTokenSource.IsCancellationRequested &&Connected){try{//todo: handle zeroawait _socket.ReceiveAsync(_headerBuffer, SocketFlags.None, _cancellationTokenSource.Token);vardataLength= ParseHeader();if(dataLength.Command == CommandId.DeviceListUpdated){//TODO: is this the best way to do this?
DeviceListUpdated?.Invoke(this, EventArgs.Empty);}else{vardataBuffer=newbyte[dataLength.DataLength];await _socket.ReceiveAsync(dataBuffer, SocketFlags.None, _cancellationTokenSource.Token);
_pendingRequests[dataLength.Command].Add(dataBuffer);}}catch(TaskCanceledException){//ignore}}}
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:
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: