| Age | Commit message (Collapse) | Author |
|---|
|
Removed old input dispatch code.
Refactored the policy callbacks.
Pushed a tiny bit of the power manager state down to native.
Fixed long press on MENU.
Made the virtual key detection and cancelation a bit more precise.
Change-Id: I5d8c1062f7ea0ab3b54c6fadb058c4d5f5a9e02e
|
|
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
|
|
Change-Id: Ib403de88f24bc1b6e5417732e3b69f89a5160bbc
|
|
Updated ScaleGestureDetector for framework deprecations.
|
|
We now only consider a device to be a default keyboard if its name
has "-keypad". A hack, but whatever.
Also add some debug logging for the input state to help identify such
issues in the future.
|
|
|
|
This is the framework part, moving classes around so the framework
no longer needs to link to android-common. Makes some APIs public,
others that didn't need to be public are private in the framework,
some small things are copied.
|
|
Several files were moved to android-common. Update all the references
to import those files from the new location.
|
|
Holding down the trackball now works.
Also fix a little API check warning from Intent.
Change-Id: Icb1f901535cb521917bf7f847a93c4ff7861d20e
|
|
Yet another configuration!
Change-Id: Idf7fafd338a2bebd4c305c131cd9b7ae4f906a5b
|
|
The touch location filtering hacks had a little problem.
Change-Id: Ib57366169c87f83af1adcc8b6a00dadc01582339
|
|
This was probably a side-effect of the divide by zero exception,
but we'll be safe anyway.
Change-Id: I875200febb9b3090d12f170066b2bea74c9f77f8
|
|
This introduces some hacks in the framework to try to clean up the
data we are getting from the touch screen. There are two main things
being done here:
1. Look for changes in position that are unreasonably large, and
ignore them. This is intended to eliminate the spurious jumps that
often happen when releasing.
2. Add some simple adaptive averaging of the touch data. If the
difference between the last and next point is large enough, we
disable the averaging; otherwise we average up to the last 5 points.
The goal is to get rid of the noise of small movements so that things
like taps don't look like short flings, while still responding quickly
to rapid movement.
For averaging pressure, we also weight each averaged coordinate by
the reported pressure at that point. This is intended to keep the
coordinates closer together during a release, when the pressure is
going down and the accuracy decreasing. It may also result in some
other interesting artifacts, but hopefully nothing problematic.
Change-Id: I1369e9ab015c406946a45c2d72547da9c604178f
|
|
Dr.No from mcleron.
Change-Id: Iaca2268684f83fe8757e64db0b0e047a19755311
|
|
The APIs for checking whether keys are held down now also look
at virtual keys.
However it turns out there is less than a second between the time we
start the input thread and check for safe mode, so there is not enough
time to actually open all of the devices and get the data from them
about the finger being down to determine if a virtual key is down.
So now you can also hold DPAD center, trackball center, or s to
enter safe mode. Also give some vibrator feedback.
Change-Id: I55edce63bc0c375813bd3751766b8070beeb0153
|
|
This takes care of allowing us to cancel the back button. The
back button is a bear because it is strewn all over the place --
everywhere you can close something, there is some code looking
for the back button that now needs to deal with being canceled.
The main things changed are activity (of course), dialog,
input method, search dialog. There are some other misc places
in the framework (and some I missed here that I will get in a
second pass).
To facility all of this, the key dispatching APIs now provide
a lot more support for dealing with looking for cancelled keys,
and incidentally also provide an actual API for catching long
key presses. This also helped clean up the code in PhoneWindow
where it deals with all of the combinations of key pressed and
releases. (And also allows people to override
Activity.onKeyLongPress() to provide a different long press
action for a standard key like search.)
And while I was doing this, I reworked how we detect long
presses by having this be part of the key event delivered by
the window manager. This should greatly reduce (hopefully
outright eliminate) the problems with long presses being
mis-detected when an application is being slow.
Change-Id: Ia19066b8d588d573df3eee6d96e1c90fdc19f57d
|
|
This addresses a few parts of the bug:
- There was a small issue in the window manager where we could show a window
too early before the transition animation starts, which was introduced
by the recent wallpaper work. This was the cause of the flicker when
starting the dialer for the first time.
- There was a much larger problem that has existing forever where moving
an application token to the front or back was not synchronized with the
application animation transaction. This was the cause of the flicker
when hanging up (now that the in-call screen moves to the back instead
of closing and we always have a wallpaper visible). The approach to
solving this is to have the window manager go ahead and move the app
tokens (it must in order to keep in sync with the activity manager), but
to delay the actual window movement: perform the movement to front when
the animation starts, and to back when it ends. Actually, when the
animation ends, we just go and completely rebuild the window list to
ensure it is correct, because there can be ways people can add windows
while in this intermediate state where they could end up at the wrong
place once we do the delayed movement to the front or back. And it is
simply reasuring to know that every time we finish a full app transition,
we re-evaluate the world and put everything in its proper place.
Also included in this change are a few little tweaks to the input system,
to perform better logging, and completely ignore input devices that do not
have any of our input classes. There is also a little cleanup of evaluating
configuration changes to not do more work than needed when an input
devices appears or disappears, and to only log a config change message when
the config is truly changing.
Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
|
|
This was a problem with not dealing well with how the driver was
reporting data in the old touch protocol.
Also fixed issue with not correctly rotating non-primary touches.
|
|
Signed-off-by: Iliyan Malchev <malchev@google.com>
|
|
The major things going on here:
- The MotionEvent API is now extended to included "pointer ID" information, for
applications to keep track of individual fingers as they move up and down.
PointerLocation has been updated to take advantage of this.
- The input system now has logic to generate MotionEvents with the new ID
information, synthesizing an identifier as new points are down and trying to
keep pointer ids consistent across events by looking at the distance between
the last and next set of pointers.
- We now support the new multitouch driver protocol, and will use that instead
of the old one if it is available. We do NOT use any finger id information
coming from the driver, but always synthesize pointer ids in user space.
(This is simply because we don't yet have a driver reporting this information
from which to base an implementation on.)
- Increase maximum number of fingers to 10. This code has only been used
with a driver that reports up to 2, so no idea how more will actually work.
- Oh and the input system can now detect and report physical DPAD devices.
|
|
The platform now knows how to deal with a platform key, which at this
point is "just like end call, but don't end a call."
Also improve the handling of virtual keys, to allow for canceling when
sliding off into the display and providing haptic feedback.
Finally fixes a bug where the raw x and y in motion event were not
always set which caused the status bar to not work.
|
|
The MotionEvent API should be fairly solid, but there is still a lot of
work to do in the input device code. In particular, right now we are
really stupid about watching how fingers change -- we just take whatever
the driver reports as down and dump that directly into the motion event.
The big remaning work is to assign pointer IDs so that applications have
help in determine which fingers go up and down, and adding support for
the official multi-touch driver protocol.
|
|
This will be used to avoid unnecessarily listening to data from sensors
that function as event devices.
Signed-off-by: Mike Lockwood <lockwood@android.com>
|
|
The kernel can now publish a property describing the layout of virtual
hardware buttons on the touchscreen. These outside of the display
area (outside of the absolute x and y controller range the driver
reports), and when the user presses on them a key event will be
generated rather than a touch event.
This also includes a number of tweaks to the absolute controller
processing to make things work better on the new screens. For
example, we now reject down events outside of the display area.
Still left to be done is the ability to cancel a key down event,
so the user can slide up from the virtual keys to the touch screen
without causing a virtual key to execute.
|
|
new file: core/java/android/os/LatencyTimer.java
modified: core/java/android/view/MotionEvent.java
modified: core/java/android/view/ViewRoot.java
modified: services/java/com/android/server/InputDevice.java
modified: services/java/com/android/server/KeyInputQueue.java
modified: services/java/com/android/server/WindowManagerService.java
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
