Doc comments look like "/** ... */" and they
can only be in certain places.
Bug: 79865343
Test: m
Change-Id: Ic15c08ff7dc6e4f9827c1dbe7f7236c11a572ec1
Merged-In: Ic15c08ff7dc6e4f9827c1dbe7f7236c11a572ec1
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
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)
Move libVtsHalGraphicsMapperTestUtils from 2.0/vts/functional/ to
2.0/utils/vts/. Run clang-format.
Test: VTS
Change-Id: I1e87129cbdc12167160f7e2f1cd76478e88bbf41
Reimplement the default impl as a header-only library,
android.hardware.graphics.mapper@2.0-passthrough, based on the HAL
support library.
Effectively, this renames Gralloc[01]Mapper to Gralloc[01]Hal, and
make adjustments here and there to meet the requirements of the HAL
support library. This also adds GrallocLoader to load either of
Gralloc[01]Hal and create an IMapper instance.
libgrallocmapperincludes is renamed to follow the new naming and
include path conventions.
Test: boots and VTS
Change-Id: I924cadce9a10a6e544f99ceba63aadc38ec431ac
Add a header-only support library
android.hardware.graphics.mapper@2.0-hal that can be used by
implementations. There are two classes in the support library.
MapperHal is an abstract class to be implemented by implementations.
Mapper is an implementation of HIDL IMapper interface on top of
MapperHal.
An implementation can
class VendorHal : public MapperHal { ... };
auto mapper = std::make_unique<Mapper>();
mapper->init(std::make_unique<VendorHal>(...));
Or, if vendor extensions are to be added to the IMapper,
class MapperHalExt : public MapperHal { ... };
class VendorHal : public MapperHalExt { ... };
class MapperExt : public MapperImpl<IMapperExt, MapperHalExt> { ... };
auto mapper = std::make_unique<MapperExt>();
mapper->init(std::make_unique<VendorHal>(...));
Test: builds
Change-Id: Ib23c1f5977744f7e116bb93db53e882e2dad7ce3
android.hardware.graphics.allocator@2.0-passthrough should be a
header-only library to be fully reusable by vendor HALs.
This also allows us to switch from virtual inheritance to templates,
which is more straightforward. This changes nothing to the users
and we still have these relations
- AllocatorHal is an abstract class to be implemented by vendors or
the default implementations
- Gralloc[01]Hal are our default implementations
- Allocator implements HIDL IAllocator interface on top of
AllocatorHal
What we do not like about virtual inheritance is that, given
// abstract class B and D
class B {
virtual void foo() = 0;
virtual void bar() = 0;
};
class D : public virtual B {
// foo is superceded by fooEnhanced in D
void foo() { fooEnhanced(); }
virtual void fooEnhanced() = 0;
};
// an implementation of B
class BImpl : public virtual B {
void foo() {}
void bar() {}
};
// an implementation of D on top of BImpl
class DImpl : public virtual D, public virtual BImpl {
void fooEnhanced() {}
};
we get "no unique final overrider" becase both D and BImpl implement
foo. With non-virtual inheritance, on the other hand, we get "DImpl
is abstract" because foo is still pure virtual implemented in DImpl.
Templates solve the issue by allowing
namespace detail{
template<typename T>
class BImpl : public T { ... };
template<typename T>
class DImpl : public BImpl<T> { ... };
} // namespace detail
using BImpl = detail::BImpl<B>;
using DImpl = detail::DImpl<D>;
Test: boots
Change-Id: Iccb513e4fc751e9a687a1ed2d9fb2192c8324a50
Rename Gralloc0Allocator to Gralloc0Hal and make it inherit from
AllocatorHal. Do the same to Gralloc1Allocator. Add GrallocLoader
to load either of Gralloc[01]Hal and create a IAllocator instance.
Test: boots and VTS
Change-Id: I09ae680c0086ca9e73e412a34d7cd2f3665d3bc2
Convert the default impl into a static library,
android.hardware.graphics.allocator@2.0-passthrough.
Test: boots and VTS
Change-Id: I8ec8b30766462ecb3fb789af7c6dbb3c088ccf57
Add a header-only library
android.hardware.graphics.allocator@2.0-hal that can be used by
implementations. An imlpementation can
class VendorHal : public AllocatorHal { ... };
auto allocator = std::make_unique<Allocator>();
allocator->init(std::make_unique<VendorHal>(...));
Or, if vendor extensions are to be added to the IAllocator,
class AlocatorHalExt : public AllocatorHal { ... };
class VendorHal : public AllocatorHalExt { ... };
class AllocatorExt : public AllocatorImpl<IAllocatorExt, AllocatorHalExt> { ... };
auto allocator = std::make_unique<AllocatorExt>();
allocator->init(std::make_unique<VendorHal>(...));
Test: builds
Change-Id: I7cb7a4888316b871e5c49d96524b1642fc708f2d
Move libgralloc1-adapter from 2.0/default/ to
2.0/utils/gralloc1-adapter/. Fix build issues after the move.
Test: builds
Change-Id: I674fe60c724a4ffc1540c796b92209a1dbf36438
The interface lib has been in VNDK-SP because
android.hardware.graphics.mapper@1.0 was using it. However, since the
dependency has gone [1], there is no need keep it in VNDK-SP. The
VNDK-SP set should be kept as small as possible because libs in VNDK-SP
are subject to double-loading.
Unmark the 'support_system_process' property to exclude the lib from
VNDK-SP.
This commit re-lands I8722c1ac15ddf56a627a12a0c649b4d734e5e5cd because
it was reverted during O-MR1 push to AOSP-master.
Bug: 69480083
Test: walleye boots to the UI
Change-Id: I0af8115dceb9711c6c451ffaeedda6c823ec2905
Merged-In: I8722c1ac15ddf56a627a12a0c649b4d734e5e5cd
(cherry picked from commit ec44d18dbe)
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
Removing whenever I see these in code reviews.
Test: none
Merged-In: I4322f533a837d55618ec2ed2125e8966ace9d61d
Change-Id: I4322f533a837d55618ec2ed2125e8966ace9d61d
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
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
* For registerTestService/getServiceName, no need to pass
any hard coded string of HAL service FQName.
* Affect test: VtsHalCameraProviderV2_4TargetTest,
VtsHalGraphicsComposerV2_1TargetTest,
VtsHalNeuralnetworksV1_0TargetTest
Bug: 62946472
Bug: 64203181
Test: make vts
vts-tradefed run vts -m VtsHalCameraProviderV2_4Target
Merged-In: If365ab2ed9a91eb4013d71769804b9d4bf089d66
Change-Id: Id0bddbc2949337147557f45cc60dbfaa114ce25e
(cherry picked from commit d71b654d6d)
