Adithya R authored 2 years ago and Simão Gomes Viana committed 2 years ago

Layer dataspace is initialized as unknown by default, unless
overriden by the buffer source. We don't require expensive
rendering for color conversion when the dataspace is unknown.

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

Simão Gomes Viana authored 2 years ago and Simão Gomes Viana committed 2 years ago

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

Ray Zhang authored 2 years ago and Simão Gomes Viana committed 2 years ago

In streaming video case, video decoder needs to change buffer
color space dynamically according to video stream real-time
parameters.

CRs-Fixed: 3155775
Change-Id: I21590ee41708f5cb1ed45cb5a7f5c00f1c129bb0
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Simao Gomes Viana <simao@halogenos.org>
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Rui Wang authored 3 years ago and Simão Gomes Viana committed 2 years ago

CRs-Fixed: 3013293

Change-Id: Idfafcd6aa718054ff749bd5d1c7eb2630be0f109
Signed-off-by: DennySPb <dennyspb@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Simao Gomes Viana <simao@halogenos.org>
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Simao Gomes Viana authored 5 years ago and Simão Gomes Viana committed 2 years ago

Change-Id: Icdfd3512a79d9935d3fdb611c96dc8fd91a5e1c5
Signed-off-by: DennySPB <dennyspb@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Simao Gomes Viana <simao@halogenos.org>
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Danny Lin authored 3 years ago and Simão Gomes Viana committed 2 years ago

Unlinking death recipients (from linkToDeath) is a normal part of Binder
operation, and doing it when a BpBinder's refcount has reached 0 is not
much different.

This log message is constantly spamming when swiping as part of a back
navigation gesture:

04-05 22:29:41.402   655  3888 I BpBinder: onLastStrongRef automatically unlinking death recipients: <uncached descriptor>
04-05 22:29:41.413   655  3888 I BpBinder: onLastStrongRef automatically unlinking death recipients: <uncached descriptor>
04-05 22:29:41.424   655  3888 I BpBinder: onLastStrongRef automatically unlinking death recipients: <uncached descriptor>
04-05 22:29:41.435   655   681 I BpBinder: onLastStrongRef automatically unlinking death recipients: <uncached descriptor>
04-05 22:29:41.447   655  3888 I BpBinder: onLastStrongRef automatically unlinking death recipients: <uncached descriptor>

Logging is relatively expensive on Android and the log spam isn't
useful, so suppress this log message by setting it to the verbose log
level.

Change-Id: I774d0c59ca6f70a4e2ed33b9fac3fb5b86d8ff0a
Signed-off-by: Simao Gomes Viana <simao@halogenos.org>
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Kevin F. Haggerty authored 3 years ago and Simão Gomes Viana committed 2 years ago

* Change I7f4174581e24e361577640b9263514a168ed482d implemented
  validation of the buffer description info prior to creating
  the descriptor. Some of our legacy devices need to whitelist
  additional usage bits to support various functionality.

libui: Extend adb95ae to Gralloc3
libui: Extend adb95ae to Gralloc4

This commit squashes:
  libui: Convert lineage product variables to soong config variables
  Change-Id: Ib687c966d4eafcc1128611b95ebed00fd0a8bfaf

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

binzhang authored 3 years ago and Simão Gomes Viana committed 2 years ago

The candidate of presnet fence is switched dynamically between front/back buffer, based on current design, it will introudce in big side effect especially for app launching, app resume cases, sometimes the timestamp of the candidate fence is not signaled, but the other candidate has fence signaled already. Then previous logic is not well handled to pick up theright presnet fence candidate. Then frame is skiped.

This change is to use the legacy logic to pick up fence candidate. It can avoid such abnormal frame skip behavior.

Change-Id: I055942d9ae9ac6c96eba403aa4bc1979cf128ce8
CRs-Fixed: 3035044
Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Vinay Verma authored 6 years ago and Simão Gomes Viana committed 2 years ago

libstagefright_omx library need to be extended to vendor which
is depenednet on libgui which is a vndk_private lib.
Creating vendor version so that libstagefright_omx_ext can link
to libgui_vendor.

 Conflicts:
	libs/gui/Android.bp

CRs-Fixed: 2258968
Change-Id: I777eebffc405c8bb74aab270e9f272c806501458
Signed-off-by: Volodymyr Zhdanov <wight554@gmail.com>
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Change-Id: I7327923aa6952c485af578121a177262f3281432

Change-Id: I95c1b29e065e050901bb4d5ab1fa2f12e81e7b47

When an event hub device is going away, the controller associated with
it should be deleted.

Before this CL, mController would remain, and its use would result in an
illegal memory access, because it was storing a reference to a deleted
context.

Bug: 245770596
Test: atest inputflinger_tests:InputDeviceTest#DumpDoesNotCrash
Merged-In: I298f43172472f74fa4d5d8e0b7f52bd5c13d14f7
Change-Id: I298f43172472f74fa4d5d8e0b7f52bd5c13d14f7
(cherry picked from commit 30feb8c1)

