swapBuffers is called even for device composition when a flip client
target request is present. dequeueBuffer call is skipped
as there is no client composition. This is fine for single display
but if multiple display i.e. vds is present, this will be an issue
as current surface will not be switched and swapBuffers will fail
When flip client target request is present, make sure buffer is
dequeued before swapBuffers.
Bug: 151698217
Test: atest libsurfaceflinger_unittest
Change-Id: I933cbae2f09f81eef6555b1bb1e5991d2c450930
Merged-In: Ia8a1470affb2596b27986cc4153417f48cf4ed1c
For easy transition from SchedTune to UtilClamp, direct access to these
cgroups should be abstracted by using task profiles. Replace writepid
commands with new task_profiles command.
Bug: 155419956
Test: change .rc file and confirm task profile is applied
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I3e06e25a75cf79674d8381b3356c64790fd5a597
Missed callbacks if connected displayDevice is not powered on
Bug: 153112115
Test: build, boot, SurfaceFlinger_test
Change-Id: Idb89eebe70535d9bf4ca7a067d8aac10037e1d67
InputClassifier will now play a more active role in managing the
lifecycle of MotionClassifier.
In the previous version of the code, we had a circular reference:
MotionClassifier owned a wp<InputClassifier>, that sometimes got
promoted to sp<>.
But the InputClassifier was the official owner of MotionClassifier, and
owned a unique_ptr<MotionClassifier>.
The owner of InputClassifier in real code is InputManager, and in test
code, it's the test class. When the owner of InputClassifier destroyed
InputClassifier, this could sometimes happen at the time when the
MotionClassifier also held a reference to the InputClassifier. That
meant that the proper owner of InputClassifier was not invoking the
destructor.
Instead, the MotionClassifier was invoking the InputClassifier
destructor.
To fix the situation, we now do the following:
1. InputClassifier will never die before MotionClassifier.
2. MotionClassifier constructor is now allowed to block. It would block
for some time because calling getService takes a while. To account for
this, InputClassifier launches a new thread to create MotionClassifier.
3. When MotionClassifier is ready to process events, InputClassifier
updates mMotionClassifier, which makes it non-null.
4. We now create a separate death recipient, which is co-owned by
InputClassifier and MotionClassifier. This is done so that the refcount
of the deathrecipient does not affect the refcount of InputClassifier,
and thus enforces the ownership of InputClassifier by the InputManager.
Now, no one can call ~InputClassifier except for its real owner.
5. MotionClassifier will subscribe the death recipient to the death of the
HAL. InputClassifier will delete MotionClassifier if HAL dies.
MotionClassifier no longer holds on to the death recipient.
6. We move the loop of the MotionClassifier thread to focus only on
processing events. That thread will no longer do any initialization.
7. Remove the thread check inside MotionClassifier. It isn't really
useful, now that there's only 1 function for the entire thread.
Ownership summary: Both InputClassifier and MotionClassifier own
DeathRecipient. DeathRecipient has a reference to InputClassifier. Thus,
we must guarantee that DeathRecipient dies before InputClassifier.
InputClassifier owns MotionClassifier. This is OK, since even if
InputClassifier dies, it will first delete MotionClassifier. That will
cause MotionClassifier to release 1 refCount from DeathRecipient. That
means the only reference remaining to DeathRecipient will be inside
InputClassifier, so InputClassifier will always be alive until
DeathRecipient is dead. Similar argument applies if MotionClassifier and
DeathRecipient die in different order (as observed from
InputClassifier).
Tests:
1) Manually running inputflinger_tests on cuttlefish:
build/launch cuttlefish using go/acloud
m inputflinger_tests
adb push out/target/product/vsoc_x86/data/nativetest/inputflinger_tests/inputflinger_tests /data/nativetest/inputflinger_tests/inputflinger_tests
adb shell
/data/nativetest/inputflinger_tests # ./inputflinger_tests --gtest_filter=*InputClassifierTest* --gtest_repeat=1000 --gtest_break_on_failure
2) Boot flame and open logcat. Observe in logcat:
StartInputManagerService took to complete: 2ms
Previously, in synchronous approach ( b/130184032) it was
about 100 ms (so we did not regress).
3) Kill the HAL while system_server is running, and dumpsys input before
and after:
adb shell dumpsys input (observe that MotionClassifier is non-null on flame)
adb shell -t killall android.hardware.input.classifier@1.0-service
adb shell dumpsys input (observe that MotionCLassifier is null)
Bug: 153022912
Test: see "Tests" section above
Change-Id: Ic76b82bd5f2cd374e3b001400eb495ca36de7353
Merged-In: Ic76b82bd5f2cd374e3b001400eb495ca36de7353
(cherry picked from commit 1652397ab7)
The format that's passed into BufferQueueLayer creation is meant to
define what format the buffers should have that are dequeued from the
consumer. If the client submits its own buffers, they can have any
pixel format. Therefore, the format from the activeBuffer should be used
when determing opacity since that's the information about the buffer
that will be rendered.
Bug: 152162496
Test: dumpsys SurfaceFlinger
Test: LayerTypeAndRenderTypeTransactionTest#SetBufferFormat
Change-Id: Ifdaa43c28c78ef96a2e8ea4fcbb9886a6227df4d
Merged-In: I4295b837369b8ca8918d8398a29cab133a47cbf7
Signed-off-by: wukui1 <wukui1@xiaomi.com>
Some of SurfaceFlinger tests such as SurfaceInterceptorTest requires
root access as they use sf backdoor interface.
Test: adb unroot; atest SurfaceFlinger_test
Bug: 151830811
Bug: 147527408
Change-Id: Ie144891f1c413a18b705f560d70d23041d36772b
Merged-In: Ie144891f1c413a18b705f560d70d23041d36772b
When config multi display config in display driver, the active
config in java framework is not same as SF. Without the Changed
flag the active config can not report to java framework.During
the booting, will set active config and report to java framework,
when boot finished, it may change the active config, so we should
add the Changed flag, and report java framework.
Test: make, take a photo, record a video and play video,
run vts testRefreshRate
adyabr@ Note: This fix is not needed on master as we are not
changing the refresh rate in bootFinished. Added Merged-In to reference
the change on master.
Change-Id: I2e48640f48a14bc044884c2e834af53e9a87ef13
Merged-In: I5bb964572d93e5cb78d7b75054b900917be563b0
Signed-off-by: luochaojiang <luochaojiang@xiaomi.com>
SurfaceFlinger requires CAP_SYS_NICE which is set in
libcutils/fs_config.cpp. This is the old way of setting capabilities
and new the way is to set it directly on surfaceflnger.rc
Test: adb shell /data/nativetest64/SurfaceFlinger_test/SurfaceFlinger_test
Test: adb shell stop surfaceflinger && adb shell start surfaceflinger
Bug: 147271477
Change-Id: I680509a385928a9c929d4fe4857118af219e2b13
Remove the details of KeyEvent and MotionEvent logs.
Bug: 139945049
Test: Tested on a device, the input functions work as expected and input
event logs are not leaked to dumpsys on user builds.
Change-Id: I98c9c375f18963177bf0c1d8829a217b4ad4acc6
Merged-In: I98c9c375f18963177bf0c1d8829a217b4ad4acc6
Add a check for ro.debuggable in before adding the details of KeyEvent and MotionEvent to logs.
Bug: 139945049
Test: Tested on a device, the input functions work as expected and input
event logs are not leaked to dumpsys on user builds.
Change-Id: I98c9c375f18963177bf0c1d8829a217b4ad4acc6
Merged-In: I98c9c375f18963177bf0c1d8829a217b4ad4acc6
mAllowedDisplayConfigs should be protected by mStateLock when changing
it from the main thread in setAllowedDisplayConfigsInternal() as it is
being read by Binder threads in getAllowedDisplayConfigs().
Test: call setAllowedDisplayConfigs() and getAllowedDisplayConfigs()
from backdoor using different threads.
Bug: 142850581
Change-Id: I569e75968aea676c96fbc648140ac49a165ffb69
Merged-In: I569e75968aea676c96fbc648140ac49a165ffb69
Previously, the two ActiveConfigInfo fields in SurfaceFlinger are
uninitialized upon construction, and when run with debugging code that
slows down open, we reliably hit a case where setRefreshRateType is
called on an uninitialized RefreshRateType, leading to explosion.
Test: booted with libfdtrack
Change-Id: I14520775f8660fee6545d8a354a04ed3674a1597
Currently the tracing log takes the current timestamp for the log entry.
However, the tracing start after the frame is composed. On winscope
this result in the trace entry being linked to the incorrect video
frame (screenrecord). Now we obtain the frame composition time (before
the frame is send to the video recorder) and use this time for the log
entry.
Test: Log a SF trace and screen recording. Open both on winscope.
Change-Id: I81a88ef7a81a084f2ecf75bf5574a1118301a48e
Check if scale is 0 before trying to apply it on the window scale.
Bug: 137560795
Bug: 139945549
Test: Set Window Scale Animation to off from developer options menu
Change-Id: Id372d75de5787f62a9cce7c22699216e135bd0f6
Merged-in: I7ae84e2838b1562ff62cdd94484bedba954e1f33
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Revert the debug patch as layer seems to ve valid.
Instead validate the input to avoid an overflow.
Bug: 137560795
Bug: 139945549
Test: boot
This reverts commit 38172ad8cf.
Merged-in: Ia1687bca84361dc8f665b9c0f893b8f40c5362e1
Change-Id: I07905d1e69b8c0a7dd23e620252fc7c133ed666e
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
