fix(macos): wake sleeping display at the beginning of capture session - #5291
Conversation
|
We should probably add display automation logic to https://github.com/LizardByte/libdisplaydevice |
|
That makes sense long-term. I think this belongs in libdisplaydevice once macOS support exists there. But since AVFoundation capture can hang before any frames are delivered if the target display is asleep, Sunshine never reaches the point where client input can wake it. Would you be open to keeping the minimal wake/prevent-sleep logic here for now? I can also trim the diagnostic logging from this PR to keep it tighter. (Actually already have, would just need to resubmit the PR: it's -122 lines at the cost of some log clarity around display initialization.) |
|
The size of this PR is not really a problem, it's small enough as is. Would you be willing to help implement the library for macOS? This is not really work I can do since I don't own any macOS devices. |
|
Yeah I could. It's a non-trivial amount of work but it makes sense to do. I took a quick look at the code and there's almost certainly blockers in the way to complete feature parity using only public APIs (EnsurePrimary, EnsureOnlyDisplay, HDR...) but most of it - the parts that actually matter: enumeration, wake, mode selection, revert/persistence - are straightforward to implement. My recommendation would be to keep this PR as the Sunshine-side bugfix if you’re generally OK with the approach. Then I can follow up with a draft/best-effort libdisplaydevice port and a feature matrix for what works vs what macOS doesn’t expose cleanly. Once that happens, we can integrate Sunshine with it and remove the duplicated macOS display handling here. |
fdb65f8 to
7b16ca2
Compare
Bundle ReportBundle size has no change ✅ |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5291 +/- ##
=========================================
Coverage ? 17.86%
=========================================
Files ? 111
Lines ? 24589
Branches ? 10888
=========================================
Hits ? 4392
Misses ? 17650
Partials ? 2547
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Harness.
|
ReenigneArcher
left a comment
ReenigneArcher
left a comment
There was a problem hiding this comment.
I just have a small nit pic.
93b5532 to
73c013b
Compare
|
Wake the selected display before encoder probing, hold a display-sleep assertion for the capture lifetime, and bound first-frame waits so a sleeping virtual display cannot hang launch indefinitely. Based on the macOS power assertion approach from upstream Sunshine PR LizardByte#5291 (c9863eb).
2 participants
Description
Wakes the display at the beginning of the capture session, and does not let it go to sleep while it's active.
macOS does not present any capture frames on a sleeping display, thus the capture thread hangs indefinitely at session start, never sending video data to Moonlight, and therefore is not able to receive any input to wake the display either. The end result is a forever "spinning on connect" Moonlight client, and a hung Sunshine process.
This PR fixes the problem by issuing an
IOPMAssertionDeclareUserActivitybefore capture start to handle the initial wake, and holding ankIOPMAssertPreventUserIdleDisplaySleepassertion for the lifetime of the capture object to prevent sleep.I realize it's chonky; I could cut this down to about 30-40% of the proposed size by eliminating the display diagnostic logging that I added to help me track down the issue. I think it's useful to have there though, so I'm leaving it in for the original PR; but very much open to reducing it if needed.
Issues Fixed or Closed
Roadmap Issues
Type of Change
Checklist
AI Usage