Repository navigation
fix(scan): keep Windows awake while a scan runs - #1361
Merged
marcinz606 merged 2 commits intoOct 11, 2026
Merged
Conversation
thetalkingdrum
marked this pull request as ready for review
October 11, 2026 15:44
A scan batch runs for many minutes without keyboard or mouse input, so Windows idle sleep can suspend the PC in the middle of a pass. The pass then ends at the wake with the unread part of the frame left as zeros, and the IR validity mask still says the whole frame is valid. Four frames of one session were cut off this way: each was saved within two seconds of a System Idle wake, at 0.7%, 26%, 58% and 66% of the frame. power_assertion.py held a real assertion on macOS only. On Windows the assertion is now the calling thread's execution state with ES_SYSTEM_REQUIRED, so the display may still turn off. run_batch acquires and releases it on one thread, as the state requires. Linux still gets an inert assertion. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A single-frame scan runs for minutes without input, so idle sleep can cut it off the same way as a batch. run_scan now acquires the assertion like run_batch and releases it in its finally block. Tests cover the single scan, its error path and the batch, which had none. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
thetalkingdrum
force-pushed
the
fix/windows-scan-keep-awake
branch
from
October 11, 2026 15:45
cf34f22 to
c34c705
Compare
Contributor
Author
|
I could make a pr for linux as well but I can't test it. Would you rather do it? @marcinz606 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A scan runs for minutes without keyboard or mouse input, so Windows idle sleep can suspend the PC in the middle of a pass. The pass then ends at the wake with the unread part of the frame left as zeros, and the IR validity mask still marks the whole frame as valid. In one unattended session, four frames were cut off this way: each file was saved within two seconds of a System Idle wake (Kernel-Power sleep and Power-Troubleshooter wake events), with data ending at 0.7%, 26%, 58% and 66% of the frame width. Since the incomplete-pass check in #1146 such a frame raises an error instead of being saved, but the scan is still lost.
power_assertion.pyheld a real assertion on macOS only. On Windows it now sets the calling thread's execution state withES_SYSTEM_REQUIRED, so the display can still turn off.run_batchacquires and releases it on one thread, as the state requires. The second commit holds it forrun_scanas well, so a single-frame scan is covered. Both paths now have a test.Linux still gets the inert assertion. The user guide says to turn off automatic suspend before a long roll. A logind inhibitor would need a Linux desktop to test, so it is not part of this PR.
Tested with a fake kernel32 for acquire, release, refusal and failure, with the scan worker tests, and against the real API: the thread's state reads
0x80000001while held and0x80000000after release. Not tested with a full unattended roll on hardware.🤖 Generated with Claude Code