Issue #1275
openFeature #1539: Graphics acceleration
Screen content (shortly) visible before unlocking
Added by My Self over 9 years ago. Updated over 3 years ago.
0%
Description
This bug-report is an result of of the forum-issue: http://redmine.replicant.us/boards/9/topics/9633, where some more details could be found.
Summary- Issue:
The device automatically locks after the configured countdown-time (over settings).
If the device will be activated again (by the buttons for example), the last screen content is shown for a short time (~ one second) before asking for the password (or PIN).
- Suggestions:
- Android screenshots functionality in context of the missing proprietary accelerated graphics drivers.
- The framebuffer, which is only updated moments after the backlight goes up again.
Because this "is a bug that is worth fixing", I opened that ticket.
Updated by Denis 'GNUtoo' Carikli almost 9 years ago
- Category changed from 51 to Framework
- Device Not device specific added
Updated by Paul Kocialkowski over 8 years ago
- Category changed from Framework to Security
- Device added
- Device deleted (
Not device specific)
Updated by Wolfgang Wiedmeyer over 7 years ago
- Assignee deleted (
Paul Kocialkowski) - Target version changed from Any version to Replicant 6.0
Updated by Jeremy Rand over 7 years ago
Contrary to the note in https://redmine.replicant.us/projects/replicant/wiki/Graphics#Known-issues-with-the-Android-software-renderer , this bug also appears to affect Replicant 6.0 0001 when llvmpipe is in use.
Updated by Jeremy Rand about 7 years ago
Paul said in https://redmine.replicant.us/boards/9/topics/9633?r=9939#message-9939 :
Oh, I thought this was because the framebuffer is only updated moments after the backlight goes up again.
I'm pretty sure we have fully disabled the animations, so I'm not entirely sure it has to do with screenshots. I quick way to find out would be to write a black image to the framebuffer when the backlight is off and see if the previous screen still shows up or not.
Results: if I tap the power button on the i9300 to turn off the screen, and then tap it again to turn on the screen, I see the previous screen for a couple seconds before the lock screen. If I run the following over adb (as root) between turning off the screen and turning on the screen:
cat /dev/zero > /dev/graphics/fb0
Then the issue goes away; the screen stays black for slightly longer and then goes directly to the lock screen without showing the previously open screen.
Updated by Kurtis Hanna about 6 years ago
- Target version changed from Replicant 6.0 to Replicant 6.0 0005
Updated by Kurtis Hanna about 6 years ago
Jeremy, can you think of a way to have this fixed for the 0005 release? It seems like you are on the right track.
Updated by Fil Bergamo about 6 years ago
My naive approach would be to find the exact point in the screenlock app where the screen is turned off, and just run
cat /dev/zero > /dev/graphics/fb0
right before turning it off.
But that would be a very hackish solution, and far from being an elegant one.
Another approach (more refined but still not perfect) could be to change the aforementioned code to display a black screen image before locking the screen...
Updated by Kurtis Hanna about 6 years ago
I compared stock Android with Replicant and noticed that on stock there's some sort of screen effect going on when you unlock the screen slowly gets brighter instead of going to full brightness right away. I then made the assumption that this effect seems to be broken in Replicant and instead of showing it, it shows the previous image for some reason.
It looks like ColorFade.java is the program that I was noticing.
"Animates a screen transition from on to off or off to on by applying some GL transformations to a screenshot."
https://git.replicant.us/replicant/frameworks_base/tree/services/core/java/com/android/server/display/ColorFade.java
Here's the code that tries to do the screenshot:
private boolean captureScreenshotTextureAndSetViewport() {
if (!attachEglContext()) {
return false;
The code seems to not fail gracefully.
The reason why the screenshot image is kept by ColorFade after the screen fades to black is explained in the comments here: "To prevent stray photons from leaking out after the color fade has been turned off, it is a good idea to defer dismissing the animation until the color fade has been turned back on fully." https://git.replicant.us/replicant/frameworks_base/tree/services/core/java/com/android/server/display/ColorFade.java#n348
My logs show that gralloc complains that it registers "a buffer in the process that created it. This may cause memory ordering problems."
I think that this buffer is the screenshot.
DisplayPowerController.java seems to be the code that controls the settings for ColorFade.
I could be wrong, but it looks like this code lets you choose to turn the screen off without doing any colorfade: https://git.replicant.us/replicant/frameworks_base/tree/services/core/java/com/android/server/display/DisplayPowerController.java#n925
Since ColorFade doesn't work in Replicant anyways, maybe we should modify DisplayPowerController.java to tell it to not use ColorFade at all. The other option is to modify the ColorFade code so that it never takes the screenshot and puts it in the buffer.
Lastly, it should be noted that Joonas reported in the IRC that he got swiftshader to work with Replicant 6 and that it looks like this issue is resolved when using it.
Updated by Kurtis Hanna about 6 years ago
I found upstream patches for ColorFade that I think might fix this.
ColorFade: fix EGL crash on exynos4 mali blobs
https://github.com/LineageOS/android_frameworks_base/commit/3a809a8e7b11c56b7ab4df7799b52d44016897db
Git Mail version: https://github.com/LineageOS/android_frameworks_base/commit/3a809a8e7b11c56b7ab4df7799b52d44016897db.patch
This LineageOS patch may have used some of the code from this AOSP patch...
Remove ColorFade resouces when screen off
https://android.googlesource.com/platform/frameworks/base/+/d73854d%5E%21/
Updated by Kurtis Hanna about 6 years ago
The LineageOS patch named "ColorFade: fix EGL crash on exynos4 mali blobs" that I had found didn't fix this bug. Fil Bergamo told me in a conversation we had that he believes the fix should be a simple one now that we know what code needs to be altered.
Joonas confirmed that using Swiftshader with Replicant 6 not only fixes this bug, but it also makes it so screenshots work. He said that Swiftshader is quite slow though, so I'm still trying to fix this bug for people that use llvmpipe or the Android software renderer.
Updated by Kurtis Hanna about 6 years ago
If you go to this link:
https://groups.google.com/forum/?_escaped_fragment_=search/%220001-Avoid-crashes-with-Suspendon-Lollipop-ColorFade.patch%22#!search/%220001-Avoid-crashes-with-Suspendon-Lollipop-ColorFade.patch%22
Then if you click on the "Re: Android mesa-10.6 branch is ready for testing" text, you will get linked to an email where someone on the Android-x86 google group said, "To solve ColorFade problem (in fact a GLSL fragment shader which Mesa doesn't like that much) I have commented most of cmds used, keeping just gl_FragColor variable set in order to make it black".
They posted a patch named "0001-Avoid-crashes-with-Suspendon-Lollipop-ColorFade.patch" which, if we ported the patch to Replicant 6, would modify this portion of code: https://git.replicant.us/replicant/frameworks_base/tree/core/res/res/raw/color_fade_frag.frag
Updated by Fil Bergamo almost 6 years ago
Thank you for committing to this, Kurtis.
They posted a patch named "0001-Avoid-crashes-with-Suspendon-Lollipop-ColorFade.patch" which, if we ported the patch to Replicant 6, would modify this portion of code: https://git.replicant.us/replicant/frameworks_base/tree/core/res/res/raw/color_fade_frag.frag
I've checked.. that patch is already applied in replicant.
Doing:
git log -- core/res/res/raw/color_fade_frag.frag
inside frameworks/base, yields:
commit 24abb423c30dd3fa815154664bd59eb011f7c0e9 Author: Paulo Sergio Travaglia <pstglia@gmail.com> Date: Sun Jun 21 05:11:13 2015 -0300 Avoid crashes with Suspendon Lollipop (ColorFade) (...)
Indeed, the portions of code that the patch comments out, are commented in the replicant tree too..
My latest build still has the bug, so the patch doesn't solve the issue, unfortunately.
Updated by Kurtis Hanna almost 6 years ago
I found this code which I think controls how many milliseconds colorfade appears on the screen:
COLOR_FADE_ON_ANIMATION_DURATION_MILLIS = 250;
COLOR_FADE_OFF_ANIMATION_DURATION_MILLIS = 400;
I was thinking that maybe we could change the values to zero to see if it fixes the bug by not letting colorfade show anything on the screen at all.
I'm going to try to build Replicant from source again on a fresh install of Stretch, so maybe I will be able to test this and other patches out. Please feel free to test this patch idea out though if you are reading this as I can't promise that I'll be able to get Replicant to build.
Updated by Denis 'GNUtoo' Carikli over 5 years ago
- Target version changed from Replicant 6.0 0005 to Replicant 6.0 0004
Updated by Denis 'GNUtoo' Carikli over 5 years ago
- Target version changed from Replicant 6.0 0004 to Replicant 6.0 0005