Earlier only the physical connectors were added on init
to the connectors_ vector and then hotplug handler
only operated on these cached connectors. But in case of MST
when new sinks are hotplugged to the downstream ports, new
dynamic connectors get added. So refresh the list of connectors
to remove the stale connectors and add new connectors
on every uevent.
This enables MST connectors hotplugged after boot.
Change-Id: I9163c6a892c3604ad8e49be94d32b30af7a6dc88
Signed-off-by: Manasi Navare <navaremanasi@google.com>
Earlier only the physical connectors were added on init
to the connectors_ vector and then hotplug handler
only operated on these cached connectors. But in case of MST
when new sinks are hotplugged to the downstream ports, new
dynamic connectors get added. So refresh the list of connectors
to remove the stale connectors and add new connectors
on every uevent.
This enables MST connectors hotplugged after boot.
Change-Id: I9163c6a892c3604ad8e49be94d32b30af7a6dc88
Signed-off-by: Manasi Navare <navaremanasi@google.com>
We add build property vendor.hwc.drm.internal_display_names to contain
displays we want to make INTERNAL, while check the property in
GetDisplayConnectionType.
If the property is set, we decide INTERNAL/EXTERNAL based on the
included displays.
Currently it's specific for CF/desktop usage.
Change-Id: I3d607b6646ac47497b9770966d4e880f5e5c0ca6
Signed-off-by: Linjiao Zhao <ruki@google.com>
Currently, port IDs are generated by returning a monotonically
increasing value (uint64_t hwc2_display_t). This is problematic for
two reasons:
hwc2_display_t is a 64bit value, and the returned port is 8bit.
clients of drm-hwc cannot rely on port ID consistency between
re-plugs to the same connector.
This patch provides a more stable approach to producing port IDs. We
combine the index of the DRM device in the device list, with the
index of the connector within a DRM device in a 3/5 bit split. This will
allow us to support up to 8 DRM devices, each with 32 independent
connectors (ports). If more support is required in the future, we will
have to extend the API to return uint16_t port values instead.
Signed-off-by: Gil Dekel <gildekel@google.com>
To clean things up and unify the usage of properties.
Change-Id: I0e034ed309f5f8a0d4fc9be7a4a3edcb39050e7f
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
This updates the Uevent handler to handle the hotplug events
sent by the kernel for link training failure.
Adds support in hotplug handler in resourcemanager to read connector
properties and read the value of link-status property.
If this is set to DRM_MODE_LINK_STATUS_BAD, then invoke
the OnHotplugEvent() composer callback with the BAD CABLE
DisplayHotplugEvent to notify the Surfaceflinger about link training
failure.
Currently this uses the ERROR_INCOMPATIBLE_CABLE field of the
DisplayHotplugEvent callback. The longer term would be to define
a new field in this enum to indicate MODESET_RETRY and use this
INCOMPATIBLE_CABLE for the terminal link train failure state.
Change-Id: I823d7570dd08e476d0c887e350bce3f8f0069afb
Signed-off-by: Manasi Navare <navaremanasi@chromium.org>
When the ResourceManager is destructed, the UEvent thread continues to
run in the background.
Change the blocking read call to poll, and create an eventfd on which to
poll as well. When ResourceManager is destructed, write to the eventfd
to wake the UEvent thread, which can then exit cleanly.
Reported-by: Normunds Rieksts <normunds.rieksts@arm.com>
Change-Id: I18d92173165f31fcd01570e65a6ffd840c8cd138
Signed-off-by: Drew Davenport <ddavenport@google.com>
It's a pain to use logcat filters for drm_hwcomposer since each file has a different tag necessitating one to specify each tag for the logcat filter or use a regex.
Use one tag for all of drm_hwcomposer to simplify this.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Some platforms like RaspberryPI-4 can benefit from Display Blender IP Core's
ability to write back the composition into RAM, offloading the GPU in cases
where the display content needs to be used (screen record, remote display,
etc.).
To enable this feature the following system property must be enabled:
PRODUCT_VENDOR_PROPERTIES += debug.sf.enable_hwc_vds=1
The feature was requested by the Tesla Android project to improve UI
performance.
Closes: https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/4
Change-Id: I643f94551408bf218a0b889f1a031598646242f1
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
1. Add and wire-up CRTC CTM property support.
2. Add custom Android property to select behavior for cases
where DRM can't handle color transform matrix.
The "vendor.hwc.drm.ctm" property can be set to:
- DRM_OR_GPU (default) - Use GPU if CTM is not supported by DRM.
- DRM_OR_IGNORE - Ignore CTM if DRM doesn't support it.
The last option is useful for Android 13 and later where default
color transformation matrix is not an identity matrix.
At the moment I do not have any devices with CTM support, therefore
I can test only DRM_OR_IGNORE option.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
It allows to remove redundant unlock/lock pair from the code,
and should make it a little bit more race-proof.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
utils/worker just complicates the logic without providing any benefit.
Change-Id: I0e6427492b8298c6c327c1edb660c8a9789f706f
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Address new clang-tidy findings, in most cases 'misc-const-correctness'
check was addressed by adding 'const' modifier, or in some cases changed
to 'auto' (where it's better for formatting).
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
GetReleaseFences() should return release fence for the prior buffer
(not for the one assigned to layer at the moment of GetReleaseFences call).
Once not provided, old front buffer can be damaged before new buffer
presented. (Such issues start to appear once we started using
non-blocking DRM/KMS commits).
Using present (out) fence is a perfect solution, since it is
signaled once old buffer replaced with the new one.
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
This is useful for accessing the main lock from drm / compositor
related code blocks.
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
Further testing showed that several issues is still present:
1. Boot without display doesn't work.
2. Unplug/plug primary display has some flaws due to incomplete
HwcDisplay disposal.
3. In case creation of the pipeline fails, hwcomposer crashes.
This commit aims to address them.
Fixes: bb594baa1c ("drm_hwcomposer: Rework HwcDisplay disposal to avoid races")
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
Primary responsibilities of this class are:
1. Send composition/mode/active state over DRM atomic commit IOCTL
to the kernel
2. Track commit state and keep planes owned by the Pipeline while they
are either displayed or staged for displaying.
3. Keep framebuffers alive while they are in use or staged.
Not much related to composition itself, therefore rename it to
DrmAtomicStateManager and move it to drm folder.
Bump clang-tidy level of DrmAtomicStateManager.c to normal by fixing
minor clang-tidy findings.
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
The following use scenarios are now possible:
1. When no display connected, primary HwcDisplay is created in headless
mode.
2. When user connects first display, it binds to primary slot, replacing
headless HwcDisplay.
3. When user connects another display it binds to the new HwcDisplay
slot, creating new display for the framework.
4. When user disconnects first (Primary) display, drm_hwc detaches
second display and attaches it to the Primary slot. In this case
framework is notified as Primary display resolution updated
(Plugged->Plugged transition). And second display is disconnected
(Plugged->Unplugged transition).
DrmDisplayPipeline is now created on demand (after hotplug event).
HwcDisplay class is now destructed on connector unplug, which will give
us ability to destroy any resource caches (will be required for FB
caching logic).
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
1. DRM event listener doesn't work in this conditions, uevent blocks
the thread and non-blocking select() doesn't make any sense.
Remove DRM event handling for now.
2. UEvent listeren is common for all DrmDevices, therefore put it into
ResourceManager class.
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
IsKMSDev() is a DRM device helper, therefore DrmDevice class
is better home for it.
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
This should elliminate chance of any leaks in the future.
Fix drmModePropertyBlobPtr leak in DrmHwcTwo.cpp.
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
DRM framebuffer objects must be kept registered in DRM/KMS
while used for scanning-out (After atomic commit applied
for processing by display controller and until next atomic
commit is applied for processing).
Existing logic for tracking current state is overcomplicated and
needs to be redesigned. Also further developing of drm_hwc will
require migration to asynchronous atomic commit, so additional
asynchronous FB cleanup logic must be created.
Buffer caching logic will also benefit from this.
With the RAII all further changes will be less painful and more robust.
By this commit I also renamed DrmGenericImporter to DrmFbImporter:
'Fb' word is present in most of existing composers (android and linux)
so it will be easier to compare different implementations.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Add the following files to the build:
backend/BackendClient.cpp
backend/Backend.cpp
backend/BackendManager.cpp
backend/BackendRCarDu.cpp
bufferinfo/legacy/BufferInfoImagination.cpp
bufferinfo/legacy/BufferInfoLibdrm.cpp
bufferinfo/legacy/BufferInfoMaliHisi.cpp
bufferinfo/legacy/BufferInfoMaliMediatek.cpp
bufferinfo/legacy/BufferInfoMaliMeson.cpp
bufferinfo/legacy/BufferInfoMinigbm.cpp
compositor/DrmDisplayComposition.cpp
compositor/DrmDisplayCompositor.cpp
compositor/Planner.cpp
drm/DrmGenericImporter.cpp
DrmHwcTwo.cpp
drm/ResourceManager.cpp
drm/VSyncWorker.cpp
tests/worker_test.cpp
utils/autolock.cpp
Files 'bufferinfo/BufferInfoMapperMetadata.cpp' and 'utils/hwcutils.cpp' require
a lot of additional headers, therefore move them out of the scope of this commit.
'utils/gralloc.h' isn't planned to use in pure-linux builds, therefore remove
it from 'utils' and put it into '.ci/android_headers/hardware/'
Fix minor tidy fails.
Fix linux build fails (missing includes) due to differences between libc and
bionic.
Comment-out some sections in 'tests/test_include' which aren't used by drm_hwc
but causing build failures for CI due to missing dependencies.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Matvii Zorin <matvii.zorin@globallogic.com>
Drm hwcomposer project has some code-style inconsistencies.
This is the initial step to unify code-style of the code.
Clang-tidy is a great tool which can not only suggest correct styling,
but also allow predicting the errors in the code and suggest correct
coding approaches to avoid potential weaknesses.
CI was tuned to check clang-tidy recommendation for some part of the
code which is ready ATM (can be built outside AOSP tree).
For this part a limited set of clang-tidy checks has applied (coarse check).
Header files aren't checked at all.
Starting from now new code files must be included into the list that is
checked by almost all clang-tidy checks (fine checklist). New header files
should be also included into this list.
See '.gitlab-ci-clang-tidy-fine.sh'.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Build android-agnostic code in linux environment.
Enable static code analysis using clang-tidy.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
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>
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
