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
7 files changed