In HWC3 Color is represented as a float [0.0 - 1.0] to be consistent
across the stack. SF passes the color as float and it gets translated
back to uint8_t for HWC2.

Bug: 207139550
Test: atest SurfaceFlinger_test
Change-Id: I83867eed70bd3baa3292c9cc099d891ba9cc6183

The first time this topic landed, it resulted in b/212402133. We avoid
running into this bug with Ib11d46439db57b90486bad07dd90f2cf0822182a.

Original commit message:

After some discussion, we've decided to always set the ScreenDecorations
to DISPLAY_DECORATION. HWC can decide, based on the format, whether to
truly treat it as DISPLAY_DECORATION, or to change to DEVICE
composition.

Previously we were concerned that SurfaceFlinger couldn't use this
information (if we provided it). Looking to the future, it's possible SF
may use this information to help make a better plan for the next frame.

Bug: 193170859
Test: manual

Change-Id: Ib67f55b11a8c5de8f5763394b00fffee43557ed8

Revert submission 16511727-wm_DISPLAY_DECORATION

Reason for revert: b/211835607
Reverted Changes:
I1da3199ba:Allow changing composition from DISPLAY_DECORATION...
I1fae74b36:Update documentation for DISPLAY_DECORATION
I1da03a88f:Add eLayerIsDisplayDecoration flag
I7f22dfd03:Add/plumb SurfaceControl.DISPLAY_DECORATION

Change-Id: Ifa4d06453b5707626c614aad203c727681e23fed

After some discussion, we've decided to always set the ScreenDecorations
to DISPLAY_DECORATION. HWC can decide, based on the format, whether to
truly treat it as DISPLAY_DECORATION, or to change to DEVICE
composition.

Previously we were concerned that SurfaceFlinger couldn't use this
information (if we provided it). Looking to the future, it's possible SF
may use this information to help make a better plan for the next frame.

Bug: 193170859
Test: manual
Change-Id: I1da3199bacf5877e88876249c60c0a33fcd44c1e

I90543850d57323be485a0fa8562f4e965aed28ab in hardware/interfaces
introduces the new Composition type, DISPLAY_DECORATION. Handle this
case when looking at Composition.

Bug: 193170859
Test: TODO
Change-Id: Ic5d5881dbbbaa348bf5ba39c5f8a4fca7b7170b4

In preparation for adding a new Composition type which is only in AIDL.
This change is almost completely mechanical, and should have no impact
on behavior.

Bug: 193170859
Test: existing tests

Change-Id: I1f923fcc8d8e6dff388493a76e31d435638b5255

Model here is:
* HDR luminance is set to the current display brightness
* SDR luminance is set to the current SDR white point reported by
DisplayManager

Ideally we use scene-referred white points instead, so:
* PQ is always 10k nits
* HLG is always 1k nits
* Everything else is 150-200 nits

So relative dimming thresholds are fixed. But right now this is visually
less jarring (otherwise youtube UI will suddenly dim when autoplaying
HDR video).

Bug: 200310158
Test: Verified that plumbing sdr white point is sent to renderengine
Test: librenderengine_test
Test: libcompositionengine_test
Test: DataspaceUtils_test

Change-Id: I5bcea7941935c43e57cd5434e1ec69b41d31f2b4

This reverts commit d486bdf9.

Reason for revert: Crash should be resolved with Ia896419eb699903453f6f69e4b6c3527e62ec270

Change-Id: I0e36dc8093e8e4dcc45ca2ff0f3623114d541bf9

This reverts commit 028676ae.

Reason for revert: Droidfood blocking bug: 209930535

Change-Id: I9e8b4d3c4f61a080d85401aa4a503a7436930a3b

This is for letterboxed holepunch: a typical layer stack would be:
1. A solid color letterbox in back
2. A solid color layer for SurfaceView's background protection
3. A game's SurfaceView which has rounded corners

One of the constraints for creating a CachedSet is that it cannot begin
with a solid color layer, under the assumption that if there is an idle
layer on top of a solid color layer, then those two layers should not be
merged into a cached set since displaying the color layer separately is
already cheap. But, for the example layer stack above, this means that
there cannot be a candidate cached set behind the game's SurfaceView,
meaning that there is no hole punch generated, so the game is always in
client composition.

So, let's remove the constraint that a CachedSet cannot start with a solid
color layer for hole punches, which resolves the issue.

