The creation of screenshots via adb/ddms (8.1/9.0) and the thumbs in task management (9.0) does not work.

[fguy]

In testing, android 8.1 and 9.0 detected errors when getting screenshots from the screen.

When analyzing the log it turned out that the same errors appear and when android 9.0 forms a preview for the task switch.

The problem occurs when using mesa / drm on intel 6Y30 and VMware SVGA.

When booting with the "nomodeset" key on VMware, the error does not occur. The screenshot is not sent to adb / ddms, but this is another problem.

Here are examples of error logs for intel 6Y30:

D/vndksupport(2752): Loading /vendor/lib64/hw/android.hardware.graphics.mapper@2.0-impl.so from current namespace instead of sphal namespace.
D/vndksupport(2752): Loading /vendor/lib64/hw/gralloc.drm.so from current namespace instead of sphal namespace.
D/GRALLOC-DRM(2752): drmOpen i915: 9
I/GRALLOC-DRM(2752): create intel for driver i915
E/GRALLOC-I915(2752): failed to create ibo from name 53
W/GraphicBufferMapper(2752): importBuffer(0x7b161da3d940) failed: 2
E/GraphicBuffer(2752): unflatten: registerBuffer failed: Unknown error -2 (2)
W/GraphicBufferMapper(2752): lock(0x0, ...) failed: 2

for SVGA VMware:

D/vndksupport(3696): Loading /vendor/lib64/hw/android.hardware.graphics.mapper@2.0-impl.so from current namespace instead of sphal namespace.
D/vndksupport(3696): Loading /vendor/lib64/hw/gralloc.drm.so from current namespace instead of sphal namespace.
D/GRALLOC-DRM(3696): drmOpen vmwgfx: 9
I/GRALLOC-DRM(3696): create pipe for driver vmwgfx
E/GRALLOC-PIPE(3696): failed to allocate pipe buffer
W/GraphicBufferMapper(3696): importBuffer(0x72fe4523d940) failed: 2
E/GraphicBuffer(3696): unflatten: registerBuffer failed: Unknown error -2 (2)
W/GraphicBufferMapper(3696): lock(0x0, ...) failed: 2

In both cases, the error is fixed in the module libgralloc_drm.so.

If you use the "nomodeset" key in VMware, you can, with the same operations with the android, only see a warning from the gralloc.default.so module.

An error analysis in mesa results in an incorrect return of the ioctl function parameters in libdrm.

In the android 7.1.2-r2, these operations pass without errors.

Changing the mesa from 18.1.2 (oreo-x86) to 18.3.0 (maurossi) did not fix the bug.

Found the patch https://github.com/peyo-hd/external_drm_gralloc/commit/6cfa0c3c61b6fdccdc14d0d6c5dbba4e00552ac9 , but it did not help.

[Mauro Rossi]

Hi fguy

Il giorno mercoledì 22 agosto 2018 15:31:10 UTC+2, fguy ha scritto:

In testing, android 8.1 and 9.0 detected errors when getting screenshots from the screen.

When analyzing the log it turned out that the same errors appear and when android 9.0 forms a preview for the task switch.

The problem occurs when using mesa / drm on intel 6Y30 and VMware SVGA.

When booting with the "nomodeset" key on VMware, the error does not occur. The screenshot is not sent to adb / ddms, but this is another problem.

Here are examples of error logs for intel 6Y30:

D/vndksupport(2752): Loading /vendor/lib64/hw/android.hardware.graphics.mapper@2.0-impl.so from current namespace instead of sphal namespace.
D/vndksupport(2752): Loading /vendor/lib64/hw/gralloc.drm.so from current namespace instead of sphal namespace.
D/GRALLOC-DRM(2752): drmOpen i915: 9
I/GRALLOC-DRM(2752): create intel for driver i915
E/GRALLOC-I915(2752): failed to create ibo from name 53
W/GraphicBufferMapper(2752): importBuffer(0x7b161da3d940) failed: 2
E/GraphicBuffer(2752): unflatten: registerBuffer failed: Unknown error -2 (2)
W/GraphicBufferMapper(2752): lock(0x0, ...) failed: 2

In order to enable drm.debug=30 in kernel, which can be enabled in Debug Mode

modprobe i915

echo 30 > /sys/module/drm/parameters/debug

At that point it should be possible to see the error happening at kernel drm API level, could you please provide the dmesg and logcat output with drm.debug enabled?

I think the problem is related [PrintScreen] used to take a snapshot, 

