Color problem #91
Comments
|
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 |
The device comes with Android 9 :/ |
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 |
The screen remains completely white 🤮 |
|
Same issue here android_14.0.0_r2 ci-20231012 android_13.0.0_r73 ci-20230905 android_13.0.0_r41 ci-20230527 Hardware: Oukitel k12 Symptom:
Disable HW overlay - permanent washed out colors, during animations and transitions the "real color screen" is no longer visible What I tried: SurfaceFlinger_MTKMT6765_DisableHwO_ON.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 |
|
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. |
SurfaceFlinger_A12_v416_MTKMT6765_DisableHwO_ON_postReboot.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]. SurfaceFlinger_A11_v313_MTKMT6765_DisableHwO_OFF.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 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? |
1 similar comment
|
It was great to find more people... Everyone is experiencing these problems above A12, right? |
|
@YZBruh with high probability YES my phone (Honor 7x) is laggy with chunky animations and scrolling I really appreciate the hard work & dedication Any fix for animations & graphic related issues will be greatly appreciated My device: |
|
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. |
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...
video_20240105_232555_854x480.mp4
The screenshot I'm talking about (don't care which app it is xd):
The text was updated successfully, but these errors were encountered: