summaryrefslogtreecommitdiff
path: root/libs/gui/BufferQueueConsumer.cpp
diff options
context:
space:
mode:
author Dominik Laskowski <domlaskowski@google.com> 2023-05-17 12:46:21 -0400
committer Dominik Laskowski <domlaskowski@google.com> 2023-12-15 13:59:54 -0500
commitaaab4c3b4f012f48bca428b9db1cd954a6fbc8e9 (patch)
tree6a187a290826434b9ec97ab163798f87c28a6458 /libs/gui/BufferQueueConsumer.cpp
parentb067fdcf505f65137ecfb4ee5bb6d337cfbcd477 (diff)
SF: Flow DisplayModeRequest through mode set FSM
The motivation is to: - Avoid redundant state that can cause data races if stale. - Consolidate control flow for resolution and refresh rate changes. - Clarify the desired/pending/active states of the per-display FSM. The notable changes are: Consume the desired DisplayModeRequestOpt via either SF::dropModeRequest or DisplayDevice::initiateModeChange. Pull the details of SF::finalizeDisplayModeChange into DisplayDevice:: finalizeModeChange, which now returns whether there was NoModeChange, a ResolutionChange, or a RefreshRateChange. Consume the pending request. Now that DisplayDevice does not retain the desired DisplayModeRequest, applyActiveMode as soon as finalizeDisplayModeChange ends, rather than at a later point in the commit, when initiateDisplayModeChanges checks whether the active and desired modes are the same. Now that applyActiveMode happens in finalizeDisplayModeChange, remove the special case when there is a displayToUpdateImmediately. Bug: 305813445 Bug: 255635711 Bug: 241285876 Test: ALOGV of mode setting for inner/outer displays Test: InitiateModeChangeTest, DisplayModeSwitchingTest Change-Id: I688b0c922747a80e881965a1dc243d11ba2c7438
Diffstat (limited to 'libs/gui/BufferQueueConsumer.cpp')
0 files changed, 0 insertions, 0 deletions