The distance max used in the MotionRange is calculated
incorrectly.
Looks like a copy-and-paste error.
Change-Id: I2b6daab088df0fb69e05682b67ca33524ff35987
Bluetooth devices can be renamed by the user. Make the
input system aware of the user-specified name and transparently
pass it down to applications. This enables the keyboard
layout picker Settings UI to use device names that are
consistent with what the user set in the Bluetooth UI.
Bug: 6363157
Change-Id: I8eea26ce2c69c2a3f09c8de02e9e847610e0419c
The system bar uses input event injection to inject BACK keys
into the application. If the receiving application ANRs, we
used to clear the touch state unconditionally. Doing so would
prevent the system bar from receiving the ACTION_UP event so
the back button would continue to appear pressed until pressed
again.
Now we are more careful to only remove the specific ANR'd
window from the touch state. Other windows should continue
to receive touch events as usual.
Change-Id: If86bfc323e2c7aed82ca1334bc67da649953168f
Added support for mapping both scan codes and HID usages to
KeyLayoutMap and KeyCharacterMap. Keyboard overlays can
now influence how key events are mapped to key codes.
Bug: 6110399
Change-Id: I6619fd2d3e1337c55928f89869dbc45b535c7ccf
Added the concept of a keyboard layout overlay, which is
a key character map file that has "type OVERLAY".
Added support for loading keyboard layout overlays from
resources dynamically. The layouts are reloaded whenever they
are changed in the Settings application or an application
is installed. This is somewhat more aggressive than necessary
so we might want to optimize it later.
Before system-ready, the input system uses just the generic
keyboard layouts that are included on the device system image.
After system-ready, it considers the user's selected keyboard
layout overlay and attempts to load it as necessary. We need to
wait until system-ready before doing this because we need to
be in a state where it is safe to start applications or access
their resources.
Bug: 6110399
Change-Id: Iae0886d3356649b0d2440aa00910a888cedd8323
Added a getVibrator() method to InputDevice which returns a Vibrator
associated with that input device. Its uses the same API as the
system vibrator which makes it easy for applications to be modified
to use one or the other.
Bug: 6334179
Change-Id: Ifc7f13dbcb778670f3f1c07ccc562334e6109d2e
This change allows the InputManager to keep track of what input
devices are registered with the system and when they change.
It needs to do this so that it can properly clear its cache of
input device properties (especially the key map!) when changes
occur.
Added new API so that applications can register listeners for
input device changes.
Fixed a minor bug in EventHub where it didn't handle EPOLLHUP
properly so it would spam the log about unsupposed epoll events
until inotify noticed that the device was gone and removed it.
Change-Id: I937d8c601f7185d4299038bce6a2934fe4fdd2b3
Added handling for EV_MSC / MSC_SCAN which typically reports
the HID usage associated with a key. This will enable key maps
to map keys with HID usages that Linux does not natively recognize.
Removed keyCode and flags fields from EventHub RawEvent since
they don't necessarily make sense in isolation now that we
pay attention to HID usage codes too.
Removed the fallback code for mapping keys and axes. In practice,
an input device should be self-sufficient. We should not ever
need to look at the built-in keyboard's key map. In fact, there
usually isn't a built-in keyboard anyhow. This code was originally
working around a problem where we weren't loading the key map
for touch screens with virtual keys, which has long since been fixed.
Change-Id: I0a319bdec44be9514f795526347397e94d53a127
Instead of each application loading the KeyCharacterMap from
the file system, get them from the input manager service as
part of the InputDevice object.
Refactored InputManager to be a proper singleton instead of
having a bunch of static methods.
InputManager now maintains a cache of all InputDevice objects
that it has loaded. Currently we never invalidate the cache
which can cause InputDevice to return stale motion ranges if
the device is reconfigured. This will be fixed in a future change.
Added a fake InputDevice with ID -1 to represent the virtual keyboard.
Change-Id: If7a695839ad0972317a5aab89e9d1e42ace28eb7
The purpose of the input device descriptor is to make it possible
to associate persistent settings for each input device, such as the
keyboard layout.
The descriptor is a hash of the information we have about the
device, such as its vendor id, product id, unique id, name,
or location.
Bug: 6110399
Change-Id: Idb80f946819b3f0dbf4e661bb0a753dbc2b60981
On reflection, only key events need to be serialized.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I028b4eac97497d012036cb60ffbac4cb22d3966c
To support this feature, the input dispatcher now allows input
events to be acknowledged out-of-order. As a result, the
consumer can choose to defer handling an input event from one
device (because it is building a big batch) while continuing
to handle input events from other devices.
The InputEventReceiver now sends a notification when a batch
is pending. The ViewRoot handles this notification by scheduling
a draw on the next sync. When the draw happens, the InputEventReceiver
is instructed to consume all pending batched input events, the
input event queue is fully processed (as much as possible),
and then the ViewRoot performs traversals as usual.
With these changes in place, the input dispatch latency is
consistently less than one frame as long as the application itself
isn't stalled. Input events are delivered to the application
as soon as possible and are handled as soon as possible. In practice,
it is no longer possible for an application to build up a huge
backlog of touch events.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
Minor tweak to the dispatcher to handle as many finished signals
in a receive callback as possible instead of going back to
the Looper and waiting for the next poll() to hit the callback
again.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I8471107371693e21ce8ce7cca1e8d79ba4ca2351
This change enables the input dispatcher to send multiple touch
events to an application without waiting for them to be acknowledged.
Essentially this is a variation on the old streaming optimization
but it is much more comprehensive. Event dispatch will stall as
soon as 0.5sec of unacknowledged events are accumulated or a
focused event (such as a key event) needs to be delivered.
Streaming input events makes a tremendous difference in application
performance. The next step will be to enable batching of input
events on the client side once again.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I025df90c06165d719fcca7f63eed322a5cce4a78
The information gathered here will no longer be valid once we
start dispatching multiple events at a time to the same connection.
Moreover, we are more concerned with end-to-end latency, which we
can measure with sufficiently high accuracy in other ways.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I49a0c9876b64af56b40e96e0d98c45f325da2a73
The dispatcher no longer needs to track which connections are
active except perhaps for diagnostic purposes, so we might as well
remove this code.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: Ibadc830b7b792a59b9244d0a6e85f320c4947109
Since we no longer stream events to the application, we don't need to
keep the current list of input targets around longer than it takes
to begin the dispatch cycle.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I5824b04e564c8a4dec991598292441e46c331905
Since we will not longer be modifying events in place, we don't need
to use an ashmem region for input. Simplified the code to instead
use a socket of type SOCK_SEQPACKET.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I05909075ed8b61b93900913e44c6db84857340d8
Don't worry, these features will be moving to a different part of
the pipeline. We're just getting them out of the way for now so
we can make deeper changes to how the input dispatcher works.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: If97de923c8165776882eef23f5204cc448dad0fc
Try harder to test for liveness. There are situations where
the lock might not be held but the input system is stuck in
a callback into the window manager policy that has hung.
Bug: 5094994
Change-Id: Iff88655512a5dc8bbb4615be65f4115e975c020b
The new ioctls will enable the system to be more selective about
which evdev devices should hold wake-locks when their queue is
non-empty.
For now, we enable this behavior for all configured input devices,
which is more or less the status quo. This change is mainly about
ensuring that the system still works correctly when combined with
a newer kernel that supports the suspend-block ioctls. We can
tweak this behavior later.
Change-Id: I8ff69aa5198903f7e2998772a339313df17c0f24
This optimization is no longer needed now that the kernel evdev
driver's poll() implementation only wakes up the poll after
the final sync.
Change-Id: If237776861df9cfac3086e744d3bbf3484d4c53b