Bug: 208780233
Test: Hill Climb Racing with letterboxed rounded corners
Test: libcompositionengine_test
Change-Id: Ia5bcdec363f4401b9b9738c5f6ce335497d6362b

Shrinks the area of the overridebuffer sampled by the dpu to the
boundaries of the layer(s) flattened in that buffer.

Bug: b/192058025

Test: composition unit tests, confirm dpu bandwidth is reduced,
confirm secondary displays are still working.

Change-Id: I46d0401d3a08a9c9019f4e1fef1b301e91e6d241

Bug:186475872
Test: atest ProjectionSpaceTest

Change-Id: Ib633044f637d491a7aca3fdf5f780cbde0ead5b4

Bug: 185799825
Test: manual
Test: libcompositionengine_test

Some HWCs crop to the displayFrame. A shadow layer uses its
geometry.boundaries (possibly cropped by geometry.cropRect) as the
size of the object casting a shadow, so the shadow may not be contained
by the displayFrame. For a shadow, expand the displayFrame out by the
shadowRadius to prevent cropping of the shadow.

Change-Id: I8b6c7953d05718a89bdbc59d57775e52195a8131

Consider a set of five cached layers. Because ComposerResources' caches
are scoped per-layer and does not globally track buffers, the override
buffer for each layer needs to be re-imported, and a previous override
buffer needs to be freed, if the new override buffer changed between
frames. This causes a lot of churn in validate(), up to double CPU time
in the hot path.

Instead, we shouldn't override the buffer if a layer would be skipped.
In the aforementioned example, this would cause 1 buffers-worth of chrun
when importing, rather than 5.

Bug: 190654391
Test: Perfetto trace
Change-Id: I907b0c4c340fd99a0023429a8ad740ecc9208815

Inconsistencies in composer state was arising from a layer exiting layer
caching. Resolve this by:

* If a layer previously had an override buffer, but now does not for the
current frame, set the surface damage region to be the entire buffer.
* If a layer is currently being skipped, then don't update the
composition type, since the validated composition type is no longer
accurate for representing the current composition type of the device.
* If a layer was previously skipped, then update in HWC the new
composition type every time.

The inconsistencies have arised from the layer caching feature
because composer implementations cache the most recent requested
composition type for each layer, but SurfaceFlinger caches the most
recent {requested, validated} type for each layer, whichever
SurfaceFlinger sees last. So if we forced client composition, then
untoggled client composition, and if hwc was device compositing the
layer during validate instead of client compositing because hwc ignored
the layer, then SF caches DEVICE composition, but hwc caches CLIENT
composition internally. SF then doesn't update the layer's composition
type because it cached DEVICE composition, but hwc never displays the
layer because hwc cached CLIENT composition, and typical hwc
implementations never attempt to read from client composited layers.

Bug: 187193705
Test: libcompositionengine_test
Test: enable layer caching and repeatedly enable and disable client
composition when pip is playing

Change-Id: I9b6890bcf3f0612e8f99f5f1642015e53d59f862

By using a special caching slot, this avoids import/freeBuffer churn in
the composer process which can occur when a layer is no longer using an
override buffer. Previously the layer's buffer would have been cached by
a previous setBuffer call, but since the override buffer was clobbering
a caching slot, replacing the override buffer requires re-importing the
buffer.

To resolve this, increase the size of the hwc buffer cache so it's ever
so slightly less tied to buffer queue sizes, which allows for room for
the override buffer which improves caching hit rate. On devices that
don't have layer caching turned on, this is a functional no-op because
those devices will never use the additional caching slot.

Bug: 185570241
Test: libcompositionengine_test
Test: Perfetto trace of opening and closing calculator app shows fewer
import/free buffers in the composer process

Change-Id: I219b1a1f6a31c5405736cb06d4921f300fe4a3ee

Source crop needs to match the buffer dimensions, rather than the
display frame dimensions. Otherwise this causes an error in HWC.

Bug: 185398025
Test: wallpaper picker no longer flickers

Change-Id: Iedf04ed7432b34b1dad9358fd32f293cbe8fe522

Bug: 184729207
Bug: 163076219
Test: TODO

In Id721cd451209ab50e5cd8badf5f3e0917506e728, we started updating
geometry if we had an override buffer, or if the last frame did. Also do
so for a peekThroughLayer, since its blend mode changes. In addition,
the z has changed for layers starting with the peekThroughLayer, so
update geometry for those, too.

