First of all, control of my fans/coolers’ speed is a priority to me, controlling their LEDs is secondary. I use FanControl with the CorsairLink plugin to control my fans, and I’m trying to use SignalRGB for LED control,
I am also running HWiNFO in the background for monitoring purposes.
Both the CorsairLink plugin for FanControl and HWiNFO (among many others) have implemented the same “shared mutex” method for access to Corsair products. That takes care of any possible “collisions” since it will “temporarily kill” the device of two programs accessing it at the same time (a reboot will be required to “unkill” it). Now of course cases when the “shared mutex” is locked by another application will have to be handled.
Anyhow, currently, SignalRGB will just “kill” my Corsair AiO cooler, and I’m sure it’s because it’s trying to access it while it’s already being accessed by either HWiNFO or the CorsairLink plugin for FanControl.
It is my understanding that SIngnalRGB already has implemented this “shared mutex” method of locking/accessing Corsair devices, but for the “Corsair Commander” only. Please play nice, and please don’t just do it halfway, please implement this for all other applicable Corsair Link devices as well.
Don’t run other programs you say? Well, that is not an option as the other programs will have priority in my case, and they are the ones who “play nice”.
Coincidently OpenRGB has implemented the same “shared mutex” method for “Corsair Commander” devices as well, but they are in the process of expanding this to all applicable Corsair devices.
Playing nice is always a priority for us, link devices are new, and we adopted mutexes early. (before others)
We don’t tell you not to run other programs. Our software makes you very aware of things that may conflict, on purpose. What you’re suggesting about what we do, culturally, is fundamentally wrong. I’ll make sure this is on our docket, but your insinuations and comments here are a little off-putting.
We have a very long list of things to do, and limited resources to get them done - every item in gets scrutinized and I’ll make sure this is in the cue.
My apologies if you took this the wrong way, it was really not meant to be offensive or to suggest what you do or what internal culture you have. I was trying to point out why this is important, and maybe because English is really not my native language it came out a bit blunt.
You might be “playing nice”, but link devices are not at all new, and “before others” certainly doesn’t apply in this case.
Anyhow, I’m sorry that you took this the wrong way. I had no evil intentions in trying to make sure that this was being implemented for the better of everybody. In the above scenario, it is SignalRGB that is causing the issue, hence my description that you do not “play nice”. Maybe a bit blunt, but it is what it is.
My “don’t run other programs you say” was just meant to make it clear that to not to run those other programs to avoid this issue is not an option, it was not meant to suggest that that would be your answer or solution.
Thanks for considering this. Since “playing nice” is a priority to you I’m gonna assume that this will be quite high up on that long list of things to do. ::
Just to avoid any possible misunderstanding, when I am talking about “Corsair Link” above I am actually referring to Corsair devices (like AiOs) that "normally would be controlled by iCUE, and before that the “Corsair Link” software.
I was not referring to the new iCUE Link devices. But of course, support for those would be appreciated too, with the above-mentioned shared mutex if possible.
