Interface elements that never move, such as taskbars and status bars, burn permanently into an OLED panel if they sit there long enough.
Windows tracks idle time globally, which does not fit a multi-monitor desk. Typing on the primary screen counts as activity everywhere, so a secondary monitor showing a static dashboard stays fully lit.
OLED Sleeper manages each display on its own. Every monitor gets its own timer, its own criteria for what counts as idle, and its own action when the timer expires.
There are two actions. Dimming goes over DDC/CI, which talks to the monitor hardware directly. Blacking out draws a full-screen black overlay. The utility never issues a hardware power-off command.
Two displays, two independent timers. The idle one blacks out under a full-screen overlay while the one being worked on is left alone.
Constraints
People run a compiled binary from a stranger on their personal machine. Avoiding third-party dependencies keeps the amount of trust that requires as small as I could make it.
The overlay has to come off cleanly every time. If the application crashes, the overlay must clear immediately or the display is unusable.
Monitors advertise DDC/CI support and then silently ignore the commands. A monitor can accept a brightness command, return success, and change nothing; another can accept it and apply it seconds later. The software has to survive all of that without crashing and without leaving a display dark.
Idle means different things to different people, so the utility supports several triggers: cursor movement on a specific display, activity in a focused window, and global system input.
Decisions
Command pattern, with detection separated from execution
Instead of
Event handlers wired directly to displays
Why
Three ways of detecting idle and two actions is six wirings under plain handlers. With a command in between, detection emits and the executor runs, and neither knows about the other. A fourth detector becomes one emitter, and a third action becomes one command.
Zero external dependencies
Instead of
Existing wrapper libraries for Win32 and DDC/CI
Why
I wrote the Win32 and DDC/CI integrations by hand rather than pulling in wrappers. The whole codebase is auditable that way, and when a bug arrives from hardware I do not own, I can fix it in my own code instead of waiting for an upstream maintainer.
Black overlay, not OS monitor power-off
Instead of
The Windows API call that powers the display off
Why
The Windows display-change pipeline is slow. Triggering it freezes the OS while it runs and force-migrates every open window off the disabled monitor. An OLED panel has no backlight, so a pure black overlay turns the pixels off and reaches the same hardware state. The windows stay where they were and the OS never stalls.
Detection produces a command; whatever executes it does not know which detector fired. Extending either side is an addition on that side alone.
What I owned
I did the whole project: design, implementation, releases, and issue triage.
Outcome
The utility is distributed on SourceForge and was picked up on Hacker News.
Most updates since the first release fix hardware quirks that users reported. The split between detection and action is what made those cheap: a fix landed in the detection files or in the action files, and rarely in both.
Having no dependencies means no maintenance work arrives from third-party library updates.
