This reverts commit a4dfaaa4.

pjgowtham authored 5 months ago and Simão Gomes Viana committed 2 months ago

Change-Id: I367b2c395aeb8cb7cb9e3cc38eca98477befe007
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Pierre-Hugues Husson authored 4 years ago and Simão Gomes Viana committed 2 months ago

 * Supports changed z Udfps order
 * Supports changed Udfps usage bits

TheScarastic: Adapt to extension lib and support 12 BiometricPrompt
ArianK16a: Adapt layer name to UdfpsControllerOverlay for Android 13
    and only compare the prefix. Drop the BufferQueueLayer change
    because it seems unnecessary.

Co-authored-by: TheScarastic <warabhishek@gmail.com>
Change-Id: Id95aa73e06b4223a6b4f05c69fa2fc494f9a97b1
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

No need to process these layers.

Bug: 240653315
Bug: 230073351
Test: YouTube PIP at home screen
Change-Id: Iced392706e33a2241197050ddd24e0fffaa3a723

This reverts commit 7a8dc174.

Reason for revert: b/240653315

Test: YouTube PIP at home screen

Change-Id: I6979d1693356623d46349e9de33610731b420973

The shadow length is currently tracked in both the LayerFE
CompositionState and the shadow settings, which are used by the
RenderEngine. We can consolidate these fields and track shadow
settings in the LayerFE CompositionState. This makes sense because
we want the LayerFE CompositionState to contain all relevant
information that it can pass to the RenderEngine without calling
back into the frontend.

Bug: 302551905
Test: presubmit

Change-Id: I583c43993cf73784c6fec9ec2d40f2c76d21adeb

Otherwise GPU composition quality is degraded for:
* Non-prerotated layers
* Screenshots captured from devices with rotated panels

The second issue in particular is problematic for CTS.

Bug: 283075427
Test: SurfaceViewTests with a 90 degree panel installation
Test: libcompositionengine_test
Change-Id: I6dd7f0f385d7df0463a560d97c1ca5ee89998405

- Rename it to `getHdrRenderType` and return a ternary enum.
- return the hdr type that we want to treat based on the dataspace,
  format and hdr/sdr ratio.
- pixelformat is optional, in case no source buffer but there is a
  source color.
- hdr/sdr ratio is 1.0f by default, render rengine doesn't take care
  this param.
- The ternary enum has 3 types: just SDR; generic hdr, namely those we
  need to tonemap; display hdr, namely those self-promoting to HDR by
  using extended brightness API.
- This fix also contains commit I094836e460e0d64b28492061128cff11f22944d9

Bug: 261485283
Test: HdrRenderTypeUtils_test, TextureViewTest#testSDRFromSurfaceViewAndTextureView, OutputLayerUpdateCompositionStateTest

Change-Id: I281687a010bbf5bff555f6fa893002c2a9b324d1
Merged-In: I281687a010bbf5bff555f6fa893002c2a9b324d1

Bug: 261485283
Test: HdrRenderTypeUtils_test
Change-Id: I094836e460e0d64b28492061128cff11f22944d9

- Rename it to `getHdrRenderType` and return a ternary enum.
- return the hdr type that we want to treat based on the dataspace,
  format and hdr/sdr ratio.
- pixelformat is optional, in case no source buffer but there is a
  source color.
- hdr/sdr ratio is 1.0f by default, render rengine doesn't take care
  this param.
- The ternary enum has 3 types: just SDR; generic hdr, namely those we
  need to tonemap; display hdr, namely those self-promoting to HDR by
  using extended brightness API.

Bug: 261485283
Test: HdrRenderTypeUtils_test, TextureViewTest#testSDRFromSurfaceViewAndTextureView, OutputLayerUpdateCompositionStateTest

Change-Id: I281687a010bbf5bff555f6fa893002c2a9b324d1

This is only needed for configuring colorspace agnostic dataspaces, but
no device does that. For colorspace agnostic layers, it's sufficient to
just use the colormode dataspace, with the possible exception of HDR
where we can preserve some bespoke logic, so we can just get rid of
target dataspaces and any associated plumbing.

Bug: 292162273
Test: builds
Test: libsurfaceflinger_unittest
Test: libcompositionengine_test
Change-Id: I319bb354e80e3ad1eaaacd896b897e6696f96588

Bug: 267350616
Test: builds
Change-Id: I75bb485f01ae2358c77133767f01cb63f8eda6f1

Test: Device boots
BUG: 202734676
Change-Id: Ibe1943e9ee8eb6b3f9968c097095ff10c609f479

