| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I199988b521badc7c7fc1b9193d20833b719f5f34
|
|
tm-qpr-dev
|
|
As a workaround for lost release callbacks, we try to
release buffers in the submitted queue. If the buffer
was released previously but held in the pending release
queue, we would log incorrectly. This fixes the misleading
logs.
Test: presubmit
Test: logcat
Fixes: 255679881
Change-Id: I7e46f21f4c4fa1ee8c70e3ee8cd3f3665fe7442a
(cherry picked from commit 28fe2e694f5cafaf0eaad1417e15fdee2943b15b)
|
|
This fix the second pointer will use the identity transform because the
returned touched windows should be refreshed after updating the new
pointerIds to the temporary touch state.
This also fixed wallpaper window can't receive up event.
Bug: 258382964
Bug: 240308355
Test: atest inputflinger_tests
Change-Id: I96a738dcb01bf1c9e2792d3fee547c147dba33b5
Merged-In: I96a738dcb01bf1c9e2792d3fee547c147dba33b5
Merged-In: Ibf82b494e45e35babe9ba9f3dd1236fee8bcea6d
|
|
RegionSamplingThread::captureSample intentionally passes null, which is
already checked for below, but missing in this failure case of
`!renderArea`
Bug: 259021062
Test: presubmits (cost/benefit ratio of adding a new test for this seems
high, given current testing flows and simplicity of change)
Change-Id: I460539404be7a7ae434812aa1f583bba6247a812
Merged-In: I460539404be7a7ae434812aa1f583bba6247a812
|
|
Change-Id: Ida1a5d71225c5930cb0d3adff537139a1728026d
|
|
|
|
Change-Id: I611c8fbf9be9a2c62bb4441ccaec4d2559c82a12
|
|
|
|
Change-Id: I6e90240b70628e512f6684e7155086ed9ab179ab
|
|
The change in ag/19758680 made it so that we now reset TouchInputMapper
after the viewport is disabled.
When resetting, we cancel any ongoing gestures. Since the mapper is
re-configured before the gesture is canceled, this means that as the
viewport is getting disabled, the mapper (which was previously in
POINTER mode) is set to DISABLED mode. When the pointer gesture is
canceled afterwards, it is happening while the mapper is already
DISABLED.
In this CL, we allow pointer gestures to be aborted even when the mapper
is not in POINTER mode.
Bug: 257071757
Test: atest inputflinger_tests
Change-Id: I5c80a5c1c411d16f70ed4f7cce6dd97ed91e124f
Merged-In: I5c80a5c1c411d16f70ed4f7cce6dd97ed91e124f
(cherry picked from commit b80b6c0e6d9c69957fb9ffa3d0467ad626af2fbe)
|
|
Change-Id: I201002fdf06bb24b91bff72aa1ecbb1b1cd108f7
|
|
|
|
Change-Id: I1259a7f7c4fdd3bc773c198a675a34c46f6f362b
|
|
The current logic only checks if dirty is not empty, but doesn't account
for no content changing. Instead use the same logic that's in
beginFrame to compute mustRecompute and use that when determining if the
display should queue a buffer.
This fixes an issue where a Displays first few frames could be black
until the content is loaded.
Bug: 239888440
Test: First frame from screenrecord is no longer black
Change-Id: Ibb568302bf2d50db167a1f9ca76a0f37e2c65bf5
(cherry picked from commit 09fa1d6665aa6022d5c6c8f61fc81f950b476a2f)
|
|
The existing pattern in InputReader is that when a mapper is reset, all
of its state is cleared and state of the buttons/axes is
queried through EventHub to rebuild the current state of the mapper.
This approach does not work for multi-touch devices, since there is no
way to query the current state of the contacts through the evdev
multi-touch protocol.
Since we cannot fully rebuild the current state of a multi-touch device,
we work around this limitation by never clearing the multi-touch state.
Bug: 248506674
Test: atest inputflinger_tests
Change-Id: Ic59d9fcb4e13fe262c422825c2485185004b719b
Merged-In: Ic59d9fcb4e13fe262c422825c2485185004b719b
(cherry picked from commit afabcde5a9ac2b77586d61ad4a226718130663c3)
|
|
Currently only a single corner radius can be applied on a
layer. If the layer's x and y scale do not match, the average
is used to scale the corner radius. This can cause visual
defects in the rendered rounded corners.
This defect can be seen when moving the Camera app
to recents. The camera buffer is submitted with a rotation
and the layer's x and y scales are used to stretch the buffer
to the desired size in portrait mode.
Bug: 145094543, 250491108
Test: atest librenderengine_test
Test: adb shell wm size 1000x1900 & animate camera app to recents
Change-Id: Ie76581eb200a57b847f619f4da0e61758f70dce7
(cherry picked from commit 50c0afe2457ec631fc3c9a7731aa4b9c8e18fd76)
Merged-In: Ie76581eb200a57b847f619f4da0e61758f70dce7
|
|
Change-Id: I0b6d9155258dc6856a35451d5c577bbdd8c5cfd3
|
|
tm-qpr-dev
|
|
Change-Id: Ie872ece34961c0609993b1019abd7d5d94028b89
|
|
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 30feb8c162aa2e5348bba20e99e8db2a61bac6e7)
|
|
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 6761733ad1dd775f011588c59d5a6d210175c546)
Merged-In: I0748396519c924dc1b84113d44259f22d0d7ebd6
|
|
Change-Id: I4d6892f4316dbd02cccf1c464ea72952fe7928bd
|
|
|
|
Change-Id: I7923bbc7c13110db81fc63e696c9a4530259f27a
|
|
|
|
A mirror for misc_ce and misc_de storage is created for each new volume
UUID and a bind mount occurs from /mnt/expand/<uuid>/misc_{ce,de} to
/data_mirror/misc_{ce,de}/<uuid>.
This is similar to how apps use data_mirror. In addition, when a private
volume is unmounted, the mirror for that volume UUID is deleted.
Bug: 214241165
Test: atest GtsSdkSandboxInprocessTests
Ignore-AOSP-First: Will cherry pick once other CLs are merged in as well
Change-Id: I3ea99145e38ed3781a701c1305720f2d4dbe54ce
Merged-In: I3ea99145e38ed3781a701c1305720f2d4dbe54ce
|
|
Change-Id: Iebaf13651ed62988932f559ae0e853edb1711b4a
|
|
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: I98eddda97677f00c3d7fb67583eb07834606cb1b
|
|
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: I08a760d7ac3117349792a0974d21a0462f3cefd3
|
|
|
|
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
|
|
into tm-qpr-dev
|
|
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 c13ff081db31e93ee3b0a96bb007704c61d10a02)
|
|
Bug: 239775097
Test: atest libsurfaceflinger_unittest
Test: pixel 4xl camera preview test (see bug)
Change-Id: Ib92849291458f59c2ef2238d3586211b87174c7f
(cherry picked from commit 0679cf200ea30c2e791cd79b27a26676e8848932)
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: I37d6b085e3b8ffce1a7805a1639d0784057716ae
|
|
* 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 c0bdeefdcb2f8d880389cf3aa0a0d8899f46f2e4)
|
|
- 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 b5174de1a9ede697dfd2bf65e65b294321f9444d)
|
|
Change-Id: If700741bda9bd890ad4df68f6b187f9085387ed7
|
|
Turn on show touches in settings, and finger press on screen, let the
spot show, at now, display id changed, the spot will stay on screen.
when display id changed, we should cancel touch event and update
spot state.
Bug: 239378650
Bug: 234662773
Test: atest inputflinger_tests
Signed-off-by: lilinnan <lilinnan@xiaomi.corp-partner.google.com>
Change-Id: Ic289d772087e53716b4d63c431d9f41af721150e
Merged-In: Ic289d772087e53716b4d63c431d9f41af721150e
(cherry picked from commit 687e58faa44d7f5b4a5f21ca59442252716839ea)
|
|
|
|
Change-Id: I2310f65380b8a213e6d301a42ec020f70679f6f8
|
|
Bug: 227383300
Test: doxygen local generated docs
Change-Id: Iee46c5b4ae053fb9a72511329d6e974afa59e478
(cherry picked from commit e81bf2616ea406d9ee9deb038c6978cdb84d6d35)
|