do you also this problem?

Mauro

[fguy]

In order to enable drm.debug=30 in kernel, which can be enabled in Debug Mode

modprobe i915

echo 30 > /sys/module/drm/parameters/debug

At that point it should be possible to see the error happening at kernel drm API level, could you please provide the dmesg and logcat output with drm.debug enabled?

I think the problem is related [PrintScreen] used to take a snapshot, 

do you also this problem?

I did this test for VMware SVGA and intel 6Y30.

The logs of information no longer existed.

In dmesg for VMware: 

[  201.155986] audit: audit_lost=569 audit_rate_limit=5 audit_backlog_limit=64
[  201.155987] audit: rate limit exceeded
[  201.156016] type=1400 audit(1534970533.936:773): avc: denied { read } for pid=4230 comm="screencap" name="fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  201.156023] type=1400 audit(1534970533.936:774): avc: denied { open } for pid=4230 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  201.156188] type=1400 audit(1534970533.936:774): avc: denied { open } for pid=4230 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  201.156195] type=1400 audit(1534970533.936:775): avc: denied { getattr } for pid=4230 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  201.156230] type=1400 audit(1534970533.936:775): avc: denied { getattr } for pid=4230 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  201.156237] type=1400 audit(1534970533.936:776): avc: denied { getattr } for pid=4230 comm="screencap" path="/dev/dri/card0" dev="tmpfs" ino=1846 scontext=u:r:adbd:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
[  201.156265] type=1400 audit(1534970533.936:776): avc: denied { getattr } for pid=4230 comm="screencap" path="/dev/dri/card0" dev="tmpfs" ino=1846 scontext=u:r:adbd:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
[  201.156271] type=1400 audit(1534970533.936:777): avc: denied { read write } for pid=4230 comm="screencap" name="card0" dev="tmpfs" ino=1846 scontext=u:r:adbd:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
[  201.186576] [drm:vmw_surface_handle_reference.isra.17 [vmwgfx]] *ERROR* Could not find surface to reference.
[  202.862981] [drm:vmw_surface_handle_reference.isra.17 [vmwgfx]] *ERROR* Could not find surface to reference.
[  203.767412] [drm:vmw_surface_handle_reference.isra.17 [vmwgfx]] *ERROR* Could not find surface to reference.
[  216.668841] type=1400 audit(1534970533.936:777): avc: denied { read write } for pid=4230 comm="screencap" name="card0" dev="tmpfs" ino=1846 scontext=u:r:adbd:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

On intel, there are no error messages in dmesg:

[  867.096225] [drm:i915_gem_open [i915]]
[  867.096227] type=1400 audit(1534972020.735:884): avc: denied { read } for pid=3618 comm="screencap" name="fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  867.096239] type=1400 audit(1534972020.736:885): avc: denied { open } for pid=3618 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  867.096300] type=1400 audit(1534972020.736:885): avc: denied { open } for pid=3618 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  867.096310] type=1400 audit(1534972020.736:886): avc: denied { getattr } for pid=3618 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  867.096352] [drm:i915_gem_open [i915]]
[  867.096375] type=1400 audit(1534972020.736:886): avc: denied { getattr } for pid=3618 comm="screencap" path="/proc/fb" dev="proc" ino=4026531970 scontext=u:r:adbd:s0 tcontext=u:object_r:proc:s0 tclass=file permissive=1
[  867.096386] type=1400 audit(1534972020.736:887): avc: denied { getattr } for pid=3618 comm="screencap" path="/dev/dri/card0" dev="tmpfs" ino=4413 scontext=u:r:adbd:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
[  868.726907] [drm:i915_gem_open [i915]]
[  868.726959] [drm:i915_gem_open [i915]]
[  869.364562] [drm:i915_gem_open [i915]]

[youling 257]

my tablet i915 can't take screenshot.

08-23 09:54:47.679 1371 1388 I am_proc_start: [0,3532,10019,com.android.systemui:screenshot,service,com.android.systemui/.screenshot.TakeScreenshotService]

08-23 09:54:47.680 1371 1388 I ActivityManager: Start proc 3532:com.android.systemui:screenshot/u0a19 for service com.android.systemui/.screenshot.TakeScreenshotService

08-23 09:54:47.682 3532 3532 I Zygote : seccomp disabled by setenforce 0

08-23 09:54:47.686 3532 3532 W emui:screensho: Unexpected CPU variant for X86 using defaults: x86_64