Bug: 241001465
Test: manual currently, flagged off
Change-Id: I707281b9acaf6ea218f1d9ce888fc7cdbf1cf7c9

This allows the memory for the active buffer to be freed as soon as
possible by purging it from HWC cache as soon as the next buffer is sent
to the layer.

Bug: 258196272
Test: atest OutputLayerUncacheBufferTest
Change-Id: I96c24390de5757ac99b369119e9ba031afb0b042

When an app discards graphic buffers, for example when a MediaCodec
disconnects from a surface, those buffers will be uncached and removed
from HWC buffer slots. The active buffer, however, should still remain
active until the next buffer is queued up.

Bug: 262037933
Bug: 258196272
Test: atest OutputLayerUncacheBufferTest
Test: atest VtsHalGraphicsComposer3_TargetTest
Test: atest VtsHalGraphicsComposerV2_2TargetTest
Change-Id: I7c4eefb17e8bad694d698f9ad6d1d289f4af8d2c

When buffers are discarded by SurfaceFlinger clients, the memory should
be free'd immediately. This includes clearing references to them from
within the implementation of Composer HAL, specifically in cache slots
associated with the layer.

Since there is no HAL API to clear the slot directly, prior to writing
any other buffer to the layer, we set the layer's buffer multiple times
to a placeholder buffer, using each of the slot numbers that need to be
cleared. This replaces the reference to the client-discarded buffer
inside Composer HAL with a reference to the placeholder buffer, causing
the reference count to drop, allowing the buffer memory to be freed.

Bug: 258196272
Test: atest OutputLayerUncacheBufferTest
Change-Id: Id85482e8859490566f0eedbd8d8729c47a7349fb

Stop caching buffers inside SurfaceFlinger and remove the tight coupling
between SurfaceFlinger's ClientCache and the Hardware Composer cache.
This allows a better seperation of responsibility, where buffer cache
management is not split between HwcSlotGenerator and HwcBufferCache, but
is instead solely handled by HwcBufferCache.

Note that FramebufferSurface and VirtualDisplaySurface no longer use
HwcBufferCache, but instead use their own cache slot management that
is solely based on BufferQueue slot numbers.

Also do minor refactoring in FramebufferSurface to simplify code.

Bug: 258196272
Test: started and stopped multiple YouTube videos on adt4 and verified
no change in graphic buffer usage
Test: atest HwcBufferCacheTest
Test: atest OutputPrepareTest

Change-Id: Ica7955ab4bc70e3c70207390e36dff73a2fc4949

Replace Layer::prepareClientCompositionList with
Layer::prepareClientComposition now that at most one layer is returned
for any call. Also changes OutputLayer::getOverrideCompositionList to
return an optional for the same reason.

Output::generateClientCompositionRequest is updated to use buffer ids
instead of strong pointers to buffers when determining whether or not
override settings are redundant. This is done to avoid duplicate checks
on whether or not overrideInfo has a non-null buffer.

Change-Id: I777f6ba8c3ca38ea31773e6fcbacb65fad287b03
Bug: b/188891810
Test: atest libcompositionengine_test

Layers with SOLID_COLOR compostion type may cause fence leaks, and since these layers are not frequently used, skipping them should be ok.
Bug: 230073351
Test: manual, examine logs

Change-Id: I50c2488c4c5b891bf0415f1d4bd29a6e0c49be5b

This reverts commit e30a5850.

Reason for revert: b/230389971

Change-Id: I25e5f8ae18d370340ee218ea5d4ad80783e21fa6

Introduce a debug sysprop, defaulted to false, to allow for rewriting
the transfer function to sRGB when set to true.

This is due to several considerations:

1. SurfaceFlinger has not color managed SMPTE 170M properly ever since
   color management was introduced in Android O, and was only fixed in
   Android 13. This means that some camera -> encoding -> storage ->
   playback flows may be incorrectly calibrated on some devices since
   SMPTE 170M was reinterpreted as sRGB for a long time.
2. BT. 1886 recommends a reference EOTF of gamma 2.4 with tuneable
   parameters to approximate a CRT on a non-CRT display. Because the
   framework doesn't support BT. 1886 and it's too late to add support,
   casting as sRGB is probably okay for now and matches old behavior.
3. Typical Rec. 709 content is graded assuming a dim surround, but phone
   displays are used in a wide range of viewing environments, which
   means that viewing Rec. 709 content in a bright environment may
   appear to have lower contrast. Decoding as sRGB will push the dark
   codes into lower luminance levels, which will improve contrast in
   those scenarios. Note that it's better to adjust contrast based on
   the ambient viewing environment, but again it's too late for Android
   13 to improve the color pipeline in the GPU.

Bug: 229442032
Test: Photos playback after recording a video
Change-Id: I64fc8f2ea77f8e595333de36fb9da2979d8316ca

Source frame and bufferCrop calculations use the
primaryDisplayRotationFlags using the projection space
orientation just for the source crop calculation causes the
unwanted source crop in a situation where bufferCrop and
source frame are in different coordinate system. Using the
same primaryDisplayRotationFlags in Source crop calculation
will make all these calculations in line.

Test: verified manually with provided test apk in the #comment1 on
foldable, tablet and a phone and verified go/wm-smoke
atest libsurfaceflinger_unittest
atest libcompositionengine_test
atest CompositionTest
atest OutputLayerTest

BUG: 204187592
Change-Id: I23c6dcfb39979fd67eb5e1d21c011476c630058b

- Disable dimming for screenshot layer

Bug: 224860402
Test: check HDR vidoes when rotation, atest libcompositionengine_test
Change-Id: Ib07a5af1d4e3e91737b3d5f3e5869c166759563f
Merged-In: Ib07a5af1d4e3e91737b3d5f3e5869c166759563f

- Disable dimming for screenshot layer

Bug: 224860402
Test: check HDR vidoes when rotation, atest libcompositionengine_test
Change-Id: Ib07a5af1d4e3e91737b3d5f3e5869c166759563f

Caching does not perform any dimming operations, which means forcing
cached layers to not dim in composer is not correct. So...dim the cached
layers as if they were SDR layers

Note that because caching does not perform any dimming, then this does
imply that some cached sets may permanently be in GPU composition if the
dimming ratio is large enough that the DPU cannot dim + dither.

If we wanted to resolve the power cost of steady-state dimming by a
large ratio, then a future patch would have to teach caching how to dim.
That approach would have a few potential difficulties:
1. Modulating the dimming ratio of cached SDR layers may cause cache
   evictions when an HDR video comes on screen, since caching will have
   to recomposite those layers due to the change in dimming ratio, which
   can be a power regression.
2. Reusing caching results that take into account dimming may be
   difficult, since dimming can cause crush at lower grey levels, so
   brightening a dimmed cached set may cause degradation in image
   quality.

(1) and (2) aren't impossible to solve, but would either require changes
to the composer interface to communicate a dimming ratio capability,
and/or would introduce complexity into caching to selecttively dim
cached results based on composer capabilities as well as what is
expected to be more efficient. Whereas this patch is pretty
straightforward.

Bug: 217794675
Test: HDR test video
Change-Id: I618a0616f49c6ae3feac5bedbb4f5b0e283f5da7

* Send the dimming ratio over to composer as the HWC api is changing to
  not expose the notion of nits to composer, as the white point nits are
  part of logical SF state that does not map as nicely to display
  hardware
* Fixes an issue where scheduling a recomposite for a frame when
  brightness changes is contingent on the presence of HDR layers, which
  is not valid when an HDR layer exits the scene, but DisplayManager
  animates the display brightness down to the SDR white point.

Bug: 217961164
Test: builds, boots
Test: HDR test videos on youtube
Change-Id: Icc07b00f60859bbd3ee078cd2bb793eda42e7781

Devices that have support for DISPLAY_DECORATION layers may also have
support for a blockingRegion, which will allow the DPU to skip regions
that are known to be transparent, in order to save power.

Use the transparentRegionHint to compute the blockingRegion. It may not
be accurate for all layers, which is why it is only used for
DISPLAY_DECORATION layers.

Add tests.

Bug: 212736475
Test: libcompositionengine_test
Change-Id: I6c5d29614dc8d65d8481150ce717a440192083a0

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

Follow on to I2b7b3b4b5630011323a802908c5a80917bdb86ef, which makes it
so we might pass the overrideInfo's visibleRegion instead of the one on
outputDependentState. If the HWC2::Layer call fails, dump the actual
region passed to it, whether it's the original or the override.

Bug: 183456093
Test: make
Change-Id: I5dbb106f7c855d328b5c72a1e4ccacda20bda2c7

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
(cherry picked from commit c3e9a90b)
Merged-In:Ifa4d06453b5707626c614aad203c727681e23fed

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
(cherry picked from commit d486bdf9)
Merged-In:I9e8b4d3c4f61a080d85401aa4a503a7436930a3b

This reverts commit 028676ae.

Reason for revert: Droidfood blocking bug: 209930535

Change-Id: I9e8b4d3c4f61a080d85401aa4a503a7436930a3b