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
With olv@ no longer on the graphics team we need to update the
owners file to remove him and add new owners.
For composer the new owners are: lpy@ and vhau@
For allocator/mapper the new owner is: marissaw@
Test: N/A
Change-Id: Ied297e9446d480629155e1d9a96575ee518c2135
This reverts commit 399a5b8d60dd845b86c43cf4de55dda4d47384c6; this
change is no longer needed and is causing instability on some devices.
Bug: 74199279
Change-Id: Ia8ee7ae0958df029beac9eb1d343995c54fa8798
Currently display stays on when SurfaceFlinger is stopped, since HWC
runs as a separate service. There's no reason for display to remain on
in this state, and can be confusing to developers.
Restarting HWC when SurfaceFlinger stops causes display to turn off,
matching expected behavior. HWC is then ready to service SurfaceFlinger
when SurfaceFlinger starts back up.
Bug: 74199279
Change-Id: Ic772c29b362b3e8b2d6bc674a0bd237440880492
Little cores should be fast enough to handle hwcomposer work, so
avoiding using big cores for this is a potential opportunity to save
battery.
Bug: 73543056
Test: Verified using dumpsys gfxinfo that TouchLatency doesn't drop
frames.
Test: Took 10s systraces of TouchLatency and a Youtube VR video and saw
no frames dropped in SurfaceFlinger.
Change-Id: If96e13a2bacc9541f4d69a5736254817f20cacdd
Convert composer default impl to a header-only library,
android.hardware.graphics.composer@2.1-passthrough.
Test: builds and VTS
Change-Id: I9251aadc28816fc4c1d9326e09e297f30e9c25fe
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
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
ComposerClient destroys its internal model of the display while handling
the onHotPlug event from the Hwc. Subsequently SurfaceFlinger destroys
its model of the display, and destroys all Hwc layers associated with
the display.
This fixes the code for destroying layers to not dereference an invalid
iterator if the display does not exist, allowing destruction to
continue.
It also fixes a similar issue which could occur if a HWC layer is being
created for a display at around the same time as the disconnect event.
Test: hotplug disconnect no longer crashes
Bug: 38464421
Change-Id: I0f2d28fe89fccf997b4bbb9fa6b5c0e6a6e49b93
There is no cap defined for PRESENT_OR_VALIDATE_DISPLAY in HIDL so
it must always work. Make sure it does not call HWC2 presentDisplay
when the underlying HWC2 does not support
HWC2_CAPABILITY_SKIP_VALIDATE.
Bug: 70407085
Test: boots
Change-Id: I54a4400e09e669c5064f05739f595ed978dcc713
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
After initialization or onRefresh, we want to make sure
validateDisplay is called before presentDisplay.
Bug: 67505273
Test: manual
Change-Id: Id876d9251586aaaf552ca82c52f8f902af364251
The hardware composer service has a rule that only one client can be
connected at a time. The surface flinger process, when transitioning
composer ownership from surface flinger to vr flinger, will destroy the
current client on one thread and create a new client on another
thread. Although surface flinger ensures that these events happen in the
expected sequence (delete then create), the requests sometimes land in
the hardware composer service in inverted order, causing the creation
request to fail with an error.
Instead of failing with an error, block for a brief period (1 second)
until the existing client is removed, then proceed to initialize the new
client. This gives us enough time to ensure an inverted
creation/destruction order doesn't cause client creation to fail, while
avoiding a deadlock if the existing client is never destroyed.
Bug: 62925812
Test: - Transitioned to/from vr flinger hundreds of times, and confirmed
I no longer see sporadic composer client creation failure due to an
already existing client.
- Ran the vts graphics composer tests and confirmed they all pass.
Change-Id: I40be1fb0cb3d42ddb5a9fc159188886e9f5b6267
After initialization or onRefresh, we want to make sure
validateDisplay is called before presentDisplay.
Bug: 67505273
Test: manual
Change-Id: Id876d9251586aaaf552ca82c52f8f902af364251
To prevent property name collisions between properties of system and
vendor, 'vendor.' prefix must be added to a vendor HAL service name.
You can see the details in http://go/treble-sysprop-compatibility.
Test: succeeded building and tested on a walleye device
Bug: 36796459
Change-Id: I4e8fbee791ec917a8f627a1366f4d44ec7e6febc
Our use of message queues is synchronous. If there are already data
in the queue when writeQueue is called, we know they are stale and
can be discarded.
Bug: 65449888
Test: manual
Change-Id: Ie29b8a7386c9733c183a6c3569e3572efa62cbc2
The hardware composer service has a rule that only one client can be
connected at a time. The surface flinger process, when transitioning
composer ownership from surface flinger to vr flinger, will destroy the
current client on one thread and create a new client on another
thread. Although surface flinger ensures that these events happen in the
expected sequence (delete then create), the requests sometimes land in
the hardware composer service in inverted order, causing the creation
request to fail with an error.
Instead of failing with an error, block for a brief period (1 second)
until the existing client is removed, then proceed to initialize the new
client. This gives us enough time to ensure an inverted
creation/destruction order doesn't cause client creation to fail, while
avoiding a deadlock if the existing client is never destroyed.
Bug: 62925812
Test: - Transitioned to/from vr flinger hundreds of times, and confirmed
I no longer see sporadic composer client creation failure due to an
already existing client.
- Ran the vts graphics composer tests and confirmed they all pass.
Change-Id: I40be1fb0cb3d42ddb5a9fc159188886e9f5b6267
We should call native_handle_clone instead of IMapper::importBuffer
on sideband stream handles.
Bug: 63707399
Test: manual
Change-Id: Ie07e50f6bb771f3c7a69d29e36f60b149dc6af95
There are implmentations that can dead lock when calling certain
functions in certain states. It works fine before HIDL because
SurfaceFlinger calls those functions in another thread. We allow
for 4 hwbinder threads in this commit to simulate how SurfaceFlinger
calls hwcomposer.
Bug: 38183197
Test: camera, videos, multi windows, screencap, screenrecord
Change-Id: Ie05b2ca349b8c1ed9a3ac962981434f2efee92d9
When setLayerBuffer() was called on a layer previously destroyed by
destroyLayer() the code would crash. Instead, return an error.
Bug: 37159844
Test: Ran vr flinger in a way that would trigger the crash, and
confirmed that I now get error logs instead of crashing. Unfortunately
the error code is consumed by the Composer wrapper class and not
propagated back to the caller, but that's a separate issue (b/37901601).
Change-Id: I75a5b954d47a1deac44d03851f60f347085eca89
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
This has been copy pasted and isn't actually required.
Test: all hals manually tested to work on internal marlin (which have them binderized).
Note: tv hals not tested (and they never have been). Filed b/36562029
Note: for thermal hal, could only run VTS/check logs for errors.
Test: lshal outputs proper stuff
Fixes: 31928447
Change-Id: Id1be584dc0fa2d70e9189b922335146bf6d1382d
Remove undeclared dependency of libhwcomposer-client on Hwc.h which
created a circular dependency.
Test: Manual
Change-Id: I74d5c4e2db5d247f8b406d1ea42fece41e76659d
