drm-hwcomposer issueshttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues2021-03-04T10:44:08Zhttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/49How to validate new code using clang-tidy.2021-03-04T10:44:08ZRoman StratiienkoHow to validate new code using clang-tidy.Every new code should be validated using clang-tidy and should not introduce new warnings.
At this moment there is no way to include all the checks into the build, so following steps should be done by the committer:
1. Use AOSP master b...Every new code should be validated using clang-tidy and should not introduce new warnings.
At this moment there is no way to include all the checks into the build, so following steps should be done by the committer:
1. Use AOSP master branch to validate (It includes latest clang).
```
repo init -u https://android.googlesource.com/platform/manifest && repo sync
```
2. Apply a patch to the Soong build system:
```
cd build/soong
git fetch https://android.googlesource.com/platform/build/soong refs/changes/49/1534349/2 && git cherry-pick FETCH_HEAD
```
3. Replace existing tidy configs in `external/drm_hwcomposer/Android.bp` with this section:
```
tidy: true,
tidy_checks: [
"*",
/* Conflicts with other checks */
"-fuchsia*",.
/* Does not match drm_hwc header guard style */
"-llvm-header-guard",
/* Allow using ALOGE */
"-cppcoreguidelines-pro-type-vararg", "-hicpp-vararg",
],
tidy_flags: [
"--header-filter=^.*external/drm_hwcomposer/.*.h$",
],
tidy_config: "\"{CheckOptions: ["
+ "{ key: readability-identifier-naming.NamespaceCase, value: lower_case },"
+ "{ key: readability-identifier-naming.NamespaceCase, value: lower_case },"
+ "{ key: readability-identifier-naming.ClassCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.StructCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.TemplateParameterCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.FunctionCase, value: aNy_CasE },"
+ "{ key: readability-identifier-naming.VariableCase, value: lower_case },"
+ "{ key: readability-identifier-naming.ClassMemberCase, value: lower_case },"
+ "{ key: readability-identifier-naming.ClassMemberSuffix, value: _ },"
+ "{ key: readability-identifier-naming.PrivateMemberSuffix, value: _ },"
+ "{ key: readability-identifier-naming.ProtectedMemberSuffix, value: _ },"
+ "{ key: readability-identifier-naming.EnumConstantCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.EnumConstantPrefix, value: k },"
+ "{ key: readability-identifier-naming.ConstexprVariableCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.ConstexprVariablePrefix, value: k },"
+ "{ key: readability-identifier-naming.GlobalConstantCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.GlobalConstantPrefix, value: k },"
+ "{ key: readability-identifier-naming.MemberConstantCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.MemberConstantPrefix, value: k },"
+ "{ key: readability-identifier-naming.StaticConstantCase, value: CamelCase },"
+ "{ key: readability-identifier-naming.StaticConstantPrefix, value: k },"
+ "{ key: misc-non-private-member-variables-in-classes.IgnoreClassesWithAllMemberVariablesBeingPublic, value: 1 },"
+ "]}\"",
```
4. Build drm_hwcomposer
#### Warning: this manual is still raw and you will probably get >400 warnings in existing code. So you might need to compare build log before and after your change to check for regression (using meld or any other diff tool)https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/48Android GUI not booting anymore after commit 3a5fb5062021-08-25T02:30:51ZmaurossiAndroid GUI not booting anymore after commit 3a5fb506drm_hwcomposer with gbm_gralloc gralloc0 is not working anymore
modesetting at Bootanimation does not work, I see only text mode with white cursor at top left
reverting 3a5fb506 ("drm_hwcomposer: implement Gralloc 4 BufferInfoMapperMet...drm_hwcomposer with gbm_gralloc gralloc0 is not working anymore
modesetting at Bootanimation does not work, I see only text mode with white cursor at top left
reverting 3a5fb506 ("drm_hwcomposer: implement Gralloc 4 BufferInfoMapperMetadata")
everything goes back to normalhttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/47Improve flattening logic2021-03-24T13:42:41ZRoman StratiienkoImprove flattening logic### 1. Decide do we need writeback-based flattening considering we already have GPU-based.
Writeback Pros:
a. Less power consumption required to render composition
(Difference in mAH should be really tiny, considering that switchin...### 1. Decide do we need writeback-based flattening considering we already have GPU-based.
Writeback Pros:
a. Less power consumption required to render composition
(Difference in mAH should be really tiny, considering that switching to flattening mode occurs not so often, and it is planned to reduce it by an order of magnitude. See items 2 below.)
Writeback Cons:
a. A lot of extra code. High maintenance cost(effort). Nobody tests it as for now.
b. Writeback isn't implemented by most of KMS drivers
c. Require separate memory buffer to be allocated
Also I am not sure can both readback feature and writeback-based flattening co-exist.
And currently writeback-based flattening doesn't work on RPI4. Does it work anywhere today?
### 2. Exit from flattening mode only if really needed:
Sometime AOSP just updating clock on top, or text cursor is blinking;
We do not need to offload the GPU in this cases, since DU will draw more power while counting down to flatten again.
My proposal is to use screen damage region as a flag. In case it exceeds some value (e.g. 30% of whole screen) then enable flattening.
In this case power consumption can be further saved by implementing composing which respects the damage region. (Unfortunately SurfaceFlinger can't do it at this moment).
In addition, we can ignore single-frame events.
### 3. Implement partial flattening.
Merge layers which aren't updating by the apps. SurfaceFlinger should store such layers cached and do not waste GPU energy/time to merge them again.
Thus making only layers which require to redraw will be composed by DU.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/46Android GUI affected by "black strobo surface" effect when moving mouse2022-02-17T12:31:45ZmaurossiAndroid GUI affected by "black strobo surface" effect when moving mouseHello,
I recently tested drm_hwcomposer with gbm_gralloc and after booting
Logs of q-x86 but r-x86 (Android R) is also affected.
I have encountered a weird problem GUI is ok when mouse is not moved
and becomes black (meaning only Statu...Hello,
I recently tested drm_hwcomposer with gbm_gralloc and after booting
Logs of q-x86 but r-x86 (Android R) is also affected.
I have encountered a weird problem GUI is ok when mouse is not moved
and becomes black (meaning only Status and Navigation bar stay visible)
when moving the mouse.
I am reporting it because recent Intel and AMD HW is affected
and AOSP and derived project may be affected.
The black screen happens with following HW,
[edited] but some other Intel HW is affected only in Settings window and AMD GPUs have a darkened but not pure black wallpaper at mouse movement, but still have completely black Settings windows so both Intel and AMD GPU are severely affected.
```
Athlon 200GE (Raven)
eTab Pro 2018 (Celeron N4000 Intel UHD GLK2)
Lenovo T460 (Skylake GT2)
```
It's been really difficult to collect logs due to the screen becoming black at each mouse movement,
but here it is the one for Athlon 200GE
[logcat.txt.gz](/uploads/421ba863c3eac0ee32d9906dcd808d83/logcat.txt.gz)
[modetest.txt](/uploads/4327850e5f6240b1e3a5d953f09f6fcf/modetest.txt)
the black screen events seem correlated to the following logcat entry
`E hwc-platform: Alpha is not supported on plane 48`
however Alpha is supported on plane 48 at least from modetest output
```
Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
48 58 85 0,0 0,0 0 0x00000001
formats: XR24 AR24 RA24 XR30 XB30 AR30 AB30 XB24 AB24 RG16 NV12 P010 XR4H AR4H XB4H AB4H
```https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/45Building error in Android P after commit ef3c797d2022-02-11T21:36:26ZmaurossiBuilding error in Android P after commit ef3c797dHere is the building error introduced by ef3c797d
"drm_hwcomposer: Add backend-dependent validation for HwcDisplay class"
Android.bp has cppflag -DHWC2_USE_CPP11
Please fix build with Android P
```
external/drm_hwcomposer/backend/Bac...Here is the building error introduced by ef3c797d
"drm_hwcomposer: Add backend-dependent validation for HwcDisplay class"
Android.bp has cppflag -DHWC2_USE_CPP11
Please fix build with Android P
```
external/drm_hwcomposer/backend/Backend.cpp:115:15: error: decomposition declarations are a C++17 extension [-Werror,-Wc++17-extensions]
for (auto & [ z_order, layer ] : z_map) {
^~~~~~~~~~~~~~~~~~
1 error generated.
```https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/43Discuss correct way to get per-plane FD using mapper metadata API.2022-01-13T12:38:26ZRoman StratiienkoDiscuss correct way to get per-plane FD using mapper metadata API.Approach 0:
(Used by mesa3d EGL importer for as generic solution for some time)
Use buffer_handle_t->data[plane_idx or 0] as FD.
Approach 1:
> One approach is having each vendor define their custom metadata to access the fds. For dr...Approach 0:
(Used by mesa3d EGL importer for as generic solution for some time)
Use buffer_handle_t->data[plane_idx or 0] as FD.
Approach 1:
> One approach is having each vendor define their custom metadata to access the fds. For drm_hwcomposer this would mean having to support all these different ways of retrieving the fds. In this case, we would indeed not have a custom AIDL in drm_hwcomposer, but would have to support the ones each customer provides.
Approach 2:
> To have drm_hwcomposer define its custom metadata. Interested vendors can then add support for drm_hwcomposer in their Gralloc implementations.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/42Replace AutoLock/Worker with std::lock_guard and std::tread. Do not use separ...2022-01-13T12:59:47ZRoman StratiienkoReplace AutoLock/Worker with std::lock_guard and std::tread. Do not use separate vsyncworker for flattening.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/41Investigate the reason why GetEdidBlob can return NULL2022-01-13T12:50:39ZRoman StratiienkoInvestigate the reason why GetEdidBlob can return NULLMR !116 fixes boot with composer@2.3, but the root cause is still not found.
At least we need to check either client gets correct EDID blob or not.MR !116 fixes boot with composer@2.3, but the root cause is still not found.
At least we need to check either client gets correct EDID blob or not.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/40All composer VTS tests (v11r1) fails due to vsyncworker activity2020-10-03T03:04:43ZRoman StratiienkoAll composer VTS tests (v11r1) fails due to vsyncworker activity```
09-24 15:06:57.681 4285 4285 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-24 15:06:57.681 4285 4285 F DEBUG : Build fingerprint: 'Pine64/pinephone/pinephone:11/RP1A.200720.011/eng.romans.202009...```
09-24 15:06:57.681 4285 4285 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-24 15:06:57.681 4285 4285 F DEBUG : Build fingerprint: 'Pine64/pinephone/pinephone:11/RP1A.200720.011/eng.romans.20200919.225719:userdebug/test-keys'
09-24 15:06:57.682 4285 4285 F DEBUG : Revision: '1.0'
09-24 15:06:57.682 4285 4285 F DEBUG : ABI: 'arm64'
09-24 15:06:57.683 4285 4285 F DEBUG : Timestamp: 2020-09-24 15:06:57+0000
09-24 15:06:57.683 4285 4285 F DEBUG : pid: 324, tid: 371, name: vsync >>> /vendor/bin/hw/android.hardware.graphics.composer@2.1-service <<<
09-24 15:06:57.683 4285 4285 F DEBUG : uid: 1000
09-24 15:06:57.683 4285 4285 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
09-24 15:06:57.683 4285 4285 F DEBUG : Cause: null pointer dereference
09-24 15:06:57.683 4285 4285 F DEBUG : x0 0000000000000000 x1 0000000000000000 x2 0000019b309713b0 x3 0000ed326d84f0a0
09-24 15:06:57.683 4285 4285 F DEBUG : x4 0000000000000883 x5 0000000000082c10 x6 2e64696f72646e61 x7 0000ed3501b23010
09-24 15:06:57.684 4285 4285 F DEBUG : x8 b400ed33bff58350 x9 00000000000003e8 x10 000000000000b6ae x11 0000ed326d0a6ac0
09-24 15:06:57.684 4285 4285 F DEBUG : x12 ffffff80ffffffd0 x13 000000000000004c x14 0000000000000000 x15 0000000000000030
09-24 15:06:57.684 4285 4285 F DEBUG : x16 0000ed326d6f22e8 x17 0000ed35000f5c98 x18 0000ed326b4f6000 x19 b400ed331ff5b1d0
09-24 15:06:57.684 4285 4285 F DEBUG : x20 b400ed33fff62c90 x21 b400ed331ff5b1e8 x22 0000000000000000 x23 0000019b309713b0
09-24 15:06:57.684 4285 4285 F DEBUG : x24 0000ed326d0a7000 x25 0000ed326d0a6cc0 x26 0000ed326d0a6ff8 x27 00000000000fe000
09-24 15:06:57.684 4285 4285 F DEBUG : x28 00000000000fc000 x29 0000ed326d0a6be0
09-24 15:06:57.684 4285 4285 F DEBUG : lr 0000ed326d62d630 sp 0000ed326d0a6bb0 pc 0000ed326d84f0a4 pst 0000000000000000
09-24 15:06:57.701 4285 4285 F DEBUG : backtrace:
09-24 15:06:57.701 4285 4285 F DEBUG : #00 pc 00000000000090a4 /vendor/lib64/hw/android.hardware.graphics.composer@2.1-impl.so (android::hardware::graphics::composer::V2_1::passthrough::detail::HwcHalImpl<android::hardware::graphics::composer::V2_1::hal::ComposerHal>::vsyncHook(void*, unsigned long, long)+4) (BuildId: 591b894a1f448343f3994c3a0ae6478e)
09-24 15:06:57.701 4285 4285 F DEBUG : #01 pc 000000000002c62c /vendor/lib64/hw/hwcomposer.drm.so (android::VSyncWorker::Routine()+324) (BuildId: c6d9fa7b6d9d8be81e5c8cc9ad8a4504)
09-24 15:06:57.701 4285 4285 F DEBUG : #02 pc 000000000002f6fc /vendor/lib64/hw/hwcomposer.drm.so (android::Worker::InternalRoutine()+108) (BuildId: c6d9fa7b6d9d8be81e5c8cc9ad8a4504)
09-24 15:06:57.702 4285 4285 F DEBUG : #03 pc 000000000002f874 /vendor/lib64/hw/hwcomposer.drm.so (void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (android::Worker::*)(), android::Worker*> >(void*)+60) (BuildId: c6d9fa7b6d9d8be81e5c8cc9ad8a4504)
09-24 15:06:57.702 4285 4285 F DEBUG : #04 pc 00000000000b0758 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: c78cdff5b820a550771130d6bde95081)
09-24 15:06:57.702 4285 4285 F DEBUG : #05 pc 0000000000050150 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: c78cdff5b820a550771130d6bde95081)
09-24 15:06:57.775 4288 4288 I HidlServiceManagement: Registered android.hardware.audio@6.0::IDevicesFactory/default (start delay of 98ms)Before:
```
Reproducibility: 95%Roman StratiienkoRoman Stratiienkohttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/38compositor: Add support for dataspace2021-03-24T14:28:14ZRoman Stratiienkocompositor: Add support for dataspaceLinux kernel has support for dataspace attributes for YUV.
In case plane has corresponding property, set it as below:
Android dataspace:
```
HAL_DATASPACE_STANDARD_BT709 = 65536, // (1 << STANDARD_SHIFT)
...Linux kernel has support for dataspace attributes for YUV.
In case plane has corresponding property, set it as below:
Android dataspace:
```
HAL_DATASPACE_STANDARD_BT709 = 65536, // (1 << STANDARD_SHIFT)
HAL_DATASPACE_STANDARD_BT601_625 = 131072, // (2 << STANDARD_SHIFT)
HAL_DATASPACE_STANDARD_BT601_625_UNADJUSTED = 196608, // (3 << STANDARD_SHIFT)
HAL_DATASPACE_STANDARD_BT601_525 = 262144, // (4 << STANDARD_SHIFT)
HAL_DATASPACE_STANDARD_BT601_525_UNADJUSTED = 327680, // (5 << STANDARD_SHIFT)
HAL_DATASPACE_STANDARD_BT2020 = 393216, // (6 << STANDARD_SHIFT)
HAL_DATASPACE_STANDARD_BT2020_CONSTANT_LUMINANCE = 458752, // (7 << STANDARD_SHIFT)
Map to:
enum drm_color_encoding {
DRM_COLOR_YCBCR_BT601,
DRM_COLOR_YCBCR_BT709,
DRM_COLOR_YCBCR_BT2020,
DRM_COLOR_ENCODING_MAX,
};
```
```
Android dataspace range:
HAL_DATASPACE_RANGE_UNSPECIFIED = 0, // (0 << RANGE_SHIFT)
HAL_DATASPACE_RANGE_FULL = 134217728, // (1 << RANGE_SHIFT)
HAL_DATASPACE_RANGE_LIMITED = 268435456, // (2 << RANGE_SHIFT)
Map to:
enum drm_color_range {
DRM_COLOR_YCBCR_LIMITED_RANGE,
DRM_COLOR_YCBCR_FULL_RANGE,
DRM_COLOR_RANGE_MAX,
```
EDIT:
Same should be added into the mesa3d EGL interface:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txthttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/37GPU flattening causes video to freeze until playback restarted2022-01-13T12:49:16ZRoman StratiienkoGPU flattening causes video to freeze until playback restartedSteps to reproduce:
1. Download video file.
2. Run Gallery app (or VLC with full acceleration enabled)
3. Start playing the video
4. Click on pause
5. Wait ~1s to trigger Flattening
6. Continue playback
I'm not 100% sure bug is caused ...Steps to reproduce:
1. Download video file.
2. Run Gallery app (or VLC with full acceleration enabled)
3. Start playing the video
4. Click on pause
5. Wait ~1s to trigger Flattening
6. Continue playback
I'm not 100% sure bug is caused by flattening, but it very likely to be so.
Also need to test on rpi4, where write-back flattening is present.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/36Prefer include files in same directories as source files2020-09-24T21:08:55ZRoman StratiienkoPrefer include files in same directories as source filesThis project uses mixed include files location.
For the platform code it uses same-directory include files.
For other parts all include files located in ./include/ directory.
This project should use unified place for include file...This project uses mixed include files location.
For the platform code it uses same-directory include files.
For other parts all include files located in ./include/ directory.
This project should use unified place for include files.
Personally I prefer to use same-directory location, since it much easier to navigate between src/include files which is related to the same component.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/35Move HwcDisplay, HwcLayer and HwcCallback out of DrmHwcTwo class2022-01-13T21:22:56ZRoman KovalivskyiMove HwcDisplay, HwcLayer and HwcCallback out of DrmHwcTwo classAs for now HwcDisplay, HwcLayer and HwcCallback are inner classes of DrmHwcTwo class. Moreover, they are private. This creates some issues with further code changes and for simpler support of the code in future those classes should be ex...As for now HwcDisplay, HwcLayer and HwcCallback are inner classes of DrmHwcTwo class. Moreover, they are private. This creates some issues with further code changes and for simpler support of the code in future those classes should be extracted as a separate entities.
1. Those classes are logically separate from DrmHwcTwo just as DrmDevice or DrmConnector. All those entities could be described without DrmHwcTwo which serves only as a entry point and interface for whole composer infrastructure. I can't come up with any reason to have it inside private part of other class, honestly.
2. Other composer implementations have similar types but none of them are private or hidden in some other class. As for example, one of Qualcomm implementations [here](https://android.googlesource.com/platform/hardware/qcom/display/+/refs/heads/master/msm8998/sdm/libs/hwc2/hwc_display.h), HWCDisplay is separate class which is instantiated from HWCSession which serves similar purpose to DrmHwcTwo.
3. There's no easy way to pass display if there is any need of doing that. HwcDisplay is private internal class, so no way it could be used anywhere outside DrmHwcTwo, even tho it is desirable in some cases for simpler implementation of other features, for example it could be used for backend-specific validation requested in issue #34, to simplify passing of all data to separate validator.
Based on that I believe that this refactoring could simplify further development and improve code quality.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/34Implement backend-dependent validation (and later provisioning)2020-08-28T19:50:39ZRoman StratiienkoImplement backend-dependent validation (and later provisioning)I am holding this idea in my head for a couple of month, but it looks like it can help to solve several unmerged MRs (!95 !107 ) in a generic way, so it's time to share:
Problem:
Different DRM/KMS backends have different set of limi...I am holding this idea in my head for a couple of month, but it looks like it can help to solve several unmerged MRs (!95 !107 ) in a generic way, so it's time to share:
Problem:
Different DRM/KMS backends have different set of limitation, which is not always exposes via DRM ioctls.
For example:
rcar-du: No scaling support, AB24 mode is unsupported.
sun4i-drm: Layer order matters. Limitations on HW scaling resolution. But currently unusable due to bugs.
Suggested implementation:
Add backend-specific validation function:
backend/rcar-du.cpp:
```
static ret_type rcar_du_validate() {
// Filter-out unsupported layers (mark client)
return generic_validate();
}
REGISTER_BACKEND(rcar_du_validate, "rcar-du");
```
backend/generic.cpp:
```
static ret_type generic_validate() {
// Current ValidateDisplay() logic here
}
REGISTER_BACKEND(generic_validate, "generic");
```
backend/client.cpp:
```
static ret_type validate_to_client() {
// Mark all as client and return
}
REGISTER_BACKEND(validate_to_client, "client");
```
resources.cpp:
```
ret_type (*validator)()
Init() {
...
// 1. Open KMS device, read driver name.
// 2. Read property "hwc.backend_override", fallback to current KMS name by default
// 3. Find backend among registered using name property.
// 4. If nothing found, select "generic"
// 5. Set (*validator) variable
}
```
drmhwc.cpp:
```
HWC::ValidateDisplay() {
return resources->validator(); // Invoke a selected validator
}
```https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/33Display freezing frequently, AOSP Master w/automotive on Dragonboard 820c2022-02-17T07:52:36ZAdam SerbinskiDisplay freezing frequently, AOSP Master w/automotive on Dragonboard 820cI've been working with db820c to get AOSP master w/automotive running well on it. The biggest issue I've been having with it is with regards to the display frequently locking up.
My work is all here; https://gitlab.com/aosp-automotive<b...I've been working with db820c to get AOSP master w/automotive running well on it. The biggest issue I've been having with it is with regards to the display frequently locking up.
My work is all here; https://gitlab.com/aosp-automotive<br>
My builds can be reproduces with instructions in the readme in this repository;<br>
https://gitlab.com/aosp-automotive/pinned-manifests
The bulk of the issue has been related to the following line;<br>
https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/blob/master/drmhwctwo.cpp#L973
Any time that conditional evaluates as TRUE, the display freezes for some period of time ranging from several seconds to permanently (requiring a reboot).
I've identified two situations where that conditional evaluates as TRUE on db820c;
1) When the number of planes to be composited exceeds 6,
2) When ValidatePlane fails here;<br>
https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/blob/master/platform/platform.cpp#L49
In the below patch, I've got 2 hacks, which together seem to eliminate the display freezes (and add some very noisy debug messages). Obviously, the patch is unsuited for inclusion in the project.
I'm not sure where to go from here. Obviously it would be nice to come up with a solution to the freezing that doesn't involve adding hacks.
```
From 9424274e9e5b980e06a82450e83505124f0f8254 Mon Sep 17 00:00:00 2001
Date: Sun, 21 Jun 2020 08:15:02 -0400
Subject: [PATCH] HACKS: stop display from freezing on db820c
drmhwctwo.cpp:
Limit maximum number of planes to 6.
- This avoids the kernel error:
[ 76.351693] msm 900000.mdss: [drm:mdp5_crtc_atomic_check [msm]] *ERROR* too many planes! cnt=7, start stage=2
platform/platform.cpp:
Ignore "Alpha is not supported on plane X" error.
- This error caused drm compositing to abort, and the screen to freeze.
The errors were causing CreateComposition(true) to return failure,
which results in the screen freezing.
There is still an occasional freeze even with this, reason unknown, however,
it is fairly rare.
There are some color glitches observable in OsmAnd.
Change-Id: Ifb53455dd597723d62d1e3e5ff85babd43ff819e
---
drmhwctwo.cpp | 8 ++++++++
platform/platform.cpp | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index 605406b..1cfe273 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -889,6 +889,7 @@ void DrmHwcTwo::HwcDisplay::MarkValidated(
std::map<uint32_t, DrmHwcTwo::HwcLayer *> &z_map, size_t client_first_z,
size_t client_size) {
for (std::pair<const uint32_t, DrmHwcTwo::HwcLayer *> &l : z_map) {
+ ALOGE("CDBG MarkValidated: z_map.size(): %zu, l.first: %u, client_first_z: %zd, client_size: %zu", z_map.size(), l.first, client_first_z, client_size);
if (l.first >= client_first_z && l.first < client_first_z + client_size)
l.second->set_validated_type(HWC2::Composition::Client);
else
@@ -903,6 +904,10 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
*num_requests = 0;
size_t avail_planes = primary_planes_.size() + overlay_planes_.size();
+ ALOGE("CDBG avail_planes: %zd, primary_planes_.size(): %zd, overlay_planes_.size(): %zd", avail_planes, primary_planes_.size(), overlay_planes_.size());
+
+ if (avail_planes > 6) avail_planes = 6;
+
/*
* If more layers then planes, save one plane
* for client composited layers
@@ -932,12 +937,14 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
if (client_start < 0)
client_start = l.first;
client_size = (l.first - client_start) + 1;
+ ALOGE("CDBG unsupported layer: client_start: %d, client_size: %d", client_start, client_size);
}
}
int extra_client = (z_map.size() - client_size) - avail_planes;
if (extra_client > 0) {
int start = 0, steps;
+ ALOGE("CDBG extra client: %d", extra_client);
if (client_size != 0) {
int prepend = std::min(client_start, extra_client);
int append = std::min(int(z_map.size() - (client_start + client_size)),
@@ -964,6 +971,7 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
MarkValidated(z_map, client_start, client_size);
if (CreateComposition(true) != HWC2::Error::None) {
+ ALOGE("CDBG CreateComposition(true) failed");
++total_stats_.failed_kms_validate_;
gpu_pixops = total_pixops;
client_size = z_map.size();
diff --git a/platform/platform.cpp b/platform/platform.cpp
index b7a47c7..02e417c 100644
--- a/platform/platform.cpp
+++ b/platform/platform.cpp
@@ -48,7 +48,8 @@ int Planner::PlanStage::ValidatePlane(DrmPlane *plane, DrmHwcLayer *layer) {
if (plane->alpha_property().id() == 0 && layer->alpha != 0xffff) {
ALOGE("Alpha is not supported on plane %d", plane->id());
- return -EINVAL;
+ //return -EINVAL;
+ layer->alpha = 0xffff;
}
if (plane->blend_property().id() == 0) {
--
2.21.0
```https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/32CI checkpatch pipeline failed due to lack of space2020-09-14T08:19:35ZAndrii ChepurnyiCI checkpatch pipeline failed due to lack of spaceSometimes CI checkpatch pipeline failed with error, not related to the code:
W: The repository 'http://archive.ubuntu.com/ubuntu xenial-updates InRelease' is not signed.
W: GPG error: http://archive.ubuntu.com/ubuntu xenial-backports I...Sometimes CI checkpatch pipeline failed with error, not related to the code:
W: The repository 'http://archive.ubuntu.com/ubuntu xenial-updates InRelease' is not signed.
W: GPG error: http://archive.ubuntu.com/ubuntu xenial-backports InRelease: At least one invalid signature was encountered.
W: The repository 'http://archive.ubuntu.com/ubuntu xenial-backports InRelease' is not signed.
$ apt-get --quiet install --yes clang-format-5.0 git >/dev/null
E: You don't have enough free space in /var/cache/apt/archives/.
Uploading artifacts...
WARNING: untracked: no files
ERROR: No files to upload
ERROR: Job failed: exit code 1
and succeed further without code change.
Example: https://gitlab.freedesktop.org/andrii82/drm-hwcomposer/pipelines/132015/buildshttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/31Port useful features from one of the downstreams2021-03-24T16:24:31ZRoman StratiienkoPort useful features from one of the downstreamshttps://github.com/xen-troops/android_external_drm_hwcomposer/commits/android-9.0.0_r3-xt0.2https://github.com/xen-troops/android_external_drm_hwcomposer/commits/android-9.0.0_r3-xt0.2Andrii ChepurnyiAndrii Chepurnyihttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/30Building errors with Android P after commit b3d817812020-09-12T14:53:45ZmaurossiBuilding errors with Android P after commit b3d81781Here are the building errors:
```
external/drm_hwcomposer/drmhwctwo.cpp:1318:36: error: no member named 'GetDisplayIdentificationData' in 'HWC2::FunctionDescriptor'
case HWC2::FunctionDescriptor::GetDisplayIdentificationData:
...Here are the building errors:
```
external/drm_hwcomposer/drmhwctwo.cpp:1318:36: error: no member named 'GetDisplayIdentificationData' in 'HWC2::FunctionDescriptor'
case HWC2::FunctionDescriptor::GetDisplayIdentificationData:
~~~~~~~~~~~~~~~~~~~~~~~~~~^
external/drm_hwcomposer/drmhwctwo.cpp:1319:21: error: use of undeclared identifier 'HWC2_PFN_GET_DISPLAY_IDENTIFICATION_DATA'
return ToHook<HWC2_PFN_GET_DISPLAY_IDENTIFICATION_DATA>(
^
external/drm_hwcomposer/drmhwctwo.cpp:1323:36: error: no member named 'GetDisplayCapabilities' in 'HWC2::FunctionDescriptor'
case HWC2::FunctionDescriptor::GetDisplayCapabilities:
~~~~~~~~~~~~~~~~~~~~~~~~~~^
external/drm_hwcomposer/drmhwctwo.cpp:1324:21: error: unknown type name 'HWC2_PFN_GET_DISPLAY_CAPABILITIES'; did you mean 'HWC2_PFN_GET_HDR_CAPABILITIES'?
return ToHook<HWC2_PFN_GET_DISPLAY_CAPABILITIES>(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HWC2_PFN_GET_HDR_CAPABILITIES
hardware/libhardware/include/hardware/hwcomposer2.h:1428:36: note: 'HWC2_PFN_GET_HDR_CAPABILITIES' declared here
typedef int32_t /*hwc2_error_t*/ (*HWC2_PFN_GET_HDR_CAPABILITIES)(
^
In file included from external/drm_hwcomposer/drmhwctwo.cpp:20:
external/drm_hwcomposer/include/drmhwctwo.h:276:5: error: static_assert failed due to requirement 'std::is_same<int (*)(hwc2_device *, unsigned long, unsigned int *, int *, float *, float *, float *), int (*)(hwc2_device *, unsigned long, unsigned int *, unsigned int *)>::value' "Incompatible fn pointer"
static_assert(std::is_same<PFN, T>::value, "Incompatible fn pointer");
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/drm_hwcomposer/drmhwctwo.cpp:1324:14: note: in instantiation of function template specialization 'android::DrmHwcTwo::ToHook<int (*)(hwc2_device *, unsigned long, unsigned int *, int *, float *, float *, float *), int (*)(hwc2_device *, unsigned long, unsigned int *, unsigned int *)>' requested here
return ToHook<HWC2_PFN_GET_DISPLAY_CAPABILITIES>(
^
5 errors generated.
```https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/29Cannot build drm_hwc due to Android.bp / Android.mk mix between drm_hwc and l...2022-01-13T13:13:19ZMartin FuzzeyCannot build drm_hwc due to Android.bp / Android.mk mix between drm_hwc and libdrmThe latest drm_hwc now uses Android.bp files.
However it has a dependency on libdrm which is still using Android.mk (as of the latest tag libdrm-2.4.100, and indeed git master too).
This causes the build to fail with:
```
FAILED: out/s...The latest drm_hwc now uses Android.bp files.
However it has a dependency on libdrm which is still using Android.mk (as of the latest tag libdrm-2.4.100, and indeed git master too).
This causes the build to fail with:
```
FAILED: out/soong/build.ninja
out/soong/.bootstrap/bin/soong_build -t -b out/soong -d out/soong/build.ninja.d -o out/soong/build.ninja Android.bp
error: external/drm_hwcomposer/Android.bp:102:1: "hwcomposer.drm_minigbm" depends on undefined module "libdrm"
error: external/drm_hwcomposer/Android.bp:67:1: "drm_hwcomposer" depends on undefined module "libdrm"
error: external/drm_hwcomposer/Android.bp:94:1: "hwcomposer.drm" depends on undefined module "libdrm"
```
From what I have read it is not possible for a Android.bp based module to depend on a Android.mk base module (but the reverse is allowed).
How to fix this?
Converting libdrm to Android.bp would be one way but that wants to build on Android > 4.4 and Android 5 doesn't support Android.bphttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/28Detecting whether the screen is updating. If it isn't, delegate composition t...2020-03-20T13:47:27ZRoman StratiienkoDetecting whether the screen is updating. If it isn't, delegate composition to GLES instead of the HWC to save power.Implement an item from https://source.android.com/devices/graphics/implement-hwc , 'Optimize the HWC' section:
- Detecting whether the screen is updating. If it isn't, delegate composition to GLES instead of the HWC to save power. Whe...Implement an item from https://source.android.com/devices/graphics/implement-hwc , 'Optimize the HWC' section:
- Detecting whether the screen is updating. If it isn't, delegate composition to GLES instead of the HWC to save power. When the screen updates again, continue to offload composition to the HWC.
There is already implementation of similar feature added by https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/3 , but unfortunately not all hardware have write-back implemented on the kernel side.
Using the method recommended by Google would cover all the hardware.