Streaming now survives the Windows lock screen, and the display restore is transactional. Both changes were verified on real hardware, not just in tests.
Fixed
- Controller and touchpad keep working through sign-in. Streaming to a locked PC used to lose all input the moment Windows switched from the clock screen to the secure PIN/password screen, which meant you could see the machine but not log into it. Windows startup is now owned by an automatic
LocalSystemservice rather than a user task, so input survives that switch. Verified on device: reached the PIN screen over a stream, signed in with the on-screen keypad and touchpad-as-mouse. - Display restore is now one transaction with a confirmed fallback. After a stream ends, the helper tries the saved snapshot and, if that does not confirm, applies the Windows display database and verifies the result before reporting success - checking that a real topology came back, that a primary display exists at
(0,0), and that the OS accepts it. Previously a scheduled restore could be treated as a completed one, so a failure had no second owner. - Excluding a display no longer produces an impossible layout. If the saved primary display was excluded from a restore, its primary role is now re-assigned to a surviving display and the remaining displays are re-anchored to it. Before this, a snapshot could be left with no primary and a display stranded at an off-screen offset - a layout Windows can never apply, so restore retried forever.
- A disabled monitor is no longer dropped from its own restore. Saved layouts are filtered only by explicit exclusions, not by whichever displays happen to be enumerable mid-teardown, so a monitor the stream had switched off still gets switched back on.
- Virtual displays are identified from live enumeration rather than remembered IDs, so a stale or reused identifier can no longer remove a physical monitor from a restore baseline.
Notes
Windows installer SHA-256: 4D38B564544FAF11E4EFE4D24A59C9A620F8CBFBBF4D47D526CC4AF343ADDCCB