drm-hwcomposer issueshttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues2020-09-14T08:19:35Zhttps://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.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/27Building error in android-x86 due to commit df8829942019-12-03T17:40:04ZmaurossiBuilding error in android-x86 due to commit df882994Here is the build error happening after commit df882994
```
external/drm_hwcomposer/drm/drmconnector.cpp:120:18: error: use of class template 'std::array' requires template arguments
constexpr std::array names = {"None", "VGA", ...Here is the build error happening after commit df882994
```
external/drm_hwcomposer/drm/drmconnector.cpp:120:18: error: use of class template 'std::array' requires template arguments
constexpr std::array names = {"None", "VGA", "DVI-I", "DVI-D",
^
external/libcxx/include/array:124:29: note: template is declared here
struct _LIBCPP_TEMPLATE_VIS array
^
1 error generated.
```https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/26Using xml file for configuration in upstream drm_hwcomposer2019-11-06T09:43:46ZRoman StratiienkoUsing xml file for configuration in upstream drm_hwcomposerI plan to contribute some features to this repository that we need for our project, but first I want to know your opinion regarding implementation:
Features we need:
1. Setting of primary display connector name. (Similar issue #14)
2. ...I plan to contribute some features to this repository that we need for our project, but first I want to know your opinion regarding implementation:
Features we need:
1. Setting of primary display connector name. (Similar issue #14)
2. Setting maximum UI frame size (!62)
3. Overriding display resolution for each connector.
4. This list could be extended while user experience is growing.
Also some of configuration are already defined as system properties, like path to DRM device, enabling overlay planes etc.
My concern is that Android has a lot of ways to set the properties, like multiple init.rc files, system.prop file, PRODUCT_PROPERTY_OVERRIDE definition in makefiles.
This could cause multiple properties related to drm_hwcomposer to be spread across these sources, making debugging process harder.
Inspired from tinyhal that have flexible configuration ability using .xml file: https://github.com/CirrusLogic/tinyhal/blob/master/audio.example.xml, I was wondering if we could make something similar here?
Please provide your feedback to allow me to plan this activity.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/22DRM Interlaced and "similar" modes are merged into single modes, leading to s...2022-01-13T13:03:51ZNeil ArmstrongDRM Interlaced and "similar" modes are merged into single modes, leading to selecting the wrong modeIn the process of bringing up the Amlogic Meson G12A for AOSP and drm-hwcomposer,
I'm having a very suspicious behavior from the Android Graphics stack and the DRM
modes handling.
The initial behavior was:
My 1080p Samsung TV reports t...In the process of bringing up the Amlogic Meson G12A for AOSP and drm-hwcomposer,
I'm having a very suspicious behavior from the Android Graphics stack and the DRM
modes handling.
The initial behavior was:
My 1080p Samsung TV reports the following modes: (using modetest)
```
1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags: phsync, pvsync; type: driver
1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 74250 flags: phsync, pvsync, interlace; type: driver
1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 74176 flags: phsync, pvsync, interlace; type: driver
1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: driver
1920x1080i 50 1920 2448 2492 2640 1080 1084 1094 1125 74250 flags: phsync, pvsync, interlace; type: driver
1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver
1920x1080 25 1920 2448 2492 2640 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver
1600x900 60 1600 1624 1704 1800 900 901 904 1000 108000 flags: phsync, pvsync; type: driver
1280x1024 75 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags: phsync, pvsync; type: driver
1280x1024 60 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync, pvsync; type: driver
1366x768 60 1366 1436 1579 1792 768 771 774 798 85500 flags: phsync, pvsync; type: driver
1152x864 75 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, pvsync; type: driver
1280x720 60 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
1280x720 60 1280 1390 1430 1650 720 725 730 750 74176 flags: phsync, pvsync; type: driver
1280x720 50 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync, pvsync; type: driver
1024x768 70 1024 1048 1184 1328 768 771 777 806 75000 flags: nhsync, nvsync; type: driver
800x600 75 800 816 896 1056 600 601 604 625 49500 flags: phsync, pvsync; type: driver
720x576 50 720 732 796 864 576 581 586 625 27000 flags: nhsync, nvsync; type: driver
720x480 60 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
640x480 75 640 656 720 840 480 481 484 500 31500 flags: nhsync, nvsync; type: driver
640x480 73 640 664 704 832 480 489 492 520 31500 flags: nhsync, nvsync; type: driver
```
Using AOSP master, drm-hwc-two initializes and reports the following modes:
```
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 0 mode.id=1 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 1 mode.id=2 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 2 mode.id=3 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 3 mode.id=7 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 4 mode.id=10 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 5 mode.id=11 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 6 mode.id=12 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 7 mode.id=13 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 8 mode.id=14 => 1920x1080
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 9 mode.id=15 => 1600x900
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 10 mode.id=16 => 1280x1024
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 11 mode.id=17 => 1280x1024
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 12 mode.id=18 => 1366x768
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 13 mode.id=19 => 1152x864
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 14 mode.id=20 => 1280x720
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 15 mode.id=21 => 1280x720
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 16 mode.id=22 => 1280x720
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 17 mode.id=23 => 1280x720
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 18 mode.id=24 => 1280x720
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 19 mode.id=25 => 1024x768
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 20 mode.id=26 => 800x600
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 21 mode.id=27 => 720x576
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 22 mode.id=28 => 720x480
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 23 mode.id=29 => 640x480
01-01 00:00:10.469 2364 2364 E hwc-drm-two: GetDisplayConfigs() 24 mode.id=30 => 640x480
```
The reported configs are:
```
DisplayManagerService: Display device added: DisplayDeviceInfo{"Built-in Screen": uniqueId="local:0", 1920 x 1080, modeId 18, defaultModeId 18, supportedModes [{id=1, width=640, height=480, fps=73.0}, {id=2, width=640, height=480, fps=75.0}, {id=3, width=720, height=480, fps=60.0}, {id=4, width=720, height=576, fps=50.0}, {id=5, width=800, height=600, fps=75.0}, {id=6, width=1024, height=768, fps=70.0}, {id=7, width=1280, height=720, fps=50.0}, {id=8, width=1280, height=720, fps=60.0}, {id=9, width=1152, height=864, fps=75.0}, {id=10, width=1366, height=768, fps=60.0}, {id=11, width=1280, height=1024, fps=60.0}, {id=12, width=1280, height=1024, fps=75.0}, {id=13, width=1600, height=900, fps=60.0}, {id=14, width=1920, height=1080, fps=24.0}, {id=15, width=1920, height=1080, fps=25.0}, {id=16, width=1920, height=1080, fps=30.0}, {id=17, width=1920, height=1080, fps=50.0}, {id=18, width=1920, height=1080, fps=60.0}], colorMode 0, supportedColorModes [0], HdrCapabilities android.view.Display$HdrCapabilities@40f16308, density 102, 101.6 x 101.6 dpi, appVsyncOff 1000000, presDeadline 16666667, touch INTERNAL, rotation 0, type BUILT_IN, state UNKNOWN, FLAG_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS}
```
We can see most of the mode have been "merged", and looking at the following behavior, only the "higher" drm-hwc-two internal ID has been kept.
Then `bootanim` starts and drm-hwcomposer selects the correct EDID preferred mode (1):
```
01-01 00:00:11.787 2378 2378 I SurfaceFlinger: Enter boot animation
01-01 00:00:12.037 2365 2365 E hwc-drm-two: GetActiveConfig() mode.id=1
```
Then `bootanim` stops, and the UI takes over, but strangely, the mode `6` (1920x1080i) is selected:
```
06-04 12:16:02.568 2364 2364 E hwc-drm-two: SetActiveConfig(6)
06-04 12:36:32.450 2377 2377 D SurfaceFlinger: Set active config mode=24, type=0 flinger=0xfc1d07049000
06-04 12:16:02.568 2364 2364 E hwc-drm-display-compositor: Create blob_id 45
06-04 12:16:02.782 2364 2364 E hwc-drm-two: GetActiveConfig() mode.id=6
```
Here 6 is mode.id=12 => 1920x1080, it can be explained because the 6 first modes were "merged" in a single 1920x1080 mode, keeping only the last mode id (6).
My findings are:
* Interlaced modes are not handled *at all*, so dropping them should be the ultimate solution until handled in the uppper layers
* `vrefresh` is used from the integer format reported by the kernel, but in our case, the TV reports some 1000/1001 US modes, and HWC2 and upper does some mode merging and these modes are mixed with the standard modes, but keeping the worst/wrong DRM-HWC mode id
With the following changes, things are better:
```
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -399,17 +399,18 @@ HWC2::Error DrmHwcTwo::HwcDisplay::GetDisplayConfigs(uint32_t *num_configs,
}
}
- auto num_modes = static_cast<uint32_t>(connector_->modes().size());
- if (!configs) {
- *num_configs = num_modes;
- return HWC2::Error::None;
- }
-
uint32_t idx = 0;
for (const DrmMode &mode : connector_->modes()) {
- if (idx >= *num_configs)
+ if (configs && idx >= *num_configs)
break;
- configs[idx++] = mode.id();
+ /* Drop interlaced modes */
+ if (mode.flags() & DRM_MODE_FLAG_INTERLACE)
+ continue;
+ if (configs) {
+ configs[idx++] = mode.id();
+ } else {
+ idx++;
+ }
}
*num_configs = idx;
return HWC2::Error::None;
```
and
```
--- a/drmmode.cpp
+++ b/drmmode.cpp
@@ -122,8 +122,8 @@ uint32_t DrmMode::v_scan() const {
}
float DrmMode::v_refresh() const {
- return v_refresh_ ? v_refresh_ * 1.0f
- : clock_ / (float)(v_total_ * h_total_) * 1000.0f;
+ // Always recalculate refresh to report correct float rate
+ return clock_ / (float)(v_total_ * h_total_) * 1000.0f;
}
uint32_t DrmMode::flags() const {
```
Then we get:
```
DisplayManagerService: Display device added: DisplayDeviceInfo{"Built-in Screen": uniqueId="local:0", 1920 x 1080, modeId 21, defaultModeId 21, supportedModes [{id=1, width=640, height=480, fps=72.8088}, {id=2, width=640, height=480, fps=75.0}, {id=3, width=720, height=480, fps=59.94006}, {id=4, width=720, height=576, fps=50.0}, {id=5, width=1280, height=720, fps=50.0}, {id=6, width=1280, height=720, fps=59.9402}, {id=7, width=1280, height=720, fps=60.0}, {id=8, width=1152, height=864, fps=75.0}, {id=9, width=1366, height=768, fps=59.789543}, {id=10, width=1280, height=1024, fps=60.019737}, {id=11, width=1280, height=1024, fps=75.02467}, {id=12, width=1600, height=900, fps=60.0}, {id=13, width=1920, height=1080, fps=29.9701}, {id=14, width=1920, height=1080, fps=30.0}, {id=15, width=1920, height=1080, fps=23.97608}, {id=16, width=800, height=600, fps=75.0}, {id=17, width=1920, height=1080, fps=59.9402}, {id=18, width=1920, height=1080, fps=50.0}, {id=19, width=1920, height=1080, fps=24.0}, {id=20, width=1024, height=768, fps=70.06936}, {id=21, width=1920, height=1080, fps=60.0}, {id=22, width=1920, height=1080, fps=25.0}], colorMode 0, supportedColorModes [0], HdrCapabilities android.view.Display$HdrCapabilities@40f16308, density 102, 101.6 x 101.6 dpi, appVsyncOff 1000000, presDeadline 16666667, touch INTERNAL, rotation 0, type BUILT_IN, state UNKNOWN, FLAG_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS}
```
Now refresh rates are correctly reported, and modes are less "merged", interlaced modes are no more present.
But still, the preferred mode is still not selected:
```
06-04 12:50:51.551 2373 2373 D SurfaceFlinger: Set active config mode=23, type=0 flinger=0xfb5400e49000
06-04 12:50:51.551 2364 2395 E hwc-drm-two: SetActiveConfig(2)
06-04 12:50:51.551 2364 2395 E hwc-drm-display-compositor: Create blob_id 45
```
since the mode "1" is the HDMI preferred mode, and the mode "2" is the legacy EDID timings, but "1" should be selected.
Using a 4k UHD TV with 4:4:4 modes, these modes are merged with the 4:2:0 modes and the 4:4:4 preferred mode is never used after the bootanim.
Maybe at some point, the uppers layers should keep all the different modes ?https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/21Question about allocate/release virtual memory every vsync?2019-06-07T15:12:58ZJunho ChaQuestion about allocate/release virtual memory every vsync?I'm SW Engineer in SoC Vendor.
I've exchanged e-mail with John, and I think it would be better to pulicize it here.
I am developing HWComposer of Android BSP based on DRM Framework.
During the development of AOSP BSP, I'd like to inform...I'm SW Engineer in SoC Vendor.
I've exchanged e-mail with John, and I think it would be better to pulicize it here.
I am developing HWComposer of Android BSP based on DRM Framework.
During the development of AOSP BSP, I'd like to inform you of the open source part of drm hwcomposer.
Below is a list of things I'm curious about.
1. I saw IOCTL to map/unmap framebuffer in every vsync. Why do you allocate/release virtual memory every moments?
--> I think it will be needed only 1~n(considering multiple buffering) framebuffers in initializing sequence. not every frames. I want to know about purpose.
2. Are you planning to allocate and release framebuffer for every vsync once in the initialization process and patch it to release it later depending on the situation?
3. What are the expected effects of calling drmPrimeFDToHandle and drmModeAddFB2 on two functions in libdrm?
--> Are you expect to have a new buffer with a new frame buffer id and gem on each call?
--> For example, if 60 frames are display on a second, 60 framebuffers should be allocated and released?
I would appreciate it if you read the questions I have given and answer them.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/20hwc-drm errors in logcat2019-06-07T15:12:47ZAmit Pundirhwc-drm errors in logcatMy logcat dump on db820c is filled with following hwc-drm error messages post commit 34b954a8b506 ("drm_hwcomposer: Propagate PlanStage error"), specially if I open and browse thru Settings Application.
```
...
E hwc-drm-display-composi...My logcat dump on db820c is filled with following hwc-drm error messages post commit 34b954a8b506 ("drm_hwcomposer: Propagate PlanStage error"), specially if I open and browse thru Settings Application.
```
...
E hwc-drm-display-composition: Planner failed provisioning planes ret=-22
E hwc-drm-two: Failed to plan the composition ret=-22
E hwc-drm-display-composition: Planner failed provisioning planes ret=-22
E hwc-drm-two: Failed to plan the composition ret=-22
E hwc-drm-display-composition: Planner failed provisioning planes ret=-22
E hwc-drm-two: Failed to plan the composition ret=-22
...
```
The errors seem to be non-fatal and I don't see any obvious graphics related issues either. Is there anything I should be worried about? Something missing from platform (db820c/db410c) implementation point of view? And if these errors are not so critical, then I'm curious if should we silence these messages instead?https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/19Respect advertised zpos range from kernel2019-06-07T14:51:54ZAmit PundirRespect advertised zpos range from kernel**See comment from @alex\_g1 [below](https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/19#note_100578)**
---
Commit ea1c5e5a1bd4 ("drm_hwcomposer: Add z order support") broke hwcomposer on Qcom dragonboards (db410c/db...**See comment from @alex\_g1 [below](https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/19#note_100578)**
---
Commit ea1c5e5a1bd4 ("drm_hwcomposer: Add z order support") broke hwcomposer on Qcom dragonboards (db410c/db820c) running AOSP and display doesn't come up on boot.
In logcat I see:
E hwc-drm-display-compositor: Commit test failed for display 0, FIXME
E hwc-drm-two: Failed to apply the frame composition ret=-22
E HWComposer: presentAndGetReleaseFences: present failed for display 0: BadParameter (4)
Here is the complete logcat dump: https://pastebin.ubuntu.com/p/3ywBFwRfk8/
Reverting this z-oder patch get AOSP boot to UI again.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/18Vulkan Compositor2018-10-24T11:19:22ZZach ReiznerVulkan CompositorI'm making this issue to link in [my WIP](https://chromium-review.googlesource.com/c/chromiumos/drm_hwcomposer/+/361041) from a long time ago in case anybody decided to take up this feature. The diff files are also attached in case that ...I'm making this issue to link in [my WIP](https://chromium-review.googlesource.com/c/chromiumos/drm_hwcomposer/+/361041) from a long time ago in case anybody decided to take up this feature. The diff files are also attached in case that link ever goes dead
* [0001-add-compositor-interface.diff](/uploads/e5c3094de20a5c01a515464992418460/0001-add-compositor-interface.diff)
* [0002-add-VKTracker.diff](/uploads/c204d7c9a0c75d8f28182927b7e8ec13/0002-add-VKTracker.diff)
* [0003-add-VKCompositor.diff](/uploads/f2e99817063a4051db132578546b2e59/0003-add-VKCompositor.diff)https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/16Document Dependencies of drm-hwcomposer2019-06-07T15:25:09ZAntonioDocument Dependencies of drm-hwcomposerHi,
Could you please describe which are the dependencies that need to be fullfiled to port this to other platforms?
So far, I have identified the following:
- Kernel DRM. It seems to require support for drm: add explicit fencing. On wh...Hi,
Could you please describe which are the dependencies that need to be fullfiled to port this to other platforms?
So far, I have identified the following:
- Kernel DRM. It seems to require support for drm: add explicit fencing. On which kernel version this was introduced?, Does It require additional changes to the specific display drm driver?
- Gralloc/ION?
Is there any change needed for GPU drivers?
Are there any other dependencies in Android framework that need to be fullfilled?
Thanks in advance,
Antoniohttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/15DrmGenericImporter::ImportBuffer() regression compared to robherring handle-r...2018-06-26T05:48:48ZmaurossiDrmGenericImporter::ImportBuffer() regression compared to robherring handle-reworkHi,
drm_hwcomposer branch robherring/handle-rework works with new gralloc handle moved to libdrm,
provided that gbm_gralloc is updated accordingly.
freedesktop/master with new libdrm+gbm_gralloc shows a regression in ::ImportBuffe...Hi,
drm_hwcomposer branch robherring/handle-rework works with new gralloc handle moved to libdrm,
provided that gbm_gralloc is updated accordingly.
freedesktop/master with new libdrm+gbm_gralloc shows a regression in ::ImportBuffer() because it is trying to convert 875709016 from hal format to drm format, but 875709016 ('XB24' aka DRM_FORMAT_XBGR8888) is already a drm format.
Please check what is happening with ::ImportBuffer(), applying changes as per robherring's would most probably solve the problem, but in order to do that some change would be required in libdrm/android/gralloc_handle.h like in [1] or the (already drm) format does not need further conversion in ::ImportBuffer()
Here is the error:
06-05 17:37:45.601 2859 2859 E hwc-platform-drm-generic: Cannot convert hal format to drm format 875709016
06-05 17:37:45.601 2859 2859 E hwc-platform-drm-generic: could not create drm fb -22
06-05 17:37:45.601 2859 2859 E hwc-drm-two: Failed to import layer, ret=-22
In the attachment logcat for i965, the exact same problem happens also with amdgpu and nouveau.
Mauro Rossi
[1] https://github.com/maurossi/drm/commit/5bf075932071bba8b915a83a3855b6476d7ae6b2
[logcat_HWCOMP_2_Skylake_T460.zip](/uploads/5cf80b757f1bd38e0363e4f1ce9a7d56/logcat_HWCOMP_2_Skylake_T460.zip)https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/13Don't call CreateDisplayPipe until the display is actually needed2022-02-01T10:17:05ZmaurossiDon't call CreateDisplayPipe until the display is actually needed> [seanpaul]
> Changed title from "DrmResources::CreateDisplayPipe throws meaningless error for DRM_MODE_DISCONNECTED"
Hi,
the issue has been communicated but not tracked in gitlab nor resolved.
Here it is as a kind reminder, because ...> [seanpaul]
> Changed title from "DrmResources::CreateDisplayPipe throws meaningless error for DRM_MODE_DISCONNECTED"
Hi,
the issue has been communicated but not tracked in gitlab nor resolved.
Here it is as a kind reminder, because amdgpu, nouveau and all discrete gpus are affected.
```
... 2245 2245 E hwc-drm-resources: Could not find a suitable encoder/crtc for display 2
... 2245 2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with -19
... 2245 2245 E hwcomposer-drm: Can't initialize Drm object -19
```
Updated proposed commit to solve this problem is [1] as it is assessed that either the drm_hwcomposer code is flawed to return error for DRM_MODE_DISCONNECTED,
or, in any case, it is necessary to identify E2E root cause of the problem.
Mauro Rossi
[1] https://github.com/maurossi/drm_hwcomposer/commit/027a1bf233589349761c49714defea82cd28951dhttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/12Failure pset test and modesetting on amdgpu dc2018-06-12T11:14:24ZmaurossiFailure pset test and modesetting on amdgpu dcBonaire and later GPUs support atomic via AMD DC, available with kernel 4.15 and later.
With mesa 18.1.1 and 18.2.0-devel Android GUI fails to start because of an error due to unsupported AB24 format (RGBA_8888) which is propagated ba...Bonaire and later GPUs support atomic via AMD DC, available with kernel 4.15 and later.
With mesa 18.1.1 and 18.2.0-devel Android GUI fails to start because of an error due to unsupported AB24 format (RGBA_8888) which is propagated back by hwc-drm-display-compositor to hwc-drm-two (but same happened with hwc v1) and this prevents the correct modesetting.
The weird outcome is that bootanimation proceeds and the human user just sees text console.
In the drm_gralloc path there is a necessary workaround to lack of RGBA_8888 based on [1] and [2]
which falls back to selection of EGL config based on a simpler query, which selects BGRA_8888, natively supported.
The purpose of this ticket is to assess if drm_hwcomposer needs changes or surfaceflinger HWcomposer code needs changes and proceed in solving the E2E problem affecting AMD DC.
Mauro Rossi
```
06-02 23:33:17.415 0 0 D : [drm:drm_atomic_check_only [drm]] AB24 little-endian (0x34324241), modifier 0x0
06-02 23:33:17.415 4922 4922 I hwc-drm-display-compositor: Commit test pset failed ret=-22
06-02 23:33:17.415 4922 4922 I hwc-drm-display-compositor: Commit test failed, squashing frame for display 0
06-02 23:33:17.415 4922 4922 E hwc-drm-display-compositor: Composite failed for display 0
06-02 23:33:17.415 4922 4922 E hwc-drm-two: Failed to apply the frame composition ret=-22
06-02 23:33:17.415 4922 4922 E HWComposer: presentAndGetReleaseFences: failed for display 0: BadParameter (4)
```
[1] http://git.osdn.net/view?p=android-x86/frameworks-native.git;a=commit;h=519828c5b649e5e83f18444666f0672ab7852518
[2] http://git.osdn.net/view?p=android-x86/frameworks-native.git;a=commit;h=792c8dc009bd3a0c44eb39e757a95e099c03b54c
[logcat_atomic_debug_HD7790_sample.txt](/uploads/42f1a3d73473299775c45e85b70df0ea/logcat_atomic_debug_HD7790_sample.txt)https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/11Support plane stealing/sharing between crtcs2022-02-04T19:57:20ZSean Paulseanpaul@chromium.orgSupport plane stealing/sharing between crtcsIf the hardware supports it, we should support moving planes between crtcs to maximize hw composition.If the hardware supports it, we should support moving planes between crtcs to maximize hw composition.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/10clang-format pipeline has false positives2018-05-31T12:44:20ZSean Paulseanpaul@chromium.orgclang-format pipeline has false positivesOn merge request !2 we got some false positives on the clang-format change. I assume this is due to the master..HEAD revision range we're giving git.
Something to play around with.On merge request !2 we got some false positives on the clang-format change. I assume this is due to the master..HEAD revision range we're giving git.
Something to play around with.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/9Migrate wiki to gitlab pages2018-05-07T13:37:53ZSean Paulseanpaul@chromium.orgMigrate wiki to gitlab pagesDaniel Stone pointed out that pages would be a better alternative to the wiki. I agree, so let's migrate the wiki contents (currently CONTRIBUTING, but soon to be board integration documentation) to pages.
https://docs.gitlab.com/ee/use...Daniel Stone pointed out that pages would be a better alternative to the wiki. I agree, so let's migrate the wiki contents (currently CONTRIBUTING, but soon to be board integration documentation) to pages.
https://docs.gitlab.com/ee/user/project/pages/Sean Paulseanpaul@chromium.orgSean Paulseanpaul@chromium.orghttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/8Nextgen HWC planning by Sean Paul (2018)2022-01-13T12:57:11ZSean Paulseanpaul@chromium.orgNextgen HWC planning by Sean Paul (2018)https://docs.google.com/document/d/1wtkB2w2GL_oRJn4bHGvtF27wgv-EiYj5kF8KQtaBHI0/edit?usp=sharing
~~We could use something like skia (which is already in Android) to do fallback compositing, which avoids having to deal with platform pecu...https://docs.google.com/document/d/1wtkB2w2GL_oRJn4bHGvtF27wgv-EiYj5kF8KQtaBHI0/edit?usp=sharing
~~We could use something like skia (which is already in Android) to do fallback compositing, which avoids having to deal with platform peculiarities.~~
~~This is a bit of a stretch TODO~~
Added by Roman Stratiienko:
Some of my recent patches were inspired by this doc. But not all of them.
As for original issue (Add platform-independent fallback compositing),
SF has opengl fallback instead.