What is claimed, and what was tested
The README says a session survives sleep, wake, Wi-Fi drops and display reconfiguration, and that capture recovery is typically under 0.1 s.
The recovery path is exercised in tests — but through the same entry point the wake notification calls, not by actually sleeping the Mac. Nobody has closed the lid and opened it again with a receiver attached.
That gap is listed under "What isn't proven yet", and it is the most likely of those to be hiding something, because sleep and wake touch every layer at once: the virtual display, the capture stream, the socket, and the receiver's decoder all have to come back, in an order nobody has controlled.
What to try
Each of these with a receiver connected and something moving on the second display:
- Sleep and wake the Mac — lid, and
pmset sleepnow. Does the display come back? Do the user's windows stay where they were?
- Let the receiver's machine sleep while the Mac keeps sharing.
- Drop the Wi-Fi on either end and bring it back.
- Plug in or unplug a real monitor while sharing, which triggers
CGDisplayRegisterReconfigurationCallback and is the case the supervisor watches for.
- Change the Mac's resolution in System Settings during a session.
What to record
- Whether it recovered at all, and roughly how long it took
- Whether window arrangement survived — the virtual display dies with the process holding it, and
vd_helper exists as a separate process specifically so a crash elsewhere does not scatter your windows. This is the case that tests that claim.
- What each end displayed while it was recovering. A recovery that works but shows nothing useful for ten seconds is still a bug worth filing.
- Anything in the Mac's log:
log stream --predicate 'process == "DisplayShare"'
Related
The supervisor no longer treats a still desktop as a stalled capture (#63) — it now watches a heartbeat that counts idle frames. That change makes a genuine stall easier to see, and it has not been exercised against a real one.
What is claimed, and what was tested
The README says a session survives sleep, wake, Wi-Fi drops and display reconfiguration, and that capture recovery is typically under 0.1 s.
The recovery path is exercised in tests — but through the same entry point the wake notification calls, not by actually sleeping the Mac. Nobody has closed the lid and opened it again with a receiver attached.
That gap is listed under "What isn't proven yet", and it is the most likely of those to be hiding something, because sleep and wake touch every layer at once: the virtual display, the capture stream, the socket, and the receiver's decoder all have to come back, in an order nobody has controlled.
What to try
Each of these with a receiver connected and something moving on the second display:
pmset sleepnow. Does the display come back? Do the user's windows stay where they were?CGDisplayRegisterReconfigurationCallbackand is the case the supervisor watches for.What to record
vd_helperexists as a separate process specifically so a crash elsewhere does not scatter your windows. This is the case that tests that claim.log stream --predicate 'process == "DisplayShare"'Related
The supervisor no longer treats a still desktop as a stalled capture (#63) — it now watches a heartbeat that counts idle frames. That change makes a genuine stall easier to see, and it has not been exercised against a real one.