The stylus eraser appeared not to work, i.e. Android did not respond to
input from the eraser. It turned out that all input except stylus input
is rejected when palm rejection is activated. The problem was that the
eraser itself activates palm rejection when it hovers. The solution is
to allow the eraser during palm rejection. This solution makes sense
because the eraser input works in the exact same way as normal stylus
input.
Change-Id: I9c7451112ce7dbca14a1e1694eedca2d4ed041a1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAldVtQ8ACgkQ6K0/gZqxDnhIVgCfWRMpjlr3RQ8yoizXrd1JT2e8
M6kAn2lFAPOBl7D6M28oTaPBQpLrZMdF
=kdz+
-----END PGP SIGNATURE-----
Merge tag 'android-6.0.1_r46' into HEAD
Android 6.0.1 release 46
# gpg: Signature made Mon 06 Jun 2016 10:38:23 AM PDT using DSA key ID 9AB10E78
# gpg: Can't check signature: public key not found
Due to more complex window layouts resulting in lots of overlapping
windows, the policy around FLAG_WINDOW_IS_OBSCURED has changed to
only be set when the point at which the window was touched is
obscured. Unfortunately, this doesn't prevent tapjacking attacks that
overlay the dialog's text, making a potentially dangerous operation
seem innocuous. To avoid this on particularly sensitive dialogs,
introduce a new flag that really does tell you when your window is
being even partially overlapped.
We aren't exposing this as API since we plan on making the original
flag more robust. This is really a workaround for system dialogs
since we generally know their layout and screen position, and that
they're unlikely to be overlapped by other applications.
Bug: 26677796
Change-Id: I9e336afe90f262ba22015876769a9c510048fd47
* The visible pointer icon when hovering or drawing with the stylus is
quite annoying when trying to actually draw with it. Turn it off by
default and add an option to turn it on.
Forward Port from CM-11.0
Change-Id: Ie4e9e6bcc48803b195d1615d83d6e36d663cc33a
Android 5.0 cannot form multitouch events from multiple input
devices. So it is not possible to report one touchpoint from the
stylus position and, at the same time, another touchpoint from a
finger touch. Instead, when a new input device starts up the currently
active input is cancelled. This is highly undesirable while writing
with the pen.
The easiest solution is to ignore non-stylus touch events while the
stylus is within range (hovering) of the touchscreen. For example,
N-trig digitizers implement this in hardware. But wacom digitizers do
report pen data simultaneously with touch data. This patch disables
(non-stylus) touch input within 50ms of stylus data. On my Galaxy
Note this is necessary to make stylus input usable.
Original commit by vbraun:
b9cb296130
Change-Id: I97f26369826e96c97461c8ae188f1c64dec1b4d3
Add handling of "replacement" key events in InputReader and EventHub by
consulting device's character key map (if exists) for presence of
replacement key code for given get code and meta state combination,
before passing it to InputDispatcher.
This enables defining special keys, such as ESC, on keyboards lacking
enough physical keys, via combination of normal keys and modifiers, for
example AltR + 1 => ESC.
Bug: 24504154
Change-Id: I7e36104808bedcf724436c1fbb63d37c35cca8af
This reverts commit 9b70ab7a3cb260205e81e40ba181a86710d2eb95, reversing
changes made to 153008efb5a00ed3c18d588ce15f90d2442a9786.
Bug: 24302031
Change-Id: Ia746381b30be3b54cb646ed412b7271962c4b02a
* commit '7c000280a57f352c2485dcaea1d5bfe20f7bfe63':
Fix input tests to work with new MotionEvent member
Revert "Revert "Add new MotionEvent actions for button press and release.""
Introduce ACTION_BUTTON_PRESS and ACTION_BUTTON_RELEASE as actions to
signal a button press or release. If these actions happen
simulanteously with a DOWN or UP event then they're explicitly
ordered to happen after the DOWN or preceding the UP in order to send
them to the most recently targeted view.
Also, introduce new stylus button constants that differ from the
constants we use for mouse buttons.
Bug: 20704355
Change-Id: Ib960a5004db5429ad2fc8db020704773e2978327
Occasionally we'll receive the stylus up signal (pressure = 0) before
we receive the touch screen up signal. Rather than giving pointer a
pressure value of 0 (which is one of the signals of hovering) or
falling back to the touchscreen pressure values (which would make for
an inconsistent stream), use the previous pressure value which should
always be non-zero for a stream of fused data.
Bug: 20449776
Change-Id: I71eb97e7c4ea53e42b0eb54fc1f8ae7f89aad9d1
Even when there isn't movement on the touchscreen we should produce
events for pressure and button state changes generated by external
stylii.
Change-Id: I9fd7ba85902d5d6bfb28d5e5ff5d8f340a94c2bf
Temporarily increase the stylus timeout while we figure out where the
delay in BT information is coming from.
Change-Id: I27ab5a4db4ad14358c6e6803961612420371fce9
Sometimes stylus data will be delayed by 30 - 40ms. By increasing the
timeout we pretty much always pick up stylus data and the touch
latency feels surprisingly small.
Change-Id: I39f5b9037ce0444b1e957149d3f1c3a3137804cb
This prevents us from dropping any states (namely the pressure
transition from non-zero to zero) if we get the touch up before we
get the stylus data.
Change-Id: Ifc198628d35b7079dc5ec23d81f9681d122757a0
To avoid nan or infinity when orientation value is used for
calculation without being initialized, check mOrientedRanges.haveOrientation
value before using mOrientedRanges.orientation.min or .max value.
Change-Id: I68ed9ab36819c5faa6422e9f061e1275aeed11e3
Signed-off-by: Baik Han <baik.han@lge.com>