Move isPeekingThrough to a local variable and parameter. It does not
need the lifetime of overrideInfo. Add it and zIsOverridden to
writeStateToHWC to ensure we restore the order in HWC when the
peekThroughLayer is no longer needed.

Change-Id: I4b2dda504dc52ec06795a2d2b6236b0472702880

Bug: 163076219
Test: manual
Test: I53fc851eca876d44ba7cb9347f1c62d659c38932

In Layer::preparePerFrameCompositionState, no longer set
forceClientComposition to true based on the presence of rounded corners.
This will be determined later, based on whether the Layer will peek
through a Layer with a hole-punch.

In CachedSet::requiresHolePunch, return false if the layer must be
client composited for reasons other than rounded corners (which no
longer force client composition). While we could still use a hole punch,
it would not provide the desired effect (preventing waking up the GPU).

Add an extra field to overrideInfo, denoting whether this layer will
peek through another layer. Set it on a peekThroughLayer before sending
it to the HWC. If it's not set, and the layer has rounded corners, the
layer must be client composited, as before.

Change-Id: I3b4341d049c0fa5020dfd89ca9e765588a457eb1

Bug: 163076219
Test: manual
Test: I53fc851eca876d44ba7cb9347f1c62d659c38932

Remove OutputLayerCompositionState.z, LayerStateField::ZOrder, and
LayerState::mZOrder. Note that the layers are already stored in the
proper z-order (back to front). When sending them to HWC, specify order
with a local variable. The LayerState and -Field ZOrders were used to
treat layers with different z's as a differing field for comparison. But
in practice, a change in z order will change the geometry, resulting in
recreating all CachedSets. (Add a test to verify this changes the
NonBufferHash.)

Add peekThroughLayer to overrideInfo, which is used by Output to
reorder the layers and to change the blendMode so the peekThroughLayer
can be seen through it.

In Flattener::mergeWithCachedSets, update overrideInfo to include
peekThroughLayer, using a new accessor on CachedSet.

Add more info to CachedSet::dump().

Test updates:
- Remove tests that verify the state of OutputLayerCompositionState.z
and ZOrder.
- In LayerStackTest#getApproximateMatch_doesNotMatchManyDifferences, we
were setting kMaxDifferingFields + 1 fields to be different. Removing z
made these two stacks match, so replace with another (arbitrary) field.
- Fix OutputLayer tests to expect calling the new method
LayerFE::hasRoundedCorners

Latest patch set fixes a rebase error in includesOverrideInfoIfPresent.

Change-Id: I845a0f7016c57652045f6f5a082175304272347f

Revert submission 14199598-revert-14086921-renderengine-external-tex-QJNBWQMQEU

Reason for revert: Prepare for relanding
Reverted Changes:
I01e65a7f4:Revert "Update WaylandRenderSurface to accomodate ...
I7d58118c1:Revert "Update Readback VTS to align with RenderEn...
I1501890f4:Revert "Add ExternalTexture class into RenderEngin...

Added the following fixes:
1. CachedSet renders to intermediate texture variable rather than
mTexture directly, since mTexture is not guaranteed to be nonnull.
2. Add null check when setting new buffer in BLAST.

Bug: 185524947
Bug: 180767535
Test: builds, boots
Test: librenderengine_test
Change-Id: I52ea82e24336b496d996bbe3e445db0affe1abb8

Revert submission 14086921-renderengine-external-tex

Reason for revert: Potential culprit for b/185361988
Reverted Changes:
I7796764e2:Update WaylandRenderSurface to accomodate interfac...
I13904eec4:Update Readback VTS to align with RenderEngine int...
I222c71e6e:Add ExternalTexture class into RenderEngine interf...

Change-Id: I1501890f4861a3df7ce273f1fe2ccdb275e2632c

ExternalTexture is an RAII structure that wraps raw GraphicBuffers that
are passed into RenderEngine. ExternalTexture's role is to help with
managing GPU resources of GraphicBuffers by mapping buffers into
textures, EGLImages, or AutoBackendTextures depending on the
RenderEngine backend. Under the hood, mapExternalTextureBuffer and
unmapExternalTextureBuffer (renamed from cacheExternalTextureBuffer and
unbindExternalTextureBuffer respectively) are used to help tie
resource management to the ExternalTexture lifetime.

