getClientTargetProperty will give hardware composer the ability to request some
properties of the client target that hardware composer wants. Prior to this
API, the client will does its best to produce the client target of which the
properties are pretty much fixed.
BUG: b/145968912
Test: mmma -j32 hardware/interfaces/graphics/composer/2.4/
Change-Id: I055f46b1eeba1d3e20d6a92a9d50a83e0f1ee694
Command engine always uses V2.1 CommandWriterBase, change the creation of
command writer inside command engine so that we can use the right version of
command writer.
BUG: b/147365206
Test: build and boot.
Change-Id: I61fbbce19a44244725621e9a1cef750bd4c78b4d
For reasons unknown, HWC2_CAPABILITY_SKIP_VALIDATE was never added to
the IComposer hal. However, we would like to tell the client that the
device has this capability when it is returned during a getCapabilities
query. We manually add it to the list of IComposer::Capability
(static_cast should be ok since the IComposer::Capability has a fixed
underlying type of int32_t, and HWC2_CAPABILITY_SKIP_VALIDATE = 4 is in
this range). Checking that device has skip validate functionality in
relevent test as well
Bug: 140813883
Test: build, boot, VtsHalGraphicsComposerV2_1TargetTest
Change-Id: I5f28268c4e6edeb2895502c5f4e009cebb566100
composer@2.x-hal is a header library. Any of the shared
libraries it depends on must also be included by anyone
who includes composer@2.x-hal. This means when we add a new
version of mapper, anyone who uses composer@2.x-hal must
also include the new version of the mapper. Vendors
that depend on composer@2.x-hal are broken every time we
add a new mapper.
This patch refactors ComposerResources into a seperate
shared library. ComposerResources contains all of the
mapper code. composer@2.x-hal will depend on the new
composer@2.x-resource hal. Everyone downstream must
also add the composer@2.x-resource file now. However,
they will not be broken again when we add a new mapper
version.
Bug: 136016160
Test: Compiles and boots
Change-Id: I208a954a941ed65938074cd3efb8a6893a2bc1eb
Possible race condition where EventCallbacks are registered before
old implementation deregisters on destruction. Stems from fact that
strong pointer destruction does not mean the object has completely run
its destructor method
Bug: 135210708
Test: build, boot, VtsHalGraphicsComposerV2_1TargetTest
Change-Id: I0851f1197d8341854f5bdac5fbb08553fc32b710
Change the error message that prints when IMapper 3.0 isn't present.
The old warning was causing unnecessary concerns.
Bug: 128013727
Test: compile
Change-Id: I197cd953d08a8e9f3bdee92cede973bf1b97dfe2
(cherry picked from commit ccbd24f633)
Change the error message that prints when IMapper 3.0 isn't present.
The old warning was causing unnecessary concerns.
Bug: 128013727
Test: compile
Change-Id: I197cd953d08a8e9f3bdee92cede973bf1b97dfe2
Change composer 2.1's ComposerResources to support the new major versions
of IAllocator and IMapper.
Bug: 120493579
Test: vts
Change-Id: I888364d302ba8c7f7ad30070dcad3ed738b4c663
ComposerResources allows a derived class to define specializations of
the ComposerDisplayResource and ComposerLayerResource classes, which are
returned by overrides of the createDisplayResources() and
createLayerResources() member functions. The pointers are wrapped using
a std::unique_ptr, which destroys the owned instance via the base class
destructor.
As the destructor was not virtual, this meant that only the base class
destructor functionality would be used. Any additional cleanup done by
the derived class destructor would not be run!
This impacts the composer-hal 2.2 utility code for example, which adds a
readback buffer cache as a display resource. Any readback buffers that
are imported there will not be released, effectively leaking graphic
buffer memory.
It also affected an ARC++ specialization where a similar per-layer buffer
resource cache was added, and where the leak was observable since layers
are created and destroyed much more often than displays.
Bug: 117877825
Test: No leaks for ARC++ devices
Change-Id: I6e604b415d3ed787c2e51729a77278594e41e7a9
Previously we require display to be validated in onRefresh, however, onRefresh
can be called while validateDisplay is executing, results in next
presentDisplay being skipped. This patch makes sure we don't check validation
state when presentDisplay is called.
BUG: 80063800
Test: build, flash, boot and play Youtube videos.
Change-Id: I3d8686db3274436afb6605812641768296f1af0e
Extract IComposer implementation from HwcHal and move it to the HAL
support library. This requires removal of
ComposerHal::removeClient
ComposerHal::enableCallback
and addition of
ComposerHal::dumpDebugInfo
ComposerHal::registerEventCallback
ComposerHal::unregisterEventCallback
since HwcHal does not own a client to send the events to anymore.
Test: boots and VTS
Change-Id: I491e3d2c31d686661d4d3a44842bcac62cc2b2dc
libhwcomposer-client is empty and can be removed. Note that
ComposerClient::initialize is renamed and can fail now.
Test: boots and VTS
Change-Id: Iacd3f995bc094c7dd6b7f91ae64aad0522b3f3d3
Add ComposerCommandEngine to the HAL support library to replace
ComposerClient::CommandReader and ComposerClient::mWriter.
Test: boots and VTS
Change-Id: I2d1281d37180497cbd5c623ef005cee44bce377e
Add ComposerResources to the HAL support library to replace
HandleImporter, DisplayData, and BufferCache in ComposerClient.
ComposerResources tracks the current displays and layers, as well as
managing buffer caches for them.
This is more than refactoring. HandleImporter used to be a static
object, but we want ComposerResources to be self-contained rather
than depending on a static object. This needs to be fixed. It also
becomes obvious that we used to treat sideband streams as buffers in
BufferCacheEntry destructor incorrectly. That needs to be fixed as
well (as a trivial consequence of making HandleImporter non-static).
Test: boots and VTS
Change-Id: I8e3014cb233e2a6d1a71cc244eff80f126c58a94
Create android.hardware.graphics.composer@2.1-hal and add
ComposerHal, which is heavily based on ComposerBase, to it.
There are two bigger TODOs. One is to remove the concept of
"clients" from the class and the other is to remove hwcomposer2.h
dependency.
Test: boots and VTS
Change-Id: I37b4fb3ae2239bf11aa87a56d1e2ebfe0b8c6b54
