drm-hwcomposer issueshttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues2023-11-21T17:39:50Zhttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/81CI improvements (building against the VNDK with meson)2023-11-21T17:39:50ZMattijs KorpershoekCI improvements (building against the VNDK with meson)I am wondering if we could use the VNDK to build drm_hwcomposer against instead of importing the android headers.
I did a PoC of implementing this here: https://github.com/makohoek/aosp-vndk-meson
Would that be of interest for build-te...I am wondering if we could use the VNDK to build drm_hwcomposer against instead of importing the android headers.
I did a PoC of implementing this here: https://github.com/makohoek/aosp-vndk-meson
Would that be of interest for build-testing drm_hwcomposer?https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/80HWC3 frontend integration2023-12-15T08:39:30ZRoman StratiienkoHWC3 frontend integrationThis issue is to discuss HWC3 integration/migration aspects.This issue is to discuss HWC3 integration/migration aspects.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/79Temporary black screen when switching apps on Android 142023-11-19T00:47:12ZgoffioulTemporary black screen when switching apps on Android 14I'm running an Android 14 build on a Baytrail platform, with the following components:
- android-14.0.0_r1
- mesa-23.1.9
- minigbm + gralloc4
- drm_hwcomposer @ bdc4382f8baaf9cfc95f6f818af9d138938ddde8 + composer@2.4
- kernel @ android14...I'm running an Android 14 build on a Baytrail platform, with the following components:
- android-14.0.0_r1
- mesa-23.1.9
- minigbm + gralloc4
- drm_hwcomposer @ bdc4382f8baaf9cfc95f6f818af9d138938ddde8 + composer@2.4
- kernel @ android14-6.1-lts
During some app transitions, the display turns temporarily black for .3~.5s, typically after the transition animation ends. This is only visible on the physical display, a screenrecord of the same event does not show the black screen. This is illustrated by the following videos:
- https://drive.google.com/file/d/16BBREIA9ss4M9UZH_4k7HXWt5T2XM8Yq/view?usp=share_link : the physical display
- https://drive.google.com/file/d/1LUinS05DnQp8aUjkanjMG-t125I6Yseu/view?usp=share_link : the screenrecord capture
What I've determined so far:
- the problem does not occur when running the same build in QEMU
- the problem does not occur on Baytrail platform when using kernel @ android14-5.15-lts (all the rest left unchanged)
- the problem does not occur when using sysprop `vendor.hwc.backend_override=client`https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/78On Steam Deck, DRM_MODE_ROTATE_90 and DRM_MODE_ROTATE_270 seems reversed2023-10-18T19:27:27ZKatharine ChuiOn Steam Deck, DRM_MODE_ROTATE_90 and DRM_MODE_ROTATE_270 seems reversedOn the Steam Deck, when hw compositing instead of client compositing is in-use, DRM_MODE_ROTATE_270 and DRM_MODE_ROTATE_90 are reversed, causing up-side-down rendering. No idea where the fault truly is but a band aid solution would be to...On the Steam Deck, when hw compositing instead of client compositing is in-use, DRM_MODE_ROTATE_270 and DRM_MODE_ROTATE_90 are reversed, causing up-side-down rendering. No idea where the fault truly is but a band aid solution would be to swap DRM_MODE_ROTATE_270 and DRM_MODE_ROTATE_90 at ToDrmRotation drm/DrmPlane.cpp, hardcoded or with the help of props.
The issue is not observed on Intel devices, and I don't have another amd device to test this.
Kernel in-use can be found at https://github.com/hmtheboy154/Darkmatter-kernel/tree/gloriahttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/77Build failure against AOSP2023-06-27T19:01:46ZJohn StultzBuild failure against AOSPLooking to do a merge of this upstream into AOSP, but when building with "mma", I see:
```
ld.lld: error: undefined symbol: android::MakeUniqueFd(int)
>>> referenced by UEvent.h:35 (external/drm_hwcomposer/utils/UEvent.h:35)
>>> ...Looking to do a merge of this upstream into AOSP, but when building with "mma", I see:
```
ld.lld: error: undefined symbol: android::MakeUniqueFd(int)
>>> referenced by UEvent.h:35 (external/drm_hwcomposer/utils/UEvent.h:35)
>>> out/soong/.intermediates/external/drm_hwcomposer/tests/hwc-drm-uevent-print/android_vendor.VanillaIceCream_arm64_armv8-2a_kryo385/obj/external/drm_hwcomposer/tests/uevent_print.o:(android::UEvent::CreateInstance())
clang-17: error: linker command failed with exit code 1 (use -v to see invocation)
[ 23% 9/39] //external/drm_hwcomposer/tests:hwc-drm-uevent-print link hwc-drm-uevent-print [arm]
FAILED: out/soong/.intermediates/external/drm_hwcomposer/tests/hwc-drm-uevent-print/android_vendor.VanillaIceCream_arm_armv8-2a_kryo385/unstripped/hwc-drm-uevent-print
```
I took an initial look at the Android.bp and I'm not sure why it is having trouble finding it as UEvent.h includes fd.h, but its late, so I'll have to look at it more tomorrow.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/76drm-hwcomposer (HEAD) breakage on DB845c (SDM845) running AOSP with v6.4-rc2 ...2023-06-16T16:33:15ZAmit Pundirdrm-hwcomposer (HEAD) breakage on DB845c (SDM845) running AOSP with v6.4-rc2 and mesa-23.0.2AOSP/external/drm_hwcomposer tree which is 21 commits behind upstream/main boots fine but if I update AOSP tree by merging upstream/main then DB845c do not boot to display. I see:
```
[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu e...AOSP/external/drm_hwcomposer tree which is 21 commits behind upstream/main boots fine but if I update AOSP tree by merging upstream/main then DB845c do not boot to display. I see:
```
[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]failed to get dspp on lm 0
[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]failed to get dspp on lm 0
[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]failed to get dspp on lm 0
[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]failed to get dspp on lm 0
[drm:_dpu_rm_make_reservation] [dpu error]unable to find appropriate mixers
[drm:dpu_rm_reserve] [dpu error]failed to reserve hw resources: -119
```
Complete dmesg attached here: https://bugs.linaro.org/show_bug.cgi?id=5987
Does the breakage looks familiar to anyone here? I thought I'd ask before I start bisecting.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/75AOSP Tree build breaks with the latest commit2023-03-08T08:42:10ZYongqin LiuAOSP Tree build breaks with the latest commitCommented in the MR here https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/merge_requests/222.
also create this issue for the track the work for clear:
There are following errors reported with the latest commit which seems ...Commented in the MR here https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/merge_requests/222.
also create this issue for the track the work for clear:
There are following errors reported with the latest commit which seems introduced by the merged request of https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/merge_requests/222.
```
08:58:21 external/drm_hwcomposer/hwc2_device/HwcDisplay.cpp:76:26: error: constexpr variable 'kOne' must be initialized by a constant expression
08:58:21 constexpr uint64_t kOne = 1L << 32; /* 1.0 in s31.32 format */
08:58:21 ^ ~~~~~~~~
08:58:21 external/drm_hwcomposer/hwc2_device/HwcDisplay.cpp:76:36: note: shift count 32 >= width of type 'long' (32 bits)
08:58:21 constexpr uint64_t kOne = 1L << 32; /* 1.0 in s31.32 format */
08:58:21 ^
08:58:21 external/drm_hwcomposer/hwc2_device/HwcDisplay.cpp:76:36: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
08:58:21 constexpr uint64_t kOne = 1L << 32; /* 1.0 in s31.32 format */
08:58:21 ^ ~~
08:58:21 external/drm_hwcomposer/hwc2_device/HwcDisplay.cpp:697:71: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
08:58:21 auto value = uint64_t(matrix[i * kInCtmRows + j] * float(1L << 32));
08:58:21 ^ ~~
08:58:21 3 errors generated.
```
like reported by the build job here:
https://ci.linaro.org/job/lkft-aosp/982/consolehttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/74Enable HWC2_CAPABILITY_SKIP_VALIDATE2023-12-23T14:36:13ZRoman StratiienkoEnable HWC2_CAPABILITY_SKIP_VALIDATE- Without HWC2_CAPABILITY_SKIP_VALIDATE enabled, SurfaceFlinger will always initiate VALIDATE and PRESENT binder transactions separately.
<div align="center">
![image](/uploads/f73bda5b0e116a3cff6e43ad19f03a6a/image.png)
</div>
---
- ...- Without HWC2_CAPABILITY_SKIP_VALIDATE enabled, SurfaceFlinger will always initiate VALIDATE and PRESENT binder transactions separately.
<div align="center">
![image](/uploads/f73bda5b0e116a3cff6e43ad19f03a6a/image.png)
</div>
---
- With HWC2_CAPABILITY_SKIP_VALIDATE the SurfaceFlinger will invoke PresentOrValidate transaction, and in case client composition is required, it will prepare CLIENT layer and call the PRESENT transaction again.
In case whole composition can be composed without involving SurfaceFlinger GLES compositor, a lot of CPU time can be saved:
<div align="center">
![image](/uploads/4d6e52e71c2a3ed602aa82dff90e37f6/image.png)
</div>
According to trace (which was captured on RPI4), 2mS-2.5mS of frame time can be saved, which is about 13%-15% of CPU time.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/73Enter ActivateDisplayUsingDPMS even if SetPowerMode off2022-11-29T06:32:43ZJia RenEnter ActivateDisplayUsingDPMS even if SetPowerMode offHello, when I invoke `HWC2::Error HwcDisplay::SetPowerMode`, no matter parameter is `HWC2::PowerMode::Off` or `HWC2::PowerMode::On`, always meet the condition `if (a_args.active)` , enter `GetPipe().atomic_state_manager->ActivateDisplayU...Hello, when I invoke `HWC2::Error HwcDisplay::SetPowerMode`, no matter parameter is `HWC2::PowerMode::Off` or `HWC2::PowerMode::On`, always meet the condition `if (a_args.active)` , enter `GetPipe().atomic_state_manager->ActivateDisplayUsingDPMS()` and return before `GetPipe().atomic_state_manager->ExecuteAtomicCommit(a_args)`.
Since type of a_args.active is `std::optional<bool>`, bool(a_args.active) is true after `a_args.active = false;`.
I suspect the condition `if (a_args.active)` should be `if (*a_args.active)`.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/68[AOSP] No display because hwc-drm-display-pipeline found more than 1 primary ...2022-10-06T08:34:49ZAmit Pundir[AOSP] No display because hwc-drm-display-pipeline found more than 1 primary planeDisplay is broken on Qualcomm RB5 (sm8250, Adreno 650) devboard running AOSP, since upstream kernel commit 5cf5afcdbe05 ("drm/msm/dpu: initialize dpu encoder and connector for writeback") https://patchwork.freedesktop.org/patch/483526/. ...Display is broken on Qualcomm RB5 (sm8250, Adreno 650) devboard running AOSP, since upstream kernel commit 5cf5afcdbe05 ("drm/msm/dpu: initialize dpu encoder and connector for writeback") https://patchwork.freedesktop.org/patch/483526/. I reported it on IRC #freedreno and I have been told that it is a drm_hwcomposer bug.
drm_hwcomposer complains of finding more than 1 primary plane:
01-01 14:42:57.339 475 475 I hwc-resource-manager: Attaching connector HDMI-A-1
01-01 14:42:57.339 475 475 I hwc-drm-display-pipeline: Ignoring cursor plane 75
01-01 14:42:57.339 475 475 I hwc-drm-display-pipeline: Ignoring cursor plane 81
01-01 14:42:57.339 475 475 E hwc-drm-display-pipeline: Found more than 1 primary plane for CRTC 87
01-01 14:42:57.339 475 475 I hwc-drm-display-pipeline: Ignoring cursor plane 75
01-01 14:42:57.339 475 475 I hwc-drm-display-pipeline: Ignoring cursor plane 81
01-01 14:42:57.339 475 475 E hwc-drm-display-pipeline: Found more than 1 primary plane for CRTC 88
01-01 14:42:57.339 475 475 E hwc-drm-display-pipeline: Could not find a suitable encoder/crtc for connector HDMI-A-1
01-01 14:42:57.339 475 475 I hwc-drm-two: No pipelines available. Creating null-display for headless mode
01-01 14:42:57.340 503 503 I SurfaceFlinger: onComposerHalHotplug(0, connected)
01-01 14:42:57.349 503 503 I HWComposer: Switching to legacy multi-display mode
01-01 14:42:57.359 503 503 E HWComposer: getDisplayConnectionType: getDisplayConnectionType failed for display 0: Unsupported (8)
01-01 14:42:57.369 503 503 W HwcComposer: getPerFrameMetadataKeys failed with 8
01-01 14:42:57.376 503 545 W EventThread: Ignoring VSYNC request while display is disconnected
01-01 14:42:57.376 503 546 W EventThread: Ignoring VSYNC request while display is disconnected
01-01 14:42:57.377 503 546 W EventThread: Ignoring VSYNC request while display is disconnected
01-01 14:42:57.377 503 503 I SurfaceFlinger: Dispatching display hotplug event displayId=0, connected=1
If I don't error out from TryCreatePipeline() function (when it runs into multiple primary planes) and just let hwc-drm-display-pipeline attach to the first plane then the RB5 boots up as expected. But I'm not sure if it is a reasonable fix.
Curious if you guys have any idea what might be going wrong here. I'm happy to test or run any debug patches if it would help narrow down the issue further.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/67OS crash when booting with external screen on laptop2023-01-29T18:28:12ZHuy MinhOS crash when booting with external screen on laptopHello, I am one of the maintainer of BlissOS. Yesterday one of our user have an issue that when plugging the laptop with an external screen using VGA the OS suddenly crashed during bootanimation. But if he plug it after boot it will be f...Hello, I am one of the maintainer of BlissOS. Yesterday one of our user have an issue that when plugging the laptop with an external screen using VGA the OS suddenly crashed during bootanimation. But if he plug it after boot it will be fine.
Here's the logcat https://pastebin.com/peA4Lsfp
The laptop is a HP 240 G6 using Celeron N3060 (Intel HD Graphics 400). Booting with this fork of [minigbm_gbm_mesa](https://github.com/supremegamers/minigbm/commits/gbm_mesa) and [drm_hwcomposer](https://github.com/supremegamers/drm_hwcomposer/commits/r-x86)https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/66Display doesn't switch off anymore since d0494d9b2023-01-14T23:55:12ZdkadiogluDisplay doesn't switch off anymore since d0494d9bI am using Lineage OS builds from KonstaT on my RPi 4, please see https://konstakang.com/devices/rpi4/LineageOS19/. However, I have an issue since commit d0494d9b of drm-hwcomposer, where my HDMI connected display is not switched off any...I am using Lineage OS builds from KonstaT on my RPi 4, please see https://konstakang.com/devices/rpi4/LineageOS19/. However, I have an issue since commit d0494d9b of drm-hwcomposer, where my HDMI connected display is not switched off anymore. There you will find a change-log including release dates. With the version from March 14th, the display switches off as usual, when I screen lock Android. With all later versions, the screen is locked and goes black, however, the backlight of the screen stays on forever. As I am not able to build the images for myself, I cannot really bisect this issue, sorry. The only thing I can do is to compare commits used in the Github repo used by KonstaT: https://github.com/lineage-rpi/android_external_drm_hwcomposer/commits/lineage-19.1. There you can see, that the commits of https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/commits/main/ are continuously included. So, from my understanding, as with the build from March 14th display switches off and with the build from April 7th the display backlight stays on forever, the only commit in between is https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/commit/d0494d9b80977f2f9a21db6932119211a27fe8d5.
Also important to mention is, that replacing the file hwcomposer.drm.so in any build after March 14th with the one from the build from March 14th switches the display off as it should.
I know, that analyzing and hopefully fixing this issue will be difficult, when I am approacing you as upstream with an issue in some third party project. I am happy to help in analyzing this as good as I can.
Thank you very much for accepting and looking into this!https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/65Virtualized (unified) planes handling2022-06-01T14:00:05ZRoman StratiienkoVirtualized (unified) planes handling### Inspired by:
- https://resources.linaro.org/ru/resource/KdJRxQgh8NG3J4ssja9qHe
- https://patchwork.kernel.org/project/dri-devel/patch/20210705012115.4179824-20-dmitry.baryshkov@linaro.org/7
### Problem I would like to solve:
SUN4I...### Inspired by:
- https://resources.linaro.org/ru/resource/KdJRxQgh8NG3J4ssja9qHe
- https://patchwork.kernel.org/project/dri-devel/patch/20210705012115.4179824-20-dmitry.baryshkov@linaro.org/7
### Problem I would like to solve:
SUN4I/DRM DE2.0 and DE3.0 can support up to 16 planes, but expose only 4 as universal planes.
Supporting more than 4 require some constraints to be considered, e.g.:
1. No blend support withing group of 4 , therefore can only fit opaque buffers or transparent buffers must not overlap.
2. Scaling can be applied to the whole group of 4, but not to the individual layers within group.
By modifying driver to use virtualized planes we can benefit using these planes.
### drm_hwcomposer support:
Universal planes exposes their capabilities, allowing userspace to plan the composition with big chance to successfully pass commit test ioctl.
In case using virtualized planes, chance to succeed commit test ioctl depends on ability of the driver to cover all the cases compositor is hoping to present. For the userspace there is much less room for planning.
How can we improve that?
One of the option is to run background daemon and probe different composition combination for those which failed before in a hope to find a best DE/GPU energy ratio.
Commit test ioctl takes some time. Is there any way to pass multiple composition for testing in a single commit call?
During last few years I heard various proposals to solve the probing problem:
1. Dummy (bufferless) framebuffers used only for KMS testing.
2. eBPF for drm/kms capabilities probing. (https://static.lwn.net/kerneldoc/gpu/vkms.html#atomic-check-using-ebpf)
3. Anything else?https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/64Timing issue between GPU rendering thread and hwcomposer2022-10-06T09:09:49ZLeo YanTiming issue between GPU rendering thread and hwcomposerHi @roman.stratiienko,
I am suspect that there have timing issue between GPU rendering thread and drm hwcomposer.
Please see below two pictures. We can see SurfaceFlinger will periodically run and AsyncWaitForBufferSwap() will be exec...Hi @roman.stratiienko,
I am suspect that there have timing issue between GPU rendering thread and drm hwcomposer.
Please see below two pictures. We can see SurfaceFlinger will periodically run and AsyncWaitForBufferSwap() will be executed with the same rhythm with SurfaceFlinger, this is same for both two pictures.
The question is for the render thread, it might have different time delta with SurfaceFlinger, in the first picture, renderThread needs to wait for the HWC to release fence, but we can see it needs to wait for about ~10ms until AsyncWaitForBufferSwap return back, from my understanding, this means low level (display driver?) has swapped the buffer and released fence, then the render thread can proceed for its task. But this means it will leave much less time for the frame rendering since most time are spent for waiting for fence, thus it's easily to cause janks.
If we compare to picture 2, the render thread is just coincidence with SurfaceFlinger (and AsyncWaitForBufferSwap), so the render thread doesn't need to wait and directly acquires the buffer fence, in this case, the frame rendering can be finished in short time.
So seem to me, the problem is caused by AsyncWaitForBufferSwap; if it waits for long time for buffer swap and the fence is released, then it will leave much smaller time window for GPU rendering.
Another question is: which component will notify and wake up AsyncWaitForBufferSwap()? I tried to add ATRACE log in the function HwcDisplay::GetReleaseFences(), but cannot prove that HwcDisplay::GetReleaseFences() is the module which notify AsyncWaitForBufferSwap() to run.
![Screenshot_from_2022-05-18_22-53-06](/uploads/54b2c2eec270b4576f6c681cde2a0f95/Screenshot_from_2022-05-18_22-53-06.png)
![Screenshot_from_2022-05-18_22-53-53](/uploads/ec49b15bf386cebbcc0617798a59f30f/Screenshot_from_2022-05-18_22-53-53.png)https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/63dup() and fcntl(_, F_DUPFD{_CLOEXEC}) have different behavior2022-05-03T17:34:29ZRoman Stratiienkodup() and fcntl(_, F_DUPFD{_CLOEXEC}) have different behaviorAfter we call asynchronous atomic commit IOCTL (with non-blocking flag) , out_fence is set to fd which represents the out fence.
The thing is if we will try to duplicate this fd using fcntl() , it will fail (return -1), but dup() will s...After we call asynchronous atomic commit IOCTL (with non-blocking flag) , out_fence is set to fd which represents the out fence.
The thing is if we will try to duplicate this fd using fcntl() , it will fail (return -1), but dup() will succeed.
More surprisingly if we put `ALOGE("Something");` in between of atomic commit IOCTL and fcntl(), it will successfully duplicate fd.
I was able to reproduce such scenarios on PinePhonePro (Rockchip) kernel v5.17+.
Looking into dup() and fcntl() syscall implementation I can see additional checks in fcntl() and can't see them in dup(), so it may be some in-kernel processes wasn't finished prior to returning from drm commit() IOCTL or something else.
Anyway, I'll always use dup() in drm_hwcomposer until someone fixes this issue.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/62"drm_hwcomposer: Apply same logic for 'CURSOR' layers as for 'DEVICE'" cause ...2022-04-29T17:14:40Zyouling 257"drm_hwcomposer: Apply same logic for 'CURSOR' layers as for 'DEVICE'" cause a android touchscreen cursor problem.android touchscreen cursor is white color, "drm_hwcomposer: Apply same logic for 'CURSOR' layers as for 'DEVICE'" cause touchscreen cursor become black color.
I using 3400g amdgpu running on androidx86 7 and 11.
![Screenshot_20220428-02...android touchscreen cursor is white color, "drm_hwcomposer: Apply same logic for 'CURSOR' layers as for 'DEVICE'" cause touchscreen cursor become black color.
I using 3400g amdgpu running on androidx86 7 and 11.
![Screenshot_20220428-020945](/uploads/d4c7cf8653f737dd635a415a6d675e59/Screenshot_20220428-020945.png)![Screenshot_20220428-015340](/uploads/a3e58ce19d5427f05423a03c1b27ac48/Screenshot_20220428-015340.png)https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/61Unable to use with minigbm in QEMU/virgl2022-03-23T16:52:32ZgoffioulUnable to use with minigbm in QEMU/virglSince commit https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/commit/5621f5fd4c718ce06b14e4a33dfc68f42b6d10b2, I am unable to use drm_hwcomposer with AOSP minigbm in QEMU/virgl running Android 12.
My Android build uses the...Since commit https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/commit/5621f5fd4c718ce06b14e4a33dfc68f42b6d10b2, I am unable to use drm_hwcomposer with AOSP minigbm in QEMU/virgl running Android 12.
My Android build uses the following:
- Android 12 (android-platform-12.0.0_r5) / 12L (android-platform-12.1.0_r1)
- kernel 5.10.106 (AOSP kernel/common @ android12-5.10-lts)
- AOSP mesa3d
- AOSP minigbm
- drm_hwcomposer (`main` branch)
Since the referenced commit, when running in QEMU/virgl with GRALLOC=minigbm and HWC=drm_minigbm, nothing is displayed in QEMU window and logcat is filled with:
```
03-22 16:20:12.491 1220 1389 E hwc-platform-drm-generic: could not create drm fb -22
03-22 16:20:12.491 1220 1389 E hwc-platform-drm-generic: Failed to rm fb
03-22 16:20:12.492 1220 1389 E hwc-drm-utils: Failed to import buffer
```
I compared the result of `BufferInfoMinigbm::ConvertBoInfo` before and after the commit, and noticed 2 differences:
- `bo->usage` is `0`
- `bo->pitches[i]` is `1`
For the `usage` difference, I may be wrong, but it doesn't look like drm_hwcomposer is calling `CROS_GRALLOC_DRM_GET_USAGE` with the right arguments [1]. These should be `req_usage` and `out_gralloc_usage`, but the first argument is `handle`.
For the `pitch`/`stride` difference, I believe the `1` value is coming from the fact that I'm using kernel 5.10 and according to [2], it's just the value of `drm_virtgpu_resource_info_cros.type` being equal to `VIRTGPU_RESOURCE_INFO_TYPE_EXTENDED`.
These might just be cases of _this is not supposed to work_ and I should not be using this combination in QEMU. If that's the case, then please feel free to close this but report.
[1] https://android.googlesource.com/platform/external/minigbm/+/refs/tags/android-platform-12.1.0_r1/cros_gralloc/gralloc0/gralloc0.cc#299
[2] https://android.googlesource.com/platform/external/minigbm/+/refs/tags/android-platform-12.1.0_r1/external/virtgpu_drm.h#121https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/60vts failures & hang on db845c after MR !1762022-01-14T04:04:19ZJohn Stultzvts failures & hang on db845c after MR !176While the fix in 176 gets display back and working on HiKey960/HiKey, I found while trying to do more thorough testing that it seems to be causing some VTS regressions on db845c.
This was triggered running:
"atest VtsHalGraphicsCompose...While the fix in 176 gets display back and working on HiKey960/HiKey, I found while trying to do more thorough testing that it seems to be causing some VTS regressions on db845c.
This was triggered running:
"atest VtsHalGraphicsComposerV2_1TargetTest"
Now, earlier (and with current AOSP/master) the V2_1 test would fully pass. However, usually midway through the test the display would blank out and not come back. This was consistent on HiKey960 as well as db845c. So I don't have a ton of faith in the test itself.
With the current gitlab/main branch however, the V2_1 test output looks like
```
arm64-v8a VtsHalGraphicsComposerV2_1TargetTest
----------------------------------------------
VtsHalGraphicsComposerV2_1TargetTest (53 Tests)
[1/53] PerInstance/GraphicsComposerHidlTest#GetCapabilities/0_default: PASSED (16ms)
[2/53] PerInstance/GraphicsComposerHidlTest#DumpDebugInfo/0_default: PASSED (11ms)
[3/53] PerInstance/GraphicsComposerHidlTest#CreateClientSingleton/0_default: PASSED (1.010s)
[4/53] PerInstance/GraphicsComposerHidlTest#CreateVirtualDisplay/0_default: PASSED (14ms)
[5/53] PerInstance/GraphicsComposerHidlTest#DestroyVirtualDisplayBadDisplay/0_default: PASSED (9ms)
[6/53] PerInstance/GraphicsComposerHidlTest#CreateLayer/0_default: PASSED (7ms)
[7/53] PerInstance/GraphicsComposerHidlTest#CreateLayerBadDisplay/0_default: PASSED (7ms)
[8/53] PerInstance/GraphicsComposerHidlTest#DestroyLayerBadDisplay/0_default: PASSED (8ms)
[9/53] PerInstance/GraphicsComposerHidlTest#DestroyLayerBadLayerError/0_default: PASSED (7ms)
[10/53] PerInstance/GraphicsComposerHidlTest#GetActiveConfigBadDisplay/0_default: PASSED (7ms)
[11/53] PerInstance/GraphicsComposerHidlTest#GetDisplayConfig/0_default: PASSED (671ms)
[12/53] PerInstance/GraphicsComposerHidlTest#GetDisplayConfigBadDisplay/0_default: PASSED (11ms)
[13/53] PerInstance/GraphicsComposerHidlTest#GetDisplayName/0_default: PASSED (8ms)
[14/53] PerInstance/GraphicsComposerHidlTest#GetDisplayType/0_default: PASSED (9ms)
[15/53] PerInstance/GraphicsComposerHidlTest#GetClientTargetSupport/0_default: PASSED (475ms)
[16/53] PerInstance/GraphicsComposerHidlTest#GetClientTargetSupportBadDisplay/0_default: PASSED (805ms)
[17/53] PerInstance/GraphicsComposerHidlTest#GetDisplayAttribute/0_default: PASSED (848ms)
[18/53] PerInstance/GraphicsComposerHidlTest#GetHdrCapabilities/0_default: PASSED (8ms)
[19/53] PerInstance/GraphicsComposerHidlTest#SetClientTargetSlotCount/0_default: PASSED (7ms)
[20/53] PerInstance/GraphicsComposerHidlTest#SetActiveConfig/0_default: PASSED (673ms)
[21/53] PerInstance/GraphicsComposerHidlTest#SetActiveConfigPowerCycle/0_default: PASSED (65ms)
[22/53] PerInstance/GraphicsComposerHidlTest#GetColorModes/0_default: PASSED (10ms)
[23/53] PerInstance/GraphicsComposerHidlTest#SetColorMode/0_default: PASSED (9ms)
[24/53] PerInstance/GraphicsComposerHidlTest#SetColorModeBadDisplay/0_default: PASSED (9ms)
[25/53] PerInstance/GraphicsComposerHidlTest#SetColorModeBadParameter/0_default: PASSED (8ms)
[26/53] PerInstance/GraphicsComposerHidlTest#GetDozeSupportBadDisplay/0_default: PASSED (8ms)
[27/53] PerInstance/GraphicsComposerHidlTest#SetPowerMode/0_default: PASSED (8ms)
[28/53] PerInstance/GraphicsComposerHidlTest#SetPowerModeVariations/0_default: PASSED (9ms)
[29/53] PerInstance/GraphicsComposerHidlTest#SetPowerModeBadDisplay/0_default: PASSED (7ms)
[30/53] PerInstance/GraphicsComposerHidlTest#SetPowerModeUnsupported/0_default: PASSED (7ms)
[31/53] PerInstance/GraphicsComposerHidlTest#SetPowerModeBadParameter/0_default: PASSED (7ms)
[32/53] PerInstance/GraphicsComposerHidlTest#SetVsyncEnabled/0_default: PASSED (73ms)
[33/53] PerInstance/GraphicsComposerHidlCommandTest#SET_COLOR_TRANSFORM/0_default: FAILED (41ms)
STACKTRACE:
hardware/interfaces/graphics/composer/2.1/utils/vts/ComposerVts.cpp:156: Failure
Expected equality of these values:
Error::NONE
Which is: NONE
tmpError
Which is: BAD_CONFIG
failed to get active config
hardware/interfaces/graphics/composer/2.1/utils/vts/ComposerVts.cpp:184: Failure
Expected equality of these values:
Error::NONE
Which is: NONE
tmpError
Which is: BAD_CONFIG
failed to get display attribute
hardware/interfaces/graphics/composer/2.1/utils/vts/ComposerVts.cpp:184: Failure
Expected equality of these values:
Error::NONE
Which is: NONE
tmpError
Which is: BAD_CONFIG
failed to get display attribute
[34/53] PerInstance/GraphicsComposerHidlCommandTest#SET_CLIENT_TARGET/0_default: FAILED (12ms)
...
```
All the following tests continue to fail in the same way. The display is similarly lost at this point.
This wouldn't be so worrisome, except the vts test fails to complete and seem to hang.
I'm working to debug whats going wrong. It seems re-adding the SetPowerMode activation gets us back to the prior behavior:
```
@@ -894,13 +894,7 @@ HWC2::Error DrmHwcTwo::HwcDisplay::SetPowerMode(int32_t mode_in) {
a_args.active = false;
break;
case HWC2::PowerMode::On:
- /*
- * Setting the display to active before we have a composition
- * can break some drivers, so skip setting a_args.active to
- * true, as the next composition frame will implicitly activate
- * the display
- */
- return HWC2::Error::None;
+ a_args.active = true;
break;
case HWC2::PowerMode::Doze:
case HWC2::PowerMode::DozeSuspend:
```
but that may be still problematic for the hikey boards.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/59aosp master hikey build failed to boot with drm atomic related kernel crash2022-01-13T01:14:22ZYongqin Liuaosp master hikey build failed to boot with drm atomic related kernel crashThe commit 36a7f285 ("drm_hwcomposer: Rework display Mode Setting and DPMS handling") caused the hikey aosp master build failed to boot to the home screen.
The last hikey build that could boot to the home screen is https://ci.android.com...The commit 36a7f285 ("drm_hwcomposer: Rework display Mode Setting and DPMS handling") caused the hikey aosp master build failed to boot to the home screen.
The last hikey build that could boot to the home screen is https://ci.android.com/builds/submitted/8000573/hikey-userdebug/latest, and the commit id of external/drm_hwcomposer/ repository is ac850066c3945c434cc6aa7c3d1b7cf697facace, based on that commit if I cherry picked the 36a7f285 commit, then it would fail to boot to the home screen with the drm_atomic related calls.
For details please check the attached [hikey-drm-crash-logcat.log.xz](/uploads/78f44b15c39a362b3136b0b3d583f5f9/hikey-drm-crash-logcat.log.xz). "dumpsys SurfaceFlinger" command failed with timeout error, the log is attached here as [hikey-drm-crash-dumpsys-surfaceflinger.log.xz](/uploads/df27cf96b94739208f0e863fa716e48d/hikey-drm-crash-dumpsys-surfaceflinger.log.xz), but there is no value content in it.
also attached the logcat log and dumpsys SurfaceFlinger log for the work build(with the ac850066c3945c434cc6aa7c3d1b7cf697facace commit of external/drm_hwcomposer) here as [hikey-drm-work-logcat.log.xz](/uploads/ffb96e80c3e9b19825442eaa135cd68e/hikey-drm-work-logcat.log.xz) and [hikey-drm-work-dumpsys-surfaceflinger.log.xz](/uploads/57e40cd4cc3e6ac8e1a33b2d0a123f2a/hikey-drm-work-dumpsys-surfaceflinger.log.xz)Roman StratiienkoRoman Stratiienkohttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/58[RFC] Android 12: display manager init failed with external HDMI2022-02-04T14:47:37ZJulien Masson[RFC] Android 12: display manager init failed with external HDMIAt [Baylibre](https://baylibre.com/) we do the support of Android on Mediatek boards.
Example: https://www.mediatek.com/products/AIoT/i500
Our setup is simple, mediatek board with HDMI connector (no internal display).
We are switching...At [Baylibre](https://baylibre.com/) we do the support of Android on Mediatek boards.
Example: https://www.mediatek.com/products/AIoT/i500
Our setup is simple, mediatek board with HDMI connector (no internal display).
We are switching from **Android 11** to **Android 12** and we see an issue with the display manager.
```
D AndroidRuntime: Shutting down VM
E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: main
E AndroidRuntime: java.lang.RuntimeException: Failed to boot service com.android.server.display.DisplayManagerService: onBootPhase threw an exception during phase 100
E AndroidRuntime: at com.android.server.SystemServiceManager.startBootPhase(SystemServiceManager.java:238)
E AndroidRuntime: at com.android.server.SystemServer.startBootstrapServices(SystemServer.java:1133)
E AndroidRuntime: at com.android.server.SystemServer.run(SystemServer.java:877)
E AndroidRuntime: at com.android.server.SystemServer.main(SystemServer.java:610)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:981)
E AndroidRuntime: Caused by: java.lang.RuntimeException: Timeout waiting for default display to be initialized. DefaultDisplay=null, mVirtualDisplayAdapter=com.android.server.display.VirtualDisplayAdapter@2ea9637
E AndroidRuntime: at com.android.server.display.DisplayManagerService.onBootPhase(DisplayManagerService.java:506)
E AndroidRuntime: at com.android.server.SystemServiceManager.startBootPhase(SystemServiceManager.java:235)
E AndroidRuntime: ... 6 more
E AndroidRuntime: Error reporting crash
E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke interface method 'void android.app.IActivityManager.handleApplicationCrash(android.os.IBinder, android.app.ApplicationErrorReport$ParcelableCrashInfo)' on a null object reference
E AndroidRuntime: at com.android.internal.os.RuntimeInit$KillApplicationHandler.uncaughtException(RuntimeInit.java:156)
E AndroidRuntime: at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)
E AndroidRuntime: at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
E AndroidRuntime: at java.lang.Thread.dispatchUncaughtException(Thread.java:2200)
```
From our investigation, we see that some logics have been changed in the display manager.
**On Android 11:**
https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-11.0.0_r48/services/core/java/com/android/server/display/DisplayManagerService.java#1068
`addLogicalDisplayLocked` checked the flag FLAG_DEFAULT_DISPLAY from DisplayDeviceInfo and assigned the display Id of our HDMI as DEFAULT_DISPLAY.
-> no issue, during onBootPhase, `getDisplayLocked(Display.DEFAULT_DISPLAY) != NULL`
**On Android 12:**
https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-12.0.0_r21/services/core/java/com/android/server/display/LogicalDisplayMapper.java#345
The flag FLAG_DEFAULT_DISPLAY is not checked anymore and by default the display Id of our HDMI is now set to 1.
Since our display is an External type, we don't call `initializeInternalDisplayDeviceLocked` and no display Id is assigned as DEFAULT_DISPLAY.
Thus we hit the fatal exception above.
As workaround for now in drm_hwcomposer we return the HDMIA connector as Internal.
That fix our issue, but that is not clean at all ...
We wanted to share with you this issue because you may have seen this fail and have some thoughts about that.
For us it's not clear where the fix need to be done, drm_hwcomposer or display manager ?
Please do not hesitate to ask me more logs or do some tests.
I'll be glad to help on the subject.
Thanks