Add DisplayRefreshRatesChangedAtomReporter, which reports the changed
refresh rates of all the active displays managed by drm_hwcomposer.
Change-Id: I03a81c667c44160dc319a899a3bd9a8bc527a382
Additionally, move the creation of the Backend into BackendManager so
that it the Backend is created along with the DrmDisplayPipeline
Change-Id: I24dc19cadb324429f229fe7751b60b70ab512265
Make Backend a member of DrmDisplayPipeline and move the creation of the
Backend to where the DrmDisplayPipeline is created.
Change-Id: Ib7b799df5a2ba16015b7072b0e5ce89a174932c3
This change adds a new CompositionAttributes struct which
tracks information about a given composition as it is
validated and subsequently presented.
Previously CompositionStats were tracked as totals for each
display. This change splits the stats according to the
CompositionAttributes for each presented composition.
This change only affects the reporting behavior of
CompositionStatsTracker. The stats logged by DumpState are
totaled so as to not be affected.
Change-Id: I050cce7f63891971cc807b9c5150d9b5d30f1f0b
SurfaceFlinger should now be handling this race condition more robustly
and it is find to return BAD_DISPLAY in this case. Additionally, there
is no other thread which might be holding a resource resulting in a
deadlock or race during teardown.
Change-Id: I45740febccf2efae2fa470fdbdbe050daadb053b
Add DisplayHandle which is a typedef for int64_t. Use this type instead
of the HWC2 hwc2_display_t type.
Additionally, rename variable names to prefer `display_handle` over
`display_id`, since "DisplayId" is overloaded and carries a different
meaning in the Android framework.
Change-Id: I2a8ecce3b2c19fcd5e945d6c645f83d6a7d27a42
Ensure that the display handle to destroy refers to a virtual display
before deleting the display.
Change-Id: I7c284aabdc17cef92051c47d12e4b31ef02ebc9b
Signed-off-by: Drew Davenport <ddavenport@google.com>
Change the Create/Destroy virtual display functions on DrmHwc to remove
HWC2 API stuff. Implement the corresponding functions in the HWC3 and
HWC2 frontends in terms of these functions.
Change-Id: I410da9347ccb2cd008cc94b746c2b5604969b57e
Signed-off-by: Drew Davenport <ddavenport@google.com>
Add a CompositionStatsTracker to DrmHwc which queries the displays'
stats, and keeps track of their deltas.
Extract the output formatting from HwcDisplay into DrmHwc.cpp
Change-Id: Ie3c586b18549564bcc3a05d27b0d1fba0297f0ef
Signed-off-by: Drew Davenport <ddavenport@google.com>
Rewrite DrmHwc::Dump to return a string, rather than directly
implementing the HWC2 interface.
Rewrite the HWC3 frontend Dump implementation to return this string.
Rewrite the HWC2 frontend Dump implementation to cache the string in the
frontend so that the dump string size/contents can be fetched
separately.
Change-Id: I9c286f047bb67a05ced4f0e9778679c32175084c
Signed-off-by: Drew Davenport <ddavenport@google.com>
GetDisplayType is not used for hwc3, so no frontend work is
required to remove it.
A display can be physical or virtual. A physical display can be internal
or external. Create an enum to cover these three cases (virtual,
internal, external), and add a function GetDisplayType.
Implement related functionality in the respective frontends in terms of
this new function.
Change-Id: I72b0b66d22bc91a7e6d0450469f4c140b2cb91c4
Signed-off-by: Drew Davenport <ddavenport@google.com>
To clean things up and unify the usage of properties.
Change-Id: I0e034ed309f5f8a0d4fc9be7a4a3edcb39050e7f
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Commit e11f723f ("drm_hwcomposer: Query property when checking virtual
displays availability") introduced a call to
android::base::GetBoolProperty, which is only available in Android.
This caused the test "hwcomposer.filegroups_build_test" to fail because
the code was no longer compiling for Linux-native targets.
Fix that by replacing "android::base::GetBoolProperty" with a new
function "property_get_bool," and define the function for both Android
and non-Android targets:
For Android, utilize the existing function from <cutils/properties.h>
For other targets, a new implementation is provided in
utils/properties.h.
Fixes: e11f723f ("drm_hwcomposer: Query property when checking virtual
displays availability")
Signed-off-by: Paz Zcharya <pazz@google.com>
The current implementation of "getMaxVirtualDisplayCount" function
relies on the number of writeback connectors, but doesn't consider
the availability of CRTCs. Since CRTCs can only be bound to a single
pipeline, even though there are available writeback connectors, we
might fail to create a virtual pipeline if the CRTCs are being used.
This leads to failures in the "CreateVirtualDisplay" and
"SetOutputBuffer" VTS tests because the tests expect the creation of
a virtual pipeline to work based on the positive value returned by
"getMaxVirtualDisplayCount".
The virtual display feature in drm-hwcomposer is experimental and
currently unused. To address test failures, modify the function
"getMaxVirtualDisplayCount" to return 0 unless the property
"vendor.vendor.hwc.drm.enable_virtual_display" is explicitly set to
true.
Signed-off-by: Paz Zcharya <pazz@google.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>
There is a race between the main thread and vsync thread when tearing
down the HwcDisplay.
In the HwcDisplay destructor, Deinit is called, which will call
StopThread on the vsync worker, and release the VSyncWorker reference.
The main thread is holding the main lock, and the VSyncWorker thread may
be waiting on the main lock in the out_event callback.
After the HwcDisplay destructor is complete, the main thread will
eventually release the main lock. At this point, the vsync thread can
wake and will have a dangling pointer to 'this'.
This can be mitigated by:
- Explicitly set the HwcDisplay pipeline to nullptr, which will stop the
vsync thread.
- Release the main lock after setting the pipeline to nullptr and sleep,
to allow the vsync thread to complete
A more robust solution would be to provide a mechanism to ensure that
the HwcDisplay knows that the vsync thread has completed before the
HwcDisplay has been destructed.
Change-Id: I79626427a94330b15bc138dad3163d0f2d934466
Signed-off-by: Drew Davenport <ddavenport@google.com>
DrmHwc holds implementation details that can be shared between hwc2 and
hwc3. It exposes abstract functions for implementing callbacks to hwc
clients.
Leave the HWC2 specific implementation details in the DrmHwcTwo class, such
as the client callback implementation, and implement the DrmHwc abstract
functions in terms of hwc2.
DrmHwc is based on the DrmHwcInterface extracted in
(drm_hwcomposer: Connect ComposerClient with HwcDisplay) from !238
Co-authored-by: Dennis Tsiang <dennis.tsiang@arm.com>
Co-authored-by: Normunds Rieksts <normunds.rieksts@arm.com>
Signed-off-by: Drew Davenport <ddavenport@chromium.org>
