Analyze the problem from the perspective of the display driver: Display abnormalities such as blurred screen and black screen

1. Take a screenshot or record the screen
   to determine whether the content of the source layer is normal

2. Force the use of GPU compositing.
   Disable HW overlays in the developer options.
   Sometimes the exception interface is flashing, which is inconvenient to take screenshots. Or the problem does not reappear after the screen recording is turned on (the problem does not reappear when there are more layers, and the display process changes after the screen recording is turned on), you can try to force GPU synthesis to reproduce it.
   Usually if there is a problem with GPU compositing, we will throw the bug to the GPU group first.

3. Check the log to see if there is any error.
   Analyze the error content.
   See how the software behaves when something goes wrong.

4. If there is a problem with a specific scene:
   analyze which functions are enabled in the scene, turn off these functions and reproduce. Walkthrough shows the anomaly and the relationship between these functions.
   If it is not necessary, compare the normal and abnormal software processes and hardware signals.

5. If you suspect that it has something to do with the content of the layer:
   grab the layer information dumpsys SurfaceFlinger
   to dump the source layer,
   and dump the screen before sending the image to the screen on the platform end

6. Check the dpu register.
   The IP function of the chip company is implemented by itself, and there may be incomplete consideration. When the source layer is normal, check the dpu register to see if there is any mismatch. Or use the C model to simulate to see if it is a problem with the IP itself.

black screen

1. Check the log to determine whether the system is asleep, and whether it is turned on or not.
2. Whether the backlight value is not 0, and whether the brightness changes when the backlight value is changed. Use a flashlight to shine on the screen in a dark place to see if there is any display.
3. The screen is always black when booting
   a. Check whether the screen ID is successfully read during the uboot stage?
   b. Measure the power-on sequence, whether each circuit is correctly configured, and compare it according to the screen spec;
   c. Whether the screen is normal, usually need to prepare two screens during the screen pointing stage, to avoid screen problems and waste time.
   d. Whether it is normal to read and write registers through MIPI.
   e. Skip the screen ID judgment, and the read ID in the code is successfully hardcoded.
4. The display is normal at the beginning of booting, and a black screen/faltered screen appears later
   a. Check whether the screen in the kernel is successfully found. Usually uboot and Kernel each have a set of screen configuration files. After booting into the kernel, you need to rely on the screen name or ID to find the corresponding screen dtsi configuration. (For details, see: DRM driver code analysis: how does the screen match between uboot and kernel )
   b. The boot animation is triggered by surfaceflinger, check the log to see if surfaceflinger is normal

Reference material:
The mobile phone display is a bit stuck? Maybe it's the DPU performance that's holding it back