Official 7 inch screen : white flash at startup

[okenido]

Hello

The screen is doing a fast white flash on boot, before the rainbow screen is displayed. RPI model 3 B+ with the official 7 inch screen, last boot files from the git repository. Everything works well but it would look cleaner if it stayed black, especially since I plan to use it integrated in a product.



Video here : https://www.youtube.com/watch?v=xQJWC97g7jU

I know how to disable the rainbow screen using an option in config.txt, but I had no success getting rid of this white flash.

Any ideas ?

[aBUGSworstnightmare]

An you post a short video? Afik my 7in doesn't shown white flash on boot.

[okenido]

Sure ! I updated the first post with it

[aBUGSworstnightmare]

Looks odd, flash, as well as the splash screen. You see four big squares, but it should look like a rainbow color.

Can you test with a fresh Raspbian image please (download from here and not from repository https://www.raspberrypi.org/downloads/raspbian/ ) and report back? Yoi may want to use another uSD and keep this one in case some guys from RPi foundation need further details

[okenido]

The splash screen looks like that because I disabled interpolation in config.txt (normally it's so smoothed it looks like... a rainbow). Setting to default with an empty config.txt doesn't solve the problem.

The white flash still happens with no kernel8-32.img at all, just the boot files.

[mahjongg]

Don't disable interpolation, its probably causing the GPU to create that white screen, everything that happens before the rainbow screen (a GPU test that stretches and interpolates four pixels) is done with GPU code, only afterward the Linux kernel (the ARM CPU) is started
Why do you need interpolation disabled?

[okenido]

Because I have a framebuffer that is half the real screen size (800x480 => 400x240) for my custom software renderer. Disabling the interpolation allows for crisp pixels to be rendered, instead of a blurry mess

But that's not the problem since even with an EMPTY config.txt (that means interpolation is ON) the white screen still shows up.

[DougieLawson]

It's doing nothing abnormal. My screen on my 3B does the same thing (albeit a bit quicker), I don't have an splash screen or rainbow screen (they're disabled). It's flash white then four raspberries appear.

[okenido]

Oh okay ! Would be nice if someone working on the raspberry pi's firmware could investigate this. Maybe it's due to the screen controller, in that case i'm out of luck. If it's on the GPU side maybe there is something they can do, as this white screen (seems to) serve no purpose.

[aBUGSworstnightmare]

Oh okay ! Would be nice if someone working on the raspberry pi's firmware could investigate this. Maybe it's due to the screen controller, in that case i'm out of luck. If it's on the GPU side maybe there is something they can do, as this white screen (seems to) serve no purpose.

The display is TN technology --> it's normally white.
If there is no pixel data when the backlight is switched on the display is white. That's why many displays have Backlight Enable signal to prevent irregular display. Backlight Enable will be set after valid pixel data is transferred.

So maybe somebody at RPi Foundation needs to check the DSI power on sequence.

[jamesh]

The startup sequence is:

In main startup sequence:
Probe driver

In the driver:
Detect display type
Power up the display
Hold device in reset
Turn on the DSI peripheral
Mid way through DSI setup the LCD is taken out of reset.
Set the backlight PWM (not sure what this defaults to on power up)

back to main startup sequence:
Display the splash screen


So there is a period of time after all has been started up and before the GPU send the splash to the display. That's probably the white flash.

Not sure there is a lot that can be done about that, not without a hat load of investigation and work, which we won't be doing. Just not an effective use of engineering time.

[okenido]

It depends if the people investigating this have access to the source code of RPI firmware and/or the GPU initialization source code. Probably not very hard for the right people, but too hard for the users if it requires to reverse engineer things.

Maybe a hacky solution would be to cut the power line that goes to the backlight, then put a transistor controlled by a GPIO so the backlight would be naturally OFF then could be set ON by software. However, this is not clean nor easy to do

[jamesh]

It depends if the people investigating this have access to the source code of RPI firmware and/or the GPU initialization source code. Probably not very hard for the right people, but too hard for the users if it requires to reverse engineer things.

Maybe a hacky solution would be to cut the power line that goes to the backlight, then put a transistor controlled by a GPIO so the backlight would be naturally OFF then could be set ON by software. However, this is not clean nor easy to do

I do have access to all the source code, but it's more a question of time taken to investigate vs benefit. This is the first time it's been reported as an issue in 4 years...

And of course, if it's a problem in the firmware on the display (unlikely), that cannot be upgraded anyway.

[aBUGSworstnightmare]

@jamesh : does the 7in has a Backlight enable signal. Adding some more delay to this signal might solve the issue.
As it's TN and as it's unclear to us (users) if PWM=0 is working (sorry, never tried it; question is if duty is realy 0, because if not, there will be a white flash anyhow) below sequence might not be possible.

In the driver:
Detect display type
Power up the display
Set PWM duty =0 // newly added
Hold device in reset
Turn on the DSI peripheral
Mid way through DSI setup the LCD is taken out of reset.
Set the backlight PWM (not sure what this defaults to on power up)

[jamesh]

Think I know what the problem is, have a fix in code review at the moment. Not actually the panel itself but the HVS.

https://github.com/raspberrypi/firmware ... -426631667