| commit | 9d93bac98fa52f953b43c48f94ae1add9b9b9fd1 | [log] [tgz] |
|---|---|---|
| author | George Burgess IV <gbiv@google.com> | Wed Dec 17 15:12:20 2025 |
| committer | Chromeos LUCI <chromeos-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Dec 18 23:46:19 2025 |
| tree | 6dda252b4a462947d67c3111a7e8c8e9736121cf | |
| parent | f00167d0fb518ef7663396a984f98ebdc0e33200 [diff] |
Makefile: prepopulate LINK_FLAGS with LDFLAGS This package's tests are breaking on sanitizer builders, since ldflags added by cros-sanitizers aren't making their way into linker commands here. Adding global LDFLAGS to LINK_FLAGS fixes this. BUG=b:467136157 TEST=`FEATURES=test emerge-amd64-generic chromeos-base/gestures` TEST= (on an amd64-generic board configured for ubsan) Change-Id: I15024c9b27356c69ddc8a1caf49727690d4b0d5c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/gestures/+/7268686 Tested-by: George Burgess <gbiv@chromium.org> Reviewed-by: Henry Barnor <hbarnor@chromium.org> Code-Coverage: Henry Barnor <hbarnor@chromium.org> Commit-Queue: George Burgess <gbiv@chromium.org>
The Gestures library takes input events from touchpads, mice, and multitouch mice, detects gestures, and applies quality improvements to the incoming data. It is used on ChromeOS and Android.
The Gestures library consumes hardware states, which describe the state of an input device at one instant in time. (These are represented by struct HardwareState.) For a touchpad, this is the set of touches currently down (including coordinates, dimensions, and orientations, if available) and the set of buttons currently pressed.
Hardware states flow up a stack of interpreter objects, each of which can modify them to improve data quality or report gestures that they have detected, which are represented by struct Gesture. Once a gesture is detected it passes back down the stack until it reaches the bottom, with each interpreter able to make modifications to it before it is reported to the user of the library.
The actual stacks used for different device types can be found in the relevant GestureInterpreter::Initialize... functions (e.g. InitializeTouchpad) in gestures.cc.
For example, a simplified touchpad stack might be made up of the following interpreters:
ImmediateInterpreter (the core of the touchpad stack, which detects gestures)PalmClassifyingFilterInterpreterScalingFilterInterpreterLoggingFilterInterpreterWhen a new hardware state is passed in to the library, it will first be passed to LoggingFilterInterpreter, which will add it to its activity log, and then pass it on unmodified to ScalingFilterInterpreter. ScalingFilterInterpreter will scale the values in the hardware state to be in mm, rather than whatever units and resolution the touchpad reported them in. Next, PalmClassifyingFilterInterpreter will look for any touches that look like they could be palms, and mark them with a flag. Lastly, ImmediateInterpreter will detect gestures from the remaining touches.
Any gestures that ImmediateInterpreter detects will then pass back down the stack. ScalingFilterInterpreter may apply a scale factor to them, and LoggingFilterInterpreter will add them to its activity log. Finally, the Gesture struct will be passed to the user of the library via a callback.
In addition to hardware states, the library also takes a struct HardwareProperties, which describes the unchanging capabilities of an input device. For a touchpad, this includes the ranges and resolutions of its X, Y, and orientation axes, as well as the maximum number of touches it can report simultaneously. This information is accessible to all interpreters in the stack.
Each interpreter can declare configurable parameters using gesture properties. These can include everything from simple booleans controlling whether scrolling is reversed, to arrays describing acceleration curves to be applied to pointer movement.