08-23 09:54:47.697 1371 1526 I am_proc_bound: [0,3532,com.android.systemui:screenshot]

08-23 09:54:47.680 3532 3532 I auditd : type=1400 audit(0.0:797): avc: denied { mounton } for comm="main" path="/storage" dev="tmpfs" ino=7619 scontext=u:r:zygote:s0 tcontext=u:object_r:tmpfs:s0 tclass=dir permissive=1

08-23 09:54:47.680 3532 3532 I main : type=1400 audit(0.0:797): avc: denied { mounton } for path="/storage" dev="tmpfs" ino=7619 scontext=u:r:zygote:s0 tcontext=u:object_r:tmpfs:s0 tclass=dir permissive=1

08-23 09:54:47.719 3532 3532 I emui:screensho: The ClassLoaderContext is a special shared library.

08-23 17:55:44.264 0 0 D : [drm:drm_atomic_state_init [drm]] Allocated atomic state 00000000708e4c6a

08-23 17:55:44.264 0 0 D : [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:44:pipe A] 000000008c241184 state to 00000000708e4c6a

08-23 17:55:44.264 0 0 D : [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:28:primary A] 00000000ea462203 state to 00000000708e4c6a

08-23 17:55:44.264 0 0 D : [drm:drm_atomic_set_fb_for_plane [drm]] Set [FB:84] for plane state 00000000ea462203

08-23 17:55:44.264 0 0 D : [drm:drm_atomic_check_only [drm]] checking 00000000708e4c6a

08-23 17:55:44.264 0 0 D [drm:intel_plane_atomic_calc_changes [i915]] [CRTC: 44:pipe A] has [PLANE:28:primary A] with fb 84

08-23 17:55:44.264 0 0 D [drm:intel_plane_atomic_calc_changes [i915]] [PLANE: 28:primary A] visible 1 -> 1, off 0, on 0, ms 0

08-23 17:55:44.264 0 0 D : [drm:drm_atomic_nonblocking_commit [drm]] committing 00000000708e4c6a nonblocking

08-23 17:55:44.265 0 0 I : sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=ssp0-port

08-23 09:55:45.267 2039 2039 I am_on_restart_called: [0,com.android.launcher3.Launcher,performRestartActivity]

08-23 09:55:45.274 1371 1385 I am_pss : [3532,10019,com.android.systemui:screenshot,11996160,3670016,0,109076480,0,18,5]

在 2018年8月23日星期四 UTC+8上午2:35:00，Mauro Rossi写道：

[Chih-Wei Huang]

2018-08-22 21:31 GMT+08:00 fguy <fguy...@gmail.com>:
> In testing, android 8.1 and 9.0 detected errors when getting screenshots
> from the screen.
> When analyzing the log it turned out that the same errors appear and when
> android 9.0 forms a preview for the task switch.
> The problem occurs when using mesa / drm on intel 6Y30 and VMware SVGA.
> When booting with the "nomodeset" key on VMware, the error does not occur.
> The screenshot is not sent to adb / ddms, but this is another problem.
>
> Here are examples of error logs for intel 6Y30:

Is 6Y30 a Skylake device?

How did you take the screenshots?

I have no problem to take screenshots on Intel GPUs
via the PrintScreen hot key, or by the screencap
command like:

adb shell screencap -p /sdcard/screenshot.png

I just tested on these devices:
* Cherrytrail (Surface 3)
* Apollo Lake
* Coffee Lake
* Skylake (i5-6200U)

All work well.
Tested on android-x86 8.1 with mesa 18.1.

Actually this function has worked on Intel GPUs
for a long time. I'm surprised to hear the report.

For VMware I forgot if I've tested it or not...


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

[fguy]

Is 6Y30 a Skylake device?

yes https://ark.intel.com/products/88198/Intel-Core-m3-6Y30-Processor-4M-Cache-up-to-2_20-GHz

 

How did you take the screenshots?

I have no problem to take screenshots on Intel GPUs
via the PrintScreen hot key, or by the screencap
command like:

adb shell screencap -p /sdcard/screenshot.png

I just tested on these devices:
* Cherrytrail (Surface 3)
* Apollo Lake
* Coffee Lake
* Skylake (i5-6200U)

All work well.
Tested on android-x86 8.1 with mesa 18.1.

Actually this function has worked on Intel GPUs
for a long time. I'm surprised to hear the report.

For VMware I forgot if I've tested it or not... 

You are right - everything works in 8.1 and on VMware too.

