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
Add calls to the new gralloc1 functions: import, validateBufferSize
and getTransportSize. These new gralloc1 functions are used for
security hardening.
Bug: 66876469
Test: Manual
Change-Id: I18e485c48e1a24352208753144d936e1117d4ccb
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)
When calling update-makefiles.sh there are
some unrelated changes that were missed in
previous commits.
Bug: 8675309
Test: compilation
Change-Id: I5bf67fbcc809de36bde1869ada7b835566a5198b
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
This is for reference only. It almost only has stub implementations
for the new 2.1 methods.
Test: boots and VTS
Change-Id: I60499f3094df1975ccbbcda7b5c03d4a0dc57c39
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
