Fixes a couple of problems with the return codes in the readback
documentation and adds a paragraph of clarification about when
getReadbackBufferAttributes will be called.
Bug: 67048889
Test: N/A, doc fix only
Change-Id: Ic91b8db207c1b4b1f18777bd316279747506149b
Removes the fence dump from Layer::dump, since:
a) It was leaking (a dup() without a close())
b) It's not that useful anyway since it wasn't displaying the actual
fence fd
Test: Manual
Bug: 73979009
Change-Id: I8f7446a05a1bab8c3ca781610ebeb98d17fa483b
While our intention is to only re-saturate legacy sRGB, the
re-saturation is usually performed globally by the composer. To
avoid GPU fallback when, for example, video plays, allow the
re-saturation to be applied on any legacy dataspace.
This also removes the clamping after applying the re-saturation
matrix, allowing the output dataspace to be scRGB.
Bug: 78303195
Bug: 78025845
Test: manual
Change-Id: Ic221401894789fbaf6bad944b49006163238237c
This CL makes the V2_1::vts::Composer class more reusable, and cleans up
the 2.2 boilerplate.
Bug: 74619554
Test: VtsHalGraphicsComposerV2_2TargetTest
Change-Id: Iff2905d40afe16a0b9ce735f1285d5bdc6b4cec7
Previously we introduced Dataspace V1.1 and PixelFormat V1.1, thus APIs
accepting Dataspace should also be updated to accept V1_1::Dataspace and
V1_1::PixelFormat.
BUG: 77156734
Test: adb shell /data/nativetest/VtsHalGraphicsComposerV2_2TargetTest/VtsHalGraphicsComposerV2_2TargetTest
Change-Id: I00d00749f2895b727a18a28903256128a33e8b97
This adds
ColorMode::BT2020
ColorMode::BT2100_PQ
ColorMode::BT2100_HLG
Dataspace::BT2020_HLG
Dataspace::BT2020_ITU_HLG
RenderIntent::COLORIMETRIC
RenderIntent::ENHANCE
RenderIntent::TONE_MAP_COLORIMETRIC
RenderIntent::TONE_MAP_ENHANCE
and fixes per-frame metadata to be per-layer. It also clarifies how
the composer should treat certain dataspaces and makes the
corresponding composer changes.
Bug: 73824924
Bug: 32148660
Test: manual
Change-Id: I5d12f50190522103c2ac97ee8dc2d5f6a2dabffe
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
Merged-In: I0f2d28fe89fccf997b4bbb9fa6b5c0e6a6e49b93
(cherry picked from commit 2765f9d406)
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
This adds
android.hardware.graphics.composer@2.2-hal
android.hardware.graphics.composer@2.2-passthrough
android.hardware.graphics.composer@2.2-service
The -hal module makes it easier to write composer 2.2 HAL and is
reusable by vendors. The -passthrough module provides a HwcHal
class that implements ComposerHal 2.2 on top of hwcomposer2, and is
also resuable by vendors. Finally, the -service module provides a
(stub) default implementation.
Test: boots and VTS
Change-Id: I4f940a9dea656abc7d9d485bf48d852c13d2ed56
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
Versioned library names, versioned include paths, and others.
Test: make VtsHalGraphicsComposerV2_1TargetTest
Change-Id: Ic266763c9ef25e09bc2c97026f2e1324609f48c6
Move libVtsHalGraphicsComposerTestUtils from vts/functional to
utils/vts.
Test: make VtsHalGraphicsComposerV2_1TargetTest
Change-Id: Ic3042aa7f2578d099fbe79039b60892bd0e87f25
Better include path (#include <mapper-vts/2.0/MapperVts.h>), better
library naming, and move GraphicsMapperHidlEnvironment to where
tests are defined.
Test: VTS
Change-Id: I9fbf6515993ac11852b11ca6b8194a58afe5579a
This patch:
1. Adds setLayerFloatColor API into HAL to enable setting more bits of color on
ColorLayer;
2. Adds VTS tests for setLayerFloatColor.
BUG: 69970838
Test: adb shell /data/nativetest/VtsHalGraphicsComposerV2_2TargetTest/VtsHalGraphicsComposerV2_2TargetTest
Change-Id: I439e35cb2505ee47b8e9a8dd1c19a3f3f2cf9c2f
Add new methods to support HDR, video readback mechanism and
additional power mode.
Test: adb shell /data/nativetest/VtsHalGraphicsComposerV2_2TargetTest/VtsHalGraphicsComposerV2_2TargetTest
Bug: 71513501
Change-Id: I45596df6c5a2a726e12f524e82681aef4bcbe180
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
