Enable AOD for Asus Rog Phone (Z01QD) #42
Conversation
Rocky7842
commented
Jun 18, 2023
Rocky7842
commented
- Enable AOD without doze display state, and adjust brightness.
- While at it, add some overlays pulled from stock.
* Add SystemUI overlay. * Doze display state should be supported according to stock overlay, but enabling it here broke input and caused artifacts. So disable it. * Lower the (stock) AOD brightness.
|
`` |
The main problem is that, if the user tries to enable the forced aod in phh settings, on this device, it'll completely break the input. For a normal user, that may result in only one solution, which is to reset the phone. |
|
"break the input"? |
The touchscreen has no response at all, even if I wake it up using power button, etc. When it wakes up, animation is lagging, brightness transition is weird, and sometimes there are also artifacts.
I agree the battery would be way worse than proper doze. I will put it there and see how much battery does it extactly drain. |
|
Well, it literally kills the battery. 50% loses across 8.5 hours. |
I found that DT2W is working with doze mode aod. getevent indicate that after the device leaves aod, the panel won't send normal input event. Instead, only DT2W is working (KEY_POWER is used on this device, so double tap to sleep). |
|
I've managed to get doze work by modifying the kernel. The issue comes from Asus's weird implementations.
I have no idea how to fix this without modifying the kernel. The commits include in this PR can serve one purpose, which is prevent the phone from falling into a dead loop. However, if it's not proper to enable a half broken feature, then nvm. |
|
Well that kernel works on stock, which has proper AOD, correct? From what I hear from what you say, we need to use ""lp1"" mode rather than ""lp2"" (ideally doing on => lp1 => lp2, but i guess just using lp1 could be enough), my guess is that this corresponds to DOZE and DOZE_SUSPEND modes. Did you try: ? (this would go to lp1 without trying lp2, which could be good enough) Did you try setting I'm not finding anything in systemui that would allow on => lp1 => lp2 => lp1 => on without a lot of changes to the code |
Yes.
It need "on => lp1 => lp2", but it's ok to do "lp2 => on"
I write my findings down here, it's a little long. You can skip to conclusion if needed. Applied the above changes, and the results are:
To compare it with the stock behavior, I flashed the stock ROM, and I found:
LONG STORY SHORTSo I guess the main difference is that, they probably do some trick to run |
This definitely sounds like config_displayBlanksAfterDoze=true FWIW on ROG Phone 3, this issue doesn't happen, I just tick "force enable aod" which sets doze_display_state_supported and doze_suspend_display_state_supported to true and it's alright. I didn't exactly check power loss, but that's less than 50%/24 hours (I think it was 20% over that period) |
Umm, so I do some more tests on this, and found that if (Tested on android_13.0.0_r52 ci-20230627)
Things are a bit messy on ROG Phone 1, probably because this is their first try making a gaming phone full of weird stuff. I've also checked the kernel source of ROG Phone 2, they're already using proper |
|
Okay, I think that's great information. I guess Google "just" broke config_displayBlanksAfterDoze, since it does have an effect with notifications but not power button. So let's go back to config_displayBlanksAfterDoze=true, but set the prop ro.config.low_ram=true (do it however you want, but it needs to be already set when android boot. Personally the way I would do it is The reason I'm suggesting this is because of https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/core/java/com/android/server/display/DisplayPowerController.java#2195 This code handles config_displayBlanksAfterDoze and turns screen off when going from doze to on, and it seems to be could bypassed by mColorFadeEnabled, which can be disabled with low ram prop. When setting this will fail, I'll add more logs around this code to understand precisely what happens (starting with checking whether state_off is always called or not) |
|
Now tested with |
|
https://phh.freeboxos.fr:49026/share/ar96NDtqe-HAJKIc/s-logs-aod.img take logs with that. Please take care to very cleanly cut the logs, so what we know exactly which transition we're looking at in logs |
|
Sorry for the late reply, was a little busy this week. Entering AOD: Leaveing AOD, woken up by power button: Leaveing AOD, woken up by notification. I then clicked on the notification to continue unlock the phone: It looks like the correct state change for leaving AOD should be |
Showing screen states 3/4/5/6 mean that Android does indeed properly do screen_off: My gut feeling is that it's just a timing issue (setScreenState might need to be on a vsync or something), so I'll make you a test image with a big old sleep(200ms) and let's see what happen. Here's a test image with that |
Now tested with this new build. Sadly still the same behaviour. |
|
Ok I'll try to dig down to the HAL to ensure that we do end up sending display state_off |