The main motivation for this is that currently managing buffer
lifecycle has historically been errorprone and caused memory leaks, so
this improves code health.

As part of this:
* mapExternalTextureBuffer and unmapExternalTextureBuffer
are now protected methods, and are never called outside of RenderEngine
with the exception of creating and destroying ExternalTextures.
* Because GLESRenderEngine's output buffers are cached differently from
Skia RenderEngine, if there are output-only buffers then disable the
mapExternalTextureBuffer calls whenever GLESRenderEngine is used.
* Custom RAII classes in the Planner and in BufferLayerConsumer are now
removed since they're subsumed by ExternalTexture
* RenderSurface now controls its own management of ExternalTextures in a
small queue
* cleanFramebufferCache is now unimplemented for Skia, because
ExternalTextures are now deleted whenever a RenderSurface is deleted.

Bug: 180767535
Test: libsurfaceflinger_unittest
Test: libcompositionengine_test
Test: librenderengine_test
Test: Simulate virtual displays
Test: Screen reotation
Test: Movie playback on Google TV
Test: Force GPU composition
Test: screenshot

Change-Id: I222c71e6e1c67485cdeac49e2cb829289af9efec

The geometry state of a flattened layer was overridden when layer cache
was applied. When the layer cache is invalid, it is necessary to restore
the geometry state back to original.

Bug: 184729207
Test: libcompositionengine_test
Test: Enable SF cache with smooth display
Change-Id: Id721cd451209ab50e5cd8badf5f3e0917506e728

To ensure that these are reasonably accurate when using caching so that
we're robust to partial update support in composer:

1. Set the visible region to be the union of visible regions for all
cached layers.
2. When the cached set is first created, set the surface damage to be
the cached set. For subsequent frames, set the surface damage to be
empty.

Bug: 183456093
Test: libcompositionengine_test

Change-Id: I2b7b3b4b5630011323a802908c5a80917bdb86ef

This fixes a caching issue where split screen chrome blanks out the
other side of the split screen, because chrome uses an opaque layer and
is the first layer of the cached set. The opaque bit must not be
propagated to composer, since the cached buffer is allowed to blend with
other layers if there are undamaged regions. Similarly, plane alpha is
already applied when generating the override buffer, so we should not
re-apply a non-zero plane alpha.

Bug: 183480321
Test: libcompositionengine_test
Test: split screen with chrome and recent screen

Change-Id: I22ef304409f15f10435d824e5fab6d0c075d1b9a

1. Properly set the viewport to be the layer stack content rectangle,
rather than the cachedset bounds
2. The projection space of the output buffer must be stored alongside
the override buffer. This must feed back into RenderEngine when
re-rendering a CachedSet, as the displayFrame of the cached buffer has
to map back into layer stack space
3. The Transform for override buffers must collapse to the IDENTITY
transform, because cached buffers are in the same orientation as the
client target so there's no need to apply a transform

Bug: 180660547
Test: libcompositionengine_test
Test: Youtube fullscreen playback
Test: simulate virtual displays

Change-Id: Ie78c61853b2a712060b5f17045157a457b461cb7

Bug: 180660547
Test: enable cache, play YouTube video in fullscreen
Change-Id: If70a811f5757d4b30b83191175e342a60ffb3724

Bug: 181192086
Test: libcompositionengine_test
Test: Wallpaper colors no longer flicker
Change-Id: If4c3a9b3a9151c271bbd55a657be0a6588524aaa

This ensures that:
* The proper color conversion is applied to the rendered output.
* Color information is correctly provided when passing the cached buffer
over to HWC

Also rename dataspace to outputDataspace whenever the dataspace is used
for output, so that it's less confusing than just "dataspace"

Bug: 181192086
Bug: 181192080
Test: libcompositionengine_test
Change-Id: I024ab471a9139209d2a51add145e6b14d9ed3745

Adds the Planner flattener, which detects when layers are inactive and
flattens them using GPU composition in order to reduce the workload on
the display processor.

Bug: 158790260
Test: atest libcompositionengine_test libsurfaceflinger_unittest
Change-Id: Idc5c2927c8af6fe85653404a7d94c9e68ffc329b

VrFlinger won't be used anymore now that we've divested from VR.

Bug: 168152906
Test: builds
Change-Id: I5b74c77005474bd9f6dbce589697472738416d41
Merged-In: I5b74c77005474bd9f6dbce589697472738416d41

VrFlinger won't be used anymore now.

Bug: 168152906
Bug: 173538619
Test: builds
Change-Id: I5b74c77005474bd9f6dbce589697472738416d41
Merged-In: I5b74c77005474bd9f6dbce589697472738416d41

The logic that computes the transformation matrix that maps
from one projection space to another currently lives in
DisplayDevice::setProjection although it's not specific to
the DisplayDevice. In this CL we move this to ProjectionSpace
so it can be reused and add appropriate testing. Additionally
we move most of the remaining logic from DisplayDevice::setProjection
to Output::setProjection.

Bug: 161793589
Bug: 165184567
Test: atest ProjectionSpaceTest
Test: atest libcompositionengine_test libsurfaceflinger_unittest
Test: on phone emualutor test that rotation works propertly
Change-Id: Ic65a3ba18eda597edb7d2c8635cccfa7cb58a107

VrFlinger won't be used anymore now that we've divested from VR.

Bug: 168152906
Test: builds
Change-Id: I5b74c77005474bd9f6dbce589697472738416d41

This change introduces a new class ProjectionSpace and uses
it in OutputCompositionState to describe the layer stack space,
the physical display space and the oriented display space.
We rename viewport to layerStackSpaceRect, frame to
orientedDisplaySpaceRect and destinationClip displaySpaceRect.
This aims to provide better readibility of the code and
it's also consistent with SurfaceControl.setDisplayProjction
where layerStackRect and displayRect are used for viewport
and frame.

Bug: 161793589
Bug: 160404780
Test: m && flash device
Test: atest libsurfaceflinger_unittest libcompositionengine_test
Test: adb shell dumpsys SurfaceFlinger
Change-Id: Iee20b908157cbef4de4d9addf429f98356ec942d

Use the correct display transform in calculateOutputRelativeBufferTransform().
When SF_PRIMARY_DISPLAY_ORIENTATION is set, DisplayDevice only updates the
logical to physical transform; OutputCompositionState.orientation doesn't
change.

Test: - OutputLayerTest.displayInstallOrientationBufferTransformSetTo90
      - Run "dumpsys SurfaceFlinger" on a device with SF_PRIMARY_DISPLAY_ORIENTATION
        set to 90 and verify that the HWC transform is 0 (identity)
      - screencap
Change-Id: I079b5ea22de8d47a7fb7233d01decfbd4b578be8
Merged-In: I079b5ea22de8d47a7fb7233d01decfbd4b578be8

This CL renames the variables so they are more readable and changes
snake case to camel case.

Test: m
Bug: 153991408
Change-Id: I80faa91ab514395dbf53c52282d62444c9aa579a

Layers with geomBufferUsesDisplayInverseTransform set (usually layers
showing a camera preview) were not being rotated correctly on external
displays with hardware composition. Forcing GPU composition avoided
the issue, since BufferLayer.prepareClientLayer() uses the *primary*
display's orientation to create the inverse transformation.

But, the HWC path used each screen's orientation, resulting in a bad
layer rotation when the primary and external displays' orientation
differed. So let's do what the GPU path does.

This, of course, only makes a difference when the primary and secondary
display rotations differ. In our case, we noticed the problem when
running the landscape-oriented CinemaPro app, while our default camera,
which runs in portrait, did not have a problem.

Co-authored-by: Mikael Magnusson <mikael.magnusson@sony.com>

Note: This is an updated version of the change with the same Change-Id
as uploaded to AOSP, as refactoring has continued, and more tests were
added since.

Bug: 155329360
Test: the new unit test fails without the patch
Test: the new unit test passes with the patch
Test: record using Cinema Pro app with an external screen
Reference: I0da22423490a93fe943fd59e6c122aa6aaf30b11
Change-Id: I8b4975a14a0ae42d10e4eeaa66385e72ff00c23d

Previously SurfaceFlinger codebase uses hwcomposer2.h, which contains a
bunch of types that are not versioned. The usage of hwcomposer2.h has
been causing static casting here and there. This patch removes the usage
of hwcompoer2.h, creates a Hal.h to capture all composer hal stuff that
the codebase relies on.

Bug: b/77585359
Test: atest libsurfaceflinger_unittest
Test: atest SurfaceFlinger_test
Test: atest libcompositionengine_test
Change-Id: If9dfeb2a4a2c2f9df0b3ed300bfaca22c463038e