commit | 76ca20e0224d40c1c0fcfe2c044e184997fac779 | [log] [tgz] |
---|---|---|
author | John Stultz <john.stultz@linaro.org> | Fri Jul 06 10:34:42 2018 -0700 |
committer | John Stultz <john.stultz@linaro.org> | Fri Jul 06 12:22:07 2018 -0700 |
tree | 7dce53f4bb08c91890299ca5e3dcf8bd2ccfbe38 | |
parent | 78c9f6c26210423926ea027edfab0b9504c2d7ff [diff] |
drm_hwcomposer: Really fail on CreateComposition failures The current logic in Validate assumes that if CreateComposition() fails, it was due to overlay planes as sets the avail_planes to 1. With most multi-plane compositions, this will then cause the avil_planes to be later decremented to zero (to reserve the client composited plane), resulting in all the layers to be set as client composited. However, in the case where there is only one layer, such as with the Android BootAnimation, if CreateComposition fails, we set avail_planes to one, and since there is only one layer, we don't decrement it further, resulting in the layer to be validated as a Device rendered layer, as if CreateComposition succeeded. This adds an extra flag we don't mix up a single layer failure as a success. On HiKey/HiKey960, this patch fixes the issue where the BootAnimation wouldn't display. Change-Id: I58bf5f332667a46e8e997d1743b73dd4a768657f Signed-off-by: John Stultz <john.stultz@linaro.org>
Patches to drm_hwcomposer are very much welcome, we really want this to be the universal HW composer implementation for Android and similar platforms So please bring on porting patches, bugfixes, improvements for documentation and new features.
A short list of contribution guidelines:
Submit changes via gitlab merge requests on gitlab.freedesktop.org
drm_hwcomposer is Apache 2.0 Licensed and we require contributions to follow the developer's certificate of origin: http://developercertificate.org/
When submitting new code please follow the naming conventions documented in the generated documentation. Also please make full use of all the helpers and convenience macros provided by drm_hwcomposer. The below command can help you with formatting of your patches:
`git diff | clang-format-diff-3.5 -p 1 -style=file`
Hardware specific changes should be tested on relevant platforms before committing.
If you need inspiration, please checkout our TODO issues
Happy hacking!