This is a cherry-pick from of a CL from sc-v2 adding a safety mechanism
for lost buffers. The original CL probably should have been merged in to master,
and I can't relate to my thought process adding DO NOT MERGE on the
original CL. Recently we have started seeing some of these ANRs again.
Well actually we have seen them continuously, but most have been due to
GPU hangs. Recently we started seeing some which aren't due to GPU
hangs. We found one trace, which showed the sort of situation described
below, which lead me to realizing this code was never merged in to
master. It shoud be relatively safe since we released it on sc-v2.

Perfetto telemetry shows a cluster where a transactionComplete is
arriving but an earlier releaseBufferCallback has never arrived.
This leads to blocking and ANRs. We try to work around this by
generating a fake release buffer callback for previous buffers when we
receive a TransactionCompleteCallback. How can we know this is safe? The
criteria to safely release buffers are as follows:
	Condition 1. SurfaceFlinger does not plan to use the buffer
	Condition 2. Have the acquire fence (or a later signalling fence)if
	dropped, have the HWC release fence if presented.
Now lets break down cases where the transaction complete callback
arrives before the release buffer callback. All release buffer callbacks
fall in to two categories:
	Category 1. In band with the complete callback. In which case the client
	library in SurfaceComposerClient always sends release callbacks
	first.
	Category 2. Out of band, e.g. from setBuffer or merge when dropping buffers

In category 2 there are two scenarios:
	Scenario 1: Release callback was never going to arrive (bug)
	Scenario 2. Release callback descheduled, e.g.
		a. Transaction is filled with buffer and held in VRI/WM/SysUI
		b. A second transaction with buffer is merged in, the release
		buffer callback is emitted but not scheduled (async binder)
		c. The merged transaction is applied
		d. SurfaceFlinger processes a frame and emits the transaction
		complete callback
		e. The transaction complete callback is scheduled before the
		release callback is ever scheduled (since the 1 way binders are
		from different processes).
In both scenarios, we can satisfy Conditions 1 and 2, because the HWC
present fence is a later signalling fence than the acquire fence which
the out of band callback will pass. While we may block extra on this
fence. We will be safe by condition 2. Receiving the transaction
complete callback should indicate condition 1 is satisfied.

In category 1 there should only be a single scenario, the release buffer
callback for frame N-1 is emitted immediately before the transaction
callback for frame N, and so if it hasn't come at that time (and isn't
out of band/scheduled e.g. category 2) then it will never come. We can
further break this down in to two scenarios:
	1. stat.previousReleaseFence is set correctly. This is the
	expected case. In this case, this is the same fence we would
	receive from the release buffer callback, and so we can satisfy
	condition 1 and 2 and safely release.
	2. stat.previousReleaseFence is not set correctly. There is no
	known reason for this to happen, but there is also no known
	reason why we would receive a complete callback without the
	corresponding release, and so we have to explore the option as
	a potential risk/behavior change from the change.
Hypothetically in category 1 case 2 we could experience some tearing.
In category 1 we are currently experiencing ANR, and so the tradeoff
is a risk of tearing vs a certainty of ANR. To tear the following would
have to happen:
	1. Enter the case where we previously ANRed
	2. Enter the subcase where the release fence is not set
	correctly
	3. Be scheduled very fast on the client side, in practicality
	HWC present has already returned and the fence should be firing
	very soon
	4. The previous frame not be GL comp, in which case we were
	already done with the buffer and don't need the fence anyway.
Conditions 2 and 3 should already make the occurence of tearing much
lower than the occurence of ANRs. Furthermore 100% of observed ANRs
were during GL comp (rotation animation) and so the telemetry indicates
the risk of introducing tearing is very low.

To review, we have shown that we can break down the side effects from the change in
to two buckets (category 1, and category 2). In category 2, the possible negative side
effect is to use too late of a fence. However this is still safe, and should
be exceedingly rare. In category 1 we have shown that there are two scenarios,
and in one of these scenarios we can experience tearing. We have furthermore argued
that the risk of tearing should be exceedingly low even in this scenario,
while the risk of ANR in this scenario was nearly 100%.

Bug: 247246160
Bug: 244218818
Test: Existing tests pass
Change-Id: I757ed132ac076aa811df816e04a68f57b38e47e7

SurfaceFlinger::doDump previously contained two layer traversals, one on
the main thread and one off the main thread. During concurrent dumpsys
commands, the layer traversals may race with each other, which causes
shared ownership of the underlying storage of a SortedVector containing
the z-ordered list of layers. Because the implementation of
SortedVector's STL iterators assumes that the underlying storage may be
edited, this can cause the storage to be copied whenever SortedVector::begin
and SortedVector::end are called, which means that SortedVector::begin()
+ SortedVector::size() == SortedVector::end() is not always true, which
causes invalid iteration.

In general, this use-after-free can happen as long as the off-main
thread traversal exists in doDump(), because the traversal can run in
parallel with any workload on the main thread that executes a layer
traversal. So, this patch moves the traversal for dumping out the list
of composition layers into the main thread.

A future patch could explore either fixing SortedVector to fix judicious
iterator invalidation, or building LayerVector on top of std::set, but
either option is an invasive data structure change.

Bug: 237291506
Test: Test script that calls dumpsys SurfaceFlinger on many threads
Change-Id: I0748396519c924dc1b84113d44259f22d0d7ebd6
(cherry picked from commit 6761733a)
Merged-In: I0748396519c924dc1b84113d44259f22d0d7ebd6

Change-Id: I567b6adea007cbb3571530e3bc3bf8d09c81b81e

Change-Id: I52387cfae81475b37e468024edde13bde1020046

Change-Id: If2dfe440152551d9c6b22068ffa71032d85adb35

When needsComposite is zero in persistBrightness(), the mBrightness
needs to be updated to avoid unexpected skipping.

Bug: 244268674
Test: adb shell cmd device_state state 0 or 1 repeatly
Change-Id: Iccf925c1407e4be489da2dba521b93eee1b1c4b5

Change-Id: Ibd5d3bd8ec2c54c96881ca9d3cf3f7936dd085ad

Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/native/+/19775140



Change-Id: I965677ab70958604ad123e8a2c86c4d9c9020509
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>

Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/native/+/19775140



Change-Id: Ie6aa47c375f59647fa7027aa1fa5654cf995eb9e
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>

Change-Id: Ia64f92ab5badec477704b885eedb2d1ad77d8eb7

These logs were made optional in ag/17073502, but that was not
intentional. These are useful for debugging obstructed touch issues, so
let's bring them back.

Bug: 246404700
Test: adb logcat
Change-Id: Ieca99d790d2a1c9680de9a89e0113e177488dc7b

An InputDevice can be associated with a display, in which case it should
only generate events for that display. A mouse generally generates
events for whichever display is currently showing the mouse cursor.

In the case where a mouse InputDevice is associated with a display, we
need to make sure that it only generates events when the mouse cursor is
on the associated display.

Additionally, any display-dependent configuration, such as orientation,
should depend on whichever display the device is configured for.

Bug: 236075874
Test: atest inputflinger_tests
Change-Id: I1021c121c1eae768585124d312f5187be90da666
Merged-In: I1021c121c1eae768585124d312f5187be90da666
(cherry picked from commit c13ff081)

Bug: 239775097
Test: atest libsurfaceflinger_unittest
Test: pixel 4xl camera preview test (see bug)
Change-Id: Ib92849291458f59c2ef2238d3586211b87174c7f
(cherry picked from commit 0679cf20)
Merged-In: Ib92849291458f59c2ef2238d3586211b87174c7f

After SurfaceFlinger receives the brightness commands, the commands are
sent to HWC until the next frame presents. However, no following frames
are present after the power mode is set to off, and HWC cannot receive
the last brightness commands.

This change forces SurfaceFlinger to flush the staged brightness to HWC
prior to execution of power off.

Bug: 239908529
Test: suspend and resume repeatedly
Change-Id: Ia8fb04399e757de16e06e6516d86bdfcfabd5a2e

Change-Id: I65871b1a5ac8cef1e7d9113e718b9a1768c9ec3f

* changes:
  Reset the touch state when the active viewport is disabled
  Fix issues with InputMapper tests
  Fix spot not disappear when display id changed

When an active viewport becomes inactive, cancel any ongoing gestures
immediately. When the viewport becomes active again, make sure state is
reset again so that we eliminate any race conditions between the
viewport becoming active and first touches coming in from the device.

This is a preventative measure to defend against unexpected touch
behavior around viewports being activated and deactivated.

Bug: 234662773
Test: atest inputflinger_tests
Change-Id: I111361f7470fdad39b493b516e8a8f167e0c681c
Merged-In: I111361f7470fdad39b493b516e8a8f167e0c681c
(cherry picked from commit c0bdeefd)

- When an input device is added, a device reset notification is sent.
  This should be consumed when the device is added so that it does
  not need to be consumed in every test case.
- The above change exposed an issue with a CursorInputMapper test case,
  where it was consuming the wrong device reset notification.
- When a device is configured, it may produce device reset
  notifications. After configuring, we should loop the input reader so
  that the queued input listener is flushed so that these args can be
  sent out.

Bug: 234662773
Test: atest inputflinger_tests
Change-Id: Ic4979b91207a6abf4c4ac65fd3db30307cb53729
Merged-In: Ic4979b91207a6abf4c4ac65fd3db30307cb53729
(cherry picked from commit b5174de1)

Change-Id: I5dd41425182b8c12761f044d46f9ad2ee892f931