Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 23d7a392 authored by Rupesh Bansal's avatar Rupesh Bansal Committed by Automerger Merge Worker
Browse files

Merge "Setting the display state to off when the default display is being...

Merge "Setting the display state to off when the default display is being changed" into tm-qpr-dev am: 3284b2ae

Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/20882606



Change-Id: I3b76b1c5539ab6790cb653aa19dec16a076c17e2
Signed-off-by: default avatarAutomerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
parents 8b13751e 3284b2ae
Loading
Loading
Loading
Loading
+2 −2
Original line number Diff line number Diff line
@@ -818,8 +818,8 @@ final class DisplayPowerController implements AutomaticBrightnessController.Call
                loadFromDisplayDeviceConfig(token, info);

                // Since the underlying display-device changed, we really don't know the
                // last command that was sent to change it's state. Lets assume it is unknown so
                // that we trigger a change immediately.
                // last command that was sent to change it's state. Lets assume it is off and we
                // trigger a change immediately.
                mPowerState.resetScreenState();
            }
            if (mIsEnabled != isEnabled || mIsInTransition != isInTransition) {
+11 −3
Original line number Diff line number Diff line
@@ -340,12 +340,20 @@ final class DisplayPowerState {
    }

    /**
     * Resets the screen state to unknown. Useful when the underlying display-device changes for the
     * LogicalDisplay and we do not know the last state that was sent to it.
     * Resets the screen state to {@link Display#STATE_OFF}. Even though we do not know the last
     * state that was sent to the underlying display-device, we assume it is off.
     *
     * We do not set the screen state to {@link Display#STATE_UNKNOWN} to avoid getting in the state
     * where PhotonicModulator holds onto the lock. This happens because we currently try to keep
     * the mScreenState and mPendingState in sync, however if the screenState is set to
     * {@link Display#STATE_UNKNOWN} here, mPendingState will get progressed to this, which will
     * force the PhotonicModulator thread to wait onto the lock to take it out of that state.
     * b/262294651 for more info.
     */
    void resetScreenState() {
        mScreenState = Display.STATE_UNKNOWN;
        mScreenState = Display.STATE_OFF;
        mScreenReady = false;
        scheduleScreenUpdate();
    }

    private void scheduleScreenUpdate() {