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

* 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)

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 687e58fa)

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

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 ae2e3c74
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

Merge "Plumb through Output::getSkipColorTransform() into CachedSet, to 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

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 5ed8eaab)

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

After some recent changes, the touchscreen input device has source that
is a combination of SOURCE_TOUCHSCREEN and SOURCE_STYLUS.

Before this CL, this source is rejected, and therefore palm rejection
feature is not enabled.

With this CL, any source that has SOURCE_TOUCHSCREEN is allowed. That
also means that we potentially would invoke the model for stylus events,
especially if simultaneous touch and stylus are enabled.

The model, however, was never trained on stylus, and is not designed to
work with it. In preparation to upcoming simultaneous touch+stylus
feature, in this CL we also remove the stylus pointers before sending
the data to the model.

The only case where we need to be careful is pointer-down and pointer-up
events with stylus. In this CL, we drop these events, which should be a
no-op from the palm rejection model's perpective.

Bug: 241935838
Test: atest libpalmrejection_test inputflinger_tests
Change-Id: I760207a82807e03802e72a318fca8b97a4fd7a24

The function 'processMotion' has gotten too long. To make it easier to
reason about, separate some code from the center of the function into a
new function.

Unfortunately, this new function will have side-effects, but it's still
easier to understand and reduces the number of local vars.

There's no functional change in this CL.

Bug: 241935838
Test: atest inputflinger_tests
Change-Id: I2157798b70299659791ae6ef85b2394e9130b4b3

For short strokes, the palm rejection code has a heuristic - large
touches are canceled.
Since the behaviour is currently present, let's add an integration test
for it.

Separately, we will also remove 'getLinuxToolType' here because
tool_type is not used in the palm rejection code.

However, tool_code is used in that code. So let's add getLinuxToolCode
instead. This piece does not affect the behaviour of the palm rejection
model, but it makes our inputs more correct.

Bug: 241935838
Test: atest inputflinger_tests
Change-Id: Ied9e185bdfc6e892cf3a1069b98101ca8ae9c74b

Currently AOD is bugged and does not always match refresh rate between
SF and HWC, which disrupts ADPF hint sessions in SF which are sensitive
to refresh rate (b/218066882). This patch disables ADPF CPU hints for
the AOD case until this issue is resolved.

Bug: b/240619471
Test: atest libsurfaceflinger_unittest:libsurfaceflinger_unittest.SurfaceFlingerPowerHintTest
Change-Id: I4fa617a108f14da9df278c4a449795363ec29cf3
Merged-In: I4fa617a108f14da9df278c4a449795363ec29cf3
(cherry picked from commit ba8d15a1)

After some testing, it has become clear that the rate limiter is
unhelpful and possibly harmful for performance. Rate limiting also
happens on PowerHAL side now, rendering this somewhat redundant,
so this patch disables rate limiting and hint batching on SF side.

Bug: b/241973353
Bug: b/195990840

Test: manual
Change-Id: I7ae43d7c9bfc95c94963ae4852d3190ee987c9aa
(cherry picked from commit 111de034)

Currently timing for hint sessions in SurfaceFlinger do not work for
multi-display case with virtual displays (eg: Android Auto). This
patch fixes that by tracking true sf present completion time to
supplement hwc time tracking in the sf main thread deadline case.

Bug: b/241465879

Test: manual

Change-Id: I169dd4f4afd2223ed0a648440d5f59dc19dc07f6
(cherry picked from commit 1809d90e)

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



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

Replace the existing implementation using getVsyncPeriodFromHWC with
vsync data from the current display mode

Bug: b/240621816
Test: manual
Change-Id: Ie70d17400481eed31595a5f1ae4296c4df9d4071
(cherry picked from commit 1151f467)

Composition cache checks the buffer id with the client
composition request to see if we can reuse a buffer if the
request has not changed. We never bothered with a fence
here because by the time the cache was accessed, we
would have sent the buffer to the display at least once.

With composition strategy prediction, our assumption
breaks. There is a chance we fail to predict the strategy
but the new strategy results in the same client
composition request so we can reuse the client
composition work that was submitted in the beginning
of the frame.

Test: Repro steps in bug
Test: go/wm-smoke
Bug: 239944175

Change-Id: Idbe6a9bb3bba889aa7b459b1046890ea3960982f

Currently, we have no way to debug the palm rejection operation in real
time. On some devices, we are observing touches rejected unreasonably.

For improved debugging, provide a way to turn on the logs at runtime.

Sample logs:
07-29 20:50:51.938 21364 21461 D UnwantedInteractionBlocker: notifyMotion: NotifyMotionArgs(id=437279320, eventTime=681206765436000, deviceId=4, source=TOUCHSCREEN, action=MOVE, pointerCount=2 pointers={0: id=0 x=1998.0 y=732.0 pressure=1.0 major=78.0 minor=78.0 orientation=1.6}, {1: id=1 x=1651.0 y=705.0 pressure=0.5 major=14.0 minor=14.0 orientation=1.6}, flags=0x00000000)
07-29 20:50:51.939 21364 21461 D UnwantedInteractionBlocker: Filter: touches = 0 : InProgressTouchEvdev(x=1998, y=732, tracking_id=0, slot=0, pressure=0.996094, major=78, minor=78, tool_type=0, altered=1, was_touching=1, touching=1)
07-29 20:50:51.939 21364 21461 D UnwantedInteractionBlocker: 1 : InProgressTouchEvdev(x=1651, y=705, tracking_id=1, slot=1, pressure=0.546875, major=14, minor=14, tool_type=0, altered=1, was_touching=1, touching=1)
07-29 20:50:51.939 21364 21461 D UnwantedInteractionBlocker: Response: slotsToHold = 00000000000000000000, slotsToSuppress = 00000000000000000011
07-29 20:50:51.939 21364 21461 I UnwantedInteractionBlocker: Palm detected, removing pointer ids {0, 1} after 656ms from NotifyMotionArgs(id=437279320, eventTime=681206765436000, deviceId=4, source=TOUCHSCREEN, action=MOVE, pointerCount=2 pointers={0: id=0 x=1998.0 y=732.0 pressure=1.0 major=78.0 minor=78.0 orientation=1.6}, {1: id=1 x=1651.0 y=705.0 pressure=0.5 major=14.0 minor=14.0 orientation=1.6}, flags=0x00000000)
07-29 20:50:51.939 21364 21461 D UnwantedInteractionBlocker: enqueueOutboundMotionLocked: NotifyMotionArgs(id=437279320, eventTime=681206765436000, deviceId=4, source=TOUCHSCREEN, action=CANCEL, pointerCount=1 pointers={0: id=1 x=1651.0 y=705.0 pressure=0.5 major=14.0 minor=14.0 orientation=1.6}, flags=0x00000020)
07-29 20:50:51.947 21364 21461 D UnwantedInteractionBlocker: notifyMotion: NotifyMotionArgs(id=1057496278, eventTime=681206774728000, deviceId=4, source=TOUCHSCREEN, action=MOVE, pointerCount=2 pointers={0: id=0 x=1996.0 y=732.0 pressure=1.0 major=78.0 minor=78.0 orientation=1.6}, {1: id=1 x=1651.0 y=705.0 pressure=0.5 major=14.0 minor=14.0 orientation=1.6}, flags=0x00000000)
07-29 20:50:51.947 21364 21461 D UnwantedInteractionBlocker: Filter: touches = 0 : InProgressTouchEvdev(x=1996, y=732, tracking_id=0, slot=0, pressure=0.996094, major=78, minor=78, tool_type=0, altered=1, was_touching=1, touching=1)
07-29 20:50:51.947 21364 21461 D UnwantedInteractionBlocker: 1 : InProgressTouchEvdev(x=1651, y=705, tracking_id=1, slot=1, pressure=0.542969, major=14, minor=14, tool_type=0, altered=1, was_touching=1, touching=1)
07-29 20:50:51.948 21364 21461 D UnwantedInteractionBlocker: Response: slotsToHold = 00000000000000000000, slotsToSuppress = 00000000000000000011

Bug: 239463037
Bug: 198472780
Test: looked at the logs with palm rejection enabled
Change-Id: I10e54bd0c4ca26fd6197b3ff0069f9799ea91ccf

The conversion of time to float causes weird behaviour. When the time is
received in palm rejection code, the time deltas do not match the
original values seen in Android.

Rather than debug the float conversion, switch to using integral values
for timestamps.
After the switch, printing the time difference shows the values as
expected.

Bug: 240168494
Test: printed diffs of timestamps inside palm rejection code
Test: atest inputflinger_tests
Change-Id: If6af45ba7740de4d70a300a45842bd3d6a069f40

It looks like we cache the remote configuration value in some instances,
so we'll resolve this by changing the value we use to enable/disable it,
and also remove the propagation criteria and use "experiments" and
"launches" instead.

Bug: 239675985
Test: flashed device and confirmed that palm rejection is disabled

Change-Id: I9c764ed3402d9244e6dd5928d3ca8388491f7175