Display will not turn off with iCue running -- Raw Input?

[pkillboredom]

Hello! I believe that there is a bug in the implementation of iCue's device driver that prevents displays from sleeping automatically (and presumably also system sleep). This is of importance to me as a user of an OLED display. If this is not something that is commonly experienced, please let me know and I will try to provide additional system info to narrow down a cause.

I have narrowed down the issue specifically to iCue, and I believe it may be due to raw input from the HID driver. The issue occurs whether or not the devices are in hardware memory mode.

Here are my system specs:

Windows 11 Version 23H2 (OS Build 22631.4317)

I am using both an H100i Platinum and a Lighting Node Core. ICue Version 5.20.89.

I can reproduce on my system that iCue and its drivers are responsible in two ways. The first is to simply shut down iCue AND disable its service.

1.  Set the screen-off timer to something short for easy testing.
   
2. Wait for your set amount of time without any input.
3. Display will not sleep after set duration.
4. Fully quit iCue from the tray icon.
   
5. From the Task Manager services tab, stop CorsairService.
   
6. Wait for your set amount of time without any input...
7. Display will sleep as expected.

I can reproduce more specifically that it is the communication between the iCue application and the HID driver with the following steps:

1. With iCue running...
2. Wait for your set display-off amount of time without any input.
3. Display will not turn off after time elapses.
4. Open Device Manager.
5. Under the View menu, select Device by Container.
   
6. Expand relevant nodes.
   
7. Disable the HID-compliant vendor-defined device for both Corsair devices.
8. Wait for your set display-off amount of time without any input.
9. Displays will turn off, even with iCue running. However, you will obviously not be able to control the lighting of the devices.

The issue is NOT being caused by any power management requests. Running "powercfg -requests" returns no requests. Further, I have manually added the Corsair service AND all associated device instance paths to the requestsoverride list and have seen no improvement:

While investigating the issue, I came across a similar issue that was present in NVIDIA GeForce Experience some years ago, thoroughly documented here:
https://github.com/nuzayets/rawinput-debug
Similarly to my issue, powercfg shows that there are no processes, services, or devices requesting that the display be kept on. In this case, the issue was being caused by a seemingly misconfigured use of libcef. Helpfully included in this repo is a debug utility that can show how long it has been since the system received raw input from an HID device: https://github.com/nuzayets/rawinput-debug/releases/tag/latest

Running this utility while diagnosing this problem, I have found that when iCue is running normally, there are messages occurring every second or less. (You should not use your mouse or keyboard while attempting to check for mystery inputs with this application.)

However, after performing either set of reproduction steps above, the inputs cease.

I believe that the inputs being observed by this application are responsible for my displays being kept awake.

If anyone has any input on this matter, even if just to say "me too!", it would be appreciated. As far as I can tell, no one else has documented this issue thoroughly.

And as one last note, the issue does not seem to be specific to my current Windows install. I actually reinstalled Windows several months ago due to this problem, without knowing its cause, and only upon reinstalling iCue this week have I been able to determine it as the culprit.

Edited November 12 by pkillboredom
Added iCue version.

[John Hoang]

Could you list all Corsair devices you're using?

[pkillboredom]

22 hours ago, John Hoang said:

Could you list all Corsair devices you're using?

Only a Lighting Node CORE hub and an H100i Platinum cooler.

[pkillboredom]

I gave this some more thought, and I disabled each of the two HID drivers individually instead of at the same time, just to see if it was a specific one... and it was! It was the H100i that was causing the messages to be sent continuously. If you are also facing this problem, you can disable just the H100i's HID driver. I wonder if this problem affects all Corsair AIOs. I suppose this is how they are sending pump stats to the OS?

 

In any case, I'll move my pump fans over to the controller to bypass the issue.

Edited November 17 by pkillboredom

[c-attack]

That's interesting.  I have been following this but I have been unable to recreate the issue with my gear.  I have a lot of more peripherals and controllers than you that are more likely to interact this way.  The one thing I don't have is a H100i Platinum.  So odd that device off all things is causing this problem.  I'll try to flag this for someone.  

If you don't tinker with fan speeds too much, you may be able to disconnect the USB for the H100i Plat to put it into hardware (DM Mode).  It will run from your saved fan curves.  If you have another RGB controller than can handle the fans, that is certainly an option.  You won't have desktop pump speed control in any of these scenarios, but you shouldn't need it either.  Just park it on Quiet in Device Memory Mode and leave it.