Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Setting the display state to off when the default display is being changed

Browse Source 
This fixes the issue of the display state change always being "in progress". PhotonicModulator thread fails to make any progress while waiting for a notify call to release the lock. This happensbecause the screenState is set to invalid when a device is being folded/unfolded, forcing it to wait until the screen state is recovered.

Bug: 262294651
Test:  adb shell dumpsys display | grep "Photonic Modulator" -A 10 ->
Shows mStateChangeInProgress is false
Test: Manually folding/unfolding the device wont cause the display stuck
in the power off state

Change-Id: I903f6392cbe42031aab8ffdbfbe541463d6b5e01
This commit is contained in:
Rupesh Bansal
2023-01-06 09:11:51 +00:00
parent 65e129f2eb
commit c16b2af4a2
2 changed files with 13 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
services/core/java/com/android/server/display/DisplayPowerController.java
View File

@@ -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) {

14
services/core/java/com/android/server/display/DisplayPowerState.java
View File

@@ -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() {