Add pending period to DispSync.
When the period is updated due to a config change, cache the period
and don't immediately update the model until we actually observe updated
vsyncs from the hardware.
To make this more reliable, force hardware vsync to be enabled when we
first initiate a refresh rate change.
Also, override offsets with custom offsets while the period is in flux,
so that we don't fall into bad offsets when ramping up to 90hz
Bug: 128848865
Bug: 128860504
Test: systrace
Change-Id: I6aa87ad29b3effce9067a1d54d444023c7362b22
diff --git a/services/surfaceflinger/Scheduler/Scheduler.cpp b/services/surfaceflinger/Scheduler/Scheduler.cpp
index b1c39ef..e641c9e 100644
--- a/services/surfaceflinger/Scheduler/Scheduler.cpp
+++ b/services/surfaceflinger/Scheduler/Scheduler.cpp
@@ -255,7 +255,6 @@
void Scheduler::setVsyncPeriod(const nsecs_t period) {
std::lock_guard<std::mutex> lock(mHWVsyncLock);
- mPrimaryDispSync->reset();
mPrimaryDispSync->setPeriod(period);
if (!mPrimaryHWVsyncEnabled) {
@@ -265,12 +264,13 @@
}
}
-void Scheduler::addResyncSample(const nsecs_t timestamp) {
+void Scheduler::addResyncSample(const nsecs_t timestamp, bool* periodChanged) {
bool needsHwVsync = false;
+ *periodChanged = false;
{ // Scope for the lock
std::lock_guard<std::mutex> lock(mHWVsyncLock);
if (mPrimaryHWVsyncEnabled) {
- needsHwVsync = mPrimaryDispSync->addResyncSample(timestamp);
+ needsHwVsync = mPrimaryDispSync->addResyncSample(timestamp, periodChanged);
}
}