Open YZBruh opened 8 months ago
Notes: https://www.gsmarena.com/alcatel_3t_10-9601.php / launched with Android 8.1 / SoC is MT8765WB with Imagination PowerVR GPU
Send the result of adb shell dumpsys SurfaceFlinger
on Settings screen before the screen turns white, then while it is white.
Notes: https://www.gsmarena.com/alcatel_3t_10-9601.php / launched with Android 8.1 / SoC is MT8765WB with Imagination PowerVR GPU
The device comes with Android 9 :/
Send the result of
adb shell dumpsys SurfaceFlinger
on Settings screen before the screen turns white, then while it is white.
Ok. I'm doing it now
@phhusson The printouts are too long. So I saved it to a file. There are outputs that are in white color from the first to the 2136th line. After black.
What happens if you tick Disable HW overlay
?
What happens if you tick
Disable HW overlay
?
The screen remains completely white 🤮
Same issue here Image: android_14.0.0_r21 ci-20240105 system-td-arm64-ab-vanilla.img
android_14.0.0_r2 ci-20231012 system-td-arm64-ab-vanilla.img
android_13.0.0_r73 ci-20230905 system-td-arm64-ab-vanilla.img
android_13.0.0_r41 ci-20230527 system-td-arm64-ab-vanilla.img
Hardware:
Oukitel k12 CPU MTK: 6765 Android 9 at launch integrated graphics card is PowerVR GE8320
Symptom: 1) by default image has washed out colors, problem identified as in some cases (scroll/animation..etc) real colors are visible - equivalent to a white overlay with alpha set to ~20%. 2) it seems that the clear screen (where the "overlay" is not present) animate and move faster 3) android startup logo flashing
Disable HW overlay - permanent washed out colors, during animations and transitions the "real color screen" is no longer visible
What I tried: Disable HW Overlay on/off ForceFPS from don't force to 1080x2340@60.330006 Mediatek GED KPI Support on/off
SurfaceFlinger_MTKMT6765_DisableHwO_ON.txt SurfaceFlinger_MTKMT6765_DisableHwO_OFF.txt
Can you also test on Android 10, 11 and 12? (from https://github.com/phhusson/treble_experimentations/releases/ )
yeah, yeah :)) I did 12 - AOSP 12.1 v416 and the "flickering" was not there, I am familiar with your work :).
do you need 11 and 10 ?
Also ponces's Pixel Experience 13 has the same issue, 12 is OK
Nope, knowing that 12 is ok is enough, thanks. Just to confirm, 12 is okay even if you tick "disable gpu overlay"?
correct, Disable HW Overlay on/off 12, keeps the same colors and no issues are to be seen. seems the problem started with 13.
if I have some more free time later today I will try all 13 builds below 41 maybe I can identify the one that introduced the issue
Could you get me the dumpsys SurfaceFlinger
with "disable hw overlay" enabled on Android 12?
yes, android_13.0.0_r24 ci-20230104 this is the earliest 13 build that actually boots, same issue. flashing 12 back now. I will disable hw overlay and reboot then do a dump.
Could you get me the
dumpsys SurfaceFlinger
with "disable hw overlay" enabled on Android 12?
SurfaceFlinger_A12_v416_MTKMT6765_DisableHwO_ON_postReboot.txt SurfaceFlinger_A12_v416_MTKMT6765_DisableHwO_ON.txt SurfaceFlinger_A12_v416_MTKMT6765_DisableHwO_OFF.txt
@phhusson hey, been thinking about this for a while now, I think the deep and root of the problem is been in the system before A12, the current issue is that now it is visible since A13. As you can see, this failure would not be visible under A12 since disable hw overlay on/off the image do not change.
My hunch is that there is an integration driver problem, with the video driver, while using Pixel Experience A12 (yep, just confirmed on your A12 build as well) I remember seeing tearing/strange artifacting while using, the most common point would be the PIN screen while pushing the buttons.
tested AOSP 11.0 v313 no screen tearing or artifacts, but animations as A12, A13, A14 seem chunky (A14 maybe seems a bit better) [I usually disable animations via Dev tools]. A11 - tried disable hw overlay on/off [Dev tools]- no white overlay seen, no tearing/artifacting
SurfaceFlinger_A11_v313_MTKMT6765_DisableHwO_OFF.txt SurfaceFlinger_A11_v313_MTKMT6765_DisableHwO_ON.txt
SurfaceFlinger_A11_v313_MTKMT6765_DisableHwO_ON_postReboot.txt - could not be provided, upon reboot A11 is stuck at animated boot logo and will not load the system
@ArsBinarii @phhusson I can confirm animations ARE chunky on A12 - A14 along with scroll lags even disabling hw overlaying causes the scrolls to be more laggy I'm testing on Honor 7x (kirin 659)
on A14 animations are better than before but not the way they're supposed to feel
Edit: Honor 7x with 4GBs of RAM
It was great to find more people... Everyone is experiencing these problems above A12, right?
It was great to find more people... Everyone is experiencing these problems above A12, right?
@YZBruh with high probability YES @phhusson I have not tested A11, But going to test it as soon as possible because everything besides graphics and animations are great
my phone (Honor 7x) is laggy with chunky animations and scrolling but apps seem to launch quite faster than the stock ROM so I guess the problem is related to graphics of these GSIs
I really appreciate the hard work & dedication
Any fix for animations & graphic related issues will be greatly appreciated
My device: Honor 7x CPU: Kirin 659 GPU: Mali-T830 MP2
kindly open a new ticket for your issue, we are debugging something else here, if fixing this will fix the animations that is a different story
@phhusson Is there any solution to solve the problem? The problem still exists in the latest android 14 AOSP build. At least it booted... (It wasn't booting before).
Just so everybody understands, from my experience, this is a very hard issues to debug and fix and might take a long time to fix, or might even not get fixed at all since this is not occurring on all devices, or due to closed envs that can't be debugged like drivers, implementations, ...etc.
Just be patient.
Just so everybody understands, from my experience, this is a very hard issues to debug and fix and might take a long time to fix, or might even not get fixed at all since this is not occurring on all devices, or due to closed envs that can't be debugged like drivers, implementations, ...etc.
Just be patient.
Okay. Thanks.
@phhusson I noticed something new. Before disabling the hardware layers on the device, it was constantly switching between DIRECT_LINK and RDMA_MODE modes in the kernel logs. When you disable it, it changes between DIRECT_LINK and DECOUPLE. What if the problem is here somewhere?
might or might not be the issue:
based on mt6739 code which has a PowerVR
DIRECT_LINK Mode involves direct transmission of image data from the source (e.g., GPU) to the display, any issues in the GPU rendering process could directly result in visual artifacts. If there's a problem with the GPU's rendering pipeline or if the data is corrupted before it reaches the display, you will likely see artifacts. Additionally, any synchronization issues between the GPU and the display refresh rate might also cause visual anomalies.
RDMA_MODE is designed to efficiently transfer data from memory to the display, issues could arise if there's a problem with the memory access patterns or if the data being accessed is corrupted. Incorrect or corrupted data fetched via RDMA could result in visual artifacts. Furthermore, if there are synchronization issues or errors in the configuration of the RDMA transfer, it might also lead to unexpected visual results.
DECOUPLE Mode: In DECOUPLE mode, processing and rendering paths are separated, there are several points where issues might occur leading to visual artifacts. if there's an issue with the intermediate buffering or if the processed data is corrupted before it reaches the display, artifacts could appear. This mode adds complexity to the display pipeline, and any misconfiguration or error in handling the decoupled processes could result in rendering problems.
based on the frequency of the flashing in the videos and the artefacts I provided if this was the issue then there should be a flood of these events to be the ones generating the issue.
So is it possible to keep it in a certain mode?
not unless you hardcode it into the driver, each cpu having a different code, and you need to obtain it. I might be wrong and Android could force this somehow like the switch that most likely disables RDMA_MODE.
switching between DIRECT_LINK, RDMA_MODE, and DECOUPLE modes stems from attempts of the system to optimize the device's performance and power consumption based on the current workload and content being displayed.
a problem in detection of the mode to use and fast switching between the modes could be the issue.
Then this is impossible... There is no code available. I have no idea...
The colors on the screen constantly (especially when I am in contact with the screen) become faded and colorful, as if a flash explodes. It does this very quickly. The color is also faded in the screenshots I took when the screen was in that state. And it reduces performance. I will leave a video to explain better.
As I said above, the colors fade and flash rapidly with each contact with the screen. And sometimes it just stays that way.
I want to get rid of the problem...
https://github.com/TrebleDroid/treble_experimentations/assets/131263805/966cc9d0-dbb7-49c9-8866-14aff776736b
The screenshot I'm talking about (don't care which app it is xd):