drm-hwcomposer issueshttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues2024-03-29T05:06:25Zhttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/82HWComposer: Error in notifyExpectedPresent call Unsupported2024-03-29T05:06:25ZYongqin LiuHWComposer: Error in notifyExpectedPresent call UnsupportedThe following message could be seen in the logcat:
```
03-28 12:56:58.873 433 477 W HWComposer: Ignoring duplicate VSYNC event from HWC for display 0 (t=692786454000)
03-28 12:56:58.876 624 659 D DisplayManagerService: Ignore re...The following message could be seen in the logcat:
```
03-28 12:56:58.873 433 477 W HWComposer: Ignoring duplicate VSYNC event from HWC for display 0 (t=692786454000)
03-28 12:56:58.876 624 659 D DisplayManagerService: Ignore redundant display event 0/2 to 10058/1657
03-28 12:56:58.879 1096 1096 D DisplayRepository: combining enabled=[0], connectedExternalDisplayIds=[], ignored=[]
03-28 12:56:59.246 433 433 E HWComposer: Error in notifyExpectedPresent call Unsupported
03-28 12:56:59.246 433 433 E SurfaceFlinger: notifyExpectedPresentIfRequired failed to notifyExpectedPresentHint for display 0
03-28 12:57:01.315 1301 2292 V StandardNetworkDetailsTracker: Issuing scan request from WifiManager
03-28 12:57:01.316 624 1413 I WifiService: startScan uid=1000
03-28 12:57:04.132 624 1413 I WifiService: startScan uid=10062
03-28 12:57:04.201 433 477 W HWComposer: Ignoring duplicate VSYNC event from HWC for display 0 (t=698117435000)
03-28 12:57:04.212 433 433 E HWComposer: Error in notifyExpectedPresent call Unsupported
03-28 12:57:04.212 433 433 E SurfaceFlinger: notifyExpectedPresentIfRequired failed to notifyExpectedPresentHint for display 0
03-28 12:57:04.247 433 433 E HWComposer: Error in notifyExpectedPresent call Unsupported
03-28 12:57:04.247 433 433 E SurfaceFlinger: notifyExpectedPresentIfRequired failed to notifyExpectedPresentHint for display 0
03-28 12:57:04.266 624 659 I DisplayDeviceRepository: Display device changed: DisplayDeviceInfo{"Built-in Screen": uniqueId="local:0", 1920 x 1080, modeId 1, renderFrameRate 60.000004, defaultModeId 1, userPreferredModeId -1, supportedModes [{id=1, width=1920, height=1080, fps=60.000004, vsync=60.000004, alternativeRefreshRates=[50.0], supportedHdrTypes=[]}, {id=2, width=1920, height=1080, fps=50.0, vsync=50.0, alternativeRefreshRates=[60.000004], supportedHdrTypes=[]}, {id=3, width=1280, height=720, fps=60.000004, vsync=60.000004, alternativeRefreshRates=[50.0], supportedHdrTypes=[]}, {id=4, width=1280, height=720, fps=50.0, vsync=50.0, alternativeRefreshRates=[60.000004], supportedHdrTypes=[]}, {id=5, width=1024, height=768, fps=70.06936, vsync=70.06936, alternativeRefreshRates=[], supportedHdrTypes=[]}, {id=6, width=800, height=600, fps=60.31654, vsync=60.31654, alternativeRefreshRates=[], supportedHdrTypes=[]}], colorMode 0, supportedColorModes [0], hdrCapabilities HdrCapabilities{mSupportedHdrTypes=[], mMaxLuminance=500.0, mMaxAverageLuminance=500.0, mMinLuminance=0.0}, allmSupported false, gameContentTypeSupported false, density 160, 93.784 x 94.593 dpi, appVsyncOff 1000000, presDeadline 16666666, touch INTERNAL, rotation 0, type INTERNAL, address {port=0}, deviceProductInfo null, state ON, committedState ON, frameRateOverride , brightnessMinimum 0.0, brightnessMaximum 1.0, brightnessDefault 0.39763778, hdrSdrRatio NaN, FLAG_ALLOWED_TO_BE_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS, FLAG_TRUSTED, installOrientation 0, displayShape DisplayShape{ spec=729782573 displayWidth=1920 displayHeight=1080 physicalPixelDisplaySizeRatio=1.0 rotation=0 offsetX=0 offsetY=0 scale=1.0}}
```
[hikey960-notifyExpectedPresent.log](/uploads/0d4efeee0196553f193b27f689adf007/hikey960-notifyExpectedPresent.log)
On the hdmi monitor side, it could be seen like the video attached.
![hikey960-notifyExpectedPresent.mp4](/uploads/4ae399e0285c7ecfb3d4f0f956dc32c3/hikey960-notifyExpectedPresent.mp4)https://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/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/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/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/51Project quality assurance2021-11-19T17:51:27ZRoman StratiienkoProject quality assuranceNew development means high risk of regression.
Therefore this project require some formal validation procedure to cover the most important features.
Let's use this issue to accumulate the experience ( scenarios, procedures, scripts....New development means high risk of regression.
Therefore this project require some formal validation procedure to cover the most important features.
Let's use this issue to accumulate the experience ( scenarios, procedures, scripts... )
I hope someday we can make it a part of the CI.
### Test 1. Run UIBench \<Semi-automated> (Prefer using test 2 instead)
#### Preconditions:
- Test tool: https://github.com/joshuous/uibencher
- Use same equipment (Board and Monitor) and same release (for example AOSP-11r27)
#### Procedure:
- Run the test on `drm_hwcomposer/main` and store baseline values
- Run the test with the new changes
- Collect the data. Number of Janks should be equal or less than in the baseline run.
### Test 2. Run UIBench from AOSP tree <Semi-automated>
#### Preconditions:
- Use same equipment (Board and Monitor) and same release (for example AOSP-11r27)
- Disable flattening in drm_hwc to get true results
- Patch AOSP test manifest file to enable all tests instead of 1:
```diff
--- a/platform_testing/tests/microbenchmarks/uibench/AndroidTest.xml
+++ b/platform_testing/tests/microbenchmarks/uibench/AndroidTest.xml
@@ -39,3 +39,2 @@
<option name="package" value="com.android.uibench.microbenchmark" />
- <option name="class" value="com.android.uibench.microbenchmark.UiBenchDialogListFlingMicrobenchmark#testDialogListFling" />
<option name="device-listeners" value="android.device.collectors.PerfettoListener,android.device.collectors.SfStatsListener" />
```
#### Procedure:
- Connect the board
- Execute: `atest UiBenchMicrobenchmark | tee results.txt`
- Filter-out useful data: `cat results.txt | grep -i "MISS\|CLIENT\|PASSED"`
### Test 3. Run Composer HAL VTS tests from AOSP tree
#### Procedure:
- Connect the board
- Execute:
```
atest VtsHalGraphicsComposerV2_1TargetTest VtsHalGraphicsComposerV2_2TargetTest VtsHalGraphicsComposerV2_3TargetTest VtsHalGraphicsComposerV2_4TargetTest
```https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/44Implement back-light control for internal displays.2021-05-28T12:00:49ZRoman StratiienkoImplement back-light control for internal displays.If system has 1 internal display and
`/sys/class/backlight/backlight/brightness`,
`/sys/class/backlight/backlight/max_brightness`
is availabe / accessible, HAL API can be redirected to this sysfs entries.
This could be extended in the ...If system has 1 internal display and
`/sys/class/backlight/backlight/brightness`,
`/sys/class/backlight/backlight/max_brightness`
is availabe / accessible, HAL API can be redirected to this sysfs entries.
This could be extended in the future using external configuration to map display to brightness controller.
weston reference: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/libbacklight.chttps://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/39Supported Android versions2022-03-27T14:58:23ZAleksandr BulyshchenkoSupported Android versionsfbf5c0ca45b3 introduces build-time warning for `GRALLOC_HANDLE_VERSION < 4` (Ref. [platformdrmgeneric.cpp](https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/blob/fbf5c0ca45b3c4dd1d9621eb5198c3d43f1afbf6/platform/platformdrmg...fbf5c0ca45b3 introduces build-time warning for `GRALLOC_HANDLE_VERSION < 4` (Ref. [platformdrmgeneric.cpp](https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/blob/fbf5c0ca45b3c4dd1d9621eb5198c3d43f1afbf6/platform/platformdrmgeneric.cpp#L248)),
but composer is built with `-Werror` (ref. [Android.bp](https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/blob/fbf5c0ca45b3c4dd1d9621eb5198c3d43f1afbf6/Android.bp#L54)).
This brakes compatibility with older Android versions (Android-10 and earlier)
unless `libdrm` will be upgraded to v2.4.97 which might be undesirable for some projects.
If previous Android versions are deprecated at some point, it would be useful to mark the latest composer revision compatible with them (e.g. introduce a tag or a branch).
Also it would be useful if information regarding supported Android versions will be mentioned somewhere (e.g. included in README).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/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.https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/3Add some documentation on usage + android board properties + etc2022-05-20T13:39:32ZSean Paulseanpaul@chromium.orgAdd some documentation on usage + android board properties + etcie: How to use drm_hwcomposer for your boardie: How to use drm_hwcomposer for your board