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
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>
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>
