Problem
When I use "Turn off displays" from the flyout, the displays turn back on after about 60 seconds with no interaction.
I traced the cause with a Raw Input logger. My wireless mouse (WLMOUSE Beast Max 8K) sends one HID input report when it enters its 1-minute power-saving sleep. Windows counts that report as user input and turns the displays back on. I clicked Twinkle Tray with the mouse, so the mouse's sleep timer always ends after the displays are already off. The same thing happens with other wireless mice that send a report on sleep, and I've seen reports of it with other vendors.
Twinkle Tray isn't at fault here. The same thing happens with a plain SC_MONITORPOWER broadcast. Still, Twinkle Tray is where the off button lives, so it's the natural place for a workaround.
Suggested options (any one of these would solve it)
- A configurable delay before "Turn off displays" takes effect (e.g. 0–120 s).
- A "turn off displays when idle for N seconds" action that uses GetLastInputInfo. With N longer than the mouse's sleep timer, the report would land before the displays turn off.
- Re-send the off command if new input arrives within N seconds of turning off, as long as that input is a single isolated event.
Workaround I'm using: a script that waits for a lone input about 60 s after the last one, then sends SC_MONITORPOWER. It works reliably.
Twinkle Tray [version, e.g. v1.17.2], Windows 11 [build 26200], sleepAction: "ps"
Problem
When I use "Turn off displays" from the flyout, the displays turn back on after about 60 seconds with no interaction.
I traced the cause with a Raw Input logger. My wireless mouse (WLMOUSE Beast Max 8K) sends one HID input report when it enters its 1-minute power-saving sleep. Windows counts that report as user input and turns the displays back on. I clicked Twinkle Tray with the mouse, so the mouse's sleep timer always ends after the displays are already off. The same thing happens with other wireless mice that send a report on sleep, and I've seen reports of it with other vendors.
Twinkle Tray isn't at fault here. The same thing happens with a plain SC_MONITORPOWER broadcast. Still, Twinkle Tray is where the off button lives, so it's the natural place for a workaround.
Suggested options (any one of these would solve it)
Workaround I'm using: a script that waits for a lone input about 60 s after the last one, then sends SC_MONITORPOWER. It works reliably.
Twinkle Tray [version, e.g. v1.17.2], Windows 11 [build 26200], sleepAction: "ps"