We used "default" value for the allocator in the test
and this value was used as is for the AIDL allocator.
This caused the test to fail because we were not able to acquire the
appropriate allocator as AIDL allocator instance is not named "default".
Update the test to use the correct instance name for AIDL allocator,
if available.
Test: atest VtsHalGraphicsComposerV2_1TargetTest
atest VtsHalGraphicsComposerV2_2TargetTest
atest VtsHalGraphicsComposerV2_3TargetTest
atest VtsHalGraphicsComposerV2_4TargetTest
atest VtsHalGraphicsComposer3_TargetTest
BUG: 234671596
test results after updates:
VTS 2.1 : http://ab/I84600010058657636
VTS 2.2 : http://ab/I51800010058498973
VTS 2.3 : http://ab/I87700010058914863
VTS 2.4 : http://ab/I88900010058592031
VTS 3.0 : http://ab/I96200010058838905
Change-Id: I04ae1a18d757cfd941d4929ad08f6bb2c8643f76
Some HW may not support crop function for decoration and current API
can't query this capability. Configure decoration layer to full screen
to avoid this limitation.
Bug: 225765061
Test: VtsHalGraphicsComposer3_TargetTest
--gtest_filter=*DisplayDecoration*
Change-Id: If47154adf9d48f9c1b8390b4bee090d8bf40ff3b
When there is no HIDL IAllocator installed on the device, then these
tests must still run.
Bug: 231982605
Test: VtsHalGraphicsMapperV4_0TargetTest
Change-Id: If7503d398c03086df470971cc2c10029270525f9
Before checking the service specific error
we need to check that getExceptionCode returns
EX_SERVICE_SPECIFIC error code. Added a method and
used that to do the two checks together for exceptionCode
and for the service specific error code, so that we don't
repeat two lines in all the tests that need them.
EXPECT_NO_FATAL_FAILURES print the correct line number of the test
or iteration of the test when used with helper functions, and
testing guidelines recommend it too here: go/gunitadvanced#propagating-fatal-failures
Test: atest VtsHalGraphicsComposer3_TargetTest
BUG: 205152739
Change-Id: I1d3c3aa9b34dcefb14be507ff61b73b6f08a5204
Plumbing this enum to RenderEngine requires knowledge of the intended
transfer function to apply the dimming stage in. Because this is
expected to be a contrained use-case and because apis are frozen,
document that RenderEngine is allowed to assume that the resulting
dimming matrix may be gamma corrected using a 2.2 power function.
Bug: 218954037
Test: builds
Change-Id: Ie7d357f8ce79295af017d80c62a2759dbccce5d2
This Capabiliy::BOOT_DISPLAY_CONFIG will make
the display boot display config optional on the HWC3.0
BUG: 216113429
Test: atest VtsHalGraphicsComposer3_TargetTest
Change-Id: I3be3383922fdd91e0bbccebd3c73e458753b749f
If validateDisplay returns an error, changed composition types are not
propagated back to the caller. Remove the expectation that they will be.
Fixes: 221406264
Test: this
Change-Id: I3e07e40b0c12a2cf6eaa685435647aab93172bb0
This change was missed while cherry-picking
I5675c16f0895f9958e3bee3ee4c85df8937ecdb7 due to merge conflicts.
So...actually merge this.
Bug: 218954037
Test: builds
Change-Id: Idb3a518f7dfd4f4fd598672ee709ccd5b1f3f06a
This is the error returned by cuttlefish, not EX_UNSUPPORTED_OPERATION.
This also matches other tests, e.g. SetDisplayBrightness.
Bug: 209458568
Test: this
Change-Id: I885767c4f1c42edfb11359b36852a863cbc8b0ed
* Add a DimmingStage to the client target configuration reported by HWC,
which may be used for some vendor color modes to configure when
dimming should occur during client composition
* Communicate the display brightness in nits, so that HWC
implementations do not need to parse the per-display xml to map from
display brightness to nits. Furthermore, this is more plausible for
extensibility for external displays.
Bug: 220396224
Bug: 218954037
Test: builds
Change-Id: I5675c16f0895f9958e3bee3ee4c85df8937ecdb7
An earlier patch replaced white point nits with a per-layer brightness.
This patch does the same for providing the brightness space of the
client target relative to the display brightness.
Bug: 217961164
Test: builds, boots
Change-Id: I1be65f7c511fefa239305e0735637126a1cd6622
Merged-In: I1be65f7c511fefa239305e0735637126a1cd6622
vts is moved from aidl/android/ to aidl/vts
functional, include & composer-vts directory is removed as well.
BUG: 220171967
Test: atest VtsHalGraphicsComposer3_TargetTest
Change-Id: I6cafbbd99374308a1cc06e27cc590e70618f7075
Allow getDisplayDecorationSupport to return an error, and treat that as
unsupported. This allows Cuttlefish, which, with
I91105fc3345dbd75aeb0b102f3f0138fa33120c0, returns Unsupported, to pass
the test.
Bug: 209458568
Test: this
Change-Id: I8e17d3c0ca0ac4eacb0b5e4c8ae540f271e68a23
aidl already have a dump funciton, so there is no need to
expose a custom dumpDebugInfo from IComposer.
Bug: 220171623
Test: atest VtsHalGraphicsComposer3_TargetTest
Test: adb shell dumpsys SurfaceFlinger
Test: adb shell dumpsys android.hardware.graphics.composer3.IComposer/default
Change-Id: I5036193c06ba9fdd8aa5f79cd756541d9edc146c
* Timed out runs do not show any warning messages.
* These test files cannot finish clang-tidy runs with
the following settings:
TIDY_TIMEOUT=90
WITH_TIDY=1
CLANG_ANALYZER_CHECKS=1
* When TIDY_TIMEOUT is set, in Android continuous builds,
tidy_timeout_srcs files will not be compiled by clang-tidy.
When developers build locally without TIDY_TIMEOUT,
tidy_timeout_srcs files will be compiled.
* Some of these test modules may be split into smaller ones,
or disable some time consuming checks, and then
enable clang-tidy to run within limited time.
Bug: 201099167
Test: make droid tidy-hardware-interfaces_subset
Change-Id: I1de28f1572fff368f67eab512fffec9f2e5c2a9b
Check for support via getDisplayDecorationSupport. If it is supported,
verify that we can allocate a buffer of the correct format and that
Composition.DISPLAY_DECORATION can be used without error. If it's not
supported, expect an error of EX_UNSUPPORTED_OPERATION.
Bug: 209458568
Fixes: 209458568
Test: atest VtsHalGraphicsComposer3_TargetTest (this)
Change-Id: I0a62a0ce3f8fd3a2d6088f94ce1ad0840d9c6faa
When we have a fence created with GraphicBuffer
We don't need to wait on it in VTS tests,
the composer should be able to handle the
fence in this case
BUG: 219589185
Test: atest VtsHalGraphicsComposer3_TargetTest
Change-Id: I688d695bb562dd1fe86cdceb642e746cbafe8b30
For multi-display order of the hotplug matters, and vector
maintains the order that we need for the multi-display.
see: ag/1921760 for partner cl on HIDL.
BUG: 210920960
BUG: 209409863
Test: atest VtsHalGraphicsComposer3_TargetTest
Change-Id: I4f9a86413f20c860fc0bc3850a14335d62de881a
Client composition test was broken because there was a buffer
created at the test creation and this is not how
this test works for client composition trigger.
And for the fence that was used is different from what it
needs previously fence was acquired through gralloc but now
it's internal to the Graphic Buffer and we no longer
have to wait for the fence to signal it's taken care
by the graphicBuffer->unlock call, the unlock call waits
for us.
See for unlock https://source.corp.google.com/android/frameworks/native/libs/ui/GraphicBufferMapper.cpp;rcl=HEAD;l=139
BUG: 216170021
Test: atest VtsHalGraphicsComposer3_TargetTest
Change-Id: I8fa25d8910a4e2b1df2f0e2270445a658e3b1a39
HIDL tests don't have any buffer created when test execution starts and with GraphicBuffer that wasn't the case.
We only initialize the buffer when required the way gralloc implementation did.
BUG: 199413815
Test: atest VtsHalGraphicsComposer3_TargetTest
Change-Id: I3aeec5b00e30e636de2e58cf7e6ced5539ae19b6
There are several reasons for limiting the notion of white point nits in
the composer interface:
1. Some KMS apis exposed by drivers only expose a notion of a per-plane
brightness. While these are non-mobile drivers, e.g., nouveau, this
does indicate that white point is not directly going to be understood
by typical hardware
2. Changing the brightness without requiring a frame update introduces
implicit state in composer. If the brightness and white point nits
for a set of SDR layers are 200 nits, and the brightness changes to
205 nits to respond to ambient conditions, then composer must not dim
the layers, and in fact DisplayManager will tell SurfaceFlinger that
the SDR white point will be 205 nits. But SurfaceFlinger will not
tell composer that the SDR white point changed as that would
otherwise introduce a re-composition cycle, meaning that
HW Composer must track somehow that the layer white point changed
without a corresponding change on the layer data structure, which is
confusing.
3. It's poorly defined what the dimming ratio should be if
SurfaceFlinger provides the following inputs: Layer A has a white
point of 200 nits, Layer B has a white point of 400 nits, and display
brightness is 300 nits. Current implementations may clamp the
brightness of Layer B to be 300 nits and dim layer A by 2/3s, but
there is an equally valid interpretation which is just dim Layer A to
be 50% of Layer B's brightness.
4. The problem indicated by (2) and (3) suggests that layer white point is
really an up-stack concept, that SurfaceFlinger can be aware of for
properly computing the dimming ratios it can send to composer, but
the composer hal shouldn't really be speaking in terms of nits.
Note that this patch does not yet change the interface for
ClientTargetWithNits, which may be done in a follow-up patch.
Bug: 217961164
Test: builds, boots
Change-Id: I4a1b4e8c300d22599a5683bd44b7b8afa9a29425
