search

EvanMulawski / FanControl.CorsairLink

The unofficial CorsairLink plugin for Fan Control. Adds support for Corsair controllers, liquid coolers, and power supplies. An alternative to iCUE.
120 stars 9 forks source link

OpenRGB compatibility #101

Open EvanMulawski opened 9 months ago

EvanMulawski commented 9 months ago

OpenRGB needs to implement the well-known Corsair mutex that provides compatibility with other software. This was added for Commander CORE devices in commit 6c8da3a0.

I have opened a merge request that improves it and updates existing Corsair RGB controllers to use it.

If you want to use OpenRGB with the CorsairLink Fan Control plugin, please upvote and comment on the merge request!

Now Available

See the comment below.

chjohans commented 8 months ago

Any idea on the progress on this over at OpenRGB?

And if this is implemented, will the shared mutex be used for "Commander Pro" devices as well? I only see COmmander Core and Lightning Node specifically mentioned.

EvanMulawski commented 8 months ago

@chjohans No idea on the status and no response from the developer. The "Lighting Node" implementation handles the Commander PRO devices (0c10 and 1d00).

chjohans commented 8 months ago

Ok, thanks @EvanMulawski ! Too bad, he gets compatibility with plenty of COrsair devices served on a silver platter and he doesn't even bother to respond. Thanks again for creating this plugin, I finally have proper fan control for my Corsair devices! :)

chjohans commented 8 months ago

@EvanMulawski I see that you forked OpenRGB over at GitLab, and I assume you must have built a version for Windows with your Corsair mutex implemented in order to test. While I'm waiting for @CalcProgrammer1 to hopefully accept your merge request, do you happent to have a x64 binary with this available?

chjohans commented 8 months ago

@EvanMulawski I see that the developer finally responded again over at GitLab, he wants some more changes though. Hopefully, this will be doable in the not-too-distant future. :)

chjohans commented 8 months ago

@EvanMulawski Thanks for your effort with OpenRGB, I see that you already responded to the devs request over at GitLab. Looking forward to having the shared mutex in OpenRGB! I'll go buy you a coffee now! :)

Fr0stX76 commented 8 months ago

Your commit has been merged! Thanks for the hard work you putted into this. Guess its time for me to dust off my corsair guears...

EvanMulawski commented 8 months ago

As OpenRGB 1.0 has not been released yet, the compatible Windows 64-bit build is linked below. Builds for master produced by pipelines after #1068292631 have compatibility.

OpenRGB_Windows_64_f6723975.zip

Merge commit

Zeromoon95 commented 7 months ago

Ran into issues with my Corsair H100i Pro XT when using Hardware Sync Plugin using a temperature setting on my CPU block.

Tried using a build that posted above but it gets stuck when detecting Corsair Hydro H100i Pro XT.

Help would be appreciated

CorsairLink.log log.txt

EvanMulawski commented 7 months ago

@Zeromoon95 Does this issue occur if OpenRGB is not running?

Zeromoon95 commented 7 months ago

@EvanMulawski It doesn't, I think but it doesn't run the plugin that syncs the temps.

I manage to update to the newer build you provided. But still getting issues.

Not sure if the errors are different, but here from here using the latest build: CorsairLink.log log.txt

EvanMulawski commented 7 months ago

@Zeromoon95 That is a different error - the data being read from the device is garbage/unusable (which explains the checksum error) and this indicates the device is in a bad state and needs to be rebooted. iCUE performs a device reboot when this issue occurs (and it's on the roadmap for this plugin - see #80).

Zeromoon95 commented 7 months ago

Well, So far I haven't gotten anymore errors since disabling the Hardware Sync Plugin so it might have been the effect from that.

Fr0stX76 commented 7 months ago

Tte Hardware Sync Plugin of OpenRGB, depending on the effect chosen and the FPS, will flood the device with data sent. The new interlock in theory should prevent this, for reasonnable r/w using it (ex hwinfo pooling at 1000ms + fan control corsairlink 1000ms + some open rgb profile change).

Now using an effect with Tte Hardware Sync Plugin of OpenRGB with 60fps frequency might be too much for it.

Maybe try lowering the fps of the effect?

Zeromoon95 commented 7 months ago

Tte Hardware Sync Plugin of OpenRGB, depending on the effect chosen and the FPS, will flood the device with data sent. The new interlock in theory should prevent this, for reasonnable r/w using it (ex hwinfo pooling at 1000ms + fan control corsairlink 1000ms + some open rgb profile change).

Now using an effect with Tte Hardware Sync Plugin of OpenRGB with 60fps frequency might be too much for it.

Maybe try lowering the fps of the effect?

I did, went to 1 fps and it's working fine so far.

Fr0stX76 commented 7 months ago

@Zeromoon95 to be clear, I'm not saying it is the issue, just that it is a possibility. My theory is that when the device receive a significant amount of data in a short period, the communication bus somehow "trip" and thus the device need to be rebooted. The fact that Icue is rebooting it kinda indicate that Corsair is aware of this issue.

I would suggest increasing the FPS of the OpenRGB effect until you reach the "trip" point and then stay below. 30FPS in my tests kinda look decent. Plus lower effect FPS = less CPU usage. Some of those use a lot of CPU power depending on your setup, and I suspect the mutex (lock) might be adding a bit more.

I would be curious to know if the device would still "trip" and stop responding if you did not use anything but OpenRGB with the Hardware Sync Plugin. I would see if using an effect at 60FPS with only OpenRGB (as is not use FanControl.CorsairLink, HWinfo or SIV at all for this test), if the device woul still "trip". If it did not, then that would indicate that the issue is with OpenRGB effects, ruling out other software listed above.

Zeromoon95 commented 7 months ago

@Zeromoon95 to be clear, I'm not saying it is the issue, just that it is a possibility. My theory is that when the device receive a significant amount of data in a short period, the communication bus somehow "trip" and thus the device need to be rebooted. The fact that Icue is rebooting it kinda indicate that Corsair is aware of this issue.

I would suggest increasing the FPS of the OpenRGB effect until you reach the "trip" point and then stay below. 30FPS in my tests kinda look decent. Plus lower effect FPS = less CPU usage. Some of those use a lot of CPU power depending on your setup, and I suspect the mutex (lock) might be adding a bit more.

I would be curious to know if the device would still "trip" and stop responding if you did not use anything but OpenRGB with the Hardware Sync Plugin. I would see if using an effect at 60FPS with only OpenRGB (as is not use FanControl.CorsairLink, HWinfo or SIV at all for this test), if the device woul still "trip". If it did not, then that would indicate that the issue is with OpenRGB effects, ruling out other software listed above.

Staying in 1 only look fine, if I go any higher I get a lighting issue with an odd color on part of the lighting until I hard shutdown my computer to reset it.

Running with OpenRGB only worked fine as of 60 fps.

Zeromoon95 commented 7 months ago

Oh it finally crashed the lighting died in black before I hard shutdown and booted again even on 1 fps. Guess I turning off Hardware Sync for now.