Revert "drm_hwcomposer: Workaround for screen de-activating causing db845c regression"
This workaround actually leaves pipes in an unclean state on external
displays which leads to planes bleeding and incorrect renderings in the
case of overlays being assigned to external displays.
There is also a case to be made to not have board specific hacks in
drm_hwc and we should fine a better solution if this is still a problem.
We could consider only deactivating non-primary display if the new
pipeline is set to null for instance.
This reverts commit 799e8c74c65e5d12d354a0b3f2b541f3d44273a2.
Change-Id: Ia28f9e3b0a9ee81ff934143bd2aba526219b76e4
Signed-off-by: Lucas Berthou <berlu@google.com>
diff --git a/hwc2_device/HwcDisplay.cpp b/hwc2_device/HwcDisplay.cpp
index 6797c56..51694c2 100644
--- a/hwc2_device/HwcDisplay.cpp
+++ b/hwc2_device/HwcDisplay.cpp
@@ -114,22 +114,9 @@
AtomicCommitArgs a_args{};
a_args.composition = std::make_shared<DrmKmsPlan>();
GetPipe().atomic_state_manager->ExecuteAtomicCommit(a_args);
-/*
- * TODO:
- * Unfortunately the following causes regressions on db845c
- * with VtsHalGraphicsComposerV2_3TargetTest due to the display
- * never coming back. Patches to avoiding that issue on the
- * the kernel side unfortunately causes further crashes in
- * drm_hwcomposer, because the client detach takes longer then the
- * 1 second max VTS expects. So for now as a workaround, lets skip
- * deactivating the display on deinit, which matches previous
- * behavior prior to commit d0494d9b8097
- */
-#if 0
a_args.composition = {};
a_args.active = false;
GetPipe().atomic_state_manager->ExecuteAtomicCommit(a_args);
-#endif
current_plan_.reset();
backend_.reset();