Android pie system_server crash when going into sleep (EGL problem?)

[Michael Goffioul]

Hi,

When running Android pie on my baytrail device, system_server crashes
(and the device ends up rebooting), with what looks like a problem in
the graphics stack. Anybody have a suggestion?

06-02 18:10:23.132 2799 2799 I Thread-5: type=1400 audit(0.0:951):
avc: denied { read } for path="/dev/ttyS5" dev="tmpfs" ino=8544
scontext=u:r:platform_app:s0:c512,c768
tcontext=u:object_r:serial_device:s0 tclass=chr_file permissive=1
06-02 18:10:23.153 1566 1592 D vndksupport: Loading
/vendor/lib/hw/gralloc.drm.so from current namespace instead of sphal
namespace.
06-02 18:10:23.152 1566 1566 I PowerManagerSer: type=1400
audit(0.0:952): avc: denied { read } for name="lib" dev="tmpfs"
ino=8246 scontext=u:r:system_server:s0 tcontext=u:object_r:tmpfs:s0
tclass=lnk_file permissive=1
06-02 18:10:23.152 1566 1566 I PowerManagerSer: type=1400
audit(0.0:953): avc: denied { getattr } for path="/dev/dri/card0"
dev="tmpfs" ino=8550 scontext=u:r:system_server:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
06-02 18:10:23.156 1566 1592 I EGL-MAIN: found extension DRI_Core version 2
06-02 18:10:23.156 1566 1592 I EGL-MAIN: found extension DRI_DRI2 version 4
06-02 18:10:23.156 1566 1592 I EGL-MAIN: found extension
DRI_ConfigOptions version 1
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension
DRI_TexBuffer version 3
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension DRI2_Flush version 4
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension DRI_IMAGE version 16
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension DRI2_Fence version 2
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension DRI_IMAGE version 16
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension
DRI_RENDERER_QUERY version 1
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension
DRI_MutableRenderBufferDriver version 1
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension
DRI_CONFIG_QUERY version 1
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension
DRI_Robustness version 1
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension DRI_NoError version 1
06-02 18:10:23.188 1566 1592 I EGL-MAIN: found extension DRI2_Blob version 1
06-02 18:10:23.189 1566 1592 I ConfigStore:
android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasWideColorDisplay
retrieved: 0
06-02 18:10:23.189 1566 1592 I ConfigStore:
android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasHDRDisplay
retrieved: 0
06-02 18:10:23.189 1566 1592 E libEGL : eglSetBlobCacheFuncsANDROID
resulted in an error: 0x300c
06-02 18:10:23.191 1566 1592 E libEGL :
eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID) failed: 0x3000
06-02 18:10:23.216 1566 1592 E GRALLOC-I915: failed to create ibo from name 6
06-02 18:10:23.217 1566 1592 W GraphicBufferMapper:
importBuffer(0xc77cc640) failed: 2
06-02 18:10:23.217 1566 1592 E GraphicBuffer: unflatten:
registerBuffer failed: Unknown error -2 (2)
06-02 18:10:23.217 1566 1592 E GLConsumer: error creating EGLImage: 0x300c
06-02 18:10:23.217 1566 1592 E GLConsumer: Failed to create image.
size=0x0 st=0 usage=0 fmt=0
06-02 18:10:23.217 1566 1592 W GLConsumer: [SurfaceTexture-1-1566-0]
updateAndRelease: unable to createImage on display=0x1 slot=0
06-02 18:10:23.228 1566 1592 E AndroidRuntime: *** FATAL EXCEPTION
IN SYSTEM PROCESS: PowerManagerService
06-02 18:10:23.228 1566 1592 E AndroidRuntime:
java.lang.RuntimeException: Error during updateTexImage (see logcat
for details)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
android.graphics.SurfaceTexture.nativeUpdateTexImage(Native Method)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
android.graphics.SurfaceTexture.updateTexImage(SurfaceTexture.java:243)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.display.ColorFade.captureScreenshotTextureAndSetViewport(ColorFade.java:479)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.display.ColorFade.prepare(ColorFade.java:154)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.display.DisplayPowerState.prepareColorFade(DisplayPowerState.java:179)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.display.DisplayPowerController.animateScreenStateChange(DisplayPowerController.java:1340)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.display.DisplayPowerController.updatePowerState(DisplayPowerController.java:766)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.display.DisplayPowerController.access$500(DisplayPowerController.java:81)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.display.DisplayPowerController$DisplayControllerHandler.handleMessage(DisplayPowerController.java:1745)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
android.os.Handler.dispatchMessage(Handler.java:106)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
android.os.Looper.loop(Looper.java:193)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
android.os.HandlerThread.run(HandlerThread.java:65)
06-02 18:10:23.228 1566 1592 E AndroidRuntime: at
com.android.server.ServiceThread.run(ServiceThread.java:44)
06-02 18:10:23.230 1566 1592 I Process : Sending signal. PID: 1566 SIG: 9