I was confused by a similar reaction in ddms (C: \ android-sdk-windows \ tools \ ddms.bat) - the resulting screenshot is not transferred to the PC.

More precisely, it is transmitted, but in an incomprehensible format "adb shell screencap -p > screenshot.png".

Do you have any assumptions on the logs?

Will you make pie-x86 soon? 

[Chih-Wei Huang]

2018-08-23 19:33 GMT+08:00 fguy <fguy...@gmail.com>:
>> Actually this function has worked on Intel GPUs
>> for a long time. I'm surprised to hear the report.
>>
>> For VMware I forgot if I've tested it or not...
>
> You are right - everything works in 8.1 and on VMware too.
> I was confused by a similar reaction in ddms (C: \ android-sdk-windows \
> tools \ ddms.bat) - the resulting screenshot is not transferred to the PC.
> More precisely, it is transmitted, but in an incomprehensible format "adb
> shell screencap -p > screenshot.png".
> Do you have any assumptions on the logs?

I believe it's related to the pixel format it uses.

The Android uses RGBA_8888 as the default pixel format.
However, due to some reasons (the issues of GPU driver or mesa),
we use BGRA_8888 for a long time.
That makes screenshot fail to work.
But that has been fixed in mesa i965 driver
(thanks to Intel devs) since nougat-x86 I think.
So it definitely works for Intel GPUs now
(except the very old mesa i915 driver).

For VMware I think it's fixed in kernel vmwgfx driver
in kernel 4.9 (at least).
However, the newer kernel (4.14?) has other issues
that prevent it from working in android-x86.

For other GPUs it's not so lucky.
But Mauro has made good progress to add
RGBA_8888 support to amdgpu recently.
He may reveal more details.

> Will you make pie-x86 soon?

Maybe... next month.
I'm a little busy (and lazy)...

[fguy]

>> For VMware I forgot if I've tested it or not...
>
> You are right - everything works in 8.1 and on VMware too.
> I was confused by a similar reaction in ddms (C: \ android-sdk-windows \
> tools \ ddms.bat) - the resulting screenshot is not transferred to the PC.
> More precisely, it is transmitted, but in an incomprehensible format "adb
> shell screencap -p > screenshot.png".
> Do you have any assumptions on the logs?

I believe it's related to the pixel format it uses.

The Android uses RGBA_8888 as the default pixel format.
However, due to some reasons (the issues of GPU driver or mesa),
we use BGRA_8888 for a long time.
That makes screenshot fail to work.
But that has been fixed in mesa i965 driver
(thanks to Intel devs) since nougat-x86 I think.
So it definitely works for Intel GPUs now
(except the very old mesa i915 driver).

For VMware I think it's fixed in kernel vmwgfx driver
in kernel 4.9 (at least).
However, the newer kernel (4.14?) has other issues
that prevent it from working in android-x86.

For other GPUs it's not so lucky.
But Mauro has made good progress to add
RGBA_8888 support to amdgpu recently.
He may reveal more details.

I canceled patches 

git revert --no-edit 1052a521c6f2c0c421c7cc3e4e6b100f3818451e
git revert --no-edit 9220bea48b0b84d63960e179c6e7064d2ea39e51
git revert --no-edit ce9b5e1b0edc540ef26795ca47d4d913eb9c7336

for drm_gralloc (oreo-x86), but it did not help.

Can be with them it is necessary to cancel still what patches and for a kernel 4.9? 

[fguy]

Android 9 no longer uses HWC1 - it is supported only by HWC2.

Perhaps the problem is in this.

[fguy]

The Android uses RGBA_8888 as the default pixel format.
However, due to some reasons (the issues of GPU driver or mesa),
we use BGRA_8888 for a long time.
That makes screenshot fail to work.
But that has been fixed in mesa i965 driver
(thanks to Intel devs) since nougat-x86 I think.
So it definitely works for Intel GPUs now
(except the very old mesa i915 driver).

I assembled android 9 with components from the Intel Celadon project - hwcomposer, minigbm, libdrm, mesa and kernel. This assembly works correctly with screenshots and Task Manager. But it only works on Intel graphics cards. On VMware, this assembly only works with "nomodeset" via swiftshader (aosp or ax86).

 

 

[fguy]

> Will you make pie-x86 soon?

Maybe... next month.
I'm a little busy (and lazy)...

September ends, but there's still no pie?!

[Chih-Wei Huang]

fguy <fguy...@gmail.com> 於 2018年9月28日 週五 下午3:55寫道：

No...