Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I075670b64eebbbbd6a6ae0e84ad51bf1c6f5ba36
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
Change composer 2.1's ComposerResources to support the new major versions
of IAllocator and IMapper.
Bug: 120493579
Test: vts
Change-Id: I888364d302ba8c7f7ad30070dcad3ed738b4c663
Convert composer default impl to a header-only library,
android.hardware.graphics.composer@2.1-passthrough.
Test: builds and VTS
Change-Id: I9251aadc28816fc4c1d9326e09e297f30e9c25fe
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
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
In preparation of new hwcomposer interface, updating
existing includes to include specific version.
Note: IComposerCommandBuffer.h was moved, renamed and clang
formated, but otherwise had no code changes.
Bug: 71513561
Test: compile
Change-Id: If34cb6f63012592a245708109590653ace7009f5
FB (framebuffer) HAL has been replaced by HWC HAL for 5+ years, but
we still support the legacy path in SurfaceFlinger. Devices using
the legacy path cannot be Treblized.
This change allows such devices to use HIDL IComposer, by adding
support for FB HAL in the default implementation.
Test: boots hikey960
Change-Id: Ie9050bbcaac0fd5b134786f4f9f0f5075f4ebd0c
We must use the mapper HAL instead of gralloc0/gralloc1 from the
composer.
Bug: 37540361
Test: boots on marlin, angler, and ryu
Change-Id: I5a3ff6a025bf51a3507a4f33fa77e9506a6f1ec9
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 36426473
Bug: 36079834
Test: m -j libhwcomposer-client
Test: attempt to compile with BOARD_VNDK_VERSION := current
Change-Id: I735b861fcc25bc1048ce0ce3ad48432980248b06
We need google shims on the vendor partition because they are providing
an implementation of a vendor defined interface. They were written by
google just as a courtesy/to make the transition easier. They're
basically a set for vendors to assemble their hal implementations
from.
Bug: 34135607
Test: marlin persist.hal.binderization on/off
Change-Id: I2e2af5af39264cf290259755bb9b2eb9827a21f5
It is always on now and all buffers be cloned and registered.
Clients (SF) should make use of the buffer caching mechanism and
pass each unique buffer once, to avoid the overhead.
Test: manual
Change-Id: I74ccbf74e110c8b413a66cfc60044b71ba3f44e3
Decouples the ComposerClient code which deals with parsing the command buffer
messages sent by SurfaceFlinger from the Hwc code that handles the
commands.
Bug: 33297270
Test: Compiled and verified on device that hwcomposer-2-1 service can
start correctly. SurfaceFlinger can connect to the service and the
system boots up. Also verified SurfaceFlinger runs correctly without
hwcomposer-2-1.
Change-Id: I43357306caea57d262735f4756c379ba9d0138cd
Similar to IAllocator, introduce IComposerClient to manage resources.
Rework the interface such that most state changing calls are batched in a
"command buffer" and execute together. The goal is to reduce the number
of IPC calls needed to set up the composer.
Test: builds and boots
Change-Id: I324009243234c4d2482ca0ef2591377b11530fc9
Since HALs might run binder services, we need to start thread pool for
both binder and hwbinder.
Bug: 32021609
Test: builds and boots
Change-Id: I9779e86b1e611a180b1984af36c417dafc3329bc
