surfaceflinger: flush HWC commands when present is skipped
This is how SF talks to HWC in each frame
1) queue state changes for display
2) queue validate display
3) flush
4) queue more state changes for display
5) queue present display
6) another flush
When validate implies present, we skip all steps after 3). This can
be less desirable because, when SF (incorrectly) queues more state
changes in 4), we still want to flush them to HWC such that SF
states and HWC states are consistent. The only step we want to skip
is 5) in that case. Note that we still skip 6) when 4) and 5) do
not queue anything.
The problem is much more worse in a multiple display setup
1) queue state changes for display 1
2) queue validate display 1
3) flush
4) queue state changes for display 2
5) queue validate display 2
6) flush
7) queue more state changes for display 1
8) queue more state changes for display 2
9) queue present display 1
a) flush
b) queue present display 2
c) flush
When validate implies present for display 1, but not for display 2,
we skip steps 7) to a), including the valid state changes for
display 2 in 8)! The only step we want to skip should be 9). Maybe
a) as well, but that is an optimization.
In both cases, what we really want is to skip the unnecessary
present and nothing else.
Bug: 67512553
Test: manual
Change-Id: I32d6218cda5c953e0359fecda94d2bb5482e061e
diff --git a/services/surfaceflinger/DisplayHardware/ComposerHal.h b/services/surfaceflinger/DisplayHardware/ComposerHal.h
index 31a3c1d..104ca60 100644
--- a/services/surfaceflinger/DisplayHardware/ComposerHal.h
+++ b/services/surfaceflinger/DisplayHardware/ComposerHal.h
@@ -152,6 +152,9 @@
// skip a frame but have already queued some commands.
void resetCommands();
+ // Explicitly flush all pending commands in the command buffer.
+ Error executeCommands();
+
uint32_t getMaxVirtualDisplayCount();
bool isUsingVrComposer() const { return mIsUsingVrComposer; }
Error createVirtualDisplay(uint32_t width, uint32_t height,