LCD显示异常分析——开机闪现花屏

版权声明:本文为博主原创文章,欢迎转载,转载请注明出处,谢谢! https://blog.csdn.net/hexiaolong2009/article/details/79190789

概述

最近在工作中,有同事遇到LCD开机瞬间会闪现雪花屏的问题,而这类问题都有个共同点,那就是都发生在带GRAM的屏上,同样的问题,在休眠唤醒时也会出现。

其实这类问题的原理分析并不难,只是在给别人解释的时候不太好描述,因此,我特地写了这篇文章,好让大家能够更容易、更直观的理解这类花屏问题的原因,也希望能够帮助那些遇到同样问题的朋友。


环境

  • 软件:Android
  • 硬件:带GRAM的LCD(如SPI屏,DSI CMD屏)

现象

bl_early_mass


分析

从上面的动态图可以看出,出现瞬间花屏的问题,主要有两个原因:

  1. 背光开启的时间过早
  2. 对GRAM的写速度(W) < 对GRAM的读速度(R)

其实,只要任意解决其中一个问题,都不会出现开机闪现花屏的现象。开发人员第一次碰到这类问题时,往往第一反应会认为花屏就是在第一帧产生的,但实际从上面的图中我们可以看到,人眼看到的花屏其实已经是在第二帧了。

对于第一点,其实一开始我也很疑惑,如果说开机闪现花屏是因为uboot中背光开的太早导致,这个结论我能接受。但在进入Android系统后,休眠唤醒时还会有花屏问题,这就有点说不通啊?因为Android的PowerManager框架本身能够确保在休眠的时候先关背光,后关显示;在唤醒的时候先开显示,后开背光,而且我显示驱动里面也做了刷背景色的动作,只要GRAM中的数据没有被填充完,显示驱动的流程就不会接着往下走,进而也不可能开启背光。所以一旦背光点亮,说明GRAM已经被初始化了,可为什么还能看见GRAM中的垃圾数据呢?

这就引出了第二点:因为对GRAM 写的速度小于读的速度,哪怕W只比R小那么一丁点儿,只要它们同时从第一颗像素开始扫描,屏上显示的第一帧永远都是垃圾数据。


解决方法

前面已经提到过了,只要任意解决其中一个问题,闪花屏的问题就能解决。

1. 推迟背光开启的时间

这里的推迟动作其实是相对的,即你可以:

  • 在初始化完GRAM后,等待1个TE信号,再开启背光
  • 或者在给屏幕发送Sleep Out (0x11)Display On (0x29)指令前,先通过Write Memory Start (0x2C)指令将GRAM初始化好

2. 提高GRAM的写速度

即提高主控端总线上的送图速度,比如提高SPI总线的时钟频率(SPI屏),提高RS/WR的切换速率或扩充DATA总线(MCU屏),提高PHY Clock Frequency (MIPI DSI屏)。


常白屏引起的撕裂假象

上面的问题如果发生在常白屏(即默认上电就是白屏)上,那么往往会给人产生撕裂(tear effect)的假象,见下图:
bl_early_white

其实原理和上面是类似的,只是由于人的视觉残留效应,造成背光从灭到亮那一瞬间看到的第一帧印象极为深刻。尤其对于帧率较低(如30fps)的显示屏,视觉残留效果尤为明显,因此会对该类问题错误的判断为撕裂问题而进行处理。

其实真正的撕裂问题和这里讨论的现象,原理上是完全不同的,我会在下一篇文章中详细分析LCD撕裂的问题及解决方法(虽然并不是什么高深的问题)。

展开阅读全文

没有更多推荐了,返回首页