Color problem

[YZBruh]

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...

video_20240105_232555_854x480.mp4

The screenshot I'm talking about (don't care which app it is xd):

• Device: Alcatel 3T 10 (8088X model. tb8765ap1_bsp)
• Build Flavor: system-arm32-binder-64-ab-vanilla.img.xz
• Version: Android 14

[phhusson]

Notes: https://www.gsmarena.com/alcatel_3t_10-9601.php / launched with Android 8.1 / SoC is MT8765WB with Imagination PowerVR GPU

[phhusson]

Send the result of adb shell dumpsys SurfaceFlinger on Settings screen before the screen turns white, then while it is white.

[YZBruh]

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 :/

[YZBruh]

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

[YZBruh]

@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.

dumpsys.log

[phhusson]

What happens if you tick Disable HW overlay ?

[YZBruh]

What happens if you tick Disable HW overlay ?

The screen remains completely white 🤮

[ArsBinarii]

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

[phhusson]

Can you also test on Android 10, 11 and 12? (from https://github.com/phhusson/treble_experimentations/releases/ )

[ArsBinarii]

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

[phhusson]

Nope, knowing that 12 is ok is enough, thanks. Just to confirm, 12 is okay even if you tick "disable gpu overlay"?

[ArsBinarii]

correct, Disable HW Overlay on/off 12, keeps the same colors and no issues are to be seen. seems the problem started with 13.

[ArsBinarii]

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

[phhusson]

Could you get me the dumpsys SurfaceFlinger with "disable hw overlay" enabled on Android 12?

[ArsBinarii]

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.

[ArsBinarii]

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

[ArsBinarii]

@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.

[ArsBinarii]

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

[mohammad-kazemzadeh]

@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

[YZBruh]

It was great to find more people... Everyone is experiencing these problems above A12, right?

[YZBruh]

It was great to find more people... Everyone is experiencing these problems above A12, right?

[mohammad-kazemzadeh]

@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

[ArsBinarii]

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

[YZBruh]

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

[ArsBinarii]

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.

[YZBruh]

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.

[YZBruh]

@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?

[ArsBinarii]

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.

[YZBruh]

So is it possible to keep it in a certain mode?

[ArsBinarii]

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.

[YZBruh]

Then this is impossible... There is no code available. I have no idea...