This file already exists in android-base, so use this instead of
duplicating the macros in this project.
Since the copy in android-base provides a helper class to assist with
std::unique_lock, use that instead of disabling the warnings.
Change-Id: Ib1724045e3eea29946799fb99b3fbcfcc14a5013
Add a function to approximate when the next vsync after a given
timestamp will be.
This can be used to support expectedPresentTime functionality to
determine if a pending property set should be committed immediately or
for a future vsync.
Change-Id: I6b1f0182d3416b0ffa361f54e6695b2894eb842a
Signed-off-by: Drew Davenport <ddavenport@google.com>
Vsync timestamp was being tracked in two values. One was used for
approximating the next timestamp when waiting for vblank failed, and the
other was used when vsync timestamp tracking was enabled.
Add a new bool to track whether a vsync has been recorded since a caller
enabled vsync timestamp tracking, and return the value of
vsync_timestamp_ if it is fresh.
Change-Id: I0129510d9ce7d72db8f1c64fa2178d2ce7836e81
Signed-off-by: Drew Davenport <ddavenport@google.com>
last_timestamp_ tracks the most recent timestamp from a vblank event. Do
not reset it when toggling vsync tracking on/off. This allows for
GetPhasedVSync to calculate a more precise approximation of the next
vsync relative to the current time, even if a vsync hasn't happened for
a while.
Reset last_timestamp_ when the vsync period changes, since the phased
vsync calculation is based on the current vsync.
Also change last_timestamp_ to std::optional type.
Change-Id: I101b36f87d6ba8197c321c83ac0bc230fba9cf7e
Signed-off-by: Drew Davenport <ddavenport@google.com>
See https://clang.llvm.org/docs/ThreadSafetyAnalysis.html for details.
Define thread annotation macros according to the example provided in the
documentation, and use these to annotate VSyncWorker members that can be
accessed from multiple threads.
Thread safety analysis does not yet work with std::unique_lock, so
disable the warnings when it is used.
Change-Id: I8b3b503fbaf0923588fbe3d0180f6fe6ec228350
Signed-off-by: Drew Davenport <ddavenport@google.com>
With VsyncWorker no longer acquiring the main lock, we can use
std:🧵:join on the main thread to ensure that the vsync thread is
stopped cleanly in the VSyncWorker destructor.
- Don't pass a shared_ptr<> into VSyncWorker::ThreadFn to simplify
lifetime management
- Change to unique_ptr to simplify lifetime management
- Remove the hack to destroy the HwcDisplays in two stages when
destructing ComposerClient
- Add std:🧵:join to VSyncWorker destructor
Change-Id: I25a34fd304c7b2ec48e43d538bf15794bdc9d68e
Signed-off-by: Drew Davenport <ddavenport@google.com>
Rather than explicitly enabling and disabling the VSyncWorker thread
from HwcDisplay, move the logic to enable/disable the thread into
VSyncWorker, and enable it based on whether HwcDisplay has requested
vsync timeline events, or timeline tracking.
This simplifies the public interface for VSyncWorker, and removes the
need for holding the global lock to check whether the thread should be
enabled or not.
Change-Id: Ic1632a19b268ea1d4ed2d8ec8704ef531481211c
Signed-off-by: Drew Davenport <ddavenport@google.com>
Set and clear a vsync callback based on when the client requests vsync
events to be enabled or not. The new vsync callback does not need to
acquire the global resource lock.
The vsync callback uses the vsync period that was set in the VSyncWorker
rather than querying it from the HwcDisplay.
Change-Id: Ic7868af4963ad40aa5a0982a190c67f1642d5b32
Signed-off-by: Drew Davenport <ddavenport@google.com>
Track the timestamp of the last vsync event in VSyncWorker, and provide
an interface for HwcDisplay to enable/disable tracking, and to query the
most recent timestamp.
Moving this into VSyncWorker avoids the need for the VSyncWorker thread
to acquire the global lock.
Change-Id: Ib79d9a6dc5e0f7d6a36ca01dbcda5434a0f582a4
Signed-off-by: Drew Davenport <ddavenport@google.com>
VSyncWorker::SetVsyncPeriod won't be called with a value of 0, so the
only time the internal vsync period will be zero is if SetVsyncPeriod
was not called.
Set the 60Hz vsync period as a default value, and let the synthetic
vsync code expect it to be set to a reasonable value.
Change-Id: Ie1f83b0c11504acf304cc241923bfa60a5ffd647
Signed-off-by: Drew Davenport <ddavenport@google.com>
Make HwcDisplay set the VsyncWorker's vsync_period whenever it changes,
rather than having VsyncWorker query the vsync_period from HwcDisplay.
Doing so prevents the VsyncWorker thread from needing to acquire the
global lock to read HwcDisplay's state.
The original change called GetVsyncPeriod, which checks the vsync period
for the mode that is currently committed to the kernel based on
HwcDisplay::configs_.active_config_id, so call
VsyncWorker::SetVsyncPeriod whenever active_config_id is set.
Change-Id: Ie301c47e2496748117db8cca8a6ee9691e723c74
Signed-off-by: Drew Davenport <ddavenport@google.com>
We use too much dup() system calls for present fence propagating.
Also when propagating acquire fence we use additional logic for
skipping such propagation for the validate/test cycle.
Both issues can be solved by introducing SharedFd, which will track
reference count of fd object.
After that the UniqueFd is used very rarely and can be simplified by
wrapping it into std::unique_ptr without caring too much of adding
an extra malloc/free operation.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
utils/worker just complicates the logic without providing any benefit.
Change-Id: I7b3c91aee9c0507d9ca35792d24ba6c8c3870033
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Some of existing include guards were copy-pasted without modification,
therefore have incorrect name. Switch to 'pragma once' in order to fix
it and avoid such copy-paste issues in the future.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part of frontend isolation activities.
1. Use HWC2 HAL types only inside DrmHwcTwo.{h,cpp}.
2. Use single lock for all callbacks.
3. Communicate with other drm_dwc components using std::function
without any locking.
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.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>
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
