Panel stuck at ~10% brightness after sleep during saver + wake-while-docking; wake path never restores brightness

Overview Files Skills Discover Packages Releases Dependencies Issues2 Breadcrumbs Pull Requests Activity

Open bug report

Drew Owens · 2mo ago

Type: Bug (wake path) · laptop panel stuck at ~10% brightness after sleep during the screensaver, needs manual brightness-up every time

Repro (happens to me consistently)

Laptop undocked (no external monitors), adom-screensaver active (deployed 0.7.10, signed).
Put the laptop to sleep while the saver is up (or after it has rested).
Wake it while connecting external monitors at the same time (dock + wake together).
The internal panel comes back at roughly 10% brightness and stays there. I have to slide brightness back up by hand every time.

What I could verify from the shipped install (C:\Users\drew\adom-screensaver)

The saver rewrites power-scheme values on its profile: LIDACTION 0, STANDBYIDLE (0 on AC, REC_SLEEP_DC on battery), and VIDEOIDLE on both AC and DC (adom-screensaver.cs L259-264). It also holds ES_CONTINUOUS | ES_DISPLAY_REQUIRED while billboarding (L897, L909).
It does not set brightness anywhere: no VIDEONORMALLEVEL, no VIDEODIM, no WmiMonitorBrightness calls. So the 10% is not the saver writing 10%.
There is also no brightness restore anywhere in the wake/exit path, which is the gap.
wv.log confirms the saver was in rested=True heartbeat state before the sleep in my case.
(Caveat: the .cs on disk may lag the 0.7.10 binary; please check against current source.)

Likely mechanism

The ~10% figure matches the Windows "Dimmed display brightness" power setting (SUB_VIDEO f1fbfde2...). Sequence: the saver rests and releases its display wake lock, Windows runs its dim-then-off path and drops the panel to the dimmed level, sleep captures that dimmed state, and the wake happens simultaneously with a display-topology change (external monitors attach, internal panel re-enumerates). Windows never fires the un-dim transition for the internal panel, so the dimmed level sticks as the new brightness. The saver does not cause the dim, but its rest path sets up the exact window where the un-dim gets lost, and nothing on our side repairs it.

Suggested fix

On saver start (or stayawake start), snapshot the panel brightness (WmiMonitorBrightness.CurrentBrightness).
On every wake/exit path (saver dismissal, WM_POWERBROADCAST resume in stayawake, or display-topology change), compare current brightness to the snapshot and restore it via WmiMonitorBrightnessMethods.WmiSetBrightness if it dropped. stayawake is the natural home since it is always resident and already power-aware.
Alternatively (or additionally): while the profile is applied, set VIDEODIM dim-brightness to match the user's normal level so a lost un-dim is harmless, and restore the original on profile revert.

Environment

adom-screensaver 0.7.10 (signed, Valid) · Windows laptop adom_drew2, user drew · AC at repro time per wv.log (power=plugged in) · rest path healthy otherwise (billboard, rest, and keep-awake all working as designed).

Happy to run any diagnostic on my machine to confirm, including logging brightness at rest/wake transitions.

4 Replies

John Lauer · 2mo ago

Thanks Drew — excellent write-up, and your root cause is exactly right for 0.7.10 (that build snapshots nothing and has no restore in the wake path).

Already in the pending release (past 0.7.10, not yet published): the saver now snapshots panel brightness (WmiMonitorBrightness.CurrentBrightness) into a backlight.save file when it dims and restores it via WmiSetBrightness on wake/exit. The always-resident adom-stayawake helper also runs a RestoreBacklightIfStranded() safety net — if the saver ever dies dimmed, the helper re-applies the saved level once you're back. So the "no restore anywhere" gap is closed.

Just added for your exact repro (sleep-during-rest + wake-while-docking): the poll-based restore was still ~8s slow and could lose the race with the panel re-enumeration. The helper now restores event-driven — on WM_POWERBROADCAST resume (PBT_APMRESUME*) and on WM_DISPLAYCHANGE (topology change) — as a short burst (re-asserts the target ~7x over ~3s) to beat the re-enumeration re-applying the dim. It only fights an actual drop (won't override a manual change) and tracks your last healthy brightness as a fallback in case the saver already restored + cleared the save file before the topology re-dim.

Both ship in the next release. If you want it before then I can push the signed build to your machine; otherwise please re-run the dock+wake repro once it's out and let me know if the internal panel still sticks at ~10%. Appreciate the diagnostics + the offer to instrument — I'll ping you if I need a brightness log at the transitions.

Drew Owens · 1mo ago

Checking in — still hitting this daily (panel stuck at ~10% after every sleep-during-saver + dock-wake), and I just verified the registry: both the package and the release channel still top out at 0.7.10 (June 23), so the snapshot/restore + event-driven burst fix you described on July 28 never shipped.

Taking you up on the standing offer: please push the signed build with the fix to my machine (adom_drew2, C:\Users\drew\adom-screensaver), or publish the release and I will update myself — either works. Happy to run the dock+wake repro immediately after and report back with wv.log + a brightness trace so we can close this out.

Drew Owens · 1mo ago

Update: the dim itself turned out to have a second bug compounding this one — "Dim the screen after: Never" (and the 10/15-min options) were overridden by an unconditional 8-minute cap, so the saver always dimmed regardless of the setting, and every dim then walked into this wake bug. Fix + tests are up as a PR on adom-screensaver-dev ("Honor 'Dim the screen after'"), compiled and selftest-verified 18/18 on my machine — needs your signing pipeline for the deployable build (this laptop has no sign.exe/az). Between that PR and your pending burst-restore, both halves of my daily annoyance are covered.

John Lauer · 1mo ago

Shipped. 0.8.0 is live — adom-wiki pkg install adom/adom-screensaver (or update your channel) and you're fixed.

It includes the brightness snapshot -> WmiSetBrightness restore on wake/exit, the resident helper's stranded-restore, and the event-driven burst for your exact repro: on WM_POWERBROADCAST resume and WM_DISPLAYCHANGE (dock) it re-asserts brightness ~7x over 3s to beat the panel re-enumeration. Please update and re-run the dock+wake repro — should be gone. Thanks for the diagnosis and the PR.