| Age | Commit message (Collapse) | Author |
|---|
|
Motivation:
Platform term meaning used in drm_hwcomposer does not correspond to the
content of the platform directory. Platform directory consists of:
1. Buffer information getters for different gralloc (currently called platform).
2. Composition planner logic (which has flaws and should be reworked into
layer->plane mapping during validation stage logic).
3. DrmGenericImpoter with reference counting logic.
Android-11 IMapper@4 metadata API offers a generic way to access buffer
information which makes other gralloc buffer information getters obsolete.
Legacy getters should be maintained for some time until all known users
will migrate to Mapper@4 API.
Implementation:
1. Split 'PlatformImporter' logic to 'Importer' only and 'Buffer Getter' logic.
a. Remove buffer_handle_t parameter from ImportBuffer(). Instead user should
get BufferInfo using ConvertBoInfo to struct hwc_drm_bo_t, then use it for
ImportBuffer().
b. Move DrmGenericImporter.{cpp/h} into the drm directory.
2. Isolate planner code in single file and move it to compositor directory as
compositor/Planner.{cpp/h}
3. Rename platform definition
a. Rename platform directory to bufferinfo.
b. Rename/move bufferinfo/platorm*.{cpp,h} getters to
bufferinfo/legacy/BufferInfo*.{cpp,h}. Align class names/includes.
4. Split legacy/metadata getters logic.
a. Apply existing bufferinfogetter base class only for legacy getters.
b. Combine legacy/generic gettera under new base class.
c. Create a placeholder for generic(metadata) getter.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
|
|
Since mediatek-drm has no support for premultiplied alpha buffers, we
can have issues with transparency.
Disable off-loading by adding "mediatek-drm" to the
client-backend list.
Change-Id: I12b034ecd5ae961264d01b6effaa4f4010036ac9
Suggested-by: Roman Stratiienko <r.stratiienko@gmail.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Main goal is to increase readability of file names.
AOSP uses camelcase for files in many projects.
Lets do the same for drm_hwcomposer.
Keep platform/ directory as is, since class names is different from file names.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Change-Id: I7e992357851c2a86711f4da1241c4d507359e56b
|
|
... to improve navigation between source/header file.
Unnecessary dependencies also removed.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Change-Id: I2c3bf993b8c5f356490433fd94e90011487a1276
|
|
ABGR8888 pixel format and layer scaling are unsupported for rcar-du
platform.
Handle and filter out the layers by overriding the IsClientLayer method
for additional checks. That will force layers that require scaling or have
the unsupported pixel format to be merged by GPU, and allow other layers
to be merged by DRM.
Signed-off-by: Matvii Zorin <matvii.zorin@globallogic.com>
|
|
This display backend may be chosen by setting the hwc.backend_override
system property to the "client" value.
Suggested-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
Signed-off-by: Matvii Zorin <matvii.zorin@globallogic.com>
|
|
Different DRM/KMS backends have a variable set of limitations, which is
not always exposed via DRM ioctls.
This implementation of backend-dependent validation provides a register
of platform-specific inherited backend class to the map by BackendManager
class. ValidateDisplay function is moved to generic backend
implementantion and separated into 2 additional methods.
The map key is a string that contains the corresponding DRM driver name.
During DrmHwcTwo class initialization the vendor.hwc.backend_override
system property and driver name will be checked and a backend will be set
for the appropriate display. If the map does not have any backend for the
named driver, the generic backend will be used.
Signed-off-by: Matvii Zorin <matvii.zorin@globallogic.com>
|
