| Age | Commit message (Collapse) | Author |
|---|
|
tm-qpr1-release
Change-Id: I7327923aa6952c485af578121a177262f3281432
|
|
tm-qpr-dev
|
|
tm-qpr1-release
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 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
|
|
tm-qpr1-release
Change-Id: I567b6adea007cbb3571530e3bc3bf8d09c81b81e
|
|
|
|
tm-qpr1-release
Change-Id: I52387cfae81475b37e468024edde13bde1020046
|
|
|
|
tm-qpr1-release
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
|
|
tm-qpr1-release
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>
|
|
|
|
tm-qpr1-release
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
|
|
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
|
|
tm-qpr1-release
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 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)
|
|
tm-qpr1-release
Change-Id: I5dd41425182b8c12761f044d46f9ad2ee892f931
|
|
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)
|
|
|
|
tm-qpr1-release
Change-Id: I81f03e13a3cce38abb56bf10e9dcaa21922bb218
|
|
Bug: 227383300
Test: doxygen local generated docs
Change-Id: Iee46c5b4ae053fb9a72511329d6e974afa59e478
(cherry picked from commit e81bf2616ea406d9ee9deb038c6978cdb84d6d35)
|
|
In the AIDL sensor HAL wrapper, file descriptors associated with a
direct channel were being wrapped in the AIDL NativeHandle type using
makeToAidl(), which ends up taking ownership of the fds, and
unintentionally closing them when the object goes out of scope (via
ndk::ScopedFileDescriptor), so the same fds would be closed at a later
point when the original native_handle_t is closed.
Switch to dupToAidl() which does not take ownership of the input file
handles.
Bug: 234456046
Test: apply fdsan protection (in different CL), confirm via
test-sensorservice that the file descriptor is not closed twice
Change-Id: I51c0ba0f31b43c56bf055d186a599b289ca0065f
|
|
Bug: 237745199
test: atest libsurfaceflinger_unittest:OnInitializeDisplaysTest
atest libsurfaceflinger_unittest:SetPowerModeInternalTest
Merged-In: I3a2eae4efc4a5c6113700a9ca9e9b261e364a878
Change-Id: I3a2eae4efc4a5c6113700a9ca9e9b261e364a878
|
|
We can't exclude layers that are below the frameRateMultipleThreshold
when scoring the higher refresh rates (the ones above the threshold)
as it creates gives the lower refresh rates a higher score (as there are
more layers that are allowed to score them). Instead we use a different
approach which first scores the refresh rates based on all the layers
but the fixed source ones, and then we add the fixed source ones for the
refresh rates below the thresholds and for the above ones only when other
layers already scored them.
Bug: 242283390
Test: newly added unit tests scenarios
SF: layers above the frameRateMultipleThreshold should always be counted
An additional fix on top of ae2e3c741f0d15d0ed64afd2df93e8c4b2d76cfb
which also include layers that have a desired refresh
rate that was calculated hueristically and matches the max refresh rate.
Bug: 242283390
Test: newly added unit tests scenarios
Change-Id: I85534a3e004f372349dbf923ee6013855a54e4fa
Merged-In: Ibe30ddd306265507ceedff6a6a725dadadc50af2
Merged-In: I85534a3e004f372349dbf923ee6013855a54e4fa
|
|
tm-qpr1-release
Change-Id: Iea63248e6a3b35e06e4dc10457bdbefbd668fc48
|
|
tm-qpr-dev
|
|
match the behavior in Output::composeSurfaces()." into tm-qpr-dev
|
|
the behavior in Output::composeSurfaces().
Bug: 240293363
Test: atest libcompositionengine_test. Fixed tests, added CachedSetTest::renderWhitePointNoColorTransform
Change-Id: Ic0317b34978c2ae8d5c057c0a39ed889b86b3da0
Merged-In: Ic0317b34978c2ae8d5c057c0a39ed889b86b3da0
|
|
tm-qpr1-release
Change-Id: I9b169b46e6d96d53d111166f034198afecc815b4
|
|
Some key layouts require the presence of a specific kernel module. If
the kernel module is not present, the layout should not be loaded.
In this CL, we add an option to specify which kernel modules / configs
are needed inside the kl file.
Bug: 228005926
Test: atest libinput_tests
Merged-In: I0d2ab6298bd41df6dc56120bf0385e10da6c3bfe
Change-Id: I0d2ab6298bd41df6dc56120bf0385e10da6c3bfe
|
|
|
|
As part of the next commit to allow kl files to specify a required
kernel config, some small refactorings were done. Move those here to a
separate CL to make it easier to review.
Bug: 228005926
Test: atest libinput_tests
Merged-In: Iab06bb6ef44807308ee2b3e6b8a0c780bb748f09
Change-Id: Iab06bb6ef44807308ee2b3e6b8a0c780bb748f09
(cherry picked from commit 5ed8eaab67ad7ec3ac1110d696f5d89596a5a887)
|
|
tm-qpr1-release
Change-Id: I0a8455f905e85feb9dcb26e86e064b78353a0900
|
|
Adds additional tests for PowerAdvisor functionality regarding
timing and multidisplay
Bug: b/241465879
Test: atest
libsurfaceflinger_unittest:libsurfaceflinger_unittest.PowerAdvisorTest
Change-Id: I833e91efb5608d5972220c679a061c9bb51372fa
|
|
Avoids possibility that a stale cache is used if cleanupConnection()
does not get called for some reason.
Bug: 230358834
Test: run POC from b/230358834#comment4
Change-Id: I2e7422d90cec87167968d56458af9aac6d525506
|
|
tm-qpr1-release
Change-Id: Ib90b1776f7ed3f894ada7652f8d8c0c394a5fc82
|
|
|
|
|
|
tm-qpr1-release
Change-Id: Ib700db68e3f19cef34d1e844a94610a4cdaa845f
|