[Michael Goffioul]

Does anybody have a suggestion? Is there an easy way to get/enable
logs from EGL?

[Mauro Rossi]

Hi Micheal,

On Thursday, June 6, 2019 at 10:33:03 PM UTC+2, Michael Goffioul wrote:

Does anybody have a suggestion? Is there an easy way to get/enable
logs from EGL?

The exception is there for a reason, explaind in the commit [1] message,

maybe when going into sleep the EGL context may not be current anymore?

I've read something about this here [2]

EGL log in logcat is already enable in DEBUG mode and it is set to print errors

debug.egl.trace can be set in init.sh based on following options

/**
	* There are three different tracing methods:
	* 1. libs/EGL/trace.cpp: Traces all functions to systrace.
	* To enable:
	* - set system property "debug.egl.trace" to "systrace" to trace all apps.
	* 2. libs/EGL/trace.cpp: Logs a stack trace for GL errors after each function call.
	* To enable:
	* - set system property "debug.egl.trace" to "error" to trace all apps.
	* 3. libs/EGL/trace.cpp: Traces all functions to logcat.
	* To enable:
	* - set system property "debug.egl.trace" to 1 to trace all apps.
	* - or call setGLTraceLevel(1) from an app to enable tracing for that app.

The other possible attempt is to try with Intel's mesa:

https://github.com/intel/external-mesa/commits/master

If not working the best way to proceed is to open a bug in bugzilla for i965,

if the problem is the one described in [2] at least to understand if the problem is in AOSP implementation.

Mauro

[1] https://android.googlesource.com/platform/frameworks/base/+/2b4bfa5efec7df408b4db127961cfc9aca9e57cf

[2] https://gamedev.stackexchange.com/questions/12629/workaround-to-losing-the-opengl-context-when-android-pauses

[Michael Goffioul]

Thanks for the feedback. The problem doesn't seem to be similar to the link you reference. It's basically happening right when the device is _trying_ to go to sleep, during the animation (color fade). It also didn't happen for previous versions (nougat-x86 and oreo-x86) where the going-to-sleep animation works fine.

Michael.

[Michael Goffioul]

I did some debugging and may have found some more information (no
solution, because of my lack of understanding). Hopefully, someone
will be able to commit.

I started from this log line, that appears when the problem occurs:

06-02 18:10:23.216 1566 1592 E GRALLOC-I915: failed to create ibo from name 6

As far as I can tell, this is coming from intel_alloc() in
external/drm_gralloc/gralloc_drm_intel.c, so I put a break point and
found out the allocation function was called twice:
- once as a result of eglMakeCurrent(), which succeeds
- once as a result of SurfaceControl.screenshot(), which fails with
the above message

I compared with the corresponding ColorFade.java code:
https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/core/java/com/android/server/display/ColorFade.java#L461-L501
The first call is coming from attachEglContext() (line 462), and the
second is obvious (line 477).

I believe what's happening is that the screenshot capture fails. And
the subsequent SurfaceTexture.updateTexImage() also fails and raises
the exception.

So I just tried: "adb shell screencap -p", and that fails as well,
with the following in the logs:

06-07 16:38:18.547 3099 3099 D vndksupport: Loading

/vendor/lib/hw/gralloc.drm.so from current namespace instead of sphal
namespace.

06-07 16:38:18.551 3099 3099 I GRALLOC-DRM: create intel for driver i915
06-07 16:38:18.551 3099 3099 E GRALLOC-I915: failed to create ibo from name 5
06-07 16:38:18.551 3099 3099 W GraphicBufferMapper:
importBuffer(0xef8aff40) failed: 2
06-07 16:38:18.551 3099 3099 E GraphicBuffer: unflatten:

registerBuffer failed: Unknown error -2 (2)

06-07 16:38:18.551 3099 3099 W GraphicBufferMapper: lock(0x0, ...) failed: 2

That makes me think the real problem is the inability to make
screenshot captures, but I have no idea why this is happening. Any
suggestion is welcome.

Michael.

[Michael Goffioul]

Continuing on the screenshot failure, I've tracked "intel_alloc()"
calls in SurfaceFlinger, and from what I can see, the BO is allocated
correctly in SurfaceFlinger and associated with a name, but when the
client receives the buffer handle from IPC, it fails to
import/retrieve it. Is it possible there's a problem sharing BO
between different processes?


On Fri, Jun 7, 2019 at 5:01 PM Michael Goffioul

[Michael Goffioul]

After making intel_bufmgr_gem.c print its debug entries to logcat, I'm
seeing this when calling "screencap" utiliy:

06-07 19:34:03.191 1414 1554 I DRM-I915: bo_create: buf 29
(gralloc-texture) 4227072b
06-07 19:34:03.191 1414 1554 I DRM-I915: bo_flink: buf 29
(gralloc-texture) linked with 4
06-07 19:34:14.429 1414 1554 I DRM-I915: bo_unreference final: 29
(gralloc-texture)
06-07 19:34:14.436 3149 3149 I DRM-I915: bo_create: buf 1
(gralloc-batchbuffer) 2112b
06-07 19:34:14.436 3149 3149 I DRM-I915: Couldn't reference
gralloc-r handle 0x00000004: No such file or directory

PID=1414 is SurfaceFlinger, PID=3149 is screencap.
I may be wrong, but it sounds like SurfaceFlinger destroys the BO
before screencap has a chance to reference it.


On Fri, Jun 7, 2019 at 6:26 PM Michael Goffioul

[Mauro Rossi]

Not much clear to me what is happening

This commit [1] in i965 seems related exporting prime Handle for GEM (flink), if I'm not wrong,

I am not actually sure it will solve, but if does not it is further evidence that export from i965

(import in drm_gralloc?) is having issue because

Maybe there are more changes needed in i965

[1] https://github.com/intel/external-mesa/commit/3500cd6f5fab80e0fe2e21c7010510e124e628e3#diff-5f8b0b743189a0886cf56b20842a9fda

[Michael Goffioul]

Thanks, Mauro. I tried the suggested commit, but unfortunately that
didn't change anything.

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.
> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/9fab6164-af3b-44d0-b19b-8064118fa8d1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michael Goffioul]

I've tried the combination of Intel's minigbm and drmfb-composer and the problem does not occur, screencap works and no crash when going to sleep. So the problem does seem to come from drm_gralloc.

[Jon West]

I would like to add that drm_gralloc does allow sleep on Pie when using Vulkan. Just not the normal renderer.

[Jon West]

I also tried it using an Intel GPU, drmfb-composer, Intel_minigbm & IA-Hardware-Composer, but I still get the error when returning from sleep:
eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID) failed: 0x3000

Both this setup and Vulkan seem to lock up about a minute after returning from sleep. What's worse is that the combo above also doesn't allow console yet. Will be digging into this over the weekend.

[Michael Goffioul]

When I looked into the same error message, I realized that it may be a
red herring, or at least it is misleading. AFAIK, this is coming from
this commit:
https://osdn.net/projects/android-x86/scm/git/frameworks-native/commits/0c8552ec5ea3b20285f5c221f93ff92776d03b11

If you look at the code, you'll see that the error message is printed
if eglGetConfigAttrib returns a non-zero value. And EGL documentation
states that on success, the function returns EGL_TRUE, which is
non-zero. So the message is printed when eglGetConfigAttrib actually
succeeds.

FYI, regarding the the foreground app not updating anymore after the
second sleep/wake sequence, I managed to work around it using this
patch:

diff --git a/frameworks/base/core/java/android/view/ViewRootImpl.java
b/frameworks/base/core/java/android/view/ViewRootImpl.java
index 6df0173..bee3332 100644
--- a/frameworks/base/core/java/android/view/ViewRootImpl.java
+++ b/frameworks/base/core/java/android/view/ViewRootImpl.java
@@ -1342,6 +1342,7 @@ public final class ViewRootImpl implements ViewParent,
renderer.setStopped(mStopped);
}
if (!mStopped) {
+ mWindowAttributesChanged = true;
scheduleTraversals();
} else {
if (renderer != null) {

Michael.

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/aa82d778-e526-4408-91b6-e1b50ed3d656%40googlegroups.com.

[Chih-Wei Huang]

Michael Goffioul <michael....@gmail.com> 於 2019年8月30日 週五 上午8:19寫道：

>
> When I looked into the same error message, I realized that it may be a
> red herring, or at least it is misleading. AFAIK, this is coming from
> this commit:
> https://osdn.net/projects/android-x86/scm/git/frameworks-native/commits/0c8552ec5ea3b20285f5c221f93ff92776d03b11
>
> If you look at the code, you'll see that the error message is printed
> if eglGetConfigAttrib returns a non-zero value. And EGL documentation
> states that on success, the function returns EGL_TRUE, which is
> non-zero. So the message is printed when eglGetConfigAttrib actually
> succeeds.

Oh! You're right.
I think I had a unclear mind at that moment of porting...
I've phased in a patch to fix it.
Thank you for the report.

> FYI, regarding the the foreground app not updating anymore after the
> second sleep/wake sequence, I managed to work around it using this
> patch:
>
> diff --git a/frameworks/base/core/java/android/view/ViewRootImpl.java
> b/frameworks/base/core/java/android/view/ViewRootImpl.java
> index 6df0173..bee3332 100644
> --- a/frameworks/base/core/java/android/view/ViewRootImpl.java
> +++ b/frameworks/base/core/java/android/view/ViewRootImpl.java
> @@ -1342,6 +1342,7 @@ public final class ViewRootImpl implements ViewParent,
> renderer.setStopped(mStopped);
> }
> if (!mStopped) {
> + mWindowAttributesChanged = true;
> scheduleTraversals();
> } else {
> if (renderer != null) {

Cool. Let me try...

[Sadhna Sharma]

Hello Michael and All,

I actually face the same issue, mentioned by you on my device with latest Android pie (android-9.0.0_r53),

My device looses the adb connection whenever device goes into sleep, and logs shows the PowerManagerService crash.

Because of this CTS tests also do not run to completion.

I have tried your patch in frameworks/base/core/java/android/view/ViewRootImpl.java, but it has no effect.

Can you please help me to resolve this issue?

Please find the attached log file, generated during CTS.

Thanks,

Sadhna

[Michael Goffioul]

The patch for ViewRootImpl.java was to solve another issue, that started to happen after switching to drmfb-composer/minigbm. I didn't find a solution for the crash when going into sleep mode. I switched to drmfb-composer/minigbm and the problem disappeared.

--

You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/af9f19e6-7d0d-42a2-9a4e-d5f99d499a52%40googlegroups.com.

[Sadhna Sharma]

Hello Michael,

Thank you for your response.

I have cloned minigbm (https://github.com/intel/minigbm) from here, 

For drmfb-composer, I found: https://github.com/me176c-dev/drmfb-composer, But are these the same code base you used?

Can you please confirm the source code path for both drmfb-composer and mingbm?

Thanks,

Sadhna

To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.

[Michael Goffioul]

On Mon, Mar 16, 2020 at 10:55 AM Sadhna Sharma <sadhnas...@gmail.com> wrote:

Hello Michael,

Thank you for your response.

I have cloned minigbm (https://github.com/intel/minigbm) from here, 

For drmfb-composer, I found: https://github.com/me176c-dev/drmfb-composer, But are these the same code base you used?

Can you please confirm the source code path for both drmfb-composer and mingbm?

Yes, these are the repos I'm using.

[Sadhna Sharma]

Sorry, minigbm is already part of androidx86, So that's okay...

But what about drmfb-composer?

[Michael Goffioul]

It's not the same minigbm as the one maintained by Intel. I've only used the one from Intel.

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/98a9210c-a896-422f-b9c8-e0a4b1d382cd%40googlegroups.com.

[Sadhna Sharma]

Okay, I will use the one mentioned by you, and update on the progress.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/98a9210c-a896-422f-b9c8-e0a4b1d382cd%40googlegroups.com.

[Sadhna Sharma]

Hello Michael,

I cannot make it work with drmfbcomposer+intelminigbm,

However, using x86 gralloc.gbm resolves the sleep issue on my device. PowerManagerService no longer crashed.

But during some CTS tests (ex: during cts module CtsActivityManagerDeviceTestCases) device cannot resume after going into sleep, 

This looks like suspend/resume issue to me. Find the CTS logs in the attachment. (device_logcat_setup* and test_result.xml)

But I don't know how to fix this, Can anyone help me to resolve this? 

NOTE: To load the needed gralloc version, I passed GRALLOC=android-x86 or GRALLOC=gbm in grub (can be seen in dmesg), and cross checked that gralloc.android-x86/gralloc.gbm is loaded instead of gralloc.default.

Am I missing something here.

Also, Just to mention, with drmfbcomposer+intelminigbm, surface flinger crashed, this looks similar to what you mentioned on https://groups.google.com/forum/#!searchin/android-x86/https$3A$2F$2Fgithub.com$2Fgoffioul$2Fdrmfb-composer/android-x86/yywW1cBA0MA/lyi-InzdCAAJ.

To fix this issue, I cloned drmfbcomposer maintained by you (https://github.com/goffioul/drmfb-composer), but to build that I had to remove android.hardware.graphics.mapper@3.0, this is missing in my pie source.

Still surfaceflinger crashed,  Please find the dmesg and logcat attached dmesg_drmfb_intelgralloc_surfaceflingercrash and log_drmfb_intelgralloc_surfaceflingercrash

Thanks,

Sadhna

[Michael Goffioul]

If you found a combination that works for your hardware, you should probably stick to it :)

Regarding the problems you have with drmfb-composer+intelminigbm, be aware that my own repo of drmfb-composer is only intended to be used with Android 10. For my pie build, I'm using upstream repo. I never ran into the vsync problem in my pie build. The logs you provided indicates that surfaceflinger cannot access the frame buffer device:

03-18 10:08:39.814  1585  1585 W EGL-MAIN: fail to get drm fd

I don't know why this is happening, but more importantly, I don't know why using my personal repo of drmfb-composer would change anything to that issue.

Michael.

[Sadhna Sharma]

Yes, you are right.

I will use gbm for my device.

But even after using that, I have issue with CTS, they cannot run to run to completion.

Does, anyone have an idea about this?

[Navid Mafi]

Hi Michael

i'm experienced this problem

i think it is because your storage device not have enough time to run and ready and boot the android up from suspend mode and android system will crash is kernel disconnected

I strongly suggest check your storage and Ready to go Time

[Sadhna Sharma]

Thank you Naved for your response,

Can you elaborate more on this?

I mean what you mean by storage device do not have enough time to boot? Does it mean space on the device?

Thanks,

Sadhna

--

You received this message because you are subscribed to the Google Groups "Android-x86" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/798b244a-60c0-439c-bbb9-b913456ac357%40googlegroups.com.

[Michael Goffioul]

Thanks Navi, but I don't think the problem is related to the storage. The crash happened when the device was entering stand-by mode, not the other way around. It turned out the root cause was that the system was unable to take a screenshot using the graphic stack at that time. When going into stand-by, system_server takes a screenshot of the screen, then use it to play a nice fade out animation. The screenshot was generating an exception, which crashed system_server. This was the same root cause that prevented the tool "screencap" to work. To solve the problem the screenshot problem, I moved to dfrmfb-composer+intel/minigbm.

--

[Chih-Wei Huang]

Michael Goffioul <michael....@gmail.com> 於 2020年3月27日 週五 下午8:55寫道：

>
> Thanks Navi, but I don't think the problem is related to the storage. The crash happened when the device was entering stand-by mode, not the other way around. It turned out the root cause was that the system was unable to take a screenshot using the graphic stack at that time. When going into stand-by, system_server takes a screenshot of the screen, then use it to play a nice fade out animation. The screenshot was generating an exception, which crashed system_server. This was the same root cause that prevented the tool "screencap" to work. To solve the problem the screenshot problem, I moved to dfrmfb-composer+intel/minigbm.

Right. I noticed the issue happens on some GPU like i915/i965
or virgl (maybe) when using drm_gralloc. But it's OK on amdgpu...
It's also OK if using gbm_gralloc + drmfb.

Another interesting thing is, taking screenshot just works in android 8.1 and 10
on the same device with the same graphic stacks. It just fails in android 9...
I've tried to track it down, but no concrete results...

BTW, could you share the repo of dfrmfb-composer+intel/minigbm you use?

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Sadhna Sharma]

Hello Chih-Wei,

Below are the repositories I used (confirmed with Michael in same thread...)

minigbm (https://github.com/intel/minigbm) from here, 

drmfb-composer, : https://github.com/me176c-dev/drmfb-composer, 

Also,  drmfb-composer maintained by Michael itself is here: (https://github.com/goffioul/drmfb-composer)

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAKc24n2RWxqeN-6%3DKHYiOMF9JSFFtiXTEnWUq0Z5R%2BUQ7x42wg%40mail.gmail.com.

[youling 257]

no power to test chromium/minigbm on pie-x86, 

had been test chromium/minigbm on cm14.1-x86 has better support with mesa 19 and vulkan.

https://github.com/maurossi/minigbm/commits/minigbm_amdgpu_v2

https://github.com/maurossi/drm_hwcomposer/commits/minigbm_cros

https://github.com/youling257/minigbm/commits/chromium

https://github.com/youling257/drm_hwcomposer/commits/oreo-x86

在 2020年3月31日星期二 UTC+8下午10:34:19，Chih-Wei Huang写道：

[Matt Moeller]

I have a fix for this. It is not great by any means, but has worked for me.

Patch file should be attached.

On Tuesday, March 31, 2020 at 9:34:19 AM UTC-5, Chih-Wei Huang wrote:

Michael Goffioul <michael...@gmail.com> 於 2020年3月27日 週五 下午8:55寫道：

[Mauro Rossi]

Hi Matt, 

does it work also with more aggressive timings, e.g. 0.5 seconds or less?

Mauro

[Matt Moeller]

I have not tested with more aggressive timings as my use case (adb screencap) did not require them.

-Matt

[Chih-Wei Huang]

Matt Moeller <moelle...@gmail.com> 於 2020年5月21日 週四 上午5:48寫道：

>
> I have not tested with more aggressive timings as my use case (adb screencap) did not require them.

Thank you for the patch. Great!

Further questions.
Why does it only affect some GPUs?
The issue doesn't appear in Android 10.
How was it fixed?

[Matt Moeller]

I'm no expert but here's what I believe:

Only affects Intel GPUs because of its particular implementation in gralloc_drm_intel.c of project external/gralloc_drm.

Doesn't appear in Android 10 because I don't think they are using the external/gralloc_drm project anymore as I don't see any android-10 tags in the project.

I think maybe there is a different hardware abstraction for graphics buffers using something called BufferHub. I haven't been in the Android 10 code, so I don't know much there.

On Wednesday, May 20, 2020 at 6:32:51 PM UTC-5, Chih-Wei Huang wrote:

Matt Moeller <moell...@gmail.com> 於 2020年5月21日 週四 上午5:48寫道：

[Chih-Wei Huang]

Matt Moeller <moelle...@gmail.com> 於 2020年5月21日 週四 上午10:57寫道：

>
> I'm no expert but here's what I believe:
> Only affects Intel GPUs because of its particular implementation in gralloc_drm_intel.c of project external/gralloc_drm.

Probably. The strange thing is it only affects Android 9.
Android 7, 8, 10 are all fine.

> Doesn't appear in Android 10 because I don't think they are using the external/gralloc_drm project anymore as I don't see any android-10 tags in the project.
> I think maybe there is a different hardware abstraction for graphics buffers using something called BufferHub. I haven't been in the Android 10 code, so I don't know much there.

We still use drm_gralloc in Android 10.

Anyway, I've applied the patch.
Thank you for solving the annoying problem.