Reland "Create a VsyncSchedule per display"
In order to determine the vsync offsets between displays, keep track of
a VsyncSchedule for each display.
Store the VsyncSchedules in a SmallMap. Update getVsyncSchedule with a
parameter to choose the display. The default parameter uses the leader's
display, which is what many current callers want.
Update VsyncDispatches when the leader changes, so that they are always
listening to the leader.
Enable and disable vsync callbacks per display. Earlier attempts to turn
them on and off together could leave a secondary display on a bad
schedule. Add a method for resyncing all displays at once.
Use std::shared_ptrs for VsyncDispatches. This prevents lifetime issues
if a VsyncSchedule gets removed while its VsyncDispatch is still in use.
Same for VsyncTracker, which is referenced by VsyncDispatch.
When the leader VsyncSchedule changes, call cancel on
VsyncCallbackRegistrations and replace them with new ones using the new
VsyncDispatches. If a callback was scheduled, schedule a new one.
Update VsyncSchedule's members' traces so that there is a separate track
for each display.
For refresh rate changes, modulate vsync config based on the leader
display. When switching leaders, force a period transition to ensure
that a potential refresh rate change is completed.
This reverts commit db16a2be4054d0dd7d940f4fa0a2ced0575fd2e7 aka
I0757a7df540fad316b2db42e4c77f1c73bc49420, which reverted the original
CL, If60218e85292c786b9fa70ecb33ee374d3a385e0. Notable differences from
the original CL:
- Logical pieces have been separated and landed in the following CLs:
- I21be76e20776d8a3f49e5bd295a0042de9e2dde9
- I062002245db8fd817e145a3aaf197bb874b00636
- I54a1304a3428968134cc707b24d5b325927c31df
- Remove IEventThreadCallback changes. These are ultimately orthogonal
to the motivation of this CL.
- Store the ID instead of the name and use ftl::Concat, as tracked in
b/266817103.
- Rename MessageQueue::updateVsyncRegistration to onNewVsyncSchedule, to
match the name in EventThread. These methods do essentially the same
thing, so use the same name.
- Crucially, I54a1304a3428968134cc707b24d5b325927c31df restores the
pending HWC Vsync state, which was originally removed in
If60218e85292c786b9fa70ecb33ee374d3a385e0. The removal seems to have
been responsible for b/267562341.
Bug: 255601557
Bug: 256196556
Bug: 241285473
Bug: 241286146
Bug: 268366385
Fixes: 266817103
Test: libsurfaceflinger_unittest
Test: manual (look at perfetto traces)
Change-Id: Icdb80253436b4d0034fc20fcae8583efb7c30292
diff --git a/services/surfaceflinger/SurfaceFlinger.h b/services/surfaceflinger/SurfaceFlinger.h
index b41f414..61fab81 100644
--- a/services/surfaceflinger/SurfaceFlinger.h
+++ b/services/surfaceflinger/SurfaceFlinger.h
@@ -646,7 +646,7 @@
// Toggles hardware VSYNC by calling into HWC.
// TODO(b/241286146): Rename for self-explanatory API.
- void setVsyncEnabled(bool) override;
+ void setVsyncEnabled(PhysicalDisplayId, bool) override;
void requestDisplayModes(std::vector<display::DisplayModeRequest>) override;
void kernelTimerChanged(bool expired) override;
void triggerOnFrameRateOverridesChanged() override;
@@ -1132,7 +1132,15 @@
pid_t mPid;
std::future<void> mRenderEnginePrimeCacheFuture;
- // access must be protected by mStateLock
+ // mStateLock has conventions related to the current thread, because only
+ // the main thread should modify variables protected by mStateLock.
+ // - read access from a non-main thread must lock mStateLock, since the main
+ // thread may modify these variables.
+ // - write access from a non-main thread is not permitted.
+ // - read access from the main thread can use an ftl::FakeGuard, since other
+ // threads must not modify these variables.
+ // - write access from the main thread must lock mStateLock, since another
+ // thread may be reading these variables.
mutable Mutex mStateLock;
State mCurrentState{LayerVector::StateSet::Current};
std::atomic<int32_t> mTransactionFlags = 